Hi,
I do have an issue with my latest Linux (CentOS 7) virtual machines (names
have been redacted):
1. They start their life in an AD domain (Windows 2019 DCs) and everything
is working as expected (for the rest of the explanation, I will use
"AD.DOMAIN" for this realm)
2. I have an IPA Server, which, despite having a FQDN ending in "ad.domain"
is enrolled in its own Kerberos domain (IPA.DOMAIN) => idmsrv01.ad.domain
2.On my client machine I do => realm leave
3. Then I try to make it rejoin my IPA domain/realm =>
# export KRB5_TRACE=/dev/stdout
# ipa-client-install --server idmsrv01.ad.domain --domain idm.domain
--realm IPA.DOMAIN --principal enrollmentaccount --mkhomedir --no-ntp
--force-join
And here is the issue :
(...)
Using existing certificate '/etc/ipa/ca.crt'.
Client hostname: myvm01.ad.domain
Realm: IPA.DOMAIN
DNS Domain: ipa.domain
IPA Server: idmsrv01.ad.domain
BaseDN: dc=ipa,dc=domain
Skipping synchronizing time with NTP server.
[19420] 1626829415.775243: ccselect can't find appropriate cache for server
principal ldap/idmsrv01.ad.domain(a)AD.DOMAIN
[19420] 1626829415.775244: Getting credentials enrollmentaccount(a)IPA.DOMAIN
-> ldap/idmsrv01.ad.domain(a)AD.DOMAIN using ccache
FILE:/tmp/krbccoz6hPK/ccache
[19420] 1626829415.775245: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
ldap/idmsrv01.ad.domain(a)AD.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with
result: -1765328243/Matching credential not found (filename:
/tmp/krbccoz6hPK/ccache)
[19420] 1626829415.775246: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
krbtgt/AD.DOMAIN(a)AD.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with result:
-1765328243/Matching credential not found (filename:
/tmp/krbccoz6hPK/ccache)
[19420] 1626829415.775247: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
krbtgt/IPA.DOMAIN(a)IPA.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with result:
0/Success
[19420] 1626829415.775248: Starting with TGT for client realm:
enrollmentaccount(a)IPA.DOMAIN -> krbtgt/IPA.DOMAIN(a)IPA.DOMAIN
[19420] 1626829415.775249: Retrieving enrollmentaccount(a)IPA.DOMAIN ->
krbtgt/AD.DOMAIN(a)AD.DOMAIN from FILE:/tmp/krbccoz6hPK/ccache with result:
-1765328243/Matching credential not found (filename:
/tmp/krbccoz6hPK/ccache)
[19420] 1626829415.775250: Requesting TGT krbtgt/AD.DOMAIN(a)IPA.DOMAIN using
TGT krbtgt/IPA.DOMAIN(a)IPA.DOMAIN
[19420] 1626829415.775251: Generated subkey for TGS request: aes256-cts/3835
[19420] 1626829415.775252: etypes requested in TGS request: aes256-cts,
aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac,
camellia128-cts, camellia256-cts
[19420] 1626829415.775254: Encoding request body and padata into FAST
request
[19420] 1626829415.775255: Sending request (1565 bytes) to IPA.DOMAIN
[19420] 1626829415.775256: Resolving hostname idmsrv01.ad.domain
[19420] 1626829415.775257: Initiating TCP connection to stream
10.xxx.xxx.xxx:88
[19420] 1626829415.775258: Sending TCP request to stream 10.xxx.xxx.xxx:88
[19420] 1626829415.775259: Received answer (482 bytes) from stream
10.xxx.xxx.xxx:88
[19420] 1626829415.775260: Terminating TCP connection to stream
10.xxx.xxx.xxx:88
[19420] 1626829415.775261: Response was from master KDC
[19420] 1626829415.775262: Decoding FAST response
[19420] 1626829415.775263: TGS request result: -1765328377/Server
krbtgt/AD.DOMAIN(a)IPA.DOMAIN not found in Kerberos database
Unable to download CA cert from LDAP but found preexisting cert, using it.
Joining realm failed: HTTP response code is 401, not 200
Installation failed. Rolling back changes.
(...)
So basically my interpretation is : the IPA client is trying to initiate a
Kerberos authentication which fails and being unable to do that it is
unable to get a valid credential for the IPA server which in turn results
in a 401 error when doing an XML RPC call on it. The account used for
enrollment is not locked, not expired and is having the correct roles
especially the enrollment capability.
Understanding "TGS request result: -1765328377/Server
krbtgt/AD.DOMAIN(a)IPA.DOMAIN" seems the key to my issue but I have no clue
on what to do at this point.
- My IPA server has no direct trust to AD.DOMAIN.
- Client and server are both using IPA 4.6.8
- Server certificates seem correct and not expired.
Any idea on what is going on / what to look at next?
Best regards,
Show replies by date