We help IT Professionals succeed at work.

Setup Citrix Netscaler 12 LDAP Authentication fails with Invalid Credentials.

rojiru
rojiru asked
on
1,082 Views
Last Modified: 2017-11-29
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?

Thanks!
Comment
Watch Question

yo_beeDirector of Information Technology
CERTIFIED EXPERT

Commented:
For testing I would recommend disabling Windows Firewall and see what result you get.  It could be a misconfigured firewall?
LearnctxEngineer
CERTIFIED EXPERT

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

Author

Commented:
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.

Thanks!
LearnctxEngineer
CERTIFIED EXPERT

Commented:
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.

Author

Commented:
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!
Engineer
CERTIFIED EXPERT
Commented:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Author

Commented:
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.

Author

Commented:
Thanks for all the help!
It is good to have folks available that can provide insight into the workings of Windows AD.
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.