Hi everyone, Up front, a tl;dr, we are having trouble getting our FreeIPA cross-forest trust to allow us to authenticate AD users on our Linux machines using ssh. It seems like the AD is only allowing RC4 encryption and won’t allow us to enable AES encryption. The “the other domain supports Kerberos AES encryption” checkbox in AD’s trust settings is grayed out and cannot be set. Trying to manually set msDS-SupportedEncryptionTypes to 24 or 28 (or 0x18, 0x1c) results in the following error: "Operation failed. Error code: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted. 00002077: SvcErr: DSID-0319039A, problem 5003 (WILL_NOT_PERFORM), data 0."
The main questions are: is there something that needs to be set on the FreeIPA side for AD to allow these settings to be enabled? Have you encountered similar issues in the past? Do you have any ideas what we could try to get authentication working? There are also some less pressing questions at the bottom of the post, in case you have any answers to those. Thanks in advance! Best, Owen The longer version: I’ve been trying to get this to work for a couple of weeks now and each time I solve one problem, another pops up. I think I have narrowed it down to one of the final issues, but given the way things have been going, I could well be wrong. I have tried to find more information online, but nothing really seems to fit my situation, so I decided to ask you guys for help. First off a little background information, this is setup is at a relatively large organization with a well established AD. I have don’t have admin access on the AD controllers, but do have read access, it doesn’t allow me to see some things (e.g. all of the AES encryption check boxes are grayed out when I look on my user). The AD admin has been very agreeable overall and has done the things we have asked them to do, but hasn’t taken much initiative in helping solve the problem, so we need to be as precise and descriptive as possible when making suggestions. The AD setup seems to be a little weird (though I’m not sure as I don’t have much experience with windows servers and AD). The domain controllers are all running Windows Server 2016, the domain functional level is 2012 R2, and the forest functional level is 2008 R2. I have the feeling that this might be part of the problem, but again, I don’t have much experience with windows. Where we stand now: we have successfully established a one-way cross-forest trust between the AD root domain and our FreeIPA installation. Both on the AD side and on our side DNS is run separate from AD/FreeIPA, in case that matters, but the necessary entries are configured and were working well enough to establish the trust. On the FreeIPA machines we can run getent passwd user1@AD and get a valid response, ID View overrides are also in effect when using getent (ID Views are the primary reason for trying to setup FreeIPA), however those users are unable to login via ssh. At this point when we try to login via ssh we get this error the journal on the FreeIPA server we are trying to login to: krb5_child[3343]: KDC has no support for encryption type and this in /var/log/sssd/krb5_child.log: (2021-05-10 10:49:12): [krb5_child[3343]] [validate_tgt] (0x0020): TGT failed verification using key for [host/[email protected]]. (2021-05-10 10:49:12): [krb5_child[3343]] [get_and_save_tgt] (0x0020): 1762: [-1765328370][KDC has no support for encryption type] (2021-05-10 10:49:12): [krb5_child[3343]] [map_krb5_error] (0x0020): 1854: [-1765328370][KDC has no support for encryption type] (I can provide more detailed logs in needed, though I would prefer not to do that on a public channel) When doing a packet capture (tcpdump/wireshark) of this login attempt we can see: 1) a successful AS-REQ and AS-REP for CNameString IPA$ in realm AD.DOMAIN.COM for SnameString krbtgt/AD.DOMAIN.COM 2) a successful TGS-REQ and TGS-REP in realm AD.DOMAIN.COM for SnameString ldap/adc01.ad.domain.com 3) a successful encrypted LDAP session between the freeipa machine and adc01.ad.domain.com 4) the same process in 1-3 for adc02.ad.domain.com as well 5) a successful AS-REQ and AS-REP for CNameString [email protected] in realm AD.DOMAIN.COM for SnameString krbtgt/AD.DOMAIN.COM 6) a failed TGS-REQ and TGS-REP in realm AD.DOMAIN.COM for SnameString krbtgt/IPA.DOMAIN.COM with the error: KRB5KDC_ERR_ETYPE_NOSUPP This lead us to some googling and then testing with the following added to our /etc/krb5.conf.d/freeipa file: 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 (Note: I know we RC4 is not advisable, this was a test to figure out what was going on.) Which got us a step further, now when trying to authenticate we would get this error in our journal: krb5_child[2159]: KDC returned error string: PROCESS_TGS and this in /var/log/sssd/krb5_child.log: (2021-05-10 10:45:25): [krb5_child[2159]] [validate_tgt] (0x0020): TGT failed verification using key for [host/[email protected]]. (2021-05-10 10:45:25): [krb5_child[2159]] [get_and_save_tgt] (0x0020): 1762: [-1765328324][KDC returned error string: PROCESS_TGS] (2021-05-10 10:45:25): [krb5_child[2159]] [map_krb5_error] (0x0020): 1854: [-1765328324][KDC returned error string: PROCESS_TGS] Again, this let to some googling, after which we added the following line to our /etc/sssd/sssd.conf [global] section: krb5_validate = False (Note: I know turning off krb5 validation is not a good idea, this was a test to figure out what was going on.) At this point AD users could successfully login via ssh on the FreeIPA servers. When they were logging in the packet capture looked very similar to the previous packet capture from above, with the exception that step 6 resulted in a successful TGS-REQ and TGS-REP, however using eTYPE-ARCFOUR-HMAC-MD5, while the rest of the exchange was done entirely in eTYPE-AES256-CTS-HMAC-SHA1-96. The whole point of going through all that was to try to narrow down where the configuration issue is. It definitely appears to be that that AD is not allowing AES encryption to be used for a necessary part of the trust relationship, which is causing problems. In the AD Trust settings the “the other domain supports Kerberos AES encryption” checkbox is grayed out and cannot be set. When you open the trust in AD’s ADSI Editor you can see that msDS-SupportedEncryptionTypes is <not set>, which means it defaults to 0 or only RC4 (which is also how it’s behaving). When trying to manually set msDS-SupportedEncryptionTypes to 24 or 28 (or 0x18, 0x1c) results in the following error: "Operation failed. Error code: 0x2077 Illegal modify operation. Some aspect of the modification is not permitted. 00002077: SvcErr: DSID-0319039A, problem 5003 (WILL_NOT_PERFORM), data 0." I wasn’t able to find any really helpful information about the check box being grayed out. The most extensive discussion I could find was this link: https://social.technet.microsoft.com/Forums/en-US/7f43b815-46a8-483c-a8d7-4300e37f084e/enable-kerberos-aes-encryption-on-an-existing-oneway-trust?forum=winserverDS But that only vaguely suggests recreating the trust might help. We have already recreated the trust on both ends and it hasn’t enabled the check box. I also looked up the “Operation failed. Error code: 0x2077 Illegal modify operation.” error and found this: https://community.spiceworks.com/topic/1824257-cannot-change-domain-attributes-server-2008-policy-problem But this one discusses password related GPO information. I don’t know if that would affect the msDS-SupportedEncryptionTypes attribute in the same way, or if that attribute has a GPO related setting. It also discusses the default domain policy being corrupted, which I’m a little worried about implying, as I’m not sure if the agreeableness of the AD Admin would continue into rebuilding the default domain policy. If you have read this far, thank you for your dedication. I know it was a lot, but I wanted to be thorough. Now for the questions: Is there something that needs to be set on the FreeIPA side for AD to allow the Kerberos AES encryption checkbox to be enabled? Have you encountered similar issues in the past? Do you have any ideas what we could try to get authentication working with proper encryption? Is there anything else we aren’t not thinking about that you think would be relevant to this situation? Of lesser importance: Why is there a validation error after enabling RC4 but before disabling krb5 validation? Is it because RC4 is deprecated? Or is there another reason? (we DON’T want to use RC4, we’re just curious) Again, Thanks in advance! 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
