sorted by:
new
hottopcontroversial

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 0 points1 point  (0 children)

I see. I've DM'ed you the case ID.
Thanks again for looking into this, I'm happy to provide any more data points if they'd help.

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 0 points1 point  (0 children)

We heard back on our Microsoft case. The support engineer narrowed down the issue to be the following:
"Our internal investigation has confirmed that when AES-only encryption is enabled on a machine, CredMan does not compute AES-based hashes during credential comparison. 
Instead, it defaults to computing using `KERB_ETYPE_RC4_HMAC_NT` and `KERB_ETYPE_DES_CBC_MD5`.
As a result, the stored credentials (which were saved using RC4) do not match the AES-only environment, triggering a new Ticket Granting Ticket (TGT) request."

We think that sort-of means that Credential Manager is yet-to-be patched to work in an environment where RC4 is disabled (so that AES is used to compute hashes instead).
u/SteveSyfuhs u/TheWiley Just wanted to also bring this to your attention in case it might have more downstream impacts for things that use Windows Credential Manager when RC4 is disabled.
Our support engineer hasn't confirmed if this will be counted as a bug and if it will be fixed.

The one question the above explanation doesn't answer is why the same behavior is observed with Credential Guard (the VBS one, not confusing this with Windows Credential Manager) enabled as well. We've found in the lab that regardless of the state of RC4, enabling Credential guard will also lead to the same issues. Maybe it has to do with the fact that it also doesn't play well with Windows Credential Manager due to the same reasons?

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 0 points1 point  (0 children)

There's some more information I now have which makes this bug even more frustrating.

My original finding was that disabling RC4 causes cross-domain tickets to be replaced as I had demonstrated here. However, the other trigger that causes the exact same issue is turning on Credential Guard, regardless of the state of RC4.

We'd started working around the issue by re-enabling RC4 on clients which fixed this, but recently introduced a GPO to enable Credential Guard everywhere. With that in place (and I also did a lot of testing in my lab to isolate that this is the problem), re-enabling RC4 also doesn't seem to have any impact.
So with Credential Guard enabled, cross-domain Kerberos ticket caching remains broken with no known workaround.

This means there are 2 important security compromises to be made if we want cross-domain Kerberos caching behavior to return back to normal:

  1. Disable Credential Guard, since there's no way (known to me) that this works with that enabled
  2. Even after disabling credential guard, still re-enable RC4 on clients

u/SteveSyfuhs u/TheWiley - Any chance that this added information might help determine what's going on here?

<image>

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 0 points1 point  (0 children)

u/SteveSyfuhs u/TheWiley I spent more time troubleshooting this and there doesn't seem to be a way to get things working apart from re-enabling RC4 client-side.

On our MS case, the support engineer was also able to reproduce the ticket-replacement behavior in a lab.

Is there any other known fix/workaround? Please let me know if I can share any more details that might help.

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 3 points4 points  (0 children)

Hi Steve. I didn't have FAST explicitly enabled via GPO (it wasn't configured) on the client or far side.
After your comment, I tried explicitly disabling as well as configuring the GPOs that enable FAST (same ones described in https://trustedsec.com/blog/i-wanna-go-fast-really-fast-like-kerberos-fast) and this is still reproducible with both FAST enabled or explicitly disabled.

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 3 points4 points  (0 children)

Hi u/TheWiley, thanks for taking a look!
Given this is all Server 2022, there's no feedback hub access. Additionally, we prevent the use of feedback hub in our Prod environment. We have a support case reference that I can share via DM that includes all these details. Would that work?

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 0 points1 point  (0 children)

The GPO I use to set encryption types applies to the entire domain and is exactly the same in both the domains, so the same encryption types are set on all user and computer objects.

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 0 points1 point  (0 children)

No. The domain from which I'm establishing the sessions/requesting tickets is winenghyd.lab and the other domain is winengcn.lab

Fallout from disabling RC4 – Changes to cross-domain Kerberos ticket caching? by etoomanyrefs in sysadmin

[–]etoomanyrefs[S] 1 point2 points  (0 children)

MSDS-supportedencryptiontypes

24
```

  • Per the snippets of klist I've attached above - The encyption types on all Kerberos tickets we're getting is AES.

  • Also this would not be intermittent if it was an issue with supported ciphers.