[SSSD] Support for subdomains - stage 1

Jakub Hrozek jhrozek at redhat.com
Wed Apr 4 13:02:15 UTC 2012


On Wed, Apr 04, 2012 at 09:08:11AM +0200, Jan Zelený wrote:
> > On Mon, Apr 02, 2012 at 10:07:00AM +0200, Jan Zeleny wrote:
> > > > > #0011
> > > > > New ID-related config options for subdomains, these have to be
> > > > > present because IPA provider doesn't provide these values and
> > > > > defaults need to be implemented. Having defaults on the responder
> > > > > level didn't seem right since the policy might differ for each
> > > > > domain.
> > > > 
> > > > Nack.
> > > > 
> > > > I don't think this really makes sense at all. In most cases, users will
> > > > prefer to use the value on the LDAP server. If they choose to override
> > > > it, they'll do so through the existing override options (in the case of
> > > > override_homedir, it already has %d available anyway.
> > > > 
> > > > We definitely don't need separate handling for shells. I can *kind of*
> > > > see a value if you wanted to have only subdomains have a non-default
> > > > location. I'm not sure I like that though. I feel like it's probably
> > > > more complexity than we need.
> > > 
> > > I think you possibly missed the point. The point is that this information
> > > is NOT on the server, therefore we need a value that will fill it in.
> > > Otherwise only a blank field will be stored in sysdb and returned to the
> > > client
> > 
> > Returning an empty string for user shell is perfectly valid, the shell then
> > defaults to system default (/bin/sh usually). But we already reopened
> > the override ticket anyway..
> > 
> > Doesn't the existing homedir override work even with no shell? I just
> > tested the override work when ldap_user_home_directory is set to an
> > attribute that doesn't exist.
> 
> The override works, but the problem I have with it is that it's not for a 
> single domain but for the entire responder. That might not be acceptable in 
> some environments.
> 
> Thanks
> Jan

It is also per-domain, see man sssd.conf



More information about the sssd-devel mailing list