Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

No suffix for bind dn found error for 1st retry LDAP BIND

Description

I'm getting occasional failed logins at our client site.

We are using 389 Directory Server, with CentOS 7.  We have load balancing HW sending requests to 2 separate servers running dirsrv service.

The ldap "access" logs are showing back-to-back bind errors, like:

...access:[04/Jun/2020:18:57:41.50213366 -0400] conn=48 op=0 BIND dn="uid=XXXXX,cn=users,ou=roxie,dc=dscprod,dc=XXX,dx=vmdomain" method=128 version=3

...access:[04/Jun/2020:18:57:41.502349458 -0400] conn=48 op=0 RESULT err=49 tag=97 nentries=0 etime=0.0000275302 - Invalid credentials

...access:[04/Jun/2020:18:57:41.504737116 -0400] conn=48 op=1 BIND dn="uid=XXXXX" method=128 version=3

...access:[04/Jun/2020:18:57:41.504779036 -0400] conn=48 op=1 RESULT err=49 tag=97 nentries=0 etime=0.0000084449 - No suffix for bind dn found

These two errors are for the same user-bind request, presumably retried - but within 5 milliseconds of each other - which makes me wonder if they're retries attempted by HPCC or by a lower-level LDAP layer.

Also, note that the 2nd BIND (op=1) will seemingly never work with this LDAP.  See the error "No suffix for bind dn found".

 

Are these retries attempted by HPCC?

If so, the 2nd attempt is sending just the uid=XXXXX?

 

Conclusion

None

Activity

Show:

James Wiltshire June 23, 2020 at 5:52 PM

Great, thanks, Russ.

 

Russ Whitehead June 17, 2020 at 3:25 PM

As Yanrui pointed out, the purpose of the second LDAP call is to try with the domain component stripped out (uid=XXXXX,cn=users,ou=roxie"). However, this code looks wrong, since it chops at the first comma. I will fix

Yanrui Ma June 17, 2020 at 2:33 PM

I do see the following retry code, which was apparently added specifically for fedora 389. The extra bind is called only when the regular bind fails, and only for 389/openldap. But apparently it's not adding any value in James' case. It's possible that 389's behavior changed in newer versions.

 

int rc = LdapSimpleBind(ld, ldapTimeout, (char*)userdn, (char*)password); if (rc != LDAP_SUCCESS && server_type == OPEN_LDAP && strchr(userdn,',')) { //Fedora389 is happier without the domain component specified StringBuffer cn(userdn); cn.replace(',',(char)NULL); if (cn.length())//disallow call if no cn rc = LdapSimpleBind(ld, ldapTimeout, (char*)cn.str(), (char*)password); }

Anthony Fishbeck June 17, 2020 at 1:51 PM

any comments?

James Wiltshire June 9, 2020 at 3:17 AM

We've since determined that the 1st of these LDAP failures, "Invalid credentials", are valid and match the user's password errors.
So, no issues there.

I'm still curious, however, where that retry comes from - the BIND with only "uid=XXXXX" and no full Distinguished Name (dn). 

I think we're seeing that only when our user actually enters the wrong password.

But - the question, would LDAP (at least, 389 DS) ever accept that?  We always get the "err=49", "No suffix for bind dn found".

Not a critical issue - but wondering if that can be improved? 

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Components

Assignee

Reporter

Priority

Compatibility

Minor

Fix versions

Pull Request URL

https://github.com/hpcc-systems/HPCC-Platform/pull/13877

Created June 5, 2020 at 2:40 AM
Updated June 23, 2020 at 5:52 PM
Resolved June 18, 2020 at 12:12 PM

Flag notifications