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 _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
