# SSSD response inconsistent with Active Directory integration **URL:** \ **Category:** SLED Configure-Administer\ **Created:** [September 23, 2014, 5:19am UTC](https://forums.suse.com/t/sssd-response-inconsistent-with-active-directory-integration/26114 "2014-09-23T05:19:05Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![abhi\_dit2006](https://avatars.discourse-cdn.com/v4/letter/a/ec9cab/32.png) [@abhi\_dit2006](https://forums.suse.com/u/abhi_dit2006)\ **Post date:** [September 23, 2014, 5:19am UTC](https://forums.suse.com/t/sssd-response-inconsistent-with-active-directory-integration/26114/1 "2014-09-23T05:19:05Z")
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](mailto: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](http://inddelvm25.mytest.com) krb5\_realm = [mytest.com](http://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](http://inddelvm25.mytest.com) ############################################################## Can somebody suggest for how do we make SSSD to work with Windows Server 2008 R2 based domain controller. ---
**Author:** ![ab1](https://avatars.discourse-cdn.com/v4/letter/a/d2c977/32.png) [@ab1](https://forums.suse.com/u/ab1)\ **Post date:** [September 23, 2014, 6:07am UTC](https://forums.suse.com/t/sssd-response-inconsistent-with-active-directory-integration/26114/2 "2014-09-23T06:07:33Z")
Duplicate of post in server forum: [http://forums.suse.com/showthread.php?t=5332](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… ---
**Author:** ![Lawrence1](https://avatars.discourse-cdn.com/v4/letter/l/e56c9b/32.png) [@Lawrence1](https://forums.suse.com/u/Lawrence1)\ **Post date:** [June 20, 2016, 3:46pm UTC](https://forums.suse.com/t/sssd-response-inconsistent-with-active-directory-integration/26114/3 "2016-06-20T15:46:57Z")
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