abbra

Thanks. I plan to remove rc4 stuff as well, this is a good opportunity to test interoperability.

MS-KILE, MS-LSAD and friends, where TDO creds must have rc4 enckey, for example. I haven't checked recently, may be this is fixed already.
Re: 2008 - this is what your link says, 2008 and later will be updated. It means 2008 will gain smb3 support to allow AES-based session key to replace rc4 use?

Would be happy to see the specs update as well. And backports to 2008 - great!

Glad you are getting some progress on making it more accessible.

Life doesn't spare anyone who remembers win95

... type is used by the client code when obtaining initial credentials. `kinit` in Heimdal provides an option to set that. So if RDP client on macOS does use enteprise principal type OID for GSSAPI import name, that should work.

It depends on the implementation. MIT Kerberos has `canonicalize = True` which should be set on AD clients. SSSD sets it automatically, for example, for both IPA and AD id providers. Heimdal doesn't have explicit configuration option for that but it forces canonicalization if enterprise principal...

Ah, is it Apple?

Maybe Microsoft could fix the client to actually follow MS-KILE?

If your clients are part of ad deployment, they really should follow MS-KILE in their settings. And that effectively means treating returned principal name case-insensitive. See "3.1.5.7 Internationalization and Case Sensitivity"

If that client is not using enterprise principals, it should definitely be fixed. The name might be anything in the response :)

I'm saying that kerberos RFC states that realm is case-sensitive. AD respects this but requires all clients to use enterprise principals flag in the requests, allowing to rewrite the principal in response. This effectively solves case-sensitivity issue for ad clients.

AD clients all should use enterprise principals and be ready to get KDCs to return a rewritten principal. This is part of MS-KILE spec.

By RFC it is case sensitive, yes.

Testing, obviously. Autocorrect is awful at times.

Thanks! I'm looking forward to reading that in interop.

Yep. But the client needs to know a realm in AS-REQ and it cannot, in a general case without local heuristics. So I guess we stuck with an empty realm first in iakerb and a retry to fix up the realm. Again, this is a guess so far and we are waiting for ability to actually test and agree for smth.

macOS did a referral to their correct realm. An iakerb spec discovery is to fill in a server's default realm in response if as-req had an empty one. We currently have no support on the client side of GSSAPI implementation to react on this because we are waiting for the interop testing.

At this point it would help to have a basic interop with MIT code because there is simply no released Windows version with new iakerb implementation so we cannot release MIT krb5 version either. MS-KILE and other specs aren't updated either so discovery semantics aren't documented as well.

We still haven't had access to your bits to test against Windows changes. It would be best to collaborate on this May be someone from your team can come to SDC IOLab next month in Germany?

Sometimes yes, sometimes no. It depends on your customer's FIPS auditors. While you can treat non-FIPS crypto as a plaintext within otherwise FIPS-compliant channel (VPN, TLS, etc.), it may well be rejected by an auditor.

We keep seeing customers who insist that RHEL cannot use Kerberos in FIPS mode with SHA1-based enctypes even though they have AD deployments alongside with the same enctypes and claim those are FIPS compliant. Welcome to the world of inconsistent audit.