8:35 a.m.
Thanks Stephen,
May I add an additional information to the description,
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 <sgallagh(a)redhat.com>:
> 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:
>
> 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
> sssd-devel(a)lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel
>