Please allow me to ask couple of questions: - You want userPassword attribute to pull with Cache Refresh? - You want your users as they can change password from Gluu Server ( by oxTrust GUI )?

Thanks for the response from Mohib. In short, we need to add new users to a Gluu server based on records in an AD server (using Cache Refresh). And then, such new users can login to the Gluu server. However, we are not able to pull values from the AD server to the userPassword attribute during Cache Refresh operation. Therefore, currently, we need to have an administrator set passwords manually for those new users (using oxTrust) before such new users can login to the Gluu server. Any advice for the case?

>> we need to add new users to a Gluu server based on records in an AD server (using Cache Refresh). Ok. Default cache refresh; straight solution. >> And then, such new users can login to the Gluu server. Ok, general authentication method. Straight purpose. >> However, we are not able to pull values from the AD server to the userPassword attribute during Cache Refresh operation. We need to check why 'userPassword' attribute is not pulling. But if you use your backend as 'user source'; you actually don't need to pull this password attribute and value. Check out '[Manage Authentication](https://gluu.org/docs/ce/3.0.1/admin-guide/user-group/#ldap-synchronization)' section in Cache Refresh. By using 'Manage Authentication', you are actually pointing to your backend AD server which will 'validate' passwords for any active users so you do not need to store any password here in Gluu Server. >> Therefore, currently, we need to have an administrator set passwords manually for those new users (using oxTrust) before such new users can login to the Gluu server. Whenever you will point your backend AD server in Manage Authentication section, users who are active in your backend will be able to login in Gluu Server. But make sure to use multiple browser when you apply Manage Authentication settings, keep old browser active for any kind of roll back.

Thanks for the further information provided by Mohib. Following the steps as shown in "Part 3/3: Managing Authentication After You've Setup Cache Refresh", new users can now login to the Gluu server. However, there comes another problem. Without the original backend LDAP server, all administrator accounts no longer exist. On the other hand, all new users (from the AD server) do not have administrator rights. What is the suggested approach for having administrators under the new arrangement (using the AD server for authentication)? My only idea is that, with the original backend LDAP server still in use, import new users from the AD server, appoint some new users as administrators, then start using the AD server for authentication. I wonder whether there can be a better approach with less human intervene. For example, can a new user be directly imported as an administrator? If so, how can it be done?

You can add any user in Gluu Server administrative group with oxTrust /GUI. Please read [User Management](https://gluu.org/docs/ce/3.0.1/admin-guide/user-group/) doc for clarifications. If doc is not clear, let us know please.

Thanks for reply by Mohib. Before posting my last message, I have already read "[User Management in Gluu Server](https://gluu.org/docs/ce/3.0.1/admin-guide/user-group/)". However, from the web page, I can only find the steps to add a user to the administrator group (Gluu Manager Group) manually using the UI of oxTrust. On the other hand, what I want is adding selected new users to the administrator group automatically during the operation of Cache Refresh.

>> On the other hand, what I want is adding selected new users to the administrator group automatically during the operation of Cache Refresh. Let's create a new ticket and move forward from there? This ticket's subject is different. Please use proper subject for next ticket, if you don't mind; that will help other community users to search solutions/suggestions on same situation.

Thanks for the advice by Mohib. I have create a new ticket: [https://support.gluu.org/identity-management/4038/assign-users-to-suitable-groups-during-cache-refresh-operation/](https://support.gluu.org/identity-management/4038/assign-users-to-suitable-groups-during-cache-refresh-operation/)