Thank you Alexander for your response and for clarifying on the observed behaviour.
> 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. If the initial AS, TGT and TGS have agreed upon the common encryption types, at what stage is the denial occurring? Because, I do not see any logs when it is unsuccessful. > 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). So if I understand this correctly, despite having permitted_enctypes set to all of these, 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, KDC prefers the strongest encryption, which perhaps is the aes256-cts-hmac-sha384-192. Obviously the Windows OS does not support this type. If this is the case, how are the AS, TGT and TGS successful and not the final login? -- _______________________________________________ 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
