Assigning Roles stopped working

[micbar]

Steps to reproduce

1. Set up oCIS with LDAP à la https://ocis.ocis-ldap.latest.owncloud.works
2. Go to user management app
3. Change Role of user einstein from user to space-admin

Expected behaviour

Role assignment should work and be confirmed

Actual behaviour

The role assignment creates an error

Api Request that fails

curl 'https://ocis.ocis-ldap.latest.owncloud.works/graph/v1.0/users/4c510ada-c86b-4815-8820-42cdf82c3d51' \
  -X 'PATCH' \
  --data-raw '{"displayName":"Albert Einstein","id":"4c510ada-c86b-4815-8820-42cdf82c3d51","mail":"einstein@example.org","onPremisesSamAccountName":"einstein","memberOf":[],"passwordProfile":{"password":""}}' \
  --compressed

Response

Status: 500

{"error":{"code":"notAllowed","innererror":{"date":"2022-11-22T13:05:08Z","request-id":"6ab12c33-2630-49ce-97dd-a2d04adf7326"},"message":"server is configured read-only"}}

This seems wrong, the correct API call should be

curl 'https://ocis.ocis-ldap.latest.owncloud.works//api/v0/settings/assignments-add' \
  -H 'Accept: application/json, text/plain, */*' \
  --data-raw '{"account_uuid":"f7fbf8c8-139b-4376-b307-cf0a8c2d0d9c","role_id":"d7beeea8-8ff4-406b-8fb6-ab2dd81e6b11"}' \
  --compressed \
  --insecure

Environment general

Operating system:

Backend (ownCloud Core or Infinite Scale):

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Environment ownCloud Infinite Scale

Version:

Updated from an older Infinite Scale or fresh install:

Where did you install Infinite Scale from:

Environment ownCloud Core

Web server:

Database:

PHP version:

Version: (see ownCloud admin page)

Updated from an older ownCloud or fresh install:

Where did you install ownCloud from:

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and put the link here.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well-sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to diligently
remove *all* hostnames, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption: yes/no

Client configuration

Browser:

Operating system:

Logs

Web server error log

Insert your webserver log here

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

Browser log

Insert your browser log here, this could for example include:

a) The javascript console log
b) The network log 
c) ...

[JammingBen]

Works for me on current master and stable-6.0 (without LDAP):

There is an additional PATCH request beforehand, because the user itself gets saved as well. My guess is that this request fails, so the settings request for the role does not happen at all.

We already have an issue regarding this: #7986. Currently there is no way for Web to find out if the user backend is read-only. A solution for now would be to disable the user management when having LDAP configured as read-only (as @wkloucek suggested).

[JammingBen]

Assigning roles has been fixed via #8013. However, the original issue with LDAP still persists. Let's follow up in this issue: #7986