On ma, 29 huhti 2019, David McDaniel via FreeIPA-users wrote:
Environment:
Single Site
Two FreeIPA Idm Servers (1 Trust-Controller 1 Trust-Agent)
We ran into an issue were our Trust-Controller was offline and Kerberos
authentication began failing for AD users. We do not allow interactive
password auth. via sshd_config on IPA clients, only Pubkey or GSSAPI.
From the clients we could resolve AD users without issue but AD user
Kerberos authentication was failing with error regarding KDC not
reachable. Once we got the Trust-Controller back online, all was well
and working again. Clearly our Trust-Controller was handling the KDC
role in this use-case.
Example of klist output after Trust-Controller was back online.
Hostnames/Users changed to protect the innocent of course.
Client: aduser @
AD-DOMAIN.COM
Server:
host/ipaclient.freeipadomain.com @
FREEIPADOMAIN.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a90000 -> forwardable renewable pre_authent name_canonicalize 0x80000
Start Time: 4/29/2019 6:35:26 (local)
End Time: 4/29/2019 16:06:39 (local)
Renew Time: 5/6/2019 6:06:39 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called:
freeipa-trust-controller.freeipadomain.com
My question is this; since we are only doing Kerberos auth for AD
users, is it necessary we add the Trust-Agent to some/all MSDCS SRV
records within FreeIPA DNS for this to work, in the event
Trust-Controller is offline? It's been awhile since needing to dig into
FreeIPA, so perhaps I am missing something.
Yes, it would be needed to add the trust
agent to the msdcs site records. We
are actually relying on the logic from MS-ADTS 6.3.6.1 which talks about
non-site-based searches but it seems there are exceptions from it.
It would probably be good to see what DNS SRV records Windows machines try to
look up prior to talking to IPA KDC?
Could you please open a ticket for FreeIPA?
Please reference
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fcd...,
"MS-ADTS 6.3.6.1 DNS-Based Discovery" for details:
---------------------------
To locate a server that is running the Kerberos Key Distribution Center
service over TCP for default NC X, the client machine issues a DNS query
for the SRV record _kerberos._tcp.X, constructed from the default NC
name (X).
To locate a server that is running the Kerberos Key Distribution Center
service over UDP for default NC X, the client machine issues a DNS query
for the SRV record _kerberos._udp.X, constructed from the default NC
name (X).
To locate a server in site Y that is running the Kerberos Key
Distribution Center service over TCP for default NC X, the client
machine issues a DNS query for the SRV record _kerberos._tcp.Y._sites.X,
constructed from the default NC name (X) and the site name (Y).
To locate a DC that is running the Kerberos Key Distribution Center
service over TCP and that also hosts default NC X, the client machine
issues a DNS query for the SRV record _kerberos.tcp.dc._msdcs.X,
constructed from the default NC name (X).
To locate a DC in site Y that is running the Kerberos Key Distribution
Center service over TCP and that also hosts default NC X, the client
machine issues a DNS query for the SRV record
_kerberos.tcp.Y._sites.dc._msdcs.X, constructed from the default NC name
(X) and the site name (Y).
To locate a server that is running the Kerberos Password Change service
over TCP for default NC X, the client machine issues a DNS query for the
SRV record _kpasswd._tcp.X, constructed from the default NC name (X).
To locate a server that is running the Kerberos Password Change service
over UDP for default NC X, the client machine issues a DNS query for the
SRV record _kpasswd._udp.X, constructed from the default NC name (X).
---------------------------
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland