[SSSD] user and group precedence issue

Olivier ldap at guillard.nom.fr
Wed Mar 14 16:13:20 UTC 2012


Thanks Simon,

that's what I will do as a first approx I think,
however I'm not sure that this will meet my
need :

1- there are some sysacounts that I need on
   certain machines (linked for example to specific
   applications installed on them) that I wouldn't like
   to be accessible or even visible from others ;

2- I will need to maintain an additional source of
    information ( and I'm lazy :-), moreover will this
    new source always rightly synchronized with
    local passwd databases ? )

3- some accounts may have slightly different information
   from one boxe to anther ( different home directory for
   example ).

In brieve, the behaviour that would be great for me would be :
if nsswitch says that sss is the primary source of information
for groups, then returns all ldap groups for users, and add the
primary group declared locally if the primary group for that user
can't be found in ldap.

---
Olivier


2012/3/14 Simo Sorce <simo at redhat.com>:
> 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,
>> 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,
>
> One way to work around your problems is to have these accounts both
> locally and centrally. The local accounts will simply shadow the central
> ones for access purposes, but the central ones will allow you to have
> proper memberships that are resolved by sssd when requested.
>
> HTH.
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list