Hi Alexander, Thank you for your response.
> On ma, 10 touko 2021, Owen Vincent via FreeIPA-users wrote: > > That checkbox is a red herring. It’s good to know that the checkbox is a red herring, but before I stop worrying about it entirely, I have one clarifying question: I understood from my reading that this checkbox should set the msDS-SupportedEncryptedType to 0x18 or 28, so only AES128 and AES256. Whether or not the box is checked, msDS-SupportedEncryptionTypes should be set to 0x18 or 0x1c (both AES and RC4) when viewed in the AD ADSI Editor correct? Or is that attribute in AD also a red herring? > When IPA creates trust to Active > Directory, we set flags that allow RC4-HMAC and AES ciphers > unconditionally already. One thing I don’t understand is that if FreeIPA automatically sets flags that allow RC4 when creating the trust with AD, why does setting default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 rc4-hmac in /etc/krb5.conf.d/freeipa make a difference in how authentication works? Is that an indication that the trust wasn’t setup properly and we should, in fact, tear down the trust on both sides and start over? Also, when you say flags are set that allow RC4-HMAC and AES ciphers unconditionally, I assume you are referring to the FreeIPA side of the equation, correct? If so, I believe I can confirm that as the ipaNTTrustedDOmain object under cn=trusts,cn=ad does have ipaNTSupportedEncryptionTypes set to 28. > I would recommend reading great blog from Jerry Devore from Microsoft: > https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/d... > the blog covers in detail how Windows systems operate with Kerberos. > Also, for debugging AD side and enforcing settings for the domain trust > see > https://techcommunity.microsoft.com/t5/itops-talk-blog/tough-questions-an... I had a look at these links and on the one hand it gave me a better understanding of the process that’s happening during authentication, but it also raised some questions which I will address below. I will also definitely have our AD Admin try the ksetup method of setting the supported encryption types. > The most important parts are: > - user principal entry in AD must allow AES keys This seems like it could be a problem, as from my (AD account’s) perspective, almost no users have the msDS-Supported-Encryption-Types attribute set or the boxes enabling AES encryption checked, which should mean they would default only to RC4. The problem is that even when I create a user under an ou in the AD forest root domain that I have control over and explicitly allow AES keys, the result is the same as another user without AES keys allowed. Therefore it must currently be another issue preventing authentication. > - the domain where user is placed must have AES keys for its krbtgt. This, is unfortunately similar to the situation with the users. Both of the users referenced above are in the AD forest root domain, and all of the domain controllers have msDS-SupportedEncryptionTypes set to 28/0x1c. The weird part is that the cn=krbtgt,cn=Users,dc=ad object has msDS-SupportedEncryptionTypes set to 0 rather than <not set>, but in the packet capture I mentioned in my original post shows the AS-REQ/AS-REP as well as TGS-REQ/TGS-REP within the AD domain as all using the aes256 cipher. Based on that I assume this one can’t be the problem, but it also leads me to believe that there is likely something other than the msDS-SupportedEncryptionTypes attribute that is controlling which ciphers are actually available. Is that possible? If so, any idea where/how it could be controlled? Group policy maybe? > - the trust path between that domain and the forest root of its forest > must have AES keys As the desired users are in the AD forest root domain and FreeIPA is directly connected to the AD forest, there isn’t a very long trust path, so I assume it’s safe to jump directly to the next point. Please correct me if this point and the next point represent different requirements in this situation. > - trust between IPA and AD forest root must have AES keys This is where it appears the current problem is coming from. Using user1@AD to ssh into host ipac1 causes an AES krbtgt/AD.DOMAIN.COM ticket to be be successfully issued for IPA$ (cn=IPA$,cn=Users,=dc=ad), again despite IPA$ not having msDS-SupportedEncryptionTypes set. Using that TGT an AES ldap/adc01.domain.com service ticket is successfully issued. An LDAP lookup occurs. Then an AES krbtgt/AD.DOMAIN.COM ticket is successfully issued for user1@AD. At this point if default settings are used on the FreeIPA side there is an AES TGS request for krbtgt/IPA.DOMAIN.COM within the AD realm, so the trusted domain object, using the AES krbtgt/AD.DOMAIN.COM ticket which returns an error that no encryption types are supported. If I manually enable RC4 on the KDC in the IPA.DOMAIN.COM realm, the same TGS request successfully returns an RC4 krbtgt/IPA.DOMAIN.COM service ticket for user1@AD, which is returned inside an AES TGS reply. This leads me to believe that, while the various users aren’t adversely affected by not having the msDS-SupportedEncryptionTypes attribute set, the trusted domain object is. > If one of these parts is missing, you wouldn't be able to acquire AES > service ticket cross-realm. > > The catch typically is for AD krbtgt and cross-realm trust keys inside > the AD forest. They are defaulting to RC4-HMAC so even if you have AES > keys in the user account, that wouild not be enough because the ticket > with AES key would only be useful to services inside the domain. Agreed. That’s what I was so focused on the silly checkbox in my first post and am now so focused on the msDS-SupportedEncryptionTypes attributes of the various objects in this post. The problem that I see based on the description above is that the settings and the actual responses don’t seem to add up. Sometimes things that don’t seem to have AES enabled can work with AES and other times (specifically with the trusted domain object in AD) it seems that the settings are working correctly. Our problem is that we can’t figure out how to actually change the settings on the trusted domain object to actually enable AES. Which leads to the same question as above, are there any other places that available/allowed encryption types can be set or controlled? Again, thanks for your help. 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
