[Freeipa-users] replica running trust-agents can't resolve AD users - which of these sssd errors should I be focusing on?

[Chris Dagdigian]

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.