Has anyone upgraded their AD to 2016 yet

  • 256 Views
  • Last Post 14 September 2017
BrianB posted this 16 February 2017

I have a unique opportunity to build a new AD forest as part of a divesture and move our assets and resources to the new environment. We initially started our Dev and test environments with 2012 R2 given that we started the project months before the release of 2016. We have now been afforded the luxury of an extended timeline of several more months. We are now considering scrapping our Dev and test environment and rebuilding them as AD 2016 with Server 2016 PKI, ADFS, ADLDS, etc…

  Has anyone on this forum already upgraded their AD to 2016 and if so, were there any nuances or gotcha’s to look out for? We can still stay with 2012 R2 and wait for the possible R2 version of 2016 or at the very least more/better documentation but if we can forego the upgrade later by moving the latest now, we can save ourselves some work in the future.      I am looking for anything that would help us know what to expect or overcome if we went with AD 2016.

  I appreciate any and all feedback.   Brian Britt

Order By: Standard | Newest | Votes
webster posted this 16 February 2017

All the new AD projects I am working on are all 2016. My lab AD has been running 2016 since 2016 came out on MSDN. I upgraded my employer's three Forests to 2016 with no issues.

 

 

Webster

 

show

Milo posted this 16 February 2017

The only "issue" I have seen is the excessive permissions granted to one of the new security principals (Enterprise Key Admins), detailed here:

https://secureidentity.se/adprep-bug-in-windows-server-2016/




Regards




Milo.










show

a-ko posted this 17 February 2017

That’s not really an issue if users aren’t added to the group…It’s just they’ve got some extraneous stuff that isn’t quite used yet but is there to support it.

 

show

Milo posted this 17 February 2017

That's why I put the word issue in inverted commas, i.e. "issue"... however since Account Operators can manage this group and if you are in a pure 2016 envinronment the group is present and has Full Control permissions by default, bit scary. To me it is

a big concern working as an AD Security Architect, maybe not an issue as such but I was just trying to inform of what I had found... apologies for not sticking strictly to topic...












show

patrickg posted this 19 February 2017

Haven’t yet but looking to be upgraded to 2016 by Summer at latest. The only “political” debate between the admins is if the boxes will have the full GUI install or

be Core installs, not seriously considering Nano until an R2 release likely.


~Patrick

 

show

BrianB posted this 19 February 2017

Interestingly, they seem to have taken away the ability to move between core, minimal, and full gui. Gotta know what you want at the install and stick with it.



Not that we switch at all now, but the flexibility   is nice to have. We usually install core for everything that is supported.





Brian B.







Get Outlook for Android

show

barkills posted this 05 September 2017

It’s been awhile since this thread was originally raised, but we’ve just run into a related issue and I figure it is still very much relevant to most on the list, so I thought I’d share.

 

We’ve been replacing all our WS2012R2 DCs with WS2016 DCs. A non-Windows platform application which performs LDAPS queries against AD had a breaking issue. That application leverages a JDK library to establish

the TLS connection (for LDAPS) with a domain controller.

 

See

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server for Microsoft details on the newly added crypto ciphers. An interesting related detail is that the

preferred crypto cipher for WS2016 is still in draft status! Presumably that’s because it is significantly faster than the other new/strong ciphers.

 

The exact details of the known problem are still a bit sketchy, so I can’t share that level of detail definitively yet. The facts are that both WS2016 server and JDK client have ciphers in common, but a mutually

supported cipher is not negotiated (whereas a WS2012R2 server with the same JDK client does negotiate successfully). The JDK team has an issue tracking this which they have resolved based on wire-level examination showing that the WS2016 server doesn’t properly

do TLS cipher negotiation:

https://bugs.openjdk.java.net/browse/JDK-8178429.

 

We’re looking to find a solution. We are aware that the ‘bouncy castle’ provider (instead of JDK) has been used in similar situations. One option we’ll likely try in our eval environment is removing some of the

newer ciphers to see if WS2016 is just overzealous in negotiation when they are enabled. If we discover additional valuable information, I’ll share.

 

Brian

 

show

BrianB posted this 05 September 2017

Brian,

 

Thanks for that update. I have people that are trying to push me to do an upgrade to take advantage of some of the new features. I have been and remain reluctant to do this because we need more testing and don’t

have the cycles or resources to perform comprehensive testing for all that is in our environment. I am very interested in this thread and any additional comments from those who have upgraded their AD to WS 2016.



 

Brian Britt

 

show

