-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LDAP auth-, user-, and group-providers can't cope with Active Directory GUIDs #2523
Labels
bug
Something isn't working
Comments
rhafer
added a commit
to rhafer/reva
that referenced
this issue
Feb 9, 2022
Active Directory treats UUID attributes like 'objectGUID' as octet string. This means they need some special treatment: - When storing them into UserId Object we need to convert the Raw Value to a string - When using them in LDAP filter they need to be correctly escaped as backslash escaped hex values. Partial Fix for cs3org#2523
rhafer
added a commit
to rhafer/reva
that referenced
this issue
Feb 28, 2022
Active Directory treats UUID attributes like 'objectGUID' as octet string. This means they need some special treatment: - When storing them into UserId Object we need to convert the Raw Value to a string - When using them in LDAP filter they need to be correctly escaped as backslash escaped hex values. Partial Fix for cs3org#2523
rhafer
added a commit
to rhafer/reva
that referenced
this issue
Mar 1, 2022
Active Directory treats UUID attributes like 'objectGUID' as octet string. This means they need some special treatment: - When storing them into UserId Object we need to convert the Raw Value to a string - When using them in LDAP filter they need to be correctly escaped as backslash escaped hex values. Partial Fix for cs3org#2523
rhafer
added a commit
to rhafer/reva
that referenced
this issue
Mar 1, 2022
Active Directory treats UUID attributes like 'objectGUID' as octet string. This means they need some special treatment: - When storing them into UserId Object we need to convert the Raw Value to a string - When using them in LDAP filter they need to be correctly escaped as backslash escaped hex values. Partial Fix for cs3org#2523
rhafer
added a commit
to rhafer/reva
that referenced
this issue
Mar 1, 2022
Active Directory treats UUID attributes like 'objectGUID' as octet string. This means they need some special treatment: - When storing them into UserId Object we need to convert the Raw Value to a string - When using them in LDAP filter they need to be correctly escaped as backslash escaped hex values. Partial Fix for cs3org#2523
wkloucek
pushed a commit
that referenced
this issue
Mar 2, 2022
Active Directory treats UUID attributes like 'objectGUID' as octet string. This means they need some special treatment: - When storing them into UserId Object we need to convert the Raw Value to a string - When using them in LDAP filter they need to be correctly escaped as backslash escaped hex values. Partial Fix for #2523
Related to owncloud/ocis#3150 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When using and Active Directory as the backend for CS3 user and groups it should be possible to use one of the GUID that AD provides as the ID attribute for the cs3 users/groups. E.g. using this configuration:
objectGUID
and other GUID Attributes in AD are just standard UUIDs. However, AD does treat them as bare Octetstring values in LDAP Search Results and LDAP filters. (Different to other LDAP server with return the string representation of UUID). That requires special treatment when e.g. searching something by GUID. AD expects a hex-escaped representation of the GUID in the filter string (e.g.objectGUID=\8c\aa\e2\b0\2e\96\10\2f\8b\3c\97\0f\19\6e\26\95
instead ofobjectGUID=8caae2b0-2e96-102f-8b3c-970f196e2695
)This currently causes issues with LDAP filters we create from go-templates (like the
userfilter
) above. As we can't properly escape the filter any more after the template processing happened.The text was updated successfully, but these errors were encountered: