Upgrade Active Directory 2008 2 to 2016 - error LDAP

  • Last Post 25 July 2019
Alix posted this 24 July 2019

Hi Everyone,I am not an expert and I just don't completely understand the problem we have during the upgrade from 2008 R2 to 2016.The situation is :Only one Domain, 3 DCSysvol replicating with DFSRadprep without any problem3 new DC 2016, installing SSL certificate from a third party : no problemRemoving 2 old DC 2008 R2
So, for now, 3 DC 2016 and 1 DC 2008 R2The FSMO and the time server were transferred to a DC 2016
Active Directory seems all right : replication, dcdiag (few error systemlog), w32tm : okIf the 2008 R2 DC is off : new user, new computer can be added to the domain.
But some errors :- At first, on the new DC 2016ldp.exe - ssl connection : is asking for a smart card authentication. I just use the cancel button and it is ok, I can connect.
- If the DC 2008 R2 is off, one colleague cannot connect to Active Directory from a "some linux application"ldapstarttls(): Unable to start TLS: Can't contact LDAP server "I have checked the account configuration of the domain users (dsa.msc) : it is not using smart card.
-If the DC 2008 R2 is off, some applications cannot use Active Directory authentification (third party Ricoh printing solution)I have no idea where to begin my search : any suggestion ?

Order By: Standard | Newest | Votes
barkills posted this 24 July 2019

You’ve got a couple different symptoms that could be 1 problem or more than 1 problem. It’s a bit dangerous to assume it is one problem, but let’s assume that’s true for now.


It sounds like a cipher suite issue to me, but it could be something else (if it is more than 1 problem).


Here’s the cipher suite issue we had when we upgrade to WS2016 DCs:

https://blogs.uw.edu/barkills/2017/09/11/ws2016-ad-upgrade-problem-tls-ciphers/. I still don’t understand why Microsoft chose to prioritize a suite which was in draft status and which had such poor support across its non-Windows client base—that still seems

very irresponsible on their part to me. BTW, we switched the order back in fall of 2017 and intended to be in the configuration for only 6 months, but we are still in that configuration (b/c as you might guess, the application still hasn’t fixed its issue

with crypto negotiation).


Here’s an example of something else (which I doubt is your problem, but illustrates my point that sometimes the combination of a poor client implementation & a random emergence of data which affects that poorly coded client):






hcoleman posted this 24 July 2019

Have you verified that “some linux application” and “some applications” are not configured to explicitly use the 2008 R2 DC by host name or IP address?



jheaton posted this 24 July 2019

Could be as simple as those applications pointing to an incorrect LDAP.  Make sure they’re pointing to one of the new DCs.



Alix posted this 25 July 2019

Thanks Brian, It seems to be a problem concerning LDAP and non Microsoft clients...I am just a poor user of LDAP => I'll chek the certificate installation (why asking for a smart card first ?)=> I'll read again active directory cookbook etc
Joseph, I have asked my colleagues to check what DC server they are adressing : it seems that even if they adress the new DC 2016, it fails until the DC 2008 R2 is back on the network.
Le mer. 24 juil. 2019 à 19:02, Heaton, Joseph@Wildlife <Joseph.Heaton@xxxxxxxxxxxxxxxx> a écrit :

Could be as simple as those applications pointing to an incorrect LDAP.  Make sure they’re pointing to one of the new DCs.