SSSD response inconsistent with Active Directory integration

SUSE Linux Enterprise Desktop SLED Configure-Administer
1

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,2099968,2337579,1743308,1463380,2100236,1881724,1707456

  1. 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

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

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.

  1. 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.

  1. 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