Problem binding to LDAP with Dex: password too complex?

Get Help
1

We are continuing with our evaluation of Open OnDemand. I am having a problem using LDAP in Dex, specifically binding with LDAP.

Our LDAP really is Microsoft Active Directory. The security practice here is that each application relying on LDAP authentication uses its own service account to bind to LDAP. For this evaluation work, I borrowed an existing service account used by another Apache HTTPD site that I manage, so I know the account and password are valid. However, I was unable to log into Open OnDemand. I received a screen complaining about the bind credentials, and I saw the same complaint in /var/log/messages:

... msg="Failed to login user: ldap: initial bind for user \"CN=...\" failed: LDAP Result Code 49 \"Invalid Credentials\" ...

This bind account and password pair works in an Apache configuration file for the httpd service from which I borrowed it. Also, I am able to use these credentials with ldapsearch on the Open OnDemand server.

I changed the bind credentials to my personal account, and it worked. I was able to log into Open OnDemand with my LDAP credentials and receive the dashboard.

Here are the obvious differences between my account and the service account:

  • The two accounts reside in different OUs. Mine is in “…,OU=People,DC=…” while the service account is in “…,OU=Service Accounts,DC=…”. In both cases the baseDN for searches is “OU=People,DC=…”. This does not seem significant.
  • The distinguisedName for my account has no embedded space characters, but the distinguishedName for the service account has an embedded space. However, the value of the bindDN is enclosed in double-quote characters in /etc/ood/config/ood_portal.yml, in /etc/ood/dex/config.yaml, and in the error messages, so I do not think this is the issue.
  • My password is mixed-case alphanumeric with mundane special characters (period, comma), but the password for the service account looks like line noise because it contains many regular expression metacharacters (curly braces, etc.). This looks more likely as a cause.

Trying again with the service account, I put double-quote characters around the the password in ood_portal.yaml, ran update_ood_portal, and bounced ondemand-dex.service, but that made no difference. Next, I edited config.yaml directly to replace the double-quote characters with single-quote characters and bounced ondemand-dex.service; however, I still received the bind error.

It seems that the complex password is the problem, but I may be overlooking something. Is this a YAML issue, a Dex issue, or something else?

Regards,
Eric

2

Hi Eric.

Thanks for the post.

It sounds like you may have some characters in the password that need to be escaped. I found the following link that touches on that scenario. I’ve also experience in the past that using a single quote around the password will treat the string as a literal. If it were me, i would try using the single quote. If that doesn’t work, i would then try escaping the characters that may need to be escaped. The following website covers the how-tos, etc.

A YAML Primer — OctoPrint master documentation.

Thanks,
-gerald

3

Greetings, Gerald,

Thank you for the reply and for the reference. After much trial-and-error today, I have solved the problem, which was caused by the presence of a dollar sign ( $ ) in the password for the service account, at least at the initial position.

As I said, the service account worked with command line utility ldapsearch. I switched from ldaps to ldap and used tcpdump to capture the packets sent to the LDAP server. When using ldapsearch, I could see the entire password. With Open OnDemand + Dex, the leading dollar sign and the following three characters (all alphanumeric) were missing; the remaining characters in the password including special characters did appear. Modifying ood_portal.yml to put single quotes around the password did not change this; putting a backslash before the dollar sign did not change this. I replaced the dollar sign with a percent sign ( % ), and then I could see the complete password in the tcpdump output.

I contacted the account services group and had them change the password for the service account to one without a dollar sign. (They went overboard and replaced all special characters with mixed-case alphanumeric characters, which I think was unnecessary.) The service account now works to bind with LDAP from Open OnDemand + Dex.

This seems to be some kind of weird corner case. I hope that nobody else is caught by it, but I am posting this information for others in case they need it. I consider this matter closed now.

Regards,
Eric

1 Like
4

That is great news Eric. Thanks!

5

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.