LDAP Authentication will only work against one DC?

We have a product (Helix Media Library, if you want to know) on a 2008R2 server that uses LDAP authentication of Active Directory members for access.  For some reason the LDAP authentication request is only successful against one of our older (2003) Windows Domain Controllers.  If that DC is shut down, all authentication fails.

Attached is a config file for an Authorization Test program that we run, at least partially sanitized, that when set to any other DC, still ends up talking with the OLDDC and fails if that DC is down.  The log output for a successful and unsuccessful test is also attached.

I can see the 2008R2 server logon entries to other DC's in the Security Event Log of both the sending and receiving server, but it seems like the system keeps going until it gets to the OLDDC before it succeeds or fails.

Any ideas on why this process is "stuck" on the OLDDC and what I can do to un-stick it?
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Do you have all LDAP servers specified?  Page 9 states how to add more than one.. I only seen 1 in the .xml attached.

Harper McDonaldCommented:
Transfer the FSMO roles to one of the 2008 DC's and DCPROMO the 2003 DC's as they are EOL anyways.  I would start there first off.
check this article
I think your 2003 server is the only LDAP DC in domain, other servers are not configured to serve LDAP, normal or over SSL
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

e_sandrsAuthor Commented:
Thanks, I'll start looking at these suggestions.  FYI, the goal is to shut down the 2003 servers (there are two) ASAP, but we need to be certain all our authentication is moved and working -- thus this question.  :)
e_sandrsAuthor Commented:
Hm.  Not seeing it yet.  I added 3 more DC's to the LDAP list, and I have these settings in the Default  Domain Controllers Policy to try to allow all connections to all DC's.

Local Policies/Security Options
Domain controller: LDAP server signing requirements None
Microsoft network server: Digitally sign communications (always) Disabled
Network security: LDAP client signing requirements None

Is there something else I should be doing to allow LDAP communication?  Ports 389 and 636 are open on the local firewall of the DCs.  I see the actual Logon is getting routed out to a dynamic port such as 57068 - but that seems normal...
port such as 57068 - but that seems normal..
No this is not normal, but maybe you get confused between client port / server port used and 57068 is for the client
PberSolutions ArchitectCommented:
What if, instead of defining a DC in
just use the FQDN domain name instead (leave out the DC).  When your application does a DNS call of the domain name, DNS will return a round robin list of DCs which your product will usually pick the first on the list.

We do this for most of our LDAP type apps and we never have issues.
e_sandrsAuthor Commented:
Setting just FQDN does work, but what I see in the logs is a set of 4648 Logons as below (from oldest to newest):

1) mediasrv1ldap connects to NewestDC (additional information: ldap/NewestDC) three times.
2) mediasrv1ldap connects to NewerDC (ldap/NewerDC) three times.
3) mediasrv1ldap connects to OLDDC (ldap/OLDDC) three times.

AuthLog reports successful LDAP data pull.  I can find a successful Network Logon (4624) on each of the servers.

The order of the connections is probably related to my DNS weight settings, preferring the newer DC's.
e_sandrsAuthor Commented:
It does seem like the other DC's are not providing the LDAP information back to the requesting server/account.  I still don't understand why...

This tool can help you see if your even able to connect to your AD.  In the LDAP paths put the server name.domain and try each server by running the query.  Then you can troubleshoot from there if you know you can connect or not.
Here is another tool from MS Sysinternals

e_sandrsAuthor Commented:
I can run the VTLDAPQuery against LDAP://server from the Helix Media Server for all my DCs with the following query and and get all user accounts, using the mediasrv1ldap account:


I also entered only the FQDN (no server) and it selected one of the Newer servers and served the results.

I don't seem to get any capture with the Sysinternals tool running either my test file nor the VTLDAPQuery tool, but I may have to read more to use it correctly.
e_sandrsAuthor Commented:
It sure seems like LDAP is performing as expected and the issue might be something in the application.  :(  Sadly, the application support has been less than stellar in the past.
e_sandrsAuthor Commented:
K.  Mystery solved.  I'll document here for anyone who searches for Helix Media Library or such in case it helps.

The Helix system uses a web.config file for authentication from the web pages and an "AuthTestHarness.exe.config" file to test authentication.  One of the XML variables is "AuthServerGroupSearchType".  Ours was set to "SecurityGroupSearchCrossDomain".  Our old remaining 2003 DC/GC was at one time a member of our previous, single label Domain Name (Servername.[short]) that lingered here from when we first installed a Windows Domain until I "fixed" it in 2010.  Although the old DC/GC is part of the new Domain, it retains the old settings as well until it gets demoted.

So, Helix was set to search across multiple domains, which apparently means "only accept replies from DCs not in your Domain".  Therefore, the only server that it would accept an answer from was the OLDDC.

Changing this variable to "SecurityGroupSearch" allowed Helix to accept the LDAP responses from DCs in the same Domain.  The resulting search yields more Security Groups than we need, but I have tested various logins and it appears as long as rights are only set on the groups desired, discovering the extra groups is ok.

I'll close this out and distribute some points to those who helped me get down this long and winding road.  Thanks!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
e_sandrsAuthor Commented:
Help on Helix config options for LDAP servers plus LDAP testing tools helped lead me to the root issue and test an acceptable solution.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.