Results 1 to 3 of 3

Thread: SSSD response inconsistent with Active Directory integration

  1. #1

    Question SSSD response inconsistent with Active Directory integration

    We have integrated the SUSE Linux (version 11 Patch level 2) with the Microsoft Active Directory(AD) using the SSSD utility(version 1.5.11) for facilitating the AD

    Users and Groups on Linux host. We have added the "sss" as the sources for "passwd", "group", "shadow" within the "/etc/nsswitch.conf" file.

    We are facing some inconsistency issues from SSSD while fetching the User/Group information through "id" command. It appears that we are facing this inconsistency only

    while SSSD interacts with Domain Controller with version Windows Server 2008 R2, and not while SSSD is interacting with Windows Server 2003 R2 based domain controller.
    Please find the response/output from Linux host (terminal) as below:

    1) For Windows Server 2008 R2 based Domain Controller
    controller@indelappvm02:~> id user_hadoop_3001
    uid=2763510(user_hadoop_3001) gid=100513(Domain Users) groups=100513(Domain Users),2816151(Mygroups-hadoop-GED_KPI),2115887,2812298(Mygroups-hadoop-

    DAS_ANALYST),2812208(Mygroups-hadoop-CV_US),2809985(Mygroups-hadoop-DB_TICKET),2816149(Mygroups-hadoop-TLM),2827118(Mygroups-hadoop-DAS_ALL),2819228(Mygroups-hadoop-

    IMAGINE_GED_LON),2820642(Mygroups-hadoop-IMHOTEP),2812212(Mygroups-hadoop-

    OPEX),2024985,2356240,2358411,2100126,2115932,2099 968,2337579,1743308,1463380,2100236,1881724,170745 6


    2) For Windows Server 2003 R2 based Domain Controller
    controller@indelappvm02:~> id user_hadoop_3001
    uid=2763510(user_hadoop_3001) gid=100513(Domain Users) groups=100513(Domain Users),2816151(Mygroups-hadoop-GED_KPI),2812208(Mygroups-hadoop-CV_US),2819228(Mygroups-

    hadoop-IMAGINE_GED_LON),2827118(Mygroups-hadoop-DAS_ALL),2812298(Mygroups-hadoop-DAS_ANALYST),2809985(Mygroups-hadoop-DB_TICKET),2816149(Mygroups-hadoop-TLM),2820642

    (Mygroups-hadoop-IMHOTEP),2812212(Mygroups-hadoop-OPEX)


    Below is the configuration of /etc/sssd/sssd.conf

    ################################################## ############
    [sssd]
    debug_level = 5
    config_file_version = 2
    reconnection_retries = 3
    sbus_timeout = 10
    services = nss,pam
    domains = mytest

    [nss]
    debug_level = 5
    filter_groups = root
    filter_users = root
    reconnection_retries = 3
    entry_cache_timeout = 300
    entry_cache_nowait_percentage = 75

    [pam]
    debug_level = 0
    reconnection_retries = 3
    offline_credentials_expiration = 0
    offline_failed_login_attempts = 0
    offline_failed_login_delay = 5

    [domain/local]
    id_provider = local
    min_id = 1
    max_id = 499
    enumerate = False

    [domain/mytest]
    debug_level = 9
    description = Kerberos 5 domain with Active Directory servers
    id_provider = ldap
    auth_provider = krb5
    access_provider = ldap
    min_id = 500
    enumerate = False
    timeout = 10
    cache_credentials = True
    entry_cache_timeout = 300
    krb5_canonicalize = False

    # General -----------------------
    # LDAP
    ldap_uri = ldap://inddelvm25.mytest.com
    ldap_default_authtok_type = password
    ldap_default_bind_dn = linux@mytest.com
    ldap_default_authtok = *******

    ldap_id_mapping = True
    ldap_user_objectsid = objectSid
    ldap_idmap_range_min = 100000
    ldap_idmap_range_max = 2000100000
    ldap_idmap_range_size = 2000000000

    ldap_access_filter = (cn=*)
    ldap_user_search_base = DC=mytest,DC=com
    ldap_group_search_base = DC=mytest,DC=com?subtree?(|(CN=Mygroups-hadoop-*)(CN=Domain Users))
    ldap_referrals = False
    ldap_search_timeout = 20
    ldap_network_timeout = 20

    # KRB5
    chpass_provider = krb5
    ldap_force_upper_case_realm = True
    krb5_server = inddelvm25.mytest.com
    krb5_realm = mytest.com
    krb5_store_password_if_offline = True
    krb5_auth_timeout = 15

    # Mapping --------------------
    ldap_schema = ad
    ldap_user_object_class = user
    ldap_group_object_class = group
    ldap_user_name = sAMAccountName
    ldap_group_name = sAMAccountName
    ldap_id_use_start_tls = False
    krb5_kdcip = inddelvm25.mytest.com

    ################################################## ############

    Can somebody suggest for how do we make SSSD to work with Windows Server 2008 R2 based domain controller.

  2. #2

    Re: SSSD response inconsistent with Active Directory integration

    Duplicate of post in server forum:

    http://forums.suse.com/showthread.php?t=5332

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  3. #3

    Re: SSSD response inconsistent with Active Directory integra

    After giving this some additional thought, I would like a second bite at the apple so to speak.

    Considering the differences between Windows 2003 R2 and Windows 2008 R2 that could impact LDAP search returns in this manner.

    1) The schema used by each DC.

    The NIS (UNIX/LINUX POSIX) attributes and values were introduced as part of RFC 2307 support that was added in Windows Server 2003 R2 and have remain unchanged through new versions of AD on the Windows server platform.

    2) The compatibility level configured for each DC.

    This could have an impact, but is untested by me. Regardless, if both DCs are members of the same domain and unless there is an operational need for them the be different, best practice would have them be at the same compatibility level.

    3) The size of your AD environment (the enumeration of objects and attributes).

    There are two things that could cause this if your environment is very large (say, over 10,000 objects).

    a) The SSSD "enumeration" directive.
    If "enumeration = true" the daemon will attempt to cache everything it can read from the target directory to enhance local performance. However if the target user store is large the load on the back end is increased and the local caching facilities will likely become overwhelmed and return inconsistent results. Setting "enumeration = false" basically puts the server into a cache on query mode, which is a better idea in nearly all use cases really.

    That said the SSSD config shown has "enumeration = false",so that seems to not be the case here. (It may be worth while to put the daemon in debug mode, add "debug_level=7" to the domain section of the sssd.conf file and check the log to verify the setting is in play).

    b) LDAP paging constraints
    There is a difference in the LDAP query policies between 2003/2008 R2. Basically 2003 R2 has no limits and 2008 R2 limits LDAP responses to 5000 attributes to prevent the DC from being overwhelmed.

    Perhaps this is where the issue lies.

    To test you could:

    - Adjust/retest the SSSD daemon configuration and retest. The default daemon LDAP paging configuration directives are displayed below:

    ldap_page_size has value 1000
    ldap_disable_paging is FALSE

    - Adjust/retest the LDAP query policy settings for your Windows 2008 R2 DC

    - Use LDAP search base filter directives, objectClass filters or explicit SSSD access control directive filters to reduce the enumeration of objects and attributes returned in a search . The downside here being in large complex environments filtering becomes limiting from a system functionality and use case perspective pretty quickly. Hence my preference for the next option.

    - Join the target box to the domain, configure SASL/GSSAPI authentication and allow them to perform searches using native/inband security and protocols that should mitigate most of the normal LDAP constraints.


    -- lawrence

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •