On ti, 11 touko 2021, Owen Vincent via FreeIPA-users wrote:
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?
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.
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?
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.
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.
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$@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.
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.
If your user has no AES keys, that's your problem -- these users cannot
communicate with any Kerberos service that has only AES keys.
- 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 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.
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.
- 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.
For users in the forest root that's right.
- 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.
Can you show me output of
export KRB5_TRACE=/dev/stderr
kinit user1@AD.DOMAIN
kvno -S host server.ipa.domain
klist -ef
from IPA master?
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.
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.
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?
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.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
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/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
