Unable to change 'uidNumber' LDAP filter in users service (OCIS Helm/Kubernetes)

[justSem]

Describe the bug

When setting up OCIS on Kubernetes with Authentik as OIDC/LDAP backend I observe some strange behaviour. The helm charts setting externalUserManagement.ldap.user.shchema.id makes me think that is the 'uid' value the user service will use to perform it's LDAP search with. However, when going through the debug logging it becomes evident the behavior is different.

An example below: 2024-04-22T15:25:31Z DBG GetUserByClaim error="error: not found: (&(objectClass=user)(objectclass=inetOrgPerson)(uidNumber=<OIDC hash>)(!(ak-active=FALSE)))"

This error makes evident that the user service seems to be looking for an attribute called uidNumber. While this is a valid and existing attribute in my LDAP schema, it's automatically populated by Authentik and is not propagated to any OIDC claim, hence, I cannot match on this specific value. However, the OIDC claims do supply me with an uid hash, which is also present in the LDAP schema as the uid attribute.

I would assume that setting externalUserManagement.ldap.user.shchema.id to uid would alter uidNumber to uid in the LDAP search filter.

Steps to reproduce

1. Deploy both OCIS and Authentik on K3S using helm.
2. Setup LDAP/OIDC using the default values in Authentik
3. Configure the OCIS helm chart as per the values below
4. Attempt l ogin.

Expected behavior

I expected that when externalUserManagement.ldap.user.shchema.id is set to uid it would alter the LDAP search to use that specific attribute in the LDAP search filter.

Actual behavior

The user service searches for a (seemingly hardcoded?) value of uidNumber.

Setup

I'm running K3S on Ubuntu. OCIS is deployed using the OCIS helm chart. Authentik is deployed using the Authentik helm chart. There is an Authentik outpost in the proper namespace which OCIS can authenticate to.k -

Additional context

User schema example

dn: cn=<redacted>,ou=users,dc=ldap,dc=<redacted>,dc=<redacted>
app_password: <redacted>
app_username: <redacted>
uidNumber: 2005
sAMAccountName: <redacted>
name: <redacted>
mail: <redacted>
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: user
objectClass: posixAccount
objectClass: goauthentik.io/ldap/user
memberOf: cn=authentik Admins,ou=groups,dc=ldap,dc=<redacted>,dc=<redacted>
sn: <redacted>
ak-active: TRUE
ak-superuser: TRUE
uid: 2ed8e57fe0cf86d07488b6e5626e2ce0262cddaab98cde67459ad620de8dfe5a
homeDirectory: /home/username
cn: <redacted>
displayName: <redacted>
gidNumber: 2005

Helm chart values

   features:
      externalUserManagement:
        enabled: true
        adminUUID: "<redacted>"
        oidc:
          issuerURI: "<redacted>"
          webClientID: "<redacted>"
          userIDClaim: "sub"
          userIDClaimAttributeMapping: "uid"
          sessionManagementLink: "<redacted>"
          editAccountLink: "<redacted>"
          roleAssignment:
            enabled: true
            claim: "groups"
            mapping:
              - role_name: "admin"
                claim_value: "authentik Admins"
              - role_name: "user"
                claim_value: "OCIS User"
        ldap:
          writeable: false
          uri: "ldaps://<redacted>"
          certTrusted: false
          bindDN: "cn=<redacted>,OU=users,dc=ldap,dc=<redacted>,dc=<redacted>"
          baseDN: "DC=ldap,DC=<redacted>,DC=<redacted>"
          useServerUUID: true
          user:
            schema:
              id: "uid"
              userName: "cn"
              displayName: "displayName"
            baseDN: "OU=users,DC=ldap,DC=<redacted>,DC=<redacted>"
            filter: "(objectClass=user)"
          group:
            schema:
              id: "uid"
            baseDN: "OU=groups,DC=ldap,DC=<redacted>,DC=<redacted>"
            filter: "(objectClass=group)"
          disableUsers:
            disableMechanism: "attribute"
            userEnabledAttribute: "ak-active"
    secretRefs:
      ldapCaRef: "ldap-ca"
      ldapSecretRef: "ldap-bind-secrets"

[rhafer]

Moving this to the ocis-charts repository.

[rhafer]

