LDAP Result Code 49 - BindDN should have only one or two parts

I working on the integration with GLAuth in greenpau/caddy-security#32

The LDAP library used is github.com/go-ldap/ldap/v3 v3.4.1.

Working with the sample-simple.cfg provided in the getting started.

The binding does not quite work.

As user. I get: LDAP Result Code 49 "Invalid Credentials":

In GLAuth logs I see: BindDN should have only one or two parts

18:11:40.997631 Bind ▶ DEBU 023  "level"=6 "msg"="Bind request"  "basedn"="dc=glauth,dc=com" "binddn"="cn=serviceuser,ou=svcaccts,dc=glauth,dc=com" "src"={"IP":"127.0.0.1","Port":56898,"Zone":""}
18:11:40.997681 Bind ▶ DEBU 024  "level"=6 "msg"="Bind success"  "binddn"="cn=serviceuser,ou=svcaccts,dc=glauth,dc=com" "src"={"IP":"127.0.0.1","Port":56898,"Zone":""}
18:11:40.998060 Search ▶ DEBU 025  "level"=6 "msg"="Search request"  "basedn"="dc=glauth,dc=com" "binddn"="cn=serviceuser,ou=svcaccts,dc=glauth,dc=com" "filter"="(\u0026(|(uid=johndoe)(mail=johndoe))(objectClass=posixAccount))" "scope"=2 "searchbasedn"="dc=glauth,dc=com" "src"={"IP":"127.0.0.1","Port":56898,"Zone":""}
18:11:40.998076 searchMaybeTopLevelNodes ▶ DEBU 026  "level"=6 "msg"="Search request"  "special case"="top-level browse"
18:11:40.998131 searchMaybeTopLevelNodes ▶ DEBU 027  "level"=6 "msg"="AP: Top-Level Browse OK"  "filter"="(\u0026(|(uid=johndoe)(mail=johndoe))(objectClass=posixAccount))"
18:11:40.998388 Bind ▶ DEBU 028  "level"=6 "msg"="Bind request"  "basedn"="dc=glauth,dc=com" "binddn"="cn=johndoe,ou=superheros,ou=users,dc=glauth,dc=com" "src"={"IP":"127.0.0.1","Port":56898,"Zone":""}
18:11:40.998404 findUser ▶ WARN 029  "level"=2 "msg"="BindDN should have only one or two parts"  "binddn"="cn=johndoe,ou=superheros,ou=users,dc=glauth,dc=com" "numparts"=3

Please assist.

I think the issue is rooted in this code.

glauth/v2/pkg/handler/ldapopshelper.go

Lines 601 to 612 in e7195ed

    
           parts := strings.Split(strings.TrimSuffix(bindDN, baseDN), ",") 
        
           groupName := "" 
        
           userName := "" 
        
           if len(parts) == 1 { 
        
           	userName = strings.TrimPrefix(parts[0], h.GetBackend().NameFormat+"=") 
        
           } else if len(parts) == 2 { 
        
           	userName = strings.TrimPrefix(parts[0], h.GetBackend().NameFormat+"=") 
        
           	groupName = strings.TrimPrefix(parts[1], h.GetBackend().GroupFormat+"=") 
        
           } else { 
        
           	h.GetLog().V(2).Info("BindDN should have only one or two parts", "binddn", bindDN, "numparts", len(parts)) 
        
           	return nil, ldap.LDAPResultInvalidCredentials 
        
           }

The johndoe DN is cn=johndoe,ou=superheros,ou=users,dc=glauth,dc=com.

Once you strip the base dn, you are left with cn=johndoe,ou=superheros,ou=users.

glauth/sample-simple.cfg

Line 36 in e26219c

baseDN = "dc=glauth,dc=com"

The cn=johndoe,ou=superheros,ou=users will have 3 parts, as opposed to two.

Thus, the logic would never pass when you have many nested groups.

