5:55 a.m.
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/ipac1.domain.com(a)IPA.DOMAIN.COM].
(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 user1(a)DOMAIN.COM 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/ipac1.domain.com(a)IPA.DOMAIN.COM].
(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...
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-attri...
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