On Wed, 2012-03-14 at 14:35 +0100, Olivier wrote: > Thanks Stephen, > > > https://fedorahosted.org/sssd/ticket/1020 > > May I add an additional information to the description,
Please add this information to the ticket. You can create an account at https://admin.fedoraproject.org/accounts for free and use that to log into https://fedorahosted.org/sssd Thank you for your help! > this is a test that I have done and that may help to deal > with this ticket : > > If user entry is locally configured /etc/passwd with an > ldap posixgroup reference its primary group, then the > command "groups" returns properly the primary group > gid ( as declared in ldap ) as well as other secondary > groups configured locally. > > If this users is also registered as being member of other > ldap groups, those groups are not returned by "groups". > > > 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. > > let me explain the principles I have retained and that > explain my strategy : > > 1 - I consider that system accounts are let say "criticals" > so I want them to "work" properly wether ldap respond > or not, wether sssd runs or not ; > > 2 - I want the primary group for those accounts to be also > properly configured locally ( for the same reason than > above, and also to not tuch the default local configuration ) ; > > 3- I want secondary groups to be configurable for those > accounts so that I can benefit of additional opportunities > to tune in a centralized maneer things like ACL for example ; > > Hope this helps, > > --- > Olivier > > 2012/3/14 Stephen Gallagher <[email protected]>: > > 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. > > > > _______________________________________________ > > sssd-devel mailing list > > [email protected] > > https://fedorahosted.org/mailman/listinfo/sssd-devel > > > _______________________________________________ > sssd-devel mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/sssd-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
