AES encyption across forest trust

  • Last Post 25 September 2017
kbatlive posted this 28 August 2017

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…  

Order By: Standard | Newest | Votes
BrianB posted this 28 August 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.


Brian Britt



kbatlive posted this 01 September 2017

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.




kbatlive posted this 25 September 2017

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.