Not able to login with Active Directory after upgrade from 2.x to 4.x

[micbar]

Describe the bug

Picked up from a conversation in matrix: https://matrix.to/#/!MXIMfhTMMRFPuXSKJZ:matrix.org/$LlBK7zO_CNrAH5CCFbazpDECzotk-B73NN7_Xnnictk?via=chat.opencloud.eu&via=matrix.org&via=tchncs.de

Steps to reproduce

1. Use ActiveDirectory in Shared Directory mode
2. Upgrade from 2.x to 4.x
3. Try to login

Expected behavior

Login should still be possible, user accounts should not have changed

Actual behavior

No login possible

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

Details

OC_XXX=somevalue
OC_YYY=somevalue
PROXY_XXX=somevalue

Additional context

Add any other context about the problem here.

[butonic]

Let us verify the uuid in the ldap -> keycloak -> opencloud -> ldap chain is passed on correctly:

1. is keycloak federating with samba? how is the objectguid mapped to the userid claim that you have configured? it should be an additional claim. By default keycloak does not add the objectguid.
2. PROXY_USER_CS3_CLAIM=userid will try to look up the user by userid. PROXY_USER_OIDC_CLAIM needs to be set to the corresponding claim. You mentioned it is set to preferred_username ... which I assume is derived from the samaccountname from samba. That does not match the OC_LDAP_USER_SCHEMA_ID=objectGUID.

[kenodai]

Let's start with the relevant 2.x configuration snippet I was using:

OC_URL:                                 https://<ocurl>
OC_EXCLUDE_RUN_SERVICES:                idp,idm
OC_OIDC_ISSUER:                         https://<keycloak>
PROXY_OIDC_REWRITE_WELLKNOWN:           true
OC_LDAP_URI:                            ldaps://<ldap>/
OC_LDAP_SERVER_WRITE_ENABLED:           false
GRAPH_LDAP_SERVER_WRITE_ENABLED:        false
OC_ADMIN_USER_ID:                       
SETTINGS_SETUP_DEFAULT_ASSIGNMENTS:     false
GRAPH_ASSIGN_DEFAULT_USER_ROLE:         false
GRAPH_USERNAME_MATCH:                   none
FRONTEND_READONLY_USER_ATTRIBUTES:      user.onPremisesSamAccountName,user.displayName,user.mail,user.passwordProfile,user.accountEnabled,user.appRoleAssignments
OC_LDAP_USER_OBJECTCLASS:               user
OC_LDAP_USER_SCHEMA_DISPLAYNAME:        displayname
OC_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING:  true
OC_LDAP_USER_SCHEMA_ID:                 objectGUID
OC_LDAP_USER_SCHEMA_MAIL:               mail
OC_LDAP_USER_SCHEMA_USERNAME:           sAMAccountName
OC_LDAP_GROUP_OBJECTCLASS:              group
OC_GROUP_SCHEMA_DISPLAYNAME:            cn
OC_GROUP_SCHEMA_GROUPNAME:              cn
OC_GROUP_SCHEMA_ID_IS_OCTETSTRING:      true
OC_GROUP_SCHEMA_ID:                     objectGUID
OC_GROUP_SCHEMA_MAIL:                   mail
OC_GROUP_SCHEMA_MEMBER:                 member
STORAGE_USERS_DRIVER:                   decomposeds3

That was/is working absolutely fine on 2.x, but not on 4.x
Up until a few hours ago I was not passing the objectGUID claim from keycloak. So apparently it was all handled via the username.

Logs from 4.x will follow.

[kenodai]

2026-02-06T10:36:15Z DBG GetUserByClaim error="error parsing attribute 'sAMAccountName' value '' as UUID: error parsing id 'marc' as UUID: invalid UUID length: 4" host.name=main-b6b576b65-w2kzq line=github.com/opencloud-eu/reva/v2@v2.40.3/pkg/user/manager/ldap/ldap.go:156 pkg=rgrpc service=users traceid=fc45df70caacccea731dbad2c3d02d35
2026-02-06T10:36:15Z DBG unary code=OK end="06/Feb/2026:10:36:15 +0000" from=tcp://127.0.0.1:42540 host.name=main-b6b576b65-w2kzq line=github.com/opencloud-eu/reva/v2@v2.40.3/internal/grpc/interceptors/log/log.go:69 pkg=rgrpc service=users start="06/Feb/2026:10:36:15 +0000" time_ns=378874 traceid=fc45df70caacccea731dbad2c3d02d35 uri=/cs3.identity.user.v1beta1.UserAPI/GetUserByClaim user-agent=grpc-go/1.77.0
2026-02-06T10:36:15Z DBG unary code=OK end="06/Feb/2026:10:36:15 +0000" from=tcp://127.0.0.1:34352 host.name=main-b6b576b65-w2kzq line=github.com/opencloud-eu/reva/v2@v2.40.3/internal/grpc/interceptors/log/log.go:69 pkg=rgrpc service=gateway start="06/Feb/2026:10:36:15 +0000" time_ns=1284030 traceid=fc45df70caacccea731dbad2c3d02d35 uri=/cs3.gateway.v1beta1.GatewayAPI/GetUserByClaim user-agent=grpc-go/1.77.0
2026-02-06T10:36:15Z DBG authsvc: error in Authenticate error="internal error: error getting user by claim" client_id=username:marc host.name=main-b6b576b65-w2kzq line=github.com/opencloud-eu/reva/v2@v2.40.3/internal/grpc/services/authprovider/authprovider.go:141 pkg=rgrpc service=auth-machine traceid=fc45df70caacccea731dbad2c3d02d35
2026-02-06T10:36:15Z DBG unary code=OK end="06/Feb/2026:10:36:15 +0000" from=tcp://127.0.0.1:45950 host.name=main-b6b576b65-w2kzq line=github.com/opencloud-eu/reva/v2@v2.40.3/internal/grpc/interceptors/log/log.go:69 pkg=rgrpc service=auth-machine start="06/Feb/2026:10:36:15 +0000" time_ns=2401091 traceid=fc45df70caacccea731dbad2c3d02d35 uri=/cs3.auth.provider.v1beta1.ProviderAPI/Authenticate user-agent=grpc-go/1.77.0
2026-02-06T10:36:15Z DBG unary code=OK end="06/Feb/2026:10:36:15 +0000" from=tcp://127.0.0.1:34352 host.name=main-b6b576b65-w2kzq line=github.com/opencloud-eu/reva/v2@v2.40.3/internal/grpc/interceptors/log/log.go:69 pkg=rgrpc service=gateway start="06/Feb/2026:10:36:15 +0000" time_ns=4557557 traceid=fc45df70caacccea731dbad2c3d02d35 uri=/cs3.gateway.v1beta1.GatewayAPI/Authenticate user-agent=grpc-go/1.77.0
2026-02-06T10:36:15Z ERR Could not get user by claim error="could not get user by claim username with value marc : error authenticating credentials to auth provider for type: machine " line=github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/account_resolver.go:159 service=proxy
2026-02-06T10:36:15Z INF access-log bytes=0 duration=23.229338 line=github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/accesslog.go:34 method=GET path=/ocs/v1.php/cloud/capabilities proto=HTTP/1.1 remote-addr=10.50.128.6 request-id=441d6bf0-2ed1-4141-900f-1beb302a4c81 service=proxy status=500 traceid=fc45df70caacccea731dbad2c3d02d35

[kenodai]

2. PROXY_USER_CS3_CLAIM=userid will try to look up the user by userid. PROXY_USER_OIDC_CLAIM needs to be set to the corresponding claim. You mentioned it is set to preferred_username ... which I assume is derived from the samaccountname from samba. That does not match the OC_LDAP_USER_SCHEMA_ID=objectGUID.

All guesses correct, nothing to object here. Question is, why was this ever working in 2.x? Which obscure path did I misuse for this to be working?
As a side note: This installation was migrated from ocis without copying the data.