Avatar of rojiru
rojiru asked on

Setup Citrix Netscaler 12 LDAP Authentication fails with Invalid Credentials.

Running ldp.exe on domain controller using domain admin credentials and simple bind, I got the same error the first run. Now it gives me The token supplied to the function is invalid.

Running ldp.exe on a different domain controller on different domain/forest, the results are valid.

So something wrong on first domain controller. How/Where to find the problem?

CitrixNetScalerActive Directory

Avatar of undefined
Last Comment

8/22/2022 - Mon

For testing I would recommend disabling Windows Firewall and see what result you get.  It could be a misconfigured firewall?
Aard Vark

This this an LDAP or LDAP over SSL bind? If it is LDAPS, is the certificate good?

Thanks for the responses. The firewall is disabled on the DC. This is for just LDAP communication. LDAPS is not configured as far as I know.

The same test, a simple ldap bind, using ldp.exe is successful on a different DC in a different domain/forest. The only info that I have found on the INet pertains to running LDS (LDAP Directory Services) on Windows Server, which I am not doing.

Thought I might find an Active Directory guru around that could point me in the direction to locate the problem.

This is the best money I have ever spent. I cannot not tell you how many times these folks have saved my bacon. I learn so much from the contributors.
Aard Vark

Thought I might find an Active Directory guru around that could point me in the direction to locate the problem.

Hopefully someone can :)

Can you provide more information about the error. The whole error for example and all error codes?
What OS is the Domain Controller that you are connecting to?
Is the DN for the account too long (greater than 255 characters)?

See the AD published limits for character length to see if this is the cause of your problem published here.

Name Length Limitations for LDAP Simple Bind Operations

During binds to the directory, simple LDAP bind operations limit the distinguished name (also known as DN) of the user to 255 total characters. If you attempt a simple LDAP bind with more than 255 characters, you might experience authentication errors, such as the following:

Error <49>: ldap_simple_bind_s() failed: Invalid Credentials
Server error: 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 57, v1771
Error 0x80090308 The token supplied to the function is invalid

You can avoid this issue by ensuring that the applications, scripts, and utilities that attempt to bind to your directory use secure LDAP binds. You can also avoid this issue by reducing the depth of the OU structure or the length of the OU names.

You can check the amount of characters in the accounts DN with PowerShell.

(Get-ADUser -Identity LdpTestAccountName).distinguishedName.Length

Open in new window

There is hotfix available for Server 2008 R2 for simple binds where the DN for the account is greater than 255 characters. It can be downloaded here but read the notes around the hotfix as it is designed only for a the particular described scenario.

Thanks for the response, but DN is only about 30 characters. The last time that I ran ldp.exe, the output stated a requirement for strong authentication, when testing a simple bind using domain\username, password of domain admin. So some further digging, and I find that there is a Group Policy setting enabled in Default Domain Controllers Policy that requires signed ldap communication. Apparently this is set to none by default. OK, not a problem. I can disable it, but will this cause any problems? Most likely not, unless I am missing something.

My search shows me that the simple bind should work, except for the setting previously mentioned. Domain controller has Certificate Services installed & configured. Unfortunately, it was installed as Standalone instead of Enterprise, so no LDAPS configured. Looks like I need to use LDAPS for secure communication between Netscaler and ADDS. So this is my next step. Well, after I change Certificate Services to Enterprise. Hopefully, it should all work afterwards.

Thanks for the input. The adventure continues.

LearnCTX: No offense, though you may be an AD guru. I do not know. :)
Your help is very much appreciated!
Aard Vark

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
See how we're fighting big data
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question

Correct. After I read various articles and blogs, I checked the Default Domain Controller GPO on each domain. The other domain has the LDAP signing set to none. Hooray! I learned something new today. ;)

Since it is already enabled, I was leaning to setting up LDAPS. As you stated, it creates a more secure environment. Since I am adding an additional attack point from the Internet in Netscaler, it will be better overall. And Netscaler may require it anyways.

Unfortunately, whoever setup the CA Root on the DC, did so as a standalone CA. So now I have to either uninstall/reinstall CA on DC, or I setup a Enterprise subordinate CA on another server.

Anyway, Thanks for the help, it is greatly appreciated.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.

Thanks for all the help!
It is good to have folks available that can provide insight into the workings of Windows AD.