I have an app which has been working with Windows 2008 R2 DCs, basically querying AD for a user attribute, but can't do it with Windows 2012 R2. The app server runs Windows 2008 R2 and the client Windows 7, and both are able to resolve SIDs S-1-18-1 and S-1-18-2. The error in the app simply says it's unable to contact Directory Services. Were there any changes in regard to Kerberos or LDAP in Windows 2012 R2?
Forum info: http://www.activedir.org
Problems unsubscribing? Email admin@xxxxxxxxxxxxxxxx
App unable to talk to Win 2012 R2 DC
- 49 Views
- Last Post 5 days ago
Resource SID compression?
Smita Carneiro, GCWN
Active Directory Systems Engineer
IT Security and Policy
Ross Enterprise Center
3495 Kent Avenue, Suite 100
West Lafayette, IN 47906
Many thanks Smita, will test it tomorrow morning and let you know if it helps.
Sent from my iPhone
Just a quick update and a question on this one.
We ran wireshark on the app client, app server and DCs, and confirmed the communication happening without any issues (LDAP bind and queries from both the app client and server). In the end we figured out the problem was caused by name caching, probably DNS caching which by default expires after 24 hours, but couldn't identify where it was happening. The app server was logging errors and listing a DC by its name as unavailable, after the DC was completely removed from the DNS and DNS cache flushed from the app client and server. The app has many dependent apps and also talks to SharePoint, but the app owner was unable to shed much light on it.
The app is a .net one running on IIS. They say a Microsoft LDAP API was used to fetch attributes from AD. I noticed that the app pool service account was delegated LDAP SPNs for all the DCs, which need to be removed manually after a particular DC was demoted and deleted from AD.
My question is was it possible that Microsoft LDAP API actually cached something somewhere and is it really necessary to use LDAP delegation for a .net app running on IIS under a domain user credentials?
Many thanks for your help
To answer your specific question, to the best of my knowledge the MS AD libraries do not cache DC names.
When a program makes an LDAP call, it has the option of specifying a domain controller name. IOW, in the path LDAP://[<dc>/]<LDAP-FQDN> the DC name is optional.
Is the app itself specifying a DC name in the LDAP path? If the app doesn’t specify a DC name, then the MS APIs use the DC locator to get a DC name. The DC locator uses DNS records to locate DCs. This is not simply the A records for the DCs themselves, there
are a number of records per-DC that get registered when a DC is promoted.
On each DC you will find the file “c:\Windows\system32\config\netlogon.dns” (presuming that the OS is in the default location). You should ensure that all of
these records for all of your active DCs are present in your DNS and that there aren’t old records from decommissioned DCs. Old records could be left if a DC is shut down without demoting it first. Yes, there are lots of DNS records here and any missing or
incorrect records can throw the DC locator function off.
Another remote possibility is that you have multiple AD sites and a site link is unreliable, but I wouldn’t worry about that until you ensure that the DNS records
Thank you so much for your reply. DC names are not specified anywhere in the app as it started talking with the new and renamed DC 24 hours or so after the DC was built. I got a confirmation from a developer that the app uses System.DirectoryServices.
I cleaned up msdcs folder after the first DC was forcefully demoted, and during the testing of the new one, removed all the records of the second old DC which the app kept complaining about being unavailable since it was turned off. I also confirmed the new DC had all the records in.
In this domain, there is only 1 site, but another one is coming with several remote sites. Will see how we go about it.
I had a Microsoft field engineer with me for an entire day and we were unable to figure it out. It's a test environment so we were able to play around. He advised we build a new instance of Windows 2008 DC and force the app to talk to it in order to eliminate any issue related to Windows version.
It's all good now, but I have another 2 domains to do and was thinking it would be really great to know what had happened there.
I wrote a whole book about effective .NET directory services programming with System.DirectoryServices a while ago. You can still get it on Amazon and it is still a useful resource even though it is more than 10 years old because this stuff hasn't really changed much since then. Your devs might find it useful.
To help understand better what is going wrong from the perspective of the app, I'd want to see how the DirectoryEntry objects are being constructed and also know what exception they are throwing when they are failing to work properly. It may also be useful to know more details of the hosting model for the application because if the DirectoryEntry is constructed with default credentials, the identity being used to connect to AD will be the identity of the current process and you'd want to ensure that it is a domain account, at least with respective to the network (for example network service or system on a domain-joined server).
I hope that helps a bit too. If you can't repro the problem anymore, it may be difficult to figure out what was wrong but these items should help if you run into it again.
Did you check the LAN Manager Authentication levels? https://technet.microsoft.com/en-us/library/jj852207(v=ws.11).aspx
Servers may not be able to talk by default if these are mismatched between the client and the DC. I have seen this old issue pop up a few times recently during migrations and upgrades.
Cloud | Identity | Security
MVP Enterprise Mobility | MCM Directory Services
Twitter | Blog | LinkedIn | Skype