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.

Active Directory is kind of a "Single Party State". You must let it believe that it controls the DNS, among other things. If you have no control on your DNS, cloud-side, then I would advise managing `/etc/hosts` via a conf management tool (e.g. Ansible) on your fleet of servers. — Samson Scharfrichter, Jul 22 '21 at 06:54
That's not actually true. AD will pay nice with other DNS, IF you set it up correctly. However, delegation of a dedicated namespace is just simpler *and* DNS standards-compliant. For the actual issue, AD (Kerberos) auth is like most security-sensitive endpoints - you need to come at it with a valid endpoint name so it doesn't look like a MITM attempt! Here, they've seem to have done half the job with the dedicated namespace - they just need to fix the upstream delegation. It's not rocket science. — LeeM, Jul 23 '21 at 08:12

score 0 · Answer 1 · answered Jul 21 '21 at 09:39

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 "user@example.net" - 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.

They already mentioned they don't want to use `/etc/hosts`, good on them. Unless you're running some kind of mickey-mouse personal lab, a hosts file not an appropriate or sustainable solution in an enterprise except for specific use-cases. DNS is a primary prerequiste for AD operations. If you want to join your computers to domains, you need to get your name resolution working, otherwise, why bother. — LeeM, Jul 23 '21 at 08:15
You would be suprised at how much of that "mickey-mouse" patching occurs in some large banking corporations with DCs in multiple continents... not for authentication though. — Samson Scharfrichter, Jul 23 '21 at 18:39
Yeah, no, I fully do know how much of that kind of thing goes on. I prefer not to leave a mess in my own wake, though! — LeeM, Aug 03 '21 at 13:26

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

1 Answers1