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