a-ko posted this 09 September 2017

You could always do the 2016 schema upgrade and add a couple of 2016 DCs while pointing your applications that have the above TLS issue to your existing 2012R2 DCs. Best of both

worlds, IMO.

 

show

Bitzie posted this 09 September 2017

Question from the peanut gallery:

Are the ciphers defined in the registry / gpo , can you re-order

them?




On 9/9/2017 12:08 PM, Michael Cramer

wrote:














You

could always do the 2016 schema upgrade and add a couple of

2016 DCs while pointing your applications that have the

above TLS issue to your existing 2012R2 DCs. Best of both

worlds, IMO.

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx

[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Britt, Brian


Sent: Tuesday, September 5, 2017 15:25


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] Has anyone upgraded their

AD to 2016 yet





 

Brian,

 

Thanks for that

update. I have people that are trying to push me to do an

upgrade to take advantage of some of the new features. I

have been and remain reluctant to do this because we need

more testing and don’t have the cycles or resources to

perform comprehensive testing for all that is in our

environment. I am very interested in this thread and any

additional comments from those who have upgraded their AD to

WS 2016.



 

Brian Britt

 





From:

ActiveDir-owner@xxxxxxxxxxxxxxxx

[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx]

On Behalf Of Brian Arkills


Sent: Tuesday, September 5, 2017 5:18 PM


To: ActiveDir@xxxxxxxxxxxxxxxx


Subject: RE: [ActiveDir] Has anyone upgraded their

AD to 2016 yet





 

It’s been

awhile since this thread was originally raised, but we’ve

just run into a related issue and I figure it is still very

much relevant to most on the list, so I thought I’d share.

 

We’ve been

replacing all our WS2012R2 DCs with WS2016 DCs. A

non-Windows platform application which performs LDAPS

queries against AD had a breaking issue. That application

leverages a JDK library to establish the TLS connection (for

LDAPS) with a domain controller.

 

See https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server

for Microsoft details on the newly added crypto ciphers. An interesting related detail is

that the preferred crypto cipher for WS2016 is still in

draft status! Presumably that’s because it is significantly

faster than the other new/strong ciphers.

 

The exact

details of the known problem are still a bit sketchy, so I

can’t share that level of detail definitively yet. The facts

are that both WS2016 server and JDK client have ciphers in

common, but a mutually supported cipher is not negotiated

(whereas a WS2012R2 server with the same JDK client does

negotiate successfully). The JDK team has an issue tracking

this which they have resolved based on wire-level

examination showing that the WS2016 server doesn’t properly

do TLS cipher negotiation: https://bugs.openjdk.java.net/browse/JDK-8178429.

 

We’re looking

to find a solution. We are aware that the ‘bouncy castle’

provider (instead of JDK) has been used in similar

situations. One option we’ll likely try in our eval

environment is removing some of the newer ciphers to see if

WS2016 is just overzealous in negotiation when they are

enabled. If we discover additional valuable information,

I’ll share.

 

Brian

show

bpffa posted this 11 September 2017

Yes; you can define the ciphers via registry. I find the Nartac software useful in creating a baseline on a test machine then extracting the keys into GPO. Aside from the protocols, there is a cipher-order specific

registry setting but I run into GPO string length issues and directly modify this key instead:



 

HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

 

 

Brendan P Foley

 

show

barkills posted this 11 September 2017

Here’s a list of related URLs. Several of which talk about how to enable/disable ciphers and re-order priority of ciphers.

 

Our early testing shows that switching the order so that the cipher still in draft status is not first may be enough to allow the JDK based client to negotiate.

 

·        

TLS changes for WS2016:

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server

·        

Slightly dated broad overview of Windows cipher support:



https://blogs.technet.microsoft.com/askds/2015/12/08/speaking-in-ciphers-and-other-enigmatic-tonguesupdate/

·        

Additional detail on WS2016 ciphers:

https://msdn.microsoft.com/en-us/library/windows/desktop/mt490158.aspx

·        

Additional detail on Windows ciphers (not OS version specific):

https://msdn.microsoft.com/library/windows/desktop/aa374757.aspx

·        

Someone with similar error:

https://bugs.openjdk.java.net/browse/JDK-8178429

·        

Relevant tracked enhancement in JDK backlog:

https://bugs.openjdk.java.net/browse/JDK-8171279

·        

Similar JDK error, solved by adding ‘bouncycastle’ provider:



