----- Original Message -----
From: "James Ralston" ralston@pobox.com To: "End-user discussions about the System Security Services Daemon" sssd-users@lists.fedorahosted.org Sent: Wednesday, May 6, 2015 7:28:35 PM Subject: [SSSD-users] please do not remove enumeration from AD provider
On Wed, May 6, 2015 at 4:27 AM, Jakub Hrozek jhrozek@redhat.com wrote:
You know, just this morning, I was thinking about enumeration. It doesn't work for IPA views at all for example. It doesn't work for trusted domains at all either (except for some limited support in AD trusted domains that is very untested)
I wonder if we could just remove enumeration from IPA and AD back ends in some major release.
Please don't do this.
Enumeration is a very useful feature. It allows us to do things like this:
$ getent passwd | grep -i lastname
The equivalent ldapsearch command is much more tedious:
$ ldapsearch -z 0 -E pr=2147483647/noprompt -o ldif-wrap=no -L -L -H 'ldap:///dc%3Dexample%2Cdc%3Dorg -Y GSSAPI -N -b "dc=example,dc=org" "(&(objectClass=user)(cn=*lastname*))" dn cn sAMAccountName
More generically, enumeration is the way Unix/Linux has always worked. Even getting users to change from:
grep -i lastname /etc/passwdTo this:
getent passwd | grep -i lastname...has been a struggle.
We also have various services that (unfortuantely) pre-load the passwd and group files at startup by enumerating them with getpwent_r() and getgrent_r(), instead of using the get*nam_r() and get*id_r() functions as-needed. These services break outright if enumeration is disabled.
(Yes, these services are broken. Yes, they shouldn't do that. But our ability to fix them is extremely limited at best, because we don't control them.)
Finally, we have many systems that cannot be joined to Active Directory (for policy reasons, not technical reasons). But we want to use the same passwd/group entries on those systems as returned by sssd on hosts that are joined to Active Directory. We do this by scraping the output of "getent -s sss passwd" and "getent -s sss group" and manually merging it into the local passwd and group files (respectively) on these hosts.
It's just a legacy feature, so those who need it can fall back to the LDAP provider..
But the LDAP provider doesn't support ID mapping; only the AD provider does. And ID mapping is the main reason we use sssd.
ID mapping should work with LDAP provider (+ AD) But auto-discovery of domain SID does not work with ldap provider. So you need to configure it manually.
Here is a n example [domain/ad.example.com] debug_level = 0xFFF0 id_provider = ldap ldap_uri = ldap://$AD_SERVER1 ldap_schema = ad ldap_default_bind_dn = $AD_SERVER1_BINDDN ldap_default_authtok = $AD_SERVER1_BINDPASS ldap_tls_cacert = /etc/openldap/certs/ad_cert.pem
ldap_id_mapping = True ldap_idmap_default_domain_sid=S-1-5-21-1111111-2222222-3333333 ldap_idmap_default_domain=ad.example.com
But I would not recommend to use ldap+krb5 instead of ldap_defaul_bind_dn You can find some details in RHEL7 documentation[1]
LS
[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...