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?

Thanks!
LVL 1
rojiruAsked:
Who is Participating?
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.

yo_beeDirector of Information TechnologyCommented:
For testing I would recommend disabling Windows Firewall and see what result you get.  It could be a misconfigured firewall?
0
LearnctxEngineerCommented:
This this an LDAP or LDAP over SSL bind? If it is LDAPS, is the certificate good?
0
rojiruAuthor 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!
0
LearnctxEngineerCommented:
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.
0
rojiruAuthor 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!
0
LearnctxEngineerCommented:
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.

OK, read the documentation here. Specifically:

This setting does not have any impact on LDAP simple bind through SSL (LDAP TCP/636).

If signing is required, then LDAP simple binds not using SSL are rejected (LDAP TCP/389).

So 1 of 2 things.

  1. Your other domain does not require LDAP signing.
  2. Your other domain has LDAPS enabled via an internal (your AD CS PKI infra) or public CA (VeriSign, Symantec, DigiCert, etc.).

Going by your post I would say you have not implemented LDAPS? Correct me if I'm wrong. I would always encourage any environment to use LDAPS if feasible, otherwise your simple bind traffic will be transmitted across the wire in the clear. LDAP signing just prevents someone presenting a dodgy LDAP directory in place of AD.

I can disable it, but will this cause any problems?

No, it will not cause problems, it just lowers your security to a degree. Enabling LDAP signing can cause problems because you're adding a layer of security you may not have accounted for before.
0

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
rojiruAuthor 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.
0
rojiruAuthor Commented:
Thanks for all the help!
It is good to have folks available that can provide insight into the workings of Windows AD.
0
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
Citrix

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.