----- Original Message -----
From: "James Ralston" <ralston(a)pobox.com>
To: "End-user discussions about the System Security Services Daemon"
<sssd-users(a)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(a)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/passwd
To 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/...