[SSSD] Support for subdomains - stage 1

Sumit Bose sbose at redhat.com
Tue Apr 3 14:07:46 UTC 2012


On Tue, Apr 03, 2012 at 06:43:47AM -0700, Stephen Gallagher wrote:
> On Tue, 2012-04-03 at 16:36 +0300, Marko Myllynen wrote:
> > Hi,
> > 
> > > Ok, I think I understand now, but the manpages need to be MUCH more
> > > clear. It sounds like you're adding this option to always override
> > > subdomain home directory values. Please clarify the documentation.
> > > 
> > > I still don't see a use for the shells though. The OS already handles
> > > this internally by translating a NULL value for the shell into "the
> > > system default shell" (usually /bin/sh). This is handled by glibc and
> > > isn't our concern.
> > 
> > as with regular domains also with subdomains you might have the
> > situation where different domains and users have different values for
> > shell (e.g., NULL, /bin/bash, and /bin/tcsh) which in turn will cause
> > users logging into a system to have different environment. And the case
> > where bash (and other shells) behave differently depending whether
> > invoked as /bin/bash or /bin/sh might be something administrators will
> > hit especially with subdomains as not all AD domains have UNIX
> > attributes enabled.
> > 
> > It would help administrators if SSSD would provide a method to force a
> > shell to all users regardless of domain/libc/user configuration but
> > unfortunately the RFE requesting this functionality has been deferred
> > (#1087). Even though you could state that the shell users will get is
> > not of your concern, it is much of a concern for system administrators
> > and the subdomain_shell option would seem to be helpful with that regard.
> > 
> > Thanks,
> > 
> 
> The reason we deferred 1087 is because we feel that if the user has a
> preferred shell set on the central server and the same shell is
> available on the client machine, then the user should be granted access
> to that shell on any machine they log into. We have the 'vetoed_shells'
> option in the event that a particular client machine wants to prevent a
> user from using a specific shell. Otherwise, if the administrator really
> wants to force users to use a particular shell, then the most expedient
> solution is to make that change to the central LDAP attribute, thus
> percolating it out to all machines trivially.

At least for trusts to AD we won't use any LDAP attributes, because they
might not be set or it might be difficult to access the LDAP server at
all.

bye,
Sumit


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