On ma, 10 touko 2021, Owen Vincent via FreeIPA-users wrote:
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."
That checkbox is a red herring. When IPA creates trust to Active
Directory, we set flags that allow RC4-HMAC and AES ciphers
unconditionally already.
Windows UI is confusing in this place but it should not affect actual
operations.
I would recommend reading great blog from Jerry Devore from Microsoft:
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/decrypting-the-selection-of-supported-kerberos-encryption-types/ba-p/1628797
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-answered-can-i-disable-rc4-etype-for-kerberos-on/ba-p/382718
The most important parts are:
- user principal entry in AD must allow AES keys
- the domain where user is placed must have AES keys for its krbtgt.
- the trust path between that domain and the forest root of its forest
must have AES keys
- trust between IPA and AD forest root must have AES keys
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.
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
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
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
