Not able to run sssd + AD domain controllers with different FQDN

Question

I have below sssd + ad setup for ssh management.

    AD Domain - ad.example.net
    AD DC 1 hostname - dc1.example.net
    AD DC 2 hostname - dc2.example.net
    Linux (Centos) Server hostnames - server.int.example.com -> this I can not change as per Org policy

I don't want to add AD dns into my /etc/resolv.conf, we want to use cloud provided dns resolver which resolves our domain controllers hostnames with *.example.net

When I add them as

ad_server = dc1.example.net,dc2.example.net

sssd fails with -

    [dp_req_reply_gen_error] (0x0080): DP Request [Initgroups #1066]: Finished. Backend is currently offline.

Here is my sssd.conf and krb.conf

sssd.conf -

    [sssd]
    domains = ad.example.net
    reconnection_retries = 3
    config_file_version = 2
    services = nss, pam, ssh
    override_space = _
    sbus_timeout = 30
    
    [nss]
    reconnection_retries = 3
    entry_negative_timeout = 30
    entry_cache_nowait_percentage = 7
    debug_level = 9
    
    [pam]
    reconnection_retries = 3
    
    [domain/default]
    cache_credentials = True
    entry_cache_timeout = 3600
    
    [domain/ad.example.net]
    id_provider = ad
    access_provider = ad
    ldap_id_mapping = True
    auto_private_groups = True
    default_shell = /bin/bash
    fallback_homedir = /home/%u
    use_fully_qualified_names = False
    krb5_store_password_if_offline = True
    realmd_tags = manages-system joined-with-adcli
    ad_domain = ad.example.net
    ad_server = dc1.example.net,dc2.example.net
    ad_hostname = dev1210utl1.ad.example.net
    krb5_realm = AD.example.NET
    ldap_user_ssh_public_key = altSecurityIdentities
    ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
    debug_level = 9
    
    dns_resolver_timeout = 20
    krb5_lifetime = 24h
    krb5_renewable_lifetime = 7d
    krb5_renew_interval = 60s
    dyndns_update = false

krb5.conf

    # Configuration snippets may be placed in this directory as well
    includedir /etc/krb5.conf.d/
    
    [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
    
    [libdefaults]
    default_realm = AD.EXAMPLE.NET
    dns_lookup_realm = false
    dns_lookup_kdc = false
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true
    rdns = false
    pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt
    spake_preauth_groups = edwards25519
    default_ccache_name = KEYRING:persistent:%{uid}
    ignore_acceptor_hostname = true
    
    [realms]
    AD.EXAMPLE.NET = {
      kdc = dc1.example.net
      admin_server = dc1.example.net
      kdc = dc2.example.net
      admin_server = dc2.example.net
    }
    
    [domain_realm]
    .ad.example.net = AD.EXAMPLE.NET
    ad.example.net = AD.EXAMPLE.NET

I know, there are different DNS fqdn in my setup, but cant avoid them.

sssd works if i set -

ad_server = dc1.ad.example.net,dc2.ad.example.net

But i have to add AD DNS as my resolver or have them /etc/hosts which i want to avoid.

Any help related to helpful.

Answer 1

If the DC FQDN really is dc1.ad.example.net, why on earth are you attempting to use an alias? The vendor has to fix this configuration, end of story.

You MUST use the correct DC names when you bind - if it thinks you're trying to reach a completely different host/realm, then of course it won't let you connect. You might as well have "dc1.mickeymouse.com" as the alias you're trying to use - it's equally as invalid if the DC FQDN is really "dc1.ad.example.net".

Also, does your cloud provider DNS resolve SRVs like _ldap._tcp.ad.example.net _kerberos_.udp.ad.example.net correctly? This is critical stuff.

It doesn't matter if UPNs available in the domain include "[email protected]" - right now you're dealing with basic LDAP and Kerberos network protocols. If you want to bind/auth with a host, you need to provide the correct name.

The vendor doesn't need to delete the existing ones - although I have to wonder what they're intended for - but they do need to let the correct DC names resolve, whether that's through creating some records or doing what should probably have been done and delegating "ad.example.net" to the DCs as authoritative for that subzone (since I assume that hasn't been done if they don't resolve).

It doesn't matter what your machine hostname is, as long as the DCs can resolve it in the other direction.

If this provider's DNS is public, there should also be some security about external hosts resolving the internal "ad.example.net" namespace (i.e. they shouldn't).

TLDR: if the domain DNS is "ad.example.net" and that is all that subzone is used for - the AD domain - then that should be delegated from the upstream "example.net" name servers to the domain controllers as an authoritative zone.