When setting up OCIS on Kubernetes with Authentik as OIDC/LDAP backend I observe some strange behaviour. The helm charts setting externalUserManagement.ldap.user.shchema.id makes me think that is the 'uid' value the user service will use to perform it's LDAP search with. However, when going through the debug logging it becomes evident the behavior is different.

An example below: 2024-04-22T15:25:31Z DBG GetUserByClaim error="error: not found: (&(objectClass=user)(objectclass=inetOrgPerson)(uidNumber=<OIDC hash>)(!(ak-active=FALSE)))"

This is weird, we are not using the uidNumber attribute in any filter by default. This value must be coming from somewhere else. Are you sure you not externalUserManagement.ldap.user.schema.id somewhere else? . Can you check the envvars of the users pod? What is USERS_LDAP_USER_SCHEMA_ID set to?

[justSem]

When setting up OCIS on Kubernetes with Authentik as OIDC/LDAP backend I observe some strange behaviour. The helm charts setting externalUserManagement.ldap.user.shchema.id makes me think that is the 'uid' value the user service will use to perform it's LDAP search with. However, when going through the debug logging it becomes evident the behavior is different. An example below: 2024-04-22T15:25:31Z DBG GetUserByClaim error="error: not found: (&(objectClass=user)(objectclass=inetOrgPerson)(uidNumber=<OIDC hash>)(!(ak-active=FALSE)))"

This is weird, we are not using the uidNumber attribute in any filter by default. This value must be coming from somewhere else. Are you sure you not externalUserManagement.ldap.user.schema.id somewhere else? . Can you check the envvars of the users pod? What is USERS_LDAP_USER_SCHEMA_ID set to?

That's one of the first things I've checked as well, both of those reflect the values I've set in the helm chart.

sem@jumphost:~$ k -n ocis exec -it users-559b949c5-kjxrj -- env | grep ^USERS
(sensitive values omitted)
USERS_LDAP_GROUP_SCHEMA_MAIL=mail
USERS_LDAP_GROUP_SCHEMA_DISPLAYNAME=cn
USERS_LDAP_GROUP_SCHEMA_GROUPNAME=cn
USERS_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=false
USERS_LDAP_USER_SCHEMA_MAIL=mail
USERS_LDAP_CACERT=/etc/ocis/ldap-ca/ldap-ca.crt
USERS_LDAP_GROUP_SCHEMA_MEMBER=member
USERS_LOG_COLOR=true
USERS_TRACING_TYPE=jaeger
USERS_GRPC_ADDR=0.0.0.0:9144
USERS_LDAP_USER_OBJECTCLASS=inetOrgPerson
USERS_LDAP_USER_SCHEMA_DISPLAYNAME=displayName
USERS_LDAP_USER_SCHEMA_USERNAME=cn
USERS_LDAP_USER_SUBSTRING_FILTER_TYPE=any
USERS_LDAP_USER_SCHEMA_ID=uid
USERS_LDAP_USER_TYPE_ATTRIBUTE=ownCloudUserType
USERS_LDAP_USER_ENABLED_ATTRIBUTE=ak-active
USERS_LDAP_DISABLE_USER_MECHANISM=attribute
USERS_LDAP_USER_FILTER=(objectClass=user)
USERS_LDAP_GROUP_OBJECTCLASS=groupOfNames
USERS_LDAP_GROUP_SCHEMA_ID=uid
USERS_LDAP_GROUP_SCHEMA_ID_IS_OCTETSTRING=false
USERS_LDAP_GROUP_SCOPE=sub

[rhafer]

@justSem Which ocis release are you using. And which branch/tag or commitid of the ocis-charts?

[rhafer]

nevermind I think I found the problem. There's likely a misunderstanding in what the value uid for userIDClaimAttributeMapping actually means.

From your helm values:

 features:
      externalUserManagement:
[..]
        oidc:
[..]
          userIDClaim: "sub"
          userIDClaimAttributeMapping: "uid"

You set userIDClaimAttributeMapping to uid. The CS3 user attribute uid actually reflects the LDAP attribute uidNumber (which is really unfortunate, I know, but that's how it is currently). I think what you need to set there is actually userid that will map to the LDAP attribute defined in with USERS_LDAP_USER_SCHEMA_ID.

[justSem]

@rhafer I can confirm that did the trick! I was so confused for a good minute there. Thank you :)