LDAP Issue with users with single domain
We are using Azure AD for authentication of users and LDAP to sync users from Ad to archer. This is because, ultimately our Azure Ad is syncing users from AD. So we thought we leverage the ldap sync jobs.
Now, We are sending domain information from azure AD as domain is mandatory in archer. We added few users to that domain and tested their login with ADP/SSO. That worked perfectly. However, when we ran the query to update all the users with the same domain, then we observed that the users for whom this used to work also got disturbed and no user is able to log in. We used below queries:
for few users:
update tbluser set ldap_config_id = xx where ldap_config_id=xx and user_username ='xxx'
for bulk users or all users,
update tbluser set ldap_config_id = xx.
All users should have single domain. However, we are 100% sure that there are no duplicates.
What we did wrong for bulk users.
- archer 6.x
- archer admin 6.2
- archer admins
- archer discussion
- Archer Integration
- archer ldap
- Community Thread
- Forum Thread
- RSA Archer
- rsa archer 6.2
- RSA Archer Suite
To update users in bulk, the recommended and supported method is to use the Archer API. Check out these links:
- Using REST API, Metadata User
- Using Web Services, UpdateUserEx method in Access Control Class
- RSA Archer API Users
- How to use the Archer REST API and Web Services API with Windows PowerShell
- Archer Bulk User Uploader (or Import) tool
Using SQL queries is not a recommended approach for several reasons:
1. The database schema is different between Archer versions. For example, translation tables introduced.
2. SQL bypasses Archer code logic, permissions, and auditing.
3. Custom SQL queries are not supported.
4. The data can be spread across many, many tables.
5. SQL commands should not be used unless it's absolutely necessary to resolve an issue OR functionality does not exist.
For example, the SQL command you have for all users would also update Archer system user accounts for things like backend services, Data Feeds, etc and this can have unknown side effects. I recommend restoring the Instance database to a state before the SQL commands were ran for all users.
As a side note, Azure is not qualified or supported with Archer. There is an enhancement request logged as ARCHER-32451: Support for Azure Active Directory. I encourage customers wanting this functionality to open an Archer Support Case requesting your company be added to the enhancement request. Also, check out the Azure Hosting Considerations discussion.
Finally, I also recommend you Join an RSA Archer Working Group & See Upcoming Schedule and Attend an RSA Archer Roadmap Session. Joining the working groups allows you to speak directly with the Product Team about common issues, provide feedback on current and future features, and share experiences with other customers. Specifically, check out the Archer in the Cloud group hosted by Brian Schaefer.