Hi, Can you elaborate more on this please? It is not clear what you mean by "invalid". If you share with us some example we may offer better assistance.

I created a user "UserExample" with a password "123456". POST scim/v2/Users ```json { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User" ], "password": "123456", "userName": "UserExample", "roles": [ { "value": "data_collection", "type": "operator" } ] } ``` Response ```json { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User" ], "id": "44a6f912-a58d-4103-a8f2-867ddf794b3b", "meta": { "resourceType": "User", "created": "2019-10-31T21:31:37.980Z", "lastModified": "2019-10-31T21:31:37.980Z", "location": "https://sso.local/identity/restv1/scim/v2/Users/44a6f912-a58d-4103-a8f2-867ddf794b3b" }, "userName": "UserExample", "roles": [ { "value": "data_collection", "type": "operator" } ] } ``` Try get access-token use password "123456", fine, work. After, I decided to change the user’s name, lastname, role. PUT scim/v2/Users/44a6f912-a58d-4103-a8f2-867ddf794b3b ```json { "name": { "familyName": "LasNameExampleUser", "givenName": "FirstNameExampleUser" }, "active": true, "roles": [ { "value": "data_collection", "type": "operator" }, { "value": "management_processes", "type": "operator" } ] } ``` Response ```json { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:User" ], "id": "44a6f912-a58d-4103-a8f2-867ddf794b3b", "meta": { "resourceType": "User", "created": "2019-10-31T21:31:37.980Z", "lastModified": "2019-10-31T21:34:52.543Z", "location": "https://sso.local/identity/restv1/scim/v2/Users/44a6f912-a58d-4103-a8f2-867ddf794b3b" }, "userName": "UserExample", "name": { "familyName": "LasNameExampleUser", "givenName": "FirstNameExampleUser", "formatted": "FirstNameExampleUser LasNameExampleUser" }, "active": true, "roles": [ { "value": "data_collection", "type": "operator" }, { "value": "management_processes", "type": "operator" } ] } ``` After sending the request, the password is "123456" does not work anymore. **!!! now I need to reassign the password** PUT scim/v2/Users/44a6f912-a58d-4103-a8f2-867ddf794b3b ```json { "password": "123456" } ```

Hi, Sorry to reply with another question again but I would like to ensure there is not a conceptual misunderstanding here: > After sending the request, the password is "123456" does not work anymore so you are trying to log into an application with the user previously created and it does not let you in? or what do you exactly mean when you say "password does not work"? Do the following please: - Create a user via scim - log into chroot (eg. `sudo gluu-serverd login`) - execute `/opt/opendj/bin/ldapsearch -h localhost -p 1636 -D "cn=directory manager" -w SECRET -ZX -b 'ou=people,o=gluu' -s one "&(objectclass=gluuPerson)(uid=UID)" userPassword ` replacing SECRET with your admin password and UID with the userName of the user created (eg. UserExample). No need for quotes (`"`) - run the PUT request to modify the user just created - execute the `ldapsearch` again Do you notice a difference in the `userPassword` ?

> so you are trying to log into an application with the user previously created and it does not let you in? or what do you exactly mean when you say "password does not work"? Right! before change output ``` dn: inum=56c86087-a444-4f0a-873f-85858201c919,ou=people,o=gluu userPassword: {SSHA512}d6TkakrtI0GiYJT82BLhXb8IFXAckk14EB2u+GcMgNVuDLLYWFa3Z2RebCBqmMBME+WGyjmNrY9pczVly+PeNaMRKkr2qjlX ``` after change output ``` dn: inum=56c86087-a444-4f0a-873f-85858201c919,ou=people,o=gluu ``` password gone! I also found a similar problem (as it seems to me), but sending to json null does not lead to anyone, since according to the scheme null will be ignored. https://support.gluu.org/other/5291/scim-client-updateuser-is-causing-a-password-reset/

I was able to replicate. It is definitely a bug, I opened an [issue](https://github.com/GluuFederation/oxTrust/issues/1869) to keep track of this. Sorry for the inconvenience. We'll deliver a fix soon. I'll update here.

@Jose.Gonzalez Thank! Will wait.

Victor, The fix will be included in CE 4.0.1. It will take a couple of weeks to be released so If you'd like to patch your server now (manually), here is how to do so: - login to chroot - cd to `/opt/gluu/jetty/identity/webapps` - backup oxtrust: `cp identity.war /root ` - stop it: `systemctl stop identity` - download war with bug fix: `wget https://ox.gluu.org/maven/org/gluu/oxtrust-server/4.0.1.Final/oxtrust-server-4.0.1.Final.war` - replace war: `mv oxtrust-server-4.0.1.Final.war identity.war` - start identity: `systemctl start identity` Wait a couple of minutes and test. Should be good now. Let us know...

Hi Kittinan, I did I quick try and it is working fine here (4.1). Please share more details (eg. sample payloads/code) to better assist you. Also account that you should set `active` to `true` for users to be able to login to any application.

Hi, > I tried replacing oxtrust_server with version 4.1.0 Right, you cannot swap wars between major releases, ie. on 4.0 only 4.0.x wars will work, not 4.x It's strange but for some reason, the commits that fixed the bug ended up in branch 4.1 only, not 4.0.1 Gluu 4.1 is in final QA stage, but won't be available in prod repos until docs get fully updated. However, current release candidate is quite close to the final product. You can visit https://repo.gluu.org/ click on Gluu server and download the 4.1 deb file on the rightmost column inside the tab matches your distro. Then you can do `dpkg -i file.deb` ... In the following I describe how you can manually patch your 4.0/4.0.1 instance in case you want to do so. You can do the first 5 steps in a local machine if you have java installed on it, otherwise it has to be done in the server where Gluu is installed - Download 4.1 war: https://ox.gluu.org/maven/org/gluu/oxtrust-server/4.1.0.Final/oxtrust-server-4.1.0.Final.war - Download 4.1 jar: https://ox.gluu.org/maven/org/gluu/oxtrust-model/4.1.0.Final/oxtrust-model-4.1.0.Final.jar - Run `jar -xf oxtrust-server-4.1.0.Final.war WEB-INF/classes/org/gluu/oxtrust/service/scim2/Scim2UserService.class` - Run `cd WEB-INF/classes` - Run `jar -xf ../../oxtrust-model-4.1.0.Final.jar org/gluu/oxtrust/model/scim/ScimCustomPerson.class` - Transfer `WEB-INF` folder to your server **inside** chroot (eg. `/opt/gluu-server-4.0/root`) - Login to Gluu chroot (eg. `gluu-serverd login`) - Backup current war (eg. `cp /opt/gluu/jetty/identity/webapps/identity.war /root/identity.war.bak`) - Run `cd /root` - Run `jar -uf /opt/gluu/jetty/identity/webapps/identity.war WEB-INF/classes/org/gluu/oxtrust/service/scim2/Scim2UserService.class` - Run `jar -uf /opt/gluu/jetty/identity/webapps/identity.war WEB-INF/classes/org/gluu/oxtrust/model/scim/ScimCustomPerson.class` - Restart oxtrust (eg. `systemctl restart identity`)

I'm facing same issue on gluu 4.3.1. After I change the user status from "active" to "inactive" or vice versa the password gets reset

Hi. I was unable to reproduce this behavior. I grabbed a 4.3.1 installation and tried what you suggested. The password remained untouched after several updates flipping the active attribute via SCIM.