Hi Jakub,

Hopefully I’m providing a decent discussion starting point. Is placing the DC into resolv.conf the typical scenario? Or is it more that this is the Microsoft-recommended way of doing things, full stop?

For example, I don’t put 8.8.8.8 into my resolver if I want to lookup the www.google.com A record. I suspect internal zones at companies are not resolved by adding more and more lines to the resolv.conf file. I would rather think that corporate computers will generally point at a corporate DNS server which knows how to delegate AD queries to the AD servers, and other queries to other servers, and so on. But I could be overly optimistic after reading the responses on another list (I recently asked this to the bind folks, and they brought up a lot of interesting points).

https://lists.isc.org/pipermail/bind-users/2014-April/092919.html

Thanks for providing the tutorials. The previous 2008 R2 tutorial was very useful.

V/r, Bryan

On Apr 10, 2014, at 10:20 AM, Jakub Hrozek jhrozek@redhat.com 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... _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users

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.

I can remove the auth_provider line, though.

...

# Uncomment if service discovery is not working # ad_server = server.ad.example.com

# Uncomment if you want to use POSIX UIDs and GIDs # ldap_id_mapping = False

IMHO this description is a little bit misleading. Since you use UIDs and GIDs event it id mapping is turned on. It should say "if you have UIDs and GIDs set on AD side" or something similar.

You're right, fixed with the sentence you proposed.

On Thu, Apr 17, 2014 at 09:05:42AM +0300, Marko Myllynen wrote:

Hi,

On 2014-04-10 17:20, Jakub Hrozek wrote:

...

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.

I've been pretty detached from all this during the past year but perhaps that's only a good thing for the review..

In general all looks very nice and it was certainly a good move to write a new document. I have few nitpick comments, please see below and address/ignore them as you see appropriate (and please pardon me if any of these are copypastes from something I wrote for the old document :).

That's exactly why I CC-ed you and the other authors of the original document -- you may remember strange quirks of the real environments :)

• I'd add LDP/ldapsearch examples to the GC section

Good idea, this might be helpful for the admin to compare the attribute set between GC and LDAP.

• for completeness sake I'd add dns_lookup_kdc = true and master_kdc =

server.ad.example.com to the krb5.conf example

I've added dns_lookup_kdc, but I'm not sure about master_kdc, why do you think it's needed? I normally prefer to stick to the defaults and let the autodiscovery do its magic.

• I'd add KRB5_TRACE=/dev/stdout kinit -V example somewhere, perhaps

after the krb5.conf example

I agree, added.

• I would at least comment out password server in smb.conf

Right, after re-reading the section in man smb.conf, I agree password server should not be used.

• a bit of grouping in smb.conf might make it more readable, e.g.

security/realm/workgroup could be the first block, then logging options (location+level), then server options, then client options

Done.

I've changed the wiki page accordingly. Thanks a lot for the suggestions!

Hi,

this went unanswered so ...

On 2014-04-17 14:16, Marko Myllynen wrote:

On 2014-04-17 13:18, Jakub Hrozek wrote:

...

On Thu, Apr 17, 2014 at 09:05:42AM +0300, Marko Myllynen wrote:

...

• for completeness sake I'd add dns_lookup_kdc = true and master_kdc =

server.ad.example.com to the krb5.conf example

I've added dns_lookup_kdc, but I'm not sure about master_kdc, why do you think it's needed? I normally prefer to stick to the defaults and let the autodiscovery do its magic.

sorry, I meant adding master_kdc commented like kdc / admin_server already are. Under certain circumstances if you wanted to force using a certain KDC it was not enough to specify kdc / admin_server, you needed also master_kdc. In the past it was undocumented and when it was discovered it explained quite a few situations. Sumit or Alexander might remember the exact details, the bug report about it being undocumented doesn't go into details: https://bugzilla.redhat.com/show_bug.cgi?id=859961.

I added master_kdc to the example config based on the rationale above.

...

Right, after re-reading the section in man smb.conf, I agree password server should not be used.

What do you think about adding create krb5 conf = no?

This seems unnecessary. So does actually currently listed client signing = yes which is IMHO ambiguous, "yes" is not documented in the man page and I don't know what would be the reason for changing this. But I didn't remove that, perhaps someone had a reason to add it there.

Thanks,