On Пят, 01 сне 2023, Deepak Ramanath via FreeIPA-users wrote:
I have a Windows 10 server joined to a RedHat IDM (RHEL 8.9) realm
using Kerberos. When a user tries to authenticate on a Windows 10
server, the following error is shown
Just to be clear, we explicitly do not support this use case. Any
success on this path is a mistake of yours. ;)
"We cannot sign you in with this credential because your domain isn't
available"
On the IDM, looking at the `/var/log/krb5kdc.log`, I see the following...
Nov 30 23:08:17 idm.server.local krb5kdc[11775](info): AS_REQ (6 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
DEPRECATED:arcfour-hmac(23),
DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135),
UNSUPPORTED:des-cbc-md5(3)})
192.168.124.55: NEEDED_PREAUTH: win.user(a)server.local for
krbtgt/server.local(a)server.local, Additional pre-authentication required
Nov 30 23:08:17 idm.server.local krb5kdc[11774](info): AS_REQ (6 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
DEPRECATED:arcfour-hmac(23),
DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135),
UNSUPPORTED:des-cbc-md5(3)})
192.168.124.55: ISSUE: authtime 1701385697, etypes
{rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)},
win.user(a)server.local for krbtgt/server.local(a)server.local
Nov 30 23:08:17 idm.server.local krb5kdc[11775](info): TGS_REQ (5 etypes
{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17),
DEPRECATED:arcfour-hmac(23),
DEPRECATED:arcfour-hmac-exp(24), UNSUPPORTED:(-135)}) 192.168.124.55: ISSUE:
authtime
1701385697, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18),
ses=aes256-cts-hmac-sha1-96(18)}, win.user(a)server.local for
host/win-server.server.local(a)server.local
I don't see any problem above: tickets requested by the client with IP
192.168.124.55 were issued by the KDC, so clearly they've got common
enctypes between them.
In the `/etc/crypto-policies/back-ends/krb5.config`, `libdefaults` has been set
to
[libdefaults]
permitted_enctypes = aes256-cts-hmac-sha384-192 aes128-cts-hmac-sha256-128
aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 camellia256-cts-cmac
camellia128-cts-cmac
Interestingly, if all encryption types are removed except
aes256-cts-hmac-sha1-96 from the
permitted_enctypes, the authentication on Windows 10 is successful.
Any idea why only setting to aes256-cts-hmac-sha1-96 works while a list of
supported
methods including aes256-cts-hmac-sha1-96 does not?
Windows systems do not support RFC8009 encryption types (SHA-2-based) at
all. Microsoft engineer gave a hint they are working on their support
for ~2025 but it will not be backported.
IPA KDC defaults to RFC8009 and only falls back to SHA-1-based ones
for trust to Active Directory. There are few places in MIT Kerberos KDC
where a choice of the signature or encryption type is made based on the
strongest key available for the krbtgt/... principal, which is always a
SHA-2-based one for new IPA deployments. For cross-realm operations we
have special logic to fall back to SHA-1-based ones for AD DCs. For
in-realm operations we don't and shouldn't as it would be a security
issue (downgrade of encryption algorithm to a less secure one).
--
/ 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, report it:
https://pagure.io/fedora-infrastructure/new_issue
