Am going along the path of disabling RC4 encryption…but am running across an issue when crossing forests boundries. The forests are at 2012r2 functional level. In AD Domains and Trusts, on the per-domain properties is a check box that says (something like, going from memory) enable AES encryption across the trust. Are there any negative aspects of enabling that? It seems like it is allowing one additional method of encryption – AES (whereas just RC4 is working right now since DES is disabled by default with 2012r2). I can’t think of any…but given the two forests have 40+ and 160+ DC’s between them, thought I’d ask the question. Thanks in advance…
AES encyption across forest trust
- 1K Views
- Last Post 25 September 2017
I would be interested in hearing what other say about this too. I am setting up a a two way trust between a 2008 R2 DFL and FFL to a new 2012 R2 forest DFL FFL.
I am constantly getting gigged on the RC4 enablement and wanted to disable. I do however hav a lot of legacy clients that I need to take into account and therefore am a little nervous about disabling it.
I’ve got a case open with Microsoft and that is one of the questions that may be part (or the whole) cause…
Win7 clients (domain “A”) with users from domain A are able to access resources in domain B (connect to IIS then
delegated cred’s to SQL) and this works
Win10 clients (domain “A”), users cred’s from domain A are NOT able to access the same IIS (to SQL) server pair.
At first, I thought it was due to RC4 being disabled on the Win10 clients…I re-enabled it and they still cannot
reliably access the IIS/SQL servers in the other forest.
Microsoft is scratching their head…I’ve provided many network traces (taken from the IIS/SQL/Win7/Win10/DC forest
“A”/DC “forest B”) and they can’t figure it out (the weird Kerberos errors showing up in the traces). I’ve shown them where I get a Kerberos error of 0xE (or 14) that says invalid ETYPE (which implies encryption) – but they don’t think that is the issue.
Any how…I’ll provide an update to the AES across trusts once I get some information from them. We’ve got 20K
plus Win7->Win10 upgrades to work thru and it would be so much easier to have them come up with RC4 disabled than to later disable RC4.
P.S. what I find interesting is if I disable RC4 on Win10, the auth traffic to the IIS box becomes encrypted
with AES (makes sense, DES not available). However, with RC4 enabled, the auth traffic to the IIS box is encrypted with RC4 (based upon netmon decoding the packets). I would have thought that the negotiation for encryption would have been the strongest encryption
available, not the weakest.
Microsoft got back to me (we had some delays due to Irma in Florida)…
Short answer, when AES is enabled on those check boxes (in AD domains and trusts) will allow the cross forest
Kerberos requests to attempt AES first. No need to do anything more than the checkbox getting enabled.
The MS engineer verified that is his lab and said that after he marked the checkboxes, the next attempts used
AES (initially said the trust password had to be reset).
I will be verifying that also in my lab for our change control process before going forward into production.
I’ll also disable RC4 and verify the cross forest trust is still working with just AES.