On Mon, Nov 07, 2011 at 03:13:35PM -0500, Stephen Gallagher wrote:
I've noticed lately on a couple of LDAP environments (all of
which
having been converted at some point in the past from NIS) that there is
a tendency for bad conversion scripts to sometimes leave around groups
with improperly formatted memberUID values.
For example:
dn: cn=groupA,ou=Groups,dc=example,dc=com
objectClass: posixGroup
...
memberUID: user1,user2,user3
Now, the standards-compliant approach here would be to just treat
'user1,user2,user3' as a single group entry (that except on the most
psychotic of systems would never match an actual username).
However, it's well within our power in SSSD to handle this more
gracefully, by parsing the commas ourselves. My question is, is this
something we should do, or should we continue treating this as useless
data and use it to encourage admins to fix their systems?
This *has* caused negative behavior in the SSSD in the past
(specifically, there was a bug in some older versions of LDB that caused
it to be unable to perform a reindex on DNs that contained an escaped
comma, thus rendering SSSD incapable of safely upgrading to newer
versions).
I would vote for skipping (and verbosely logging) an entry like this. It's
just broken.
I'm afraid that if we tried to handle this case gracefully, admins would
not be forced to fix this entry and would go "eh, sssd works, why bother".
There may be environments where the LDAP server is administered by
different set of admins than SSSD configurations are, procedures are in
place etc, which may cause fixing the directory hard, but we need to
draw the line somewhere.
Also, I ran a quick test with nss-pam-ldapd and they would punt on this
memberuid as well.