How to authenticate users with Kerberos when port 88 is not available in a DMZ? Use an HTTPS server as a proxy. IPA comes with an integrated KDC Proxy and it’s simple to make use of it.
A typical use case is a cross-domain trust with AD, where the Linux clients are not allowed to directly talk to AD because of firewall and/or security policy restrictions. Another use-case is where clients in a DMZ are not allowed to directly communicate via Kerberos to an IPA or AD server.
Here is an example snippet in /etc/krb5.conf for an IPA and an AD realm:
[realms] EXAMPLE.COM = { dns_lookup_kdc = false kdc = https://ipa1.example.com/KdcProxy kdc = https://ipa2.example.com/KdcProxy kpasswd_server = https://ipa1.example.com/KdcProxy kpasswd_server = https://ipa2.example.com/KdcProxy pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem } WIN.EXAMPLE.COM = { dns_lookup_kdc = false kdc = https://ipa1.example.com/KdcProxy kdc = https://ipa2.example.com/KdcProxy kpasswd_server = https://ipa1.example.com/KdcProxy kpasswd_server = https://ipa2.example.com/KdcProxy pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem }
For redundancy, you should provide at least two KDC and kpasswd servers. Unfortunately, multiple KDC entries are not working round-robin, always the first one will be contacted. With a very large number of servers and users, this can be a bottleneck.
After changing stuff in krb5.conf sssd.conf, restart the sssd daemon.
Try to see if it works
Please be aware that kinit is case sensitive for looking up the Kerberos Realm, always use upper case.
[root@rhel8 ~]# KRB5_TRACE=/dev/stdout kinit jbond@WIN.EXAMPLE.COM [1562] 1617026017.956681: Getting initial credentials for jbond@WIN.EXAMPLE.COM [1562] 1617026017.956683: Sending unauthenticated request [1562] 1617026017.956684: Sending request (183 bytes) to WIN.EXAMPLE.COM [1562] 1617026017.956685: Resolving hostname ipa1.example.com [1562] 1617026018.092906: TLS certificate name matched "ipa1.example.com" [1562] 1617026018.092907: Sending HTTPS request to https 192.168.0.100:443 [1562] 1617026018.092908: Received answer (184 bytes) from https 192.168.0.100:443 [1562] 1617026018.092909: Terminating TCP connection to https 192.168.0.100:443 [1562] 1617026018.092910: Sending DNS URI query for _kerberos.WIN.EXAMPLE.COM. [1562] 1617026018.092911: No URI records found [1562] 1617026018.092912: No SRV records found [1562] 1617026018.092913: Response was not from master KDC [1562] 1617026018.092914: Received error from KDC: -1765328359/Additional pre-authentication required [1562] 1617026018.092917: Preauthenticating using KDC method data [1562] 1617026018.092918: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2) [1562] 1617026018.092919: Selected etype info: etype aes256-cts, salt "WIN.EXAMPLE.COMjbond", params "" Password for jbond@WIN.EXAMPLE:COM:
Using DNS URI Records
The usage of DNS URI entries as defined in RFC 7553 is an alternative way. Unfortunately, this is not working out-of-the-box with SSSD, you need to configure it manually.
This is a known issue which is tracked here: https://github.com/SSSD/sssd/issues/4559
Adding the URI records in IPA
[root@rhel8 ~]# ipa dnsrecord-add example.com _kerberos --uri-priority=10 --uri-weight=1 --uri-target="krb5srv:m:kkdcp:https://ipa1.example.com/KdcProxy" Record name: _kerberos TXT record: "EXAMPLE.COM" URI record: 10 1 "krb5srv:m:kkdcp:https://ipa1.example.com/KdcProxy" [root@rhel8 ~]# ipa dnsrecord-add example.com _kerberos --uri-priority=10 --uri-weight=1 --uri-target="krb5srv:m:kkdcp:https://ipa2.example.com/KdcProxy" Record name: _kerberos TXT record: "EXAMPLE.COM" URI record: 10 1 "krb5srv:m:kkdcp:https://ipa1.example.com/KdcProxy", 10 1 "krb5srv:m:kkdcp:https://ipa2.example.com/KdcProxy" [root@rhel8 ~]#
Configuring SSSD
[domain/win.example.com] krb5_use_kdcinfo = False
See it working
[root@rhel8 ~]# KRB5_TRACE=/dev/stdout kinit hmuster [1952] 1617028505.332519: Resolving unique ccache of type KCM [1952] 1617028505.332520: Getting initial credentials for hmuster@EXAMPLE.COM [1952] 1617028505.332522: Sending unauthenticated request [1952] 1617028505.332523: Sending request (176 bytes) to EXAMPLE.COM [1952] 1617028505.332524: Sending DNS URI query for _kerberos.EXAMPLE.COM. [1952] 1617028505.332525: URI answer: 10 1 "krb5srv:m:kkdcp:https://ipa1.example.com/KdcProxy" [1952] 1617028505.332526: URI answer: 10 1 "krb5srv:m:kkdcp:https://ipa2.example.com/KdcProxy" [1952] 1617028505.332527: Resolving hostname ipa1.example.com [1952] 1617028505.332528: TLS certificate name matched "ipa1.example.com" [1952] 1617028505.332529: Sending HTTPS request to https 192.168.0.100:443 [1952] 1617028505.332530: Received answer (298 bytes) from https 192.168.0.100:443 [1952] 1617028505.332531: Terminating TCP connection to https 192.168.0.100:443 [1952] 1617028505.332532: Response was from master KDC [1952] 1617028505.332533: Received error from KDC: -1765328359/Additional pre-authentication required [1952] 1617028505.332536: Preauthenticating using KDC method data [1952] 1617028505.332537: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD (15), PA-PK-AS-REQ_OLD (14), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-ENC-TIMESTAMP (2), PA-FX-COOKIE (133) [1952] 1617028505.332538: Selected etype info: etype aes256-cts, salt "gc*'9B2/6]RkrP>+", params "" [1952] 1617028505.332539: Received cookie: MIT Password for hmuster@EXAMPLE.COM:
I wonder why you don’t use this config:
WIN.EXAMPLE.COM = {
dns_lookup_kdc = false
kdc = https://ipa-ca.example.com/KdcProxy
kpasswd_server = https://ipa-ca.example.com/KdcProxy
pkinit_anchors = FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem
pkinit_pool = FILE:/var/lib/ipa-client/pki/ca-bundle.pem
}
The ipa-ca dns records provides round robin so you can spread the load