On Mon, Apr 1, 2019 at 2:18 AM Hans Schou <hsc(a)miracle.dk> wrote:
On Fri, 29 Mar 2019 at 16:49, James Ralston <ralston(a)pobox.com>
> 1. You are setting ldap_id_mapping = False, so that means
> sssd will only map groups that have the gidNumber
> attribute. If there is no gidNumber attribute on the
> group, sssd ignores it.
Yes, that was the problem. Changed to True and it is working.
It was the default value and I guess there must be a good
explanation for having it that way.
Beware: if you were getting successful user lookups with
ldap_id_mapping = false, almost certainly, it was because those user
objects in AD had POSIX attributes (uidNumber, gidNumber, loginShell)
Setting ldap_id_mapping = true will *change* the uid and gid values
that sssd returns for those users, because with LDAP id mapping, sssd
is no longer using the POSIX attributes to determine uid/gid values;
it is using a mapping algorithm based on the account SID/RID value.
(See the "Mapping Algorithm" section of sssd-ad(5).)
If your site has already started down the road of using POSIX
attributes in AD, then you have two choices:
1. Set ldap_id_mapping = false to continue to use the POSIX
attributes, and ensure all user/group objects in AD that need to
be visible via sssd have them.
2. Set ldap_id_mapping = true, and accept that this will change the
uid/gid values of all user/group objects from whatever they were
set to using POSIX attributes (uidNumber and gidNumber,
For a new site, ldap_id_mapping = true is arguably the best way to go,
but once you have started down the POSIX attributes path, switching to
ldap_id_mapping = true can cause a large amount of breakage.
Also, for the record, ldap_id_mapping = true is the default for
id_provider = ad. (This is also covered in sssd-ad(5).)