-
Title
SIDHistory Mapping and how it works -
Description
The QMM user Guide mentions the following about the SIDHistory Mapping feature:
"By default, Vmover’s INI file contains source-target account pairs migrated by the moment when the file was generated. Alternatively, Vmover can automatically locate and append to the INI file the pairs by analyzing the SIDHistory of the accounts in the target domain. This lets you use the tool even if the object migration was performed not by Quest Migration Manager but by another tool capable of adding SIDHistory. "
But how does this feature work exactly? And when can it be useful?
-
Cause
Admins often use this feature in various situations. For example, the project has been lost or the Quest tool has been removed and decommissioned, or when the migration was performed via other means. Basically in any situation, when RUM cannot be used, but target objects have the SIDHistory populated, this feature can come in very handy.
One rare scenario is as follows: The source domain participated in a migration, but resources have not been updated. Now, when processing resources, the tool doesn’t update any resources. Upon further investigation it turns out that source objects maintain access to resources based on their SIDHistory. In this situation Vmover can be used to update resources in the source and assign the permission to source users (instead of their predecessors), and then RUM can be used to update them again and this time assign the permission to target users and groups.
-
Resolution
User Guide already explains how this feature works, and offers instructions when creating the INI file. Below is some additional info: The domain pair values in the INI are not needed for the SIDHistory feature to work. The tool connects to the DC via port 389 - at least this is what it reports in the logs: \\QMMCONSOLE Initialization Informational 0 Successfully connected to 'DC1.abc.child.com', naming context 'DC=ABC,DC=child,DC=com', user: 'QMMadmin', domain: 'ABC', default port: '389'.
It looks up the information in AD and then appends it to the INI file, BUT it ONLY appends what it encounters in the ACL so from one processed server. This means that the INI created during the processing cannot be used as ultimate SIDHistory mapping INI to process other servers. Each server needs to be processed individually, and the INI should be generated for each server individually.
To rephrase: If you execute Vmover with the switch sidHistory=Yes and process a file server where only one user has permissions then the tool will first find the folder, will read the ACEs in the ACLs,, will find the SID, then it will query the DC ad will find the object which has that sid as sid history, and it will assign permissions to the target object. The INI will have only one entry. If you later process a server where 100 users have rights then you will get an INI with 100 entries. This is just an example, to explain how it works.
See the Resource Updating Manager User Guide for further information under the "Sidhistory Mapping" section