On ti, 11 touko 2021, Owen Vincent via FreeIPA-users wrote:
> On ti, 11 touko 2021, Owen Vincent via FreeIPA-users wrote:
>
> The attribute should be correct. When doing
>
> ldapsearch -Y GSSAPI -h dc.ad.test -b dc=ad,dc=test
'(trustPartner=ipa.test)'
>
> I see 'msDS-SupportedEncryptionTypes: 28', so for me a normal
> 'ipa trust-add' adds it properly.
>
This appears to be a problem. I was referring to the actual domain controller entries, but
you are talking about the TDO.
When I run kinit user1(a)AD.DOMAIN.COM and then ldapsearch -Y GSSAPI -h
adc01.ad.domain.com
-b dc=ad,dc=domain,dc=com '(trustPartner=ipa.domain.com)'
I get output that doesn’t include 'msDS-SupportedEncryptionTypes: 28'
owen@comp1:~$ ldapsearch -Y GSSAPI -h
adc01.ad.domain.com -b dc=ad,dc=domain,dc=com
'(trustPartner=ipa.domain.com)'
SASL/GSSAPI authentication started
SASL username: user1(a)AD.DOMAIN.COM
SASL SSF: 256
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <dc=ad,dc=domain,dc=com> with scope subtree
# filter: (
trustPartner=ipa.domain.com)
# requesting: ALL
#
#
ipa.domain.com, System,
ad.domain.com
dn: CN=ipa.domain.com,CN=System,DC=ad,DC=domain,DC=com
objectClass: top
objectClass: leaf
objectClass: trustedDomain
cn:
ipa.domain.com
distinguishedName: CN=ipa.domain.com,CN=System,DC=ad,DC=DOMAIN,DC=com
instanceType: 4
whenCreated: 20210506041904.0Z
whenChanged: 20210506042016.0Z
uSNCreated: 662239512
uSNChanged: 662241863
showInAdvancedViewOnly: TRUE
name:
ipa.domain.com
objectGUID:: aakw3zasieufhnieufzasgke
securityIdentifier:: alasdmahlskzhabskejfhanskdhfkasd
trustDirection: 1
trustPartner:
ipa.domain.com
trustPosixOffset: 0
trustType: 2
trustAttributes: 8
flatName: IPA
objectCategory: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=ad,DC=domain,DC=com
isCriticalSystemObject: TRUE
dSCorePropagationData: 16010101000000.0Z
msDS-TrustForestTrustInfo:: aksdfgbasjdfhnkasjdhgfskjdhfgkasjdhfnbaksdhfaksjd
aksdfgbasjdsldfijhasndfkskfhnkasjdhgfskjdhfgkaap9zpasouisdfsjdhfnbaksdhfaksjd
aksdfgbasjdsldfijhasndfkskfhnkasjdhgfskjdhfgkaap9zpasouisdfsjdhfn
That would mean something went wrong with the initial creation of the
trust, correct?
Also, I realize now that I may have left out a relevant/significant bit
of information in my initial posts. I mentioned that this is a one-way
trust, but it was also created using a shared secret rather than AD
Admin credentials. It is much less of an issue for us to temporarily
create an admin account in FreeIPA for our counterparts on the AD side
to validate the trust than the other way around.
Yes, this is significant info. OK, this might explain *WHY* it happens.
When shared secret is used to create the trust, we have no credentials
to force the encryption types on the TDO and we rely on the defaults in
AD to do so. I suspect your problem here is that your AD defaults do not
set AES types with some group policy definition and thus only RC4-HMAC
is set there as it is a default one.
Can you try by adding msDS-SupportedEncryptionTypes: 28 to the TDO
object?
Then re-try the test sequence I gave you in the previous email.
If that doesn't work, re-establish the trust using AD admin credentials.
Shared secret trust has a lot of limitations. For example, we cannot use
it in FIPS mode because we cannot activate AD side of the trust with it
(NTLMSSP is not supported in FIPS), we always have to use Kerberos and
Kerberos would not work in FIPS mode for RC4-HMAC. It also doesn't work
for non-FIPS environment by default in RHEL 8.3+/Fedora because
system-wide crypto policy blocks RC4-HMAC.
This is more or less how I understood things, so I’m glad you confirmed
it for me. One question here, does the IPA$ user on your setup also
have 'msDS-SupportedEncryptionTypes: 28' or only the TDO. On my end it
is missing the 'msDS-SupportedEncryptionTypes: 28' attribute, however
it is still able to get an AES krbtgt in the AD realm. (see the logs
below)
IPA$ doesn't have msDS-SupportedEncryptionTypes. It is mostly set on
service principals, as per MS-KILE. Note that IPA$ is not used for
cross-realm communication, TDO does. IPA$ is only used by SSSD to talk
to AD DC to lookup identities and it doesn't require cross-realm to work
because IPA$ principal is within AD domain.
>
> If your user has no AES keys, that's your problem -- these users cannot
> communicate with any Kerberos service that has only AES keys.
>
Similar to what happens with the IPA$ user, based on the logs below
user1@AD is able to get AES tickets even though there is no
'msDS-SupportedEncryptionTypes: 28' attribute for the user and the AES
check boxes aren’t checked in the GUI.
>
> The msDS-SupportedEncryptionTypes attribute is only used by AD DCs in
> two cases:
>
> - when creating new keys for the account, or
> - when creating service tickets to the account
>
> Let's say, you are changing a password. I think value '0' would refer to
> a default setting for the domain. The presence of a particular value in
> the attribute does not mean nothing. What matters is what keys were
> created by the DC at the password change time.
>
It also seems very likely to me that either a 0 or a <not set> value
would refer to a default setting for the domain. As the behavior of the
various ciphers don’t match up to the settings. The question would be
where the default settings are stored, but that’s also clearly a
Windows question rather than a FreeIPA question.
Yes, this is something to find out in Windows documentation.
[root@ipac1 ~]# kvno -S host
ipac1.DOMAIN.COM
[66459] 1620726244.069246: Getting credentials user1(a)AD.DOMAIN.COM ->
host/ipac1.DOMAIN.COM(a)IPA.DOMAIN.COM using ccache KCM:0:70821
[66459] 1620726244.069247: Retrieving user1(a)AD.DOMAIN.COM ->
host/ipac1.DOMAIN.COM(a)IPA.DOMAIN.COM from KCM:0:70821 with result: -1765328243/Matching
credential not found
[66459] 1620726244.069248: Retrieving user1(a)AD.DOMAIN.COM ->
krbtgt/IPA.DOMAIN.COM(a)IPA.DOMAIN.COM from KCM:0:70821 with result: -1765328243/Matching
credential not found
[66459] 1620726244.069249: Retrieving user1(a)AD.DOMAIN.COM ->
krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM from KCM:0:70821 with result: 0/Success
[66459] 1620726244.069250: Starting with TGT for client realm: user1(a)AD.DOMAIN.COM ->
krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM
[66459] 1620726244.069251: Retrieving user1(a)AD.DOMAIN.COM ->
krbtgt/IPA.DOMAIN.COM(a)IPA.DOMAIN.COM from KCM:0:70821 with result: -1765328243/Matching
credential not found
[66459] 1620726244.069252: Requesting TGT krbtgt/IPA.DOMAIN.COM(a)AD.DOMAIN.COM using TGT
krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM
[66459] 1620726244.069253: Generated subkey for TGS request: aes256-cts/1482
[66459] 1620726244.069254: etypes requested in TGS request: aes256-cts, aes256-sha2,
camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[66459] 1620726244.069256: Encoding request body and padata into FAST request
[66459] 1620726244.069257: Sending request (1983 bytes) to
AD.DOMAIN.COM
[66459] 1620726244.069258: Initiating TCP connection to stream 10.10.10.10:88
[66459] 1620726244.069259: Sending TCP request to stream 10.10.10.10:88
[66459] 1620726244.069260: Received answer (370 bytes) from stream 10.10.10.10:88
[66459] 1620726244.069261: Terminating TCP connection to stream 10.10.10.10:88
[66459] 1620726244.069262: Response was from master KDC
[66459] 1620726244.069263: Decoding FAST response
[66459] 1620726244.069264: TGS request result: -1765328370/KDC has no support for
encryption type
Yep, this means krbtgt/IPA@AD does not have AES encryption type keys.
Which is explainable with shared secret trust and default AD group
policy for the encryption types.
It seems like it it needs to be applied to the TDO. I think based on
the above there are settings being applied to users that are enabling
AES ciphers, but they don’t appear to have the same effect on the TDO.
As I said above, how the users are setup is clearly a more Windows
related question and as long as they work, I’m happy. The only reason
it would be interesting to know how it’s being done is because there
seems to be something preventing us from setting the
msDS-SupportedEncryptionTypes attribute on the TDO (grayed out check
box in the GUI and the error from my initial post when setting the
attribute directly with ADSI Editor) and it might be related.
I asked the AD Admin to try running the ksetup /setenctypeattr command
from one of the links you sent me. Hopefully that works and will get
AES enabled on the TDO.
If not, do you think recreating the trust would be the way to go?
Re-creating with admin credentials should work. If you are able to find
out if TDO can be updated as it is, please report back. Sadly, we simply
have no way to update the entry from IPA side without AD admin
credentials until the trust is verified.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland