[SSSD] user and group precedence issue

Simo Sorce simo at redhat.com
Wed Mar 14 17:00:56 UTC 2012


On Wed, 2012-03-14 at 17:13 +0100, Olivier wrote:
> 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 ;

Use user filters on the other machines if they really bother you, but if
you are referencing them in groups you are not really keeping them
secret anyways.

> 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 ? )

Use a script that dumps locally the users from ldap, so that you
maintain those users in only one place win-win :)

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

That's ok, you are overriding the central ones completely for
getpwnam/getpwuid purposes.

> 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.

The problem is that sssd wants to be self-consistent. You are asking it
to know about "unknown" users only for grouping purposes. It's basically
a hack. So hack per hack I think you'd be better off using the trick of
shadowing users by adding them in passwd and keeping a copy in ldap.

The only case where you may have issues is if uid/gid need to mismatch
but that shouldn't normally cause big issues as the only information you
lookup from ssd is group membership and that does not rely on uids/gids
to match.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list