Really appreciate the high-level of insight and support on this list.
Very refreshing!
Alexander Bokovoy wrote:
Can you show us ldap_child.log and krb5_child.log from /var/log/sssd on
the replica?
krb5_child.log is totally empty (strange) as I thought I had debug_level
= 10 set everywhere
ldap_child.log is posted at this URL due to length:
http://chrisdag.me/ldap_child.log.sanitized.txt
There seem to be something weird with networking stack, because at
15:43:13 the next attempt to connect gets 'connection refused'. May be
389-ds is just warming up and there is not enough CPU or I/O to handle
the load?
<snip>
So, sssd on the replica is able to retrieve information from the
replica's LDAP server. It also is able to retrieve the trust topology
information and retrieve the trusted domain objects to use against the
forest root domains your deployment trusts.
But at the point when it tries to contact global catalog and domain
controllers from the trusted domains, it cannot access them, so it
considers them offline.
Can you show us your /etc/krb5.conf on this replica, content of files in
/var/lib/sss/pubconf/krb5.include.d subdirectory which get included into
/etc/krb5.conf, and the logs I asked above?
Here is sanitized krb5.conf from the replica. The CAPATH information was
provided by someone
on this list to resolve a problem with the CAPATHs being wrong by
default on v4.2 with
our complex AD environment. We've since made an Ansible playbook to
update the krb5.conf file
on our client machines.
We comment out the include path again based on our v4.2 issues howeve
includedir /etc/krb5.conf.d/
## Disabled due to SSSD Bug related to CA paths
## across different AD trusts
# includedir /var/lib/sss/pubconf/krb5.include.d/
## This is the manual COMPANY fix:
[capaths]
COMPANYAWS.ORG = {
COMPANYIDM.ORG = COMPANYAWS.ORG
}
COMPANYIDM.ORG = {
COMPANYAWS.ORG = COMPANYAWS.ORG
COMPANY.ORG = COMPANY.ORG
EAME.COMPANY.ORG = COMPANY.ORG
APAC.COMPANY.ORG = COMPANY.ORG
LATAM.COMPANY.ORG = COMPANY.ORG
NAFTA.COMPANY.ORG = COMPANY.ORG
}
COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
APAC.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
LATAM.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
NAFTA.COMPANY.ORG = {
COMPANYIDM.ORG = COMPANY.ORG
}
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = COMPANYIDM.ORG
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
canonicalize = true
[realms]
COMPANYIDM.ORG = {
kdc = usaeilidmp002.COMPANYidm.org:88
master_kdc = usaeilidmp002.COMPANYidm.org:88
admin_server = usaeilidmp002.COMPANYidm.org:749
default_domain = COMPANYidm.org
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.COMPANYidm.org = COMPANYIDM.ORG
COMPANYidm.org = COMPANYIDM.ORG
usaeilidmp002.COMPANYidm.org = COMPANYIDM.ORG
[dbmodules]
COMPANYIDM.ORG = {
db_library = ipadb.so
}
## Also from the include path we had previously commented out
[plugins]
localauth = {
module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
}
Can you make sure that the replica is actually able to reach AD DCs for
the trusted domains (ports tcp/3268, tcp/389, tcp/88, udp/88, udp/53 at
least)?
I'm going to see if I can come up with a new verification method. My
normal way of "proving" connectivity
in this AWS environment is to use the VPC flow logs to search for REJECT
alerts between the NIC on this
IPA server and the remote AD domain controller. This was very effective
in proving on our master IPA
that something was blocking UDP:88 to a few remote controllers.
Sadly I can't find any REJECT messages for this replica server so I've
been assuming connectivity was
totally fine. Will try to test via other methods.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
