On Wed, 2012-03-14 at 13:55 +0100, Olivier wrote:
Hello,
I have configure redhat (6 and 5) boxes to authenticate users
over an openldap server via sssd. I have implemented a policy
so that "Systems" accounts ( uid > 500 ) are not in ldap but
authentified over local password db.
My ldap directory also contains posixgroups that I use to
tune some accesses ( using /etc/security/access.conf ).
I have added this in my nsswitch.conf :
passwd: files sss
shadow: files sss
group: sss files
I have configured sss as a primary source of information
for groups, because I would like pam to take into account
both groups that are declared in ldap and those that are
locally configured (even for system accounts that don't have
any entry in ldap).
The problem I'm facing is that ldap groups for a user are only
considered if the user has itself an entry in ldap ( except if
th user is declared as having an ldap group as primary in
/etc/passwd ).
Here is an example :
If I have this in /etc/passwd :
ntp:x:38:38::/etc/ntp:/sbin/sh
This in /etc/groups
ntp:x:38:
And this group in ldap :
dn: cn=sysgrp,ou=group,dc=example,dc=fr
cn: sysgrp
gidnumber: 18010
memberuid: ntp
memberuid: wheel
memberuid: ldap
objectclass: posixGroup
Then a "su - ntp -c groups" returns only "ntp" group not
"sysgrp" :
$ su - ntp -c groups
ntp
If I create a user entry for "ntp" in ldap directory, then it works :
# Entry :
dn: uid=ntp,ou=sysaccounts,ou=people,dc=example,dc=fr
cn: ntp
gidnumber: 18010
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: posixAccount
uid: ntp
uidnumber: 38
...
I have then what I want on the client machine :
$ su - ntp -c groups
ntp sysgrp
I don't want to maintain a DIT in ldap to list system accounts,
I would only like to maintain a posix group entry that lists system
accounts ( and match if the system account exist on the client ).
Is there any way to do that ?
May be someone could help me or indicate a documentation or
a mailing list that I could try to consult to deal with that problem ?
You're experiencing the behavior described in:
https://fedorahosted.org/sssd/ticket/1020
Right now, this is a limitation of SSSD. We're currently scheduled to
look into that in the SSSD 1.11 timeframe (due in roughly nine months).
In general, it's a very rare case, as most deployments choose not to
maintain local user accounts in centrally-managed groups; they instead
move those accounts to be also centrally-managed.