Op Woensdag, 24-01-2018 om 17:44 schreef Jakub Hrozek:
> On Wed, Jan 24, 2018 at 05:25:26PM +0100, Franky Van Liedekerke wrote:
> > Op Woensdag, 24-01-2018 om 16:45 schreef Jakub Hrozek:
> > > On Wed, Jan 24, 2018 at 10:10:11AM -0500, Geoff Goehle wrote:
> > > > Sorry about the line breaks.  Adding "enable_files_domain = false" to 
> > > > the [sssd] section fixed the issue.  Just out of curiosity, could I ask 
> > > > what that does?  Its not in the man page.  
> > > 
> > > SSSD has a feature which mirrors the local /etc/passwd and /etc/group
> > > files for faster lookups of local users without having to enable nscd
> > > which is tricky to operate together with sssd, especially if you run
> > > sssd for a remote domain, too:
> > >     https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
> > > But I'm surprised that Debian would enable this feature without changing
> > > the nsswitch.conf order like Fedora did. They probably should disable
> > > the files domain by default..
> > > 
> > > The files domain is currently identity-only and no authentication is
> > > performed. That, together with the duplicate users and the files domain
> > > running by default has been causing the failures for you..
> > 
> > On a side-note: I just tested this enable_files_domain and it seems using 
> > it results in the next domain still being queried for local users (verified 
> > by sifting through the ldap server logs). Using an explicit domain with 
> > id_provider=files apparently works differently (that domain answers and the 
> > next one is not queried), which is not very transparent.
> > Is this expected?
> 
> What was the order of the explicit domains? Note the implicit domain is
> always prepended before any other domain..

The order in case of an explicit domain is first the files-based one, then 
ldap. So the order is (or should be) identical in both cases.

Franky
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to