Hello, You can implement Reverse Synchronisation as descrived within the IM Guide (https://docops.ca.com/ca-identity-manager/14-2/EN/administrating/managed-endpoints-and-provisioning/managed-endpoint-accounts/reverse-synchronization-with-endpoint-accounts)For example, if an account was created in the Active Directory domain using an external tool, Identity Manager must be aware of this potential security issue. In addition, bypassing Identity Manager causes a lack of approval processes, and audit reports.
Two types of discrepancies between Identity Manager and managed endpoints are as follows:- A new account detected- A change within an existing accountYou can treat both cases by defining policies to handle the change. Then, using Explore and Correlate to update Identity Manager, you trigger the execution of policies.
If you have a Default Template assigned on the acquired Endpoint then the initial Explore of the endpoint would lead to those explored accounts getting that Default Template set. However I do not recommend doing this because it becomes difficult to track what accounts have what templates as you would not be able to reply on the User/Role associations to help with that and the IM User Console won't really help you identify it. Also consider that removing the Default Template from the Endpoint does not also remove it from those Accounts that had previously been given it.
As an example, I remember long ago where there was a customer who did not realize many UNIX accounts were linked to an account template because that template was set as a Default Template on an Endpoint when an initial Explore was done. They edited the template and were surprised when it impacted all of their UNIX accounts in an unintentional way which caused them a lot of problems.
So what I would suggest would be to use provisioning roles to manage the templates and not try using the Default Template on the endpoints.
You would need to look at maybe using a PX Policy to assign the Provisioning Role as part of the Provisioning Create User task if you wanted it to happen as part of the user creation caused by the Explore/Correlate. Or perhaps a PX Policy tied to another task which you execute by making a change to some attribute and then drive that via a Bulk Load.
Are you talking about the initial on-boarding of users? Or are you talking about a scheduled explore and correlate of AD where you intend to create new global users in IDM for any new accounts found in AD?
If you're talking about the initial on-boarding, then I would use an etautil script to assign some kind of "birthright" provisioning role to each account found.
E.g. create a file as follows
update 'eTGlobalUserContainerName=Global Users,eTNamespaceName=CommonObjects' eTGlobalUser eTGlobalUserName='C-050270' to +eTRoleDN='eTRoleName=PR-Contractors,eTRoleContainerName=Roles,eTNamespaceName=CommonObjects,dc=im' eTSyncUsers='1';update 'eTGlobalUserContainerName=Global Users,eTNamespaceName=CommonObjects' eTGlobalUser eTGlobalUserName='E-482525' to +eTRoleDN='eTRoleName=PR-Employees,eTRoleContainerName=Roles,eTNamespaceName=CommonObjects,dc=im' eTSyncUsers='1';
Then run the following command to load the file
etautil -d im -u etaadmin -p <password> -f file.txt >> Log.txt
This assumes that you have already loaded the users into the Identity Manager provisioning server through some means. This could be through an initial explore and correlate with global user creation. Or this could be throughanother etautil script to create the global user followed by explore and correlate to just correlate existing accounts to newly created global users.
Since you're assigning the prov role and account template to existing global users, capability attributes could be updated on the AD accounts. This will also depend on whether you selected strong sync or weak sync in the account template. I'd recommend weak sync. But even still, pay close attention to accountExpires.
You could split the input file into 4 separate files and have 4 command prompts open to import the 4 files in parallel with etautil (write to a different log file for each one). For 3,000 users, I think it might take about 20-30 minutes for this.
Retrieving data ...