Kvno error on validating one-way trust: "kvno: Decrypt integrity check failed while getting credentials"
Hi All,
I am setting up a one-way trust from FreeIPA server to AD domain with a pre-shared key.
It seems that it was set up successfully but I cannot verify the Kerberos configuration when I follow the steps described here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm....
Although I successfuly kinit with a username from AD domain and obtain a ticket:
klist Ticket cache: KEYRING:persistent:0:0 Default principal: testuser@DOMAIN.COM
Valid starting Expires Service principal 08/22/2017 09:47:41 08/22/2017 19:47:41 krbtgt/DOMAIN.COM@DOMAIN.COM renew until 08/23/2017 09:47:34
I am not able to request service tickets for a service within IdM domain:
[root@idm1 ~]# KRB5_TRACE=/dev/stdout kvno -S host idm1.ipa.domain.com [16119] 1503409696.153004: Getting credentials testuser@DOMAIN.COM -> host/idm1.ipa.domain.com@IPA.DOMAIN.COM using ccache KEYRING:persistent:0:0 [16119] 1503409696.153288: Retrieving testuser@DOMAIN.COM -> host/idm1.ipa.domain.com@IPA.DOMAIN.COM from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16119] 1503409696.153422: Retrieving testuser@DOMAIN.COM -> krbtgt/IPA.DOMAIN.COM@IPA.DOMAIN.COM from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16119] 1503409696.153520: Retrieving testuser@DOMAIN.COM -> krbtgt/DOMAIN.COM@DOMAIN.COM from KEYRING:persistent:0:0 with result: 0/Success [16119] 1503409696.153536: Starting with TGT for client realm: testuser@DOMAIN.COM -> krbtgt/DOMAIN.COM@DOMAIN.COM [16119] 1503409696.153600: Retrieving testuser@DOMAIN.COM -> krbtgt/IPA.DOMAIN.COM@IPA.DOMAIN.COM from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16119] 1503409696.153609: Requesting TGT krbtgt/IPA.DOMAIN.COM@DOMAIN.COM using TGT krbtgt/DOMAIN.COM@DOMAIN.COM [16119] 1503409696.153663: Generated subkey for TGS request: aes256-cts/A13D [16119] 1503409696.153718: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4 [16119] 1503409696.153875: Encoding request body and padata into FAST request [16119] 1503409696.153942: Sending request (1851 bytes) to DOMAIN.COM [16119] 1503409696.154236: Resolving hostname domain.com [16119] 1503409696.290796: Initiating TCP connection to stream 10.10.10.10:88 [16119] 1503409696.398086: Sending TCP request to stream 10.10.10.10:88 [16119] 1503409696.836098: Received answer (1551 bytes) from stream 10.10.10.10:88 [16119] 1503409696.836121: Terminating TCP connection to stream 10.10.10.10:88 [16119] 1503409696.836212: Response was from master KDC [16119] 1503409696.836258: Decoding FAST response [16119] 1503409696.836423: TGS reply is for testuser@DOMAIN.COM -> krbtgt/ipa.domain.com@DOMAIN.COM with session key aes256-cts/C0B1 [16119] 1503409696.836454: TGS request result: 0/Success [16119] 1503409696.836461: Received TGT for offpath realm ipa.domain.com [16119] 1503409696.836468: Requesting TGT krbtgt/IPA.DOMAIN.COM@ipa.domain.com using TGT krbtgt/ipa.domain.com@DOMAIN.COM [16119] 1503409696.836486: Generated subkey for TGS request: aes256-cts/743D [16119] 1503409696.836523: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts, des-cbc-crc, des, des-cbc-md4 [16119] 1503409696.836579: Encoding request body and padata into FAST request [16119] 1503409696.836648: Sending request (1854 bytes) to ipa.domain.com [16119] 1503409696.904352: Resolving hostname idm1.ipa.domain.com. [16119] 1503409696.938147: Sending initial UDP request to dgram 10.10.10.11:88 [16119] 1503409696.943465: Received answer (146 bytes) from dgram 10.10.10.11:88 [16119] 1503409696.977047: Response was from master KDC [16119] 1503409696.977102: TGS request result: -1765328353/Decrypt integrity check failed kvno: Decrypt integrity check failed while getting credentials for host/idm1.ipa.domain.com@IPA.DOMAIN.COM
Can you please advise me on how to resolve this issue?
Bart
Behavior that I described above pertains to Windows 2008 R2. When I attempt at doing exactly the same with AD set up on top of Windows 2012, it works flawlessly. Unfortunately, environment I have to set up trust with uses Windows 2008 R2. I am wondering what might be the difference between these two versions that prevent trust from working in case of Windows 2008 R2.
On Wed, Aug 30, 2017 at 10:45:11AM -0000, bogusmaster--- via FreeIPA-users wrote:
Behavior that I described above pertains to Windows 2008 R2. When I attempt at doing exactly the same with AD set up on top of Windows 2012, it works flawlessly. Unfortunately, environment I have to set up trust with uses Windows 2008 R2. I am wondering what might be the difference between these two versions that prevent trust from working in case of Windows 2008 R2.
Can you send the KRB5_TRACE output for the 2012 case as well. What looks suspicious to me in the 2008R2 output is
TGS reply is for testuser@DOMAIN.COM -> krbtgt/ipa.domain.com@DOMAIN.COM with session key aes256-cts/C0B1
I would expect krbtgt/IPA.DOMAIN.COM@DOMAIN.COM here. AD typically does not care about cases in Kerberos principal but IPA's MIT Kerberos KDC does (because the RFC says Kerberos is case-sensitive).
bye, Sumit
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
On ti, 22 elo 2017, bogusmaster--- via FreeIPA-users wrote:
Hi All,
I am setting up a one-way trust from FreeIPA server to AD domain with a pre-shared key.
This is currently not working due to chicken/egg problem: in order to turn trust into an active one, you need to validate it. We do not have code in Samba-IPA integration that makes validation _from_ Windows side working, thus we can only validate it from Linux side. However, to do that, we should have *some* administrative account on AD side because our trusted domain object is not active yet.
There are two ways to get around it today: - use administrative credentials to establish one-way trust - establish two-way trust
Thank you. I checked in my test environment and setting trust with administrative credentials works.
I got mixed results for Windows 2012 and Windows 2008 R2 because I previously had set up trust using administrative credentials for Windows 2012. Later, even though I deleted it on FreeIPA's side, setting up trust with a pre-shared key just worked. The same scenario repeated for Windows 2008 R2.
On ke, 06 syys 2017, Bart J via FreeIPA-users wrote:
Thank you. I checked in my test environment and setting trust with administrative credentials works.
I got mixed results for Windows 2012 and Windows 2008 R2 because I previously had set up trust using administrative credentials for Windows 2012. Later, even though I deleted it on FreeIPA's side, setting up trust with a pre-shared key just worked. The same scenario repeated for Windows 2008 R2.
You did explicit 'ipa trust-del ...'? That only deletes the records on IPA side, AD doesn't know about that. Now, if you'd try to add a trust again with a shared secret, we are not going to be creating anything on AD side either (that's the purpose of a shared secret). So AD would think trust continues to exist and if you set the same secret there, it would just work.
Yes, I did explicit 'ipa trust-del ...". Thank you for the explanation.
I have a question related to my set up. Will setting up trust work with a child domain in AD (given I am using --external=true as an argument of ipa trust-add), or I have to set up trust with AD root domain? In other words, if I have domain.com and its child child.domain.com, will setting up trust with child.domain.com work?
Also, could you have a look at https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost... please?
I thought I have everything needed to set up trust in production but I am receivinge strange error there (can't replicate it in test environment, though).
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Bart J -
bogusmaster＠o2.pl
-
Sumit Bose