1

I imported bulk users in WSO2 API manager, but all the users' passwords expired in 24 hours. I had to systematically change each and every user's password a couple days later. How can I avoid this? Is there a way to change the expiration time?

Community
  • 1
  • 1
Lilp
  • 11
  • 4
  • How did you import? – Bee Sep 16 '19 at 11:05
  • @Bee The method I used to do the bulk import (See Link) is similar to this method (see link) https://docs.wso2.com/display/ESB300/Importing+Users+in+Bulk. However I used the format of username,password,email,roles when doing the bulk import via comma separated list. – Lilp Sep 16 '19 at 15:41

1 Answers1

2

According to the implementation of the Bulk User Import feature, it sets "requirePasswordChange" to true when adding the users and it is not configurable. (Ref [1], [2]). Then, during the authentication [3], it checks for this flag and fails the authentication if the last password set time (UM_CHANGED_TIME column of UM_USER table) is older than 24hours.

One solution would be writing a custom userstore manager to override this property and set it to false always when adding users. Further described in [4].

One other hack would be directly removing this password expiry property for all the users from the userstore database directly. You can simply set "UM_REQUIRE_CHANGE" value for all the users to make their passwords work even after 24hours.

UPDATE UM_USER SET UM_REQUIRE_CHANGE=FALSE;

[1] https://github.com/wso2/carbon-identity-framework/blob/master/components/user-mgt/org.wso2.carbon.user.mgt/src/main/java/org/wso2/carbon/user/mgt/bulkimport/CSVUserBulkImport.java#L178

[2] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/AbstractUserStoreManager.java#L2707

[3] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/jdbc/JDBCUserStoreManager.java#L1232-L1240

[4] https://stackoverflow.com/a/47976366

Sajith
  • 1,240
  • 8
  • 15
  • 1
    For certain DBs, it's `UPDATE UM_USER SET UM_REQUIRE_CHANGE=0` instead of `FALSE`. Check the type of `UM_REQUIRE_CHANGE` for your DB in your deployment's `dbscripts` directory – Codebling Jun 08 '21 at 05:16