Sorry it took me a few days to reply. Can you test this executable? It should address the issue (you are the second user reporting it and it's a real regression):

https://file.io/vfSQH4zQnVs3

@Fusion

Sorry it took me a few days to reply. Can you test this executable? It should address the issue (you are the second user reporting it and it's a real regression):

@Fusion , this one works 👍

Fix #246 and #252

@Fusion

@Fusion seems the bootleg in that share has been deleted, does that mean the official release with fix will be published soon? Or can you share another link to download the fix, so I can try on my setup, thanks!

@joace

@joace if you are curious, I am awaiting another confirmation that this version works. You should be able to download it from https://mega.nz/file/ltgVhQJT#Kc9OBPGABc2Z1XrTFcDEXi8KGOjNwD8-SvR_emzePPg

@Fusion

@Fusion , just a side note ... what is the user is not in ou=users and the OU is deeply nested?

@joace

@joace if you are curious, I am awaiting another confirmation that this version works. You should be able to download it from https://mega.nz/file/ltgVhQJT#Kc9OBPGABc2Z1XrTFcDEXi8KGOjNwD8-SvR_emzePPg

@Fusion thanks for the new link! Currently I'm running glauth in a container, but definitely a novice here, trying to figure out how to get new binaries into container and persist them.

Also seems glauth/glauth container even doesn't have some basic cmd, e.g. ls, so hit the difficulty with my normal knowledge.

@Fusion

@Fusion I can report back that the bootleg (build: 20220130_213326Z) also worked in my setup, the previous "msg"="BindDN should have only one or two parts" issue fixed, I can login via ldap authentication.

@Fusion

@Fusion , just a side note ... what is the user is not in ou=users and the OU is deeply nested?

I would have to double check but, off the top of my head, I want to say that this scenario would only happen when forwarding queries to another LDAP server (as the built-in schema uses ou=users to allow "browse-ability" and, in that case, this check would not be active.

@Fusion

@Fusion Any idea when the fix to the BindDN should have only one or two parts is generally available in a proper release?

I am thinking this week-end, as I got confirmation from multiple sources that the fix works well.

@Fusion

EDIT: lol, feel a little stupid now, as on branch dev there seems to be some GitHub workflow. :) Anyways, I'd really like to help this project to publish more frequently. So if there's anything I can do, please let me know.

@Fusion I managed to build my own binary off of the dev branch on my linuxarm64 machine using the docker.io/golang:bullseye image. So I'm no longer in need for a timely official release.

However, I feel the whole CI/CD setup for glauth should be tweaked a little to allow for more frequent releases. I haven't dug into it too much, but from the looks of it your current release process is not well-documented and seems to run on a personal / local machine. (I have no Golang experience)

I think it would be nice to rethink the branching approach for this repo and automate all of the build/publish steps. That way maintainers could focus on their code and reviewing/merging pull requests, while building and publishing releases is handled by a CI pipeline. If there is any interest within the glauth project I would gladly contribute. I have some experience with self-managed Jenkins and Drone CI pipeline, as well as, Travis CI (though they seem to have removed their free OSS offerings) and should be apply to apply this to other offerings like GitHub Actions or Circle CI, too.

I realize that this is kind of off-topic for this specific Issue, but I thought I'd test the waters before starting a new seperate Issue (Feature Request / Improvement Request).

By no means am I trying to bash the current workflow or the maintainers. English is not my first language, so if any of my remarks are impolite (or worse), please let me know. ❤️

Hi Lorenz, thanks for taking the time to think about this in depth.

Regarding feeling stupid, the only reference I could find in our own documentation of the move to github workflows is on that page: https://glauth.github.io/docs/running-travis-ci-locally.html and is a mere reference to the process so don't feel bad.

i wish we could release more often and with more confidence as, even going through the automated workflow and unit tests, there is still room for improvement. At this time, we rely on a two-step process:

When we think that we are ready for production, we create a "preview" release (that goes through automation workflows, of course)
If issues are reported, we fix them in unofficial builds and wait for the impacted folks to report victory. Since they have their own stuff to worry about, it may take them a while to find the time to test the builds.

Since stability is a higher priority that improvements (GLAuth 's use case seems to have organically evolved to support orgs in production), this process means that releases are both meatier and less frequent (the former due to the latter)

Dev (#254)

@Fusion

@Fusion Is there any plan to update docker image with v2.1.0 release?

Fix/docker latest tag (#260)

Dev -> Master after v1/v2 cleanup (#261)

Feature/dbsshkeys (#262)

Dev -> Master get rid of old Docker files (#288)

Navigation Menu

Repository navigation

LDAP Result Code 49 - BindDN should have only one or two parts #252

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	parts := strings.Split(strings.TrimSuffix(bindDN, baseDN), ",")
	groupName := ""
	userName := ""
	if len(parts) == 1 {
	userName = strings.TrimPrefix(parts[0], h.GetBackend().NameFormat+"=")
	} else if len(parts) == 2 {
	userName = strings.TrimPrefix(parts[0], h.GetBackend().NameFormat+"=")
	groupName = strings.TrimPrefix(parts[1], h.GetBackend().GroupFormat+"=")
	} else {
	h.GetLog().V(2).Info("BindDN should have only one or two parts", "binddn", bindDN, "numparts", len(parts))
	return nil, ldap.LDAPResultInvalidCredentials
	}

LDAP Result Code 49 - BindDN should have only one or two parts #252

Description

Activity

greenpau commented on Jan 28, 2022

Fusion commented on Jan 29, 2022

greenpau commented on Jan 29, 2022

joace commented on Feb 8, 2022

Fusion commented on Feb 8, 2022

greenpau commented on Feb 8, 2022

joace commented on Feb 8, 2022

joace commented on Feb 12, 2022

Fusion commented on Feb 13, 2022

lbarnkow commented on Feb 16, 2022

Fusion commented on Feb 19, 2022

lbarnkow commented on Feb 21, 2022

Fusion commented on Feb 21, 2022

joace commented on Mar 10, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions