# LDAP users with anonymous binding
**URL:** https://community.datagerry.com/t/ldap-users-with-anonymous-binding/773
**Category:** Community Support
**Created:** [August 14, 2025, 7:14am UTC](https://community.datagerry.com/t/ldap-users-with-anonymous-binding/773 "2025-08-14T07:14:13Z")
**Posts on this page:** 1
**Page:** 1
### Author:  [@alokhovi](https://community.datagerry.com/u/alokhovi)
#### Post date: [August 14, 2025, 7:14am UTC](https://community.datagerry.com/t/ldap-users-with-anonymous-binding/773/1 "2025-08-14T07:14:13Z")
Dear community experts,
I managed to deploy DG in OKD4 using Helm charts and the official DG image without downstream modification (becongmbh/datagerry:latest). Now I’m trying to link our AD user authentication with LDAP, but without success. For regular users our LDAP server supports only anonymous requests and I cannot bind a user. 2 ldapsearch command calls with binding and without demonstrate the case. I left in the LDAP connection config the fields User and Password empty. But according to the auth error trace DG still tries to bind and fails. Any advices how to configure DG for anonymous binding?
> ldapsearch -x -H ldaps://xldap.cern.ch:636 -D brilam -w “#########” -b “OU=Users,OU=Organic Units,DC=cern,DC=ch” "(&(objectClass=user)(sAMAccountName=alokhovi)(memberOf:1
>
> .2.840.113556.1.4.1941:=CN=cms-bril-asset-management,OU=e-groups,OU=Workgroups,DC=cern,DC=ch))" dn
>
> ldap\_bind: Invalid credentials (49)
>
> ```auto
> additional info: 8009030C: LdapErr: DSID-0C09052B, comment: AcceptSecurityContext error, data 2030, v4f7c
>
> ```
>
> ldapsearch -x -H ldaps://xldap.cern.ch:636 -b “OU=Users,OU=Organic Units,DC=cern,DC=ch” "(&(objectClass=user)(sAMAccountName=alokhovi)(memberOf:1.2.840.113556.1.4.1941:=C
>
> N=cms-bril-asset-management,OU=e-groups,OU=Workgroups,DC=cern,DC=ch))" dn
>
> # extended LDIF
>
> #
>
> # LDAPv3
>
> # base \ with scope subtree
>
> # filter: (&(objectClass=user)(sAMAccountName=alokhovi)(memberOf:1.2.840.113556.1.4.1941:=CN=cms-bril-asset-management,OU=e-groups,OU=Workgroups,DC=cern,DC=ch))
>
> # requesting: dn
>
> #
>
> # alokhovi, Users, Organic Units, cern.ch
>
> dn: CN=alokhovi,OU=Users,OU=Organic Units,DC=cern,DC=ch
>
> # search result
>
> search: 2
>
> result: 0 Success
> # numResponses: 2#
> numEntries: 1
LDAP request error:
> Traceback (most recent call last):
>
> File “cmdb/interface/rest\_api/routes/auth\_routes.py”, line 200, in post\_login
>
> File “flask/helpers.py”, line 272, in abort
>
> File “werkzeug/exceptions.py”, line 863, in \__call_\_
>
> werkzeug.exceptions.InternalServerError: 500 Internal Server Error: Could not login
>
> [2025-08-14 06:49:27][ERROR] — [post\_login] Exception: Could not login., Type: \ (auth\_routes.py)
>
> [2025-08-14 06:49:27][ERROR] — [post\_login] Exception: 500 Internal Server Error: Could not login. Type: \ (auth\_routes.py)
>
> Traceback (most recent call last):
>
> File “cmdb/security/auth/providers/ldap\_auth\_provider.py”, line 177, in authenticate
>
> File “ldap3/core/connection.py”, line 363, in \__init_\_
>
> File “ldap3/core/connection.py”, line 412, in \_do\_auto\_bind
>
> ldap3.core.exceptions.LDAPBindError: automatic bind not successful - invalidCredentials
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>
> File “cmdb/security/auth/auth\_module.py”, line 258, in login
>
> File “cmdb/security/auth/providers/ldap\_auth\_provider.py”, line 179, in authenticate
>
> cmdb.errors.provider.provider\_errors.AuthenticationError: automatic bind not successful - invalidCredentials
>
> The above exception was the direct cause of the following exception:
>
> Traceback (most recent call last):
>
> File “cmdb/interface/rest\_api/routes/auth\_routes.py”, line 183, in post\_login
>
> File “cmdb/security/auth/auth\_module.py”, line 284, in login
>
> cmdb.errors.provider.provider\_errors.AuthenticationError: Could not login.
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>
> File “cmdb/interface/rest\_api/routes/auth\_routes.py”, line 200, in post\_login
>
> File “flask/helpers.py”, line 272, in abort
>
> File “werkzeug/exceptions.py”, line 863, in \__call_\_
>
> werkzeug.exceptions.InternalServerError: 500 Internal Server Error: Could not login
Also noticed, a kind of memory leak exists in the DG POD. The reported memory use is always growing. It should not be a big problem in OKD4 as at OOMKill the POD will be rolled out. But if you know some related discussions I’d join.
Regards,
Arkady