auth-basic with Active Directory produces byte-swapped objectGUID as opaque_id, causing GetUserGroups to fail

[jordivandijk]

Bug: auth-basic with Active Directory produces byte-swapped objectGUID as opaque_id, causing GetUserGroups to fail

Describe the bug

When authenticating via WebDAV using Basic Auth against an Active Directory LDAP backend, the auth-basic service successfully finds and binds the user by sAMAccountName, but then fails at the GetUserGroups step with grpc getting user groups failed: 'error getting user groups', resulting in error code 15 (UNAUTHENTICATED).

The root cause is a byte order mismatch in how auth-basic constructs the user's opaque_id from the raw AD objectGUID bytes after a successful LDAP bind. The endianness fix introduced in #1901 (for the OIDC/web login path) does not appear to be applied in the auth-basic code path.

Steps to reproduce

1. Configure OpenCloud with an external Active Directory as LDAP backend and external Keycloak as OIDC IDP, using objectGUID as the user ID attribute (OC_LDAP_USER_SCHEMA_ID=objectGUID, OC_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=true).
2. Verify that web UI login via Keycloak OIDC works correctly.
3. Attempt to authenticate a WebDAV connection from an external client (e.g. Windows) using the AD username and password via Basic Auth.

Expected behavior

Basic Auth with a valid AD username and password should authenticate successfully, allowing WebDAV access from external clients.

Actual behavior

auth-basic finds the user in AD by sAMAccountName and the LDAP bind succeeds, but the subsequent GetUserGroups call fails with not found. Authentication is rejected with code 15.

The root cause is that auth-basic constructs the user's opaque_id from the raw AD objectGUID bytes without applying the little-endian to UUID string conversion that AD requires for the first three UUID segments. This produces a byte-swapped opaque_id.

Example: A user whose objectGUID is correctly expressed as ba94e17e-da1a-44ba-a365-2c02a825d886 gets assigned the opaque_id 7ee194ba-1ada-ba44-a365-2c02a825d886 (byte-swapped). The GetUserGroups call then searches LDAP using this wrong ID and returns not found.

Relevant log sequence:

# auth-basic finds and binds the user successfully
{"service":"auth-basic","filter":"(&(objectclass=person)(|(sAMAccountName=<username>)))","message":"LDAP Search"}

# GetUserGroups is called with the byte-swapped opaque_id
{"service":"users","filter":"(&(objectclass=person)(objectGUID=\\ba\\94\\e1\\7e\\da\\1a\\44\\ba\\a3\\65\\2c\\02\\a8\\25\\d8\\86))","message":"LDAP Search"}

# Lookup fails because the opaque_id used is byte-swapped
{"service":"users","error":"error: not found: (&(objectclass=person)(objectGUID=\\ba\\94\\e1\\7e...))","userid":{"opaque_id":"7ee194ba-1ada-ba44-a365-2c02a825d886"},"message":"Failed to lookup user"}

# Final failure
{"service":"auth-basic","error":"ldap: grpc getting user groups failed: 'error getting user groups'","message":"authsvc: error in Authenticate"}
{"service":"proxy","error":"could not authenticate with username and password user: <username>, got code: 15","message":"failed to authenticate request"}

Setup

OpenCloud 7.0.0 rolling (2026-05-21), deployed via Docker Compose with external Active Directory (Windows Server) and Keycloak 26.6.0 as OIDC IDP.

Details

OC_LDAP_URI=ldap://ad.example.com:389
OC_LDAP_INSECURE=true
OC_LDAP_BIND_DN=serviceaccount@example.com
OC_LDAP_USER_BASE_DN=OU=Users,DC=example,DC=com
OC_LDAP_USER_SCHEMA_ID=objectGUID
OC_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=true
OC_LDAP_USER_OBJECTCLASS=person
OC_LDAP_USER_SCHEMA_USERNAME=sAMAccountName
OC_LDAP_GROUP_BASE_DN=OU=OpenCloud,OU=Groups,DC=example,DC=com
OC_LDAP_GROUP_SCHEMA_ID=cn
OC_LDAP_GROUP_SCHEMA_ID_IS_OCTETSTRING=false
OC_LDAP_GROUP_OBJECTCLASS=group
OC_LDAP_SERVER_WRITE_ENABLED=false
OC_EXCLUDE_RUN_SERVICES=idm,idp,search
PROXY_USER_OIDC_CLAIM=uuid
PROXY_USER_CS3_CLAIM=userid
PROXY_AUTOPROVISION_ACCOUNTS=false
USERS_LDAP_URI=ldap://ad.example.com:389
USERS_LDAP_USER_SCHEMA_ID=objectGUID
USERS_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=true
USERS_LDAP_USER_SCHEMA_USERNAME=sAMAccountName
AUTH_APP_CS3_CLAIM=userid
OC_OIDC_ISSUER=https://keycloak.example.com/realms/openCloud

Additional context

