On Tue, Dec 19, 2017 at 04:11:04PM -0500, Alexandre Pitre wrote:
> Hi Jakub,
> 
> Thanks for your response. I assume our puppet configuration was incomplete
> and ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com was left out by
> mistake. We're already using the trusted domain section to force connection
> to AD site-specific domain controllers. Is ad_site parameter useful only if
> we we relying on DNS discovery ? 

Yes.

> See our sssd.conf full configuration
> below.

The configuration looks good to me.

> 
> 
> Server side:
> 
> [domain/ipa.domain.com]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa.domain.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname = ipa-001.ipa.domain.com
> chpass_provider = ipa
> ipa_server = ipa-001.ipa.domain.com
> ipa_server_mode = True
> ignore_group_members = True
> subdomain_inherit = ignore_group_members
> 
> [sssd]
> services = nss, sudo, pam, ssh
> domains = ipa.domain.com
> 
> [domain/ipa.domain.com/domain.com]
> ad_server = ad-001.domain.com
> ad_backup_server = ad-002.domain.com
> 
> [nss]
> homedir_substring = /home
> override_shell = /bin/bash
> 
> [pam]
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> 
> Client side:
> 
> [domain/ipa.domain.com]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa.domain.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname = centos.ipa.domain.com
> chpass_provider = ipa
> dyndns_update = True
> ipa_server = _srv_, ipa-001.ipa.domain.com, ipa-002.ipa.domain.com
> dyndns_iface = eth0
> 
> [sssd]
> services = nss, sudo, pam, ssh
> domains = ipa.domain.com,domain.com
> 
> [nss]
> homedir_substring = /home
> override_shell = /bin/bash
> 
> [pam]
> pam_id_timeout = 120
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> [pac]
> 
> [ifp]
> 
> My colleague added this section as a test and this seems to have fixed our
> login slowness with AD credentials.
> 
> [domain/domain.com]
> auth_provider = krb5
> cache_credentials = True
> ldap_id_use_start_tls = False
> krb5_server = ad-001.domain.com:88
> krb5_kpasswd = ad-002.domain.com:88
> ldap_search_base = OU=Accounts,DC=domain,DC=com
> krb5_realm = DOMAIN.COM
> chpass_provider = none
> id_provider = ldap
> krb5_canonicalize = false
> 
> Is this a good practice ?

Hmm, I think this goes in the right direction, but I think it's much better
to define a Kerberos realm in krb5.conf for the AD-based DOMAIN.COM and
define the KDCs there. 

I'm not sure if this domain would be even reached, because all queries
qualified with @domain.com should be caught already be the autodiscovered
sub-domain of ipa.domain.com...but since you say the domain definition
helps here, I suspect it's because sssd the address of the AD DCs into
kerberos kdcinfo files (see man sssd_krb5_locator_plugin) and that's where
libkrb5 reads them from.

So if you put the AD DC addresses into krb5.conf, you should achieve the
same thing, except with less magic
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to