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.
I’m not sure if that is important or not, but I wanted to let you know in case that
changes things in any way.
These are unrelated. What IPA sets in the trust configuration is
unrelated to what Kerberos clients consider when initializing the
library.
What you see in krb5.conf and included files is a client side
configuration. On RHEL/Fedora/CentOS we use system-wide crypto policies
which limit what encryption types can be allowed by default in crypto
policies. The DEFAULT policy (can be checked with
'update-crypto-policies --show') does not allow RC4-HMAC usage. We have
added AD-SUPPORT subpolicy to allow getting back RC4-HMAC in Kerberos
for the cases where you cannot use AES encryption. Again, this is purely
client side behavior.
An easiest way to see that is to compare output from:
# update-crypto-policies --show
DEFAULT
# ipa-getkeytab --permitted-enctypes
Supported encryption types:
AES-256 CTS mode with 96-bit SHA-1 HMAC
AES-256 CTS mode with 192-bit SHA-384 HMAC
AES-128 CTS mode with 128-bit SHA-256 HMAC
AES-128 CTS mode with 96-bit SHA-1 HMAC
# update-crypto-policies --set DEFAULT:AD-SUPPORT
Setting system policy to DEFAULT:AD-SUPPORT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
# ipa-getkeytab --permitted-enctypes
Supported encryption types:
AES-256 CTS mode with 96-bit SHA-1 HMAC
AES-256 CTS mode with 192-bit SHA-384 HMAC
AES-128 CTS mode with 128-bit SHA-256 HMAC
AES-128 CTS mode with 96-bit SHA-1 HMAC
ArcFour with HMAC/md5
]# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
'ipa-getkeytab --permitted-enctypes' just prints the list of the
encryption types enabled by default in Kerberos client configuration.
This is super helpful, thank you for clarifying where which parts of Kerberos are looking
in which places for their encryption information. I was getting a bit mixed up as I am
essentially using the FreeIPA server for multiple roles in the Kerberos process during
these tests.
It is symmetrical -- what is set on IPA side is set to IPA trusted
domain object (TDO) on AD side too.
Please note that TDOs are special -- the object for trusted domain has a
corresponding user object that is used for authentication. They
connected together but they are not the same.
The TDO LDAP entry can be found with the LDAP search I specified above.
The user object has its name set to the flat name (NetBIOS name) of the
trusted domain plus '$' sign:
ldapsearch -Y GSSAPI -h dc.ad.test -b dc=ad,dc=test '(sAMAccountName=IPA$)'
When SSSD on IPA master needs to resolve AD users, it uses IPA$(a)AD.TEST
principal to talk to AD LDAP. This account maps to the user object with
sAMAccountName: IPA$. But when AD DCs create cross-realm TGTs, they look
into the trusted domain object content.
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)
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.
When a Kerberos client asks for a service ticket to that account
(service), AD DC would look at the requested encryption types of the
client request, at msDS-SupportedEncryptionTypes of the service account,
and would generate the keys with encryption type that overlaps. It can
do so in AD because for each AD security object it knows the actual
password, not just Kerberos keys.
See MS-KILE 3.3.5.7 for some details. In particular, for krbtgt
principals, the actual encryption types value is hardcoded to 0x1f, e.g.
all DES, RC4, AES types are allowed by default.
For users in the forest root that's right.
Glad I understood that correctly.
Can you show me output of
export KRB5_TRACE=/dev/stderr
kinit user1(a)AD.DOMAIN
kvno -S host server.ipa.domain
klist -ef
from IPA master?
Please show the output for the above sequence. Again, the content of the
attribute is irrelevant for actual ticket requests, it only matters when
an entry is created.
[root@ipac1 ~]# export KRB5_TRACE=/dev/stderr
[root@ipac1 ~]# kinit user1(a)AD.DOMAIN.COM
[66437] 1620726204.077583: Getting initial credentials for user1(a)AD.DOMAIN.COM
[66437] 1620726204.077585: Sending unauthenticated request
[66437] 1620726204.077586: Sending request (195 bytes) to
AD.DOMAIN.COM
[66437] 1620726204.077587: Initiating TCP connection to stream 10.10.10.10:88
[66437] 1620726204.077588: Sending TCP request to stream 10.10.10.10:88
[66437] 1620726204.077589: Received answer (202 bytes) from stream 10.10.10.10:88
[66437] 1620726204.077590: Terminating TCP connection to stream 10.10.10.10:88
[66437] 1620726204.077591: Response was from master KDC
[66437] 1620726204.077592: Received error from KDC: -1765328359/Additional
pre-authentication required
[66437] 1620726204.077595: Preauthenticating using KDC method data
[66437] 1620726204.077596: Processing preauth types: PA-PK-AS-REQ (16), PA-PK-AS-REP_OLD
(15), PA-ETYPE-INFO2 (19), PA-ENC-TIMESTAMP (2)
[66437] 1620726204.077597: Selected etype info: etype aes256-cts, salt
"AD.DOMAIN.COMuser1", params ""
[66437] 1620726204.077598: PKINIT client has no configured identity; giving up
[66437] 1620726204.077599: PKINIT client has no configured identity; giving up
[66437] 1620726204.077600: Preauth module pkinit (16) (real) returned: 22/Invalid
argument
Password for user1(a)AD.DOMAIN.COM:
[66437] 1620726208.906890: AS key obtained for encrypted timestamp: aes256-cts/003C
[66437] 1620726208.906892: Encrypted timestamp (for 1620726209.743279): plain
301AA011495813617268726182745479618241249165928261961151, encrypted
FB00982375039456203576203457926034952039456293765918756918756198756198327561928756192875619287561928576192857612
[66437] 1620726208.906893: Preauth module encrypted_timestamp (2) (real) returned:
0/Success
[66437] 1620726208.906894: Produced preauth for next request: PA-ENC-TIMESTAMP (2)
[66437] 1620726208.906895: Sending request (275 bytes) to
AD.DOMAIN.COM
[66437] 1620726208.906896: Initiating TCP connection to stream 10.10.10.10:88
[66437] 1620726208.906897: Sending TCP request to stream 10.10.10.10:88
[66437] 1620726208.906898: Received answer (1818 bytes) from stream 10.10.10.10:88
[66437] 1620726208.906899: Terminating TCP connection to stream 10.10.10.10:88
[66437] 1620726208.906900: Response was from master KDC
[66437] 1620726208.906901: Processing preauth types: PA-ETYPE-INFO2 (19)
[66437] 1620726208.906902: Selected etype info: etype aes256-cts, salt
"AD.DOMAIN.COMuser1", params ""
[66437] 1620726208.906903: Produced preauth for next request: (empty)
[66437] 1620726208.906904: AS key determined by preauth: aes256-cts/003C
[66437] 1620726208.906905: Decrypted AS reply; session key is: aes256-cts/54FD
[66437] 1620726208.906906: FAST negotiation: unavailable
[66437] 1620726208.906907: Initializing KCM:0:70821 with default princ
user1(a)AD.DOMAIN.COM
[66437] 1620726208.906908: Storing user1(a)AD.DOMAIN.COM ->
krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM in KCM:0:70821
[66437] 1620726208.906909: Storing config in KCM:0:70821 for
krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM: pa_type: 2
[66437] 1620726208.906910: Storing user1(a)AD.DOMAIN.COM ->
krb5_ccache_conf_data/pa_type/krbtgt\/AD.DOMAIN.COM\@AD.DOMAIN.COM(a)X-CACHECONF: in
KCM:0:70821
[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
[66459] 1620726244.069265: Trying next closer realm in path:
AD.DOMAIN.COM
[66459] 1620726244.069266: Retrieving user1(a)AD.DOMAIN.COM ->
krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM from KCM:0:70821 with result: 0/Success
[66459] 1620726244.069267: Found cached TGT for intermediate realm: user1(a)AD.DOMAIN.COM
-> krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM
[66459] 1620726244.069268: 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.069269: Requesting TGT krbtgt/IPA.DOMAIN.COM(a)AD.DOMAIN.COM using TGT
krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM
[66459] 1620726244.069270: Generated subkey for TGS request: aes256-cts/7C4B
[66459] 1620726244.069271: etypes requested in TGS request: aes256-cts, aes256-sha2,
camellia256-cts, aes128-cts, aes128-sha2, camellia128-cts
[66459] 1620726244.069273: Encoding request body and padata into FAST request
[66459] 1620726244.069274: Sending request (1983 bytes) to
AD.DOMAIN.COM
[66459] 1620726244.069275: Initiating TCP connection to stream 10.10.10.10:88
[66459] 1620726244.069276: Sending TCP request to stream 10.10.10.10:88
[66459] 1620726245.116625: Received answer (370 bytes) from stream 10.10.10.10:88
[66459] 1620726245.116626: Terminating TCP connection to stream 10.10.10.10:88
[66459] 1620726245.116627: Response was from master KDC
[66459] 1620726245.116628: Decoding FAST response
[66459] 1620726245.116629: TGS request result: -1765328370/KDC has no support for
encryption type
kvno: KDC has no support for encryption type while getting credentials for
host/ipac1.DOMAIN.COM(a)IPA.DOMAIN.COM
[root@ipac1 ~]# klist -ef
Ticket cache: KCM:0:70821
Default principal: user1(a)AD.DOMAIN.COM
Valid starting Expires Service principal
11.05.2021 11:43:28 11.05.2021 23:43:28 krbtgt/AD.DOMAIN.COM(a)AD.DOMAIN.COM
renew until 12.05.2021 11:43:24, Flags: FRIA
Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
[root@ipac1 ~]#
Depends on where you are looking them to be applied. Remember that there
are three sides of the communication here: Kerberos clients, Kerberos
KDCs, and Kerberos servers. Clients choose to use certain encryption
types in their requests to the Kerberos KDCs. KDCs respond with what
they consider right within the client's claimed encryption types. Then
clients use the returned tickets to talk to Kerberos servers.
At each point there might be incompatibility between the encryption
types requested and encryption types supported by the other side.
For IPA clients, the default Kerberos encryption types to be used by the
client apps are defined in krb5.conf/system-wide crypto policy.
For AD clients, the default Kerberos encryption types to be used by the
client apps are defined by Windows group policies.
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?
Thanks again!
Best,
Owen