You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 of objectGUID=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:
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
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: