SSSD response inconsistent with Active Directory integration

SUSE Linux Enterprise Server SLES 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

We’re using SSSD specifically only with 2008 R2 DC’s. However we’ve chose to go the posix method. Are the 2 domain controllers on different versions on the same AD level? I highly recommend all of the domain controllers be on the same OS etc.

3

I would begin by reducing the complexity of your sssd.conf file and retest. LDAP and Kerberos SSSD configs are a bit more busy than others.

I’ve removed the access_provider directives and some other directives that complicated the config. I have also added some that I have found to be best practice with these providers.

When you re-implement the access provider consider the following format using group membership:

access_provider =ldap
ldap_access_order = filter, expire
ldap_account_expire_policy = ad
ldap_access_filter = memberOf=cn=SOME_GROUP,DC=mytest,DC=com

I would also suggest joining the system to the target domain and using GSSAPI to connect to the domain instead of an LDAP bind as long as you are using Kerberos.

Then one could say:

ldap_sasl_mech = GSSAPI
ldap_sasl_authid = INDDELVM25$@MYTEST.COM

So, I would test next with:

################################################# ############
[sssd]
config_file_version = 2
services = nss,pam
domains = mytest

[nss]
filter_groups = root
filter_users = root

[pam]

[domain/mytest]
id_provider = ldap
auth_provider = krb5
enumerate = False
cache_credentials = True

General -----------------------

LDAP

ldap_uri = ldap://inddelvm25.mytest.com
ldap_default_authtok_type = password
ldap_default_bind_dn = cn=linux,ou=Users,dc=mytest,dc=com
ldap_default_authtok = ********

ldap_id_mapping = True
ldap_id_use_start_tls = False

ldap_user_search_base = DC=mytest,DC=com
ldap_group_search_base = DC=mytest,DC=com
ldap_referrals = False

ldap_force_upper_case_realm = True

KRB5

krb5_server = inddelvm25.mytest.com
krb5_realm = MYTEST.COM
krb5_renewable_lifetime = 1d
krb5_lifetime = 1d
krb5_validate = true

Mapping --------------------

ldap_schema = ad

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

Hoping it helps, someone :slight_smile:

– lawrence

4

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