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