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)
additional info: 8009030C: LdapErr: DSID-0C09052B, comment: AcceptSecurityContext error, data 2030, v4f7cldapsearch -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 <OU=Users,OU=Organic Units,DC=cern,DC=ch> 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: <class ‘cmdb.errors.provider.provider_errors.AuthenticationError’> (auth_routes.py)
[2025-08-14 06:49:27][ERROR ] — [post_login] Exception: 500 Internal Server Error: Could not login. Type: <class ‘werkzeug.exceptions.InternalServerError’> (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