On Fri, Apr 11, 2014 at 11:14:33AM -0400, Stephen Gallagher wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 04/11/2014 08:31 AM, Jakub Hrozek wrote:
On Fri, Apr 11, 2014 at 01:11:40PM +0200, Pavel Březina wrote:
On 04/10/2014 04:20 PM, Jakub Hrozek wrote:
Hi,
our current HOWTO[1] on connecting SSSD to an AD DC is outdated, mostly because the page still only introduces the LDAP provider. Recently, me, Sumit and Jeremy Agee wrote a new page that specifically advises to use the AD provider and also use realmd for setup: https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server
We started a new page and kept the old one around mostly because pre-1.9
versions still need the LDAP provider info.
I'd like to get some review and feedback from our community so we can link the wiki page from the front page or the documentation section. In addition to the lists, I also CC-ed the individual contributors to the original page directly..I hope that's fine.
Thank you for your comments.
[1] https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20...
Hi,
nice article. I have just few nitpicks to sssd.conf.
[sssd] config_file_version = 2 domains = ad.example.com services = nss, pam
[domain/ad.example.com] # Uncomment if you need offline logins # cache_credentials = true
id_provider = ad auth_provider = ad access_provider = ad
I think presenting a minimal configuration would be better, ie removing auth and access providers since they are inherited from id.
auth is inherited, access is not. The access provider defaults to permit for all backends. We talked multiple times about changing the default, but I'm not quite sure why we didn't. I remember there was a technical reason (other than 'noone sent a patch') but I can't recall it now, sorry.
Well, the major technical reason is that it would be a backwards-incompatible change. Updating the SSSD and changing that behavior could very easily mean suddenly locking a whole lot of people out of their system. There's really no easy way to change this unless we want to force an upgrade to set it explicitly to 'access_provider = permit', but that would still break if something like puppet overwrote it again.
In case of the 'ad' provider, defaulting to access_provider=ad would lock out expired accounts only, which is a good thing :-)
But I think you're right, I think we wanted to default to access_provider=ad when the ad back end was new (and had no legacy users) but found out that having a different default for the existing providers (permit) and for the new one (ad) wasn't easily possible with the current backend initialization code.