LDAP problem No Such object
"ldap_binddn": "uid=semaphore-admin,ou=system,dc=mycompany,dc=org",
"ldap_bindpassword": "PASSWORD",
"ldap_server": "ldap_host:389",
"ldap_searchdn": "ou=users,dc=mycompany,dc=org",
"ldap_searchfilter": "(&(uid=%s)(objectclass=inetOrgPerson))",
"ldap_mappings": {
"dn": "dn",
"mail": "mail",
"uid": "uid",
"cn": "cn"
},
"ldap_enable": true,
"ldap_needtls": false,
... I'm using openldap with a lot of applications connected without a problem. The problem here is time="2022-04-16T00:08:29+02:00" level=info msg="LDAP Result Code 32 \"No Such Object\": " but the exact same query in apache directory studio (searchdn and searchfilter same) works and returning me my user.
My LDAP record is:
dn: uid=dusatvoj,ou=users,dc=mycompany,dc=org
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
uid: dusatvoj
structuralObjectClass: inetOrgPerson
...
memberOf: ...
cn:: Vm9qdMSbY2ggRHXFocOhdGtv
mail: [email protected]
...
(truncated)
Any hint? Thank you
This could also be fixed with PR #1027 . @dusatvoj could you provide the version and additional log info if there is a “panic” and some stacktrace with source lines printed.
It was fixed by
olcAccess: {2} to *
...
by users search
...
... bcs you are not using bind user for everything but you are using authenticated user for search.
bcs you are not using bind user for everything but you are using authenticated user for search
I am not sure what that sentence should mean.
But yes most of the time there is a distinction between authenticated user ( not able to search ) and read-only bind user ( able to do queries). Hence LDAP access needs at least 2 requests to properly authenticate a user.
Authenticated user was meant as personal user I'm logging in with.
Bind user: user, used for read LDAP, defined in config file.
With a provider like JumpCloud i cannot manage to change ldap AccessControls like olcAccess.
JumpCloudConsole would allow only bind&search for a bind user. For normal authenticated users it is not recommended to enable it, because “As the directory gets populated with more and more data of varying sensitivity, controlling the kinds of access granted to the directory becomes more and more critical.”, would allow those users with search permission to read such sensitiv data.
Yes, it's more like a workaround than solution.
Hi @flybyray , I merged your PR, can it fix this issue?
Hi @dusatvoj , Could you test latest version of Semaphore?
I've installed ansible-semaphore 2.8.74 from releases and I still can't login into semaphore without:
olcAccess: {1} to dn.subtree="ou=groups,dc=mycompany,dc=org"
by users read
by * none
olcAccess: {2} to *
...
by self read
by users search
by * none
The main problem was when I've deleted by self read
This by self read might be required for the whoami operation to complete.
@fiftin maybe we remove the whoami call. it is not required but also not bad. Currently only return code is validated but not the data itself.
by self read is also pretty ok to have it in LDAP :) , I agree
Hi @flybyray I am not an expert in LDAP, let's do as you see fit :)