https://stackoverflow.com/questions/31971499/ecdhe-cipher-suites-not-supported-on-openjdk-8-installed-on-ec2-linux-machine,



http://milkchaser.blogspot.com/2016/06/handshake-failure-trying-to-make-ssl.html,



·        

Oracle Java TLS overview:

https://blogs.oracle.com/java-platform-group/diagnosing-tls,-ssl,-and-https

 

 

show

barkills posted this 11 September 2017

That’s suboptimal from a number of angles.

 

·        

You’ll need a custom load-balancing solution for this one app. That solution will need to keep in mind that certs used for TLS/SSL must have the hostname the client is connecting to in the cert.

·        

You have agreed to technical debt (not being able to get rid of those older DCs) for an indefinite period of time. That technical debt has to be paid sometime, and kicking the can down the road is invariably

a bad idea. Arguably, changing the cipher order on WS2016 DCs is also technical debt, but it is a smaller technical debt in my opinion because the only newer Windows 10 build clients are pre-configured to support the newer ciphers, and there currently is no

known vulnerability for the older ciphers that WS2016 supports.

 

Brian

 

show

BrianB posted this 11 September 2017

I agree with Brian. You also will not be able to update DFL and FFL if you have legacy DC’s that you are hanging on to. As a result, you will not be able to take advantage of the additional benefits that come

with a DFL and FFL of 2016.

 

We do use that approach when we upgrade the domain, though. Almost 100% of the time, and no matter how much effort you spend trying to identify your applications in your environment, there are a few that show

up as soon as you start upgrading the domain. So, we send out plenty of COMM’s to the community informing them of the upgrade and provide a sandbox for them to validate their applications in before the first DC is replaced with a new version. We always leave

one per site that will be used for applications to “Point to” until they can update their clients. Then we give a deadline and proceed with the last replacement of a DC after the deadline has been reached and after we have communicated to our clients.



 

Brian Britt.

 

show

a-ko posted this 12 September 2017

Well, the issue that brought all of this up was a client/server cipher suite negotiation issue. I’d be hesitant to add or remove ciphers in this case since that has no guarantee

to fix the problem and at best it masks the issue moving forward. If you remove newer ciphers due to an older application, you are essentially codifying technical debt into your configuration. And when it comes to cipher suites, far fewer people know the how’s

and why’s of using that registry key than people who understand why you would need to get rid of a 2012R2 Domain Controller in a migrating 2016 Domain.



Leaving the 2012R2 domain controllers in place basically forces someone’s hand eventually: Either the application side or Microsoft side patches their applications, allowing you to finish the Domain Controller migration, depending on where the issue lies.

 

I’m not certain it’s a cipher suite existence problem so much as a negotiation problem.

 

I don’t know everyone’s environments, but at scale using a load balancer solution for something like LDAP is a good model and is something we do in my org. This way you can leverage

global load balancing features, have a consistent endpoint URL for applications to point to (i.e. ldap.corp.contoso.com) no matter where they live, and applications aren’t reliant on the existence of a single DC or RR DNS to locate a potentially failed/rebooting/patching

DC.

 

My recommendation was certainly a temporary one in that regard, either way. Something that would allow you to afford the benefits of the newer schema functions (things like Windows

Hello for Business), and gaining some advantages of 2016 DCs for client functionality (better time sync, etc etc.), while maintaining the older domain controllers for this specific issue until a long-term fix is found.

 

-Mike

 

show

kool posted this 14 September 2017

More info on WS16 cipher suites. The article

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-schannel-ssp-changes-in-windows-10-and-windows-server

has a section “Elliptic Curve changes” that lists 4 new ECC algorithms. The names given don’t seem to map to any of the cipher suites listed in



https://msdn.microsoft.com/en-us/library/windows/desktop/mt490158.aspx. I understand that an ECC algorithm would just be one component of a cipher suite, but there is clearly information missing regarding these new ECCs.

 

Moreover, you cannot change the order of these Win10/WS16 elliptic curve algorithms via the registry or via certutil. Instead there is a new group policy to set the order of these curves. I’ve got more questions than answers regarding the

relationships between the TLS cipher suite list/order and these new elliptical curves. I’m now in the middle of reading several IETF RFCs (4492, 5639 and 7027) to get more info. Too bad the MS articles don’t do more to explain these very arcane concepts.

 

BTW, I set the policy to reorder these ECC algorithms to place the draft curve25519 last. That appears to have fixed the LDAPS issue we were seeing with a Java client.

 

Cheers,

 

    Eric

 

 

show

Close