• Web UI login via Keycloak OIDC works correctly — the endianness fix in handle objectguid endianess #1901 applies to this path.
• WebDAV Basic Auth fails — the same endianness fix is not applied when auth-basic constructs the opaque_id from the raw objectGUID bytes after a successful LDAP bind.
• The Keycloak token contains the correct UUID string (e.g. ba94e17e-da1a-44ba-a365-2c02a825d886), while auth-basic produces a byte-swapped opaque_id (e.g. 7ee194ba-1ada-ba44-a365-2c02a825d886). These are the same objectGUID with the first three segments' bytes reversed, which is the classic Windows AD little-endian encoding issue.
• No workaround has been found that does not require either patching reva or restructuring the entire user ID scheme away from objectGUID.
• A secondary issue exists where auth-app always calls GetUserByClaim(claim="username") regardless of the AUTH_APP_CS3_CLAIM=userid setting, causing app token authentication to also fail — but that is a separate bug.

[micbar]

@jordivandijk I don't understand: You have OpenIDConnect, what does basic auth mean in that context?

Basic auth on the API level is only supported for development.

[jordivandijk]

@micbar

We have a couple of boox tablets that we want to sync with open-cloud. For the webdav client that boox has only basic auth is configurable. Same for windows, it can't handle the OIDC/browser-based login at all.

[micbar]

We have the app token mechanism for that use case.

[jordivandijk]

@micbar I can't seem to get that working when using keycloak as well. We still would like to sync the users and roles from our windows AD. without keycloak I have had a working example for BOOX with the app token mechanism.

Should these be able to work together as well and is it a skill-issue on my part?

[micbar]

App tokens should be independent of the IdP.

[jordivandijk]

@micbar would my issue than be related to this? #581

[micbar]

That ticket relates to non standard keycloak user ids.

You can see the opencloud user id in your preferences pane. The user id and the app token should be used for WebDAV auth.

[jordivandijk]

@micbar I have tried that mutiple times with app token. I have removed support for basic auth entirely now. In the logs I can see the following issue (again):

opencloud-1  | {"level":"debug","service":"auth-app","host.name":"e802d626a479","pkg":"rgrpc","traceid":"984a2ef7d2b29ee1c5cfc2bc12023028","client_id":"Jordi","error":"internal error: error getting user by claim","time":"2026-06-01T15:18:25Z","line":"github.com/opencloud-eu/reva/v2@v2.46.0/internal/grpc/services/authprovider/authprovider.go:141","message":"authsvc: error in Authenticate"}
opencloud-1  | {"level":"debug","service":"proxy","msg":"error authenticating credentials to auth provider for type: appauth","clientid":"Jordi","time":"2026-06-01T15:18:25Z","line":"github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/app_auth.go:48","message":"app auth failed"}
opencloud-1  | {"level":"debug","service":"users","host.name":"e802d626a479","pkg":"rgrpc","traceid":"6f7b5781ce9730cb08aaf70f1201f7c5","error":"error parsing attribute 'sAMAccountName' value '' as UUID: error parsing id 'Jordi' as UUID: invalid UUID length: 5","time":"2026-06-01T15:18:25Z","line":"github.com/opencloud-eu/reva/v2@v2.46.0/pkg/user/manager/ldap/ldap.go:161","message":"GetUserByClaim"}
opencloud-1  | {"level":"debug","service":"auth-app","host.name":"e802d626a479","pkg":"rgrpc","traceid":"6f7b5781ce9730cb08aaf70f1201f7c5","client_id":"Jordi","error":"internal error: error getting user by claim","time":"2026-06-01T15:18:25Z","line":"github.com/opencloud-eu/reva/v2@v2.46.0/internal/grpc/services/authprovider/authprovider.go:141","message":"authsvc: error in Authenticate"}
opencloud-1  | {"level":"debug","service":"proxy","msg":"error authenticating credentials to auth provider for type: appauth","clientid":"Jordi","time":"2026-06-01T15:18:25Z","line":"github.com/opencloud-eu/opencloud/services/proxy/pkg/middleware/app_auth.go:48","message":"app auth failed"}

[micbar]

OpenCloud cannot find the keycloak user in LDAP. That is a different issue or a wrong user id.

[jordivandijk]

@micbar I get that, only I can login tot the web-UI using keycloak fine. This issue only appears when trying to use webdav with the app token. Username/id is used from the preferences page.

[butonic]

@jordivandijk This works:

curl 'https://cloud.opencloud.test/remote.php/dav/spaces/6a707bcc-2263-4023-9315-dec7d9234dc3%24918df074-f20c-1040-9dc4-2186e89eb6ee' -X PROPFIND -u "admin:voucher worried purist bash spelling such"
<d:multistatus xmlns:s="http://sabredav.org/ns" xmlns:d="DAV:" xmlns:oc="http://owncloud.org/ns">...</d:multistatus>

[butonic]

and since you are using AD did you configure

OC_LDAP_USER_SCHEMA_USERNAME=samaccountname
OC_LDAP_USER_SCHEMA_ID=objectguid
OC_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING=true // this specifically handles the objectguid encoding from AD
...

and maybe others to match the AD schema?

You may also double check keycloak is sending the necessary claims. Preferably the objectguid from AD ... which it should also map in the same byte order.

You can configure how to map the claims to the opencloud user using

PROXY_USER_OIDC_CLAIM=uuid ... or email, preferred_username ... or whatever
PROXY_USER_CS3_CLAIM=userid ... or mail, username