> 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 [email protected] 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: [email protected] 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 [email protected] [66437] 1620726204.077583: Getting initial credentials for [email protected] [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 [email protected]: [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 [email protected] [66437] 1620726208.906908: Storing [email protected] -> krbtgt/[email protected] in KCM:0:70821 [66437] 1620726208.906909: Storing config in KCM:0:70821 for krbtgt/[email protected]: pa_type: 2 [66437] 1620726208.906910: Storing [email protected] -> krb5_ccache_conf_data/pa_type/krbtgt\/AD.DOMAIN.COM\@AD.DOMAIN.COM@X-CACHECONF: in KCM:0:70821 [root@ipac1 ~]# kvno -S host ipac1.DOMAIN.COM [66459] 1620726244.069246: Getting credentials [email protected] -> host/[email protected] using ccache KCM:0:70821 [66459] 1620726244.069247: Retrieving [email protected] -> host/[email protected] from KCM:0:70821 with result: -1765328243/Matching credential not found [66459] 1620726244.069248: Retrieving [email protected] -> krbtgt/[email protected] from KCM:0:70821 with result: -1765328243/Matching credential not found [66459] 1620726244.069249: Retrieving [email protected] -> krbtgt/[email protected] from KCM:0:70821 with result: 0/Success [66459] 1620726244.069250: Starting with TGT for client realm: [email protected] -> krbtgt/[email protected] [66459] 1620726244.069251: Retrieving [email protected] -> krbtgt/[email protected] from KCM:0:70821 with result: -1765328243/Matching credential not found [66459] 1620726244.069252: Requesting TGT krbtgt/[email protected] using TGT krbtgt/[email protected] [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 [email protected] -> krbtgt/[email protected] from KCM:0:70821 with result: 0/Success [66459] 1620726244.069267: Found cached TGT for intermediate realm: [email protected] -> krbtgt/[email protected] [66459] 1620726244.069268: Retrieving [email protected] -> krbtgt/[email protected] from KCM:0:70821 with result: -1765328243/Matching credential not found [66459] 1620726244.069269: Requesting TGT krbtgt/[email protected] using TGT krbtgt/[email protected] [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/[email protected] [root@ipac1 ~]# klist -ef Ticket cache: KCM:0:70821 Default principal: [email protected] Valid starting Expires Service principal 11.05.2021 11:43:28 11.05.2021 23:43:28 krbtgt/[email protected] 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 _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
