4.7 Using vob_sidwalk to Change or Update VOB Users and Groups

Any time you move a VOB to a host in a domain that does not trust the domain in which the VOB's original host exists, all SIDs stored in the VOB database become invalid, because they do not resolve to an account in the new domain. This scenario occurs during domain migration (the host moves to a different domain, but the VOB stays on the host). It also occurs when a VOB is moved from a host in one domain to a host in a different domain.

The vob_sidwalk command provides a flexible means of reassigning ownership of objects in a VOB, updating the SIDS that represent the groups in a VOB's group list, and correcting VOB storage directory protections. Common uses for vob_sidwalk include:

• Migrating a VOB from a Windows NT domain to an Active Directory domain

• Moving a VOB to a host in a domain that does not trust the original domain

• Moving a VOB from a Windows host to a UNIX host or vice versa

• Moving a VOB server host to a domain that does not trust the original domain

This section provides several examples of procedures that use vob_sidwalk and vob_siddump. There are additional examples of procedures that use vob_sidwalk in Chapter 12, Moving VOBs. The vob_sidwalk reference page provides complete information on all vob_sidwalk and vob_siddump options.

Regardless of the procedure you are using, we recommend that you run vob_siddump (or vob_sidwalk without the -execute option) and then examine the output to determine which objects in the VOB would have new owners. After you are sure that the changes in ownership are the ones you want, run vob_sidwalk with the -execute option to actually remap the SIDs. The output SID file is written in comma-separated-value (.csv) form, so it can be viewed and changed with any text editor or any spreadsheet program that can read a file of this format.

NOTE: On Windows, vob_sidwalk can only be used on VOBs formatted with schema version 54. It is only installed on hosts that are configured to support local views and VOBs and support VOB schema version 54.

Remapping Historical SIDs After Domain Migration

In a domain migration scenario, a VOB database includes additional SIDs that represent the SID histories of the security principals (users and groups) who own objects in the VOB. These historical SIDs were associated with the security principals before migration and are stored in the principal's sIDHistory attribute in an Active Directory domain.

To replace the historical SIDs stored in the VOB database with new ones that resolve to the appropriate security principals in the Active Directory domain, use a command like this one:

vob_sidwalk -sidhistory -execute vob-tag SIDfile-path

When invoked with the -sidhistory option, vob_sidwalk uses the following algorithm to determine SID history:

1. Look up a SID to find the account name.

2. Look up the account name found in Step #1 to find its SID.

3. If the SID returned in Step #2 is different from the SID used in Step #1, the SID used in Step #1 is assumed to be an historical SID, and the SID returned in Step #2 is written to the new-SID field of the current line of SIDfile-path.

If vob_sidwalk was invoked with the -execute option, the SID used in Step #1 is replaced with the SID returned in Step #2.

Remapping Current SIDs When Moving a VOB to a New Domain

When you move a VOB to another domain, you must use vob_sidwalk to retrieve and store (in the VOB database) the new SIDs for all security principals who own objects in the VOB. The procedure is essentially the same whether you are moving the VOB to a host in another domain or simply moving a VOB server host to another domain and leaving the VOB on the host. Moving a VOB to a Different Domain provides a detailed description of the procedure for remapping SIDs as part of a VOB move.

Reassigning Ownership to the VOB Owner

To reassign ownership of objects in the VOB by mapping all existing SIDs to the new SIDs of the VOB owner and group, use a command line like this one:

vob_sidwalk -unknown -execute vob-tag SIDfile-path

When invoked with the -unknown and -execute options, vob_sidwalk maps unresolvable user SIDs to the SID of the VOB owner and maps unresolvable group SIDs to the SID of the VOB's group.

NOTE: If you are using UCM, you may not want to reassign ownership with -unknown. Reassigning an open activity to the VOB owner makes it unusable by its creator (unless it was created by the VOB owner).

Resetting VOB Storage Directory Protections

If VOB storage directory ACLs have been damaged during a migration (or by any other event), you can use vob_sidwalk as shown here to correct the ACLs on the VOB storage directory and container files:

vob_sidwalk -recover_filesystem vob-tag SIDfile-path

When used with the -recover_filesystem option, vob_sidwalk also corrects the SIDs for the VOB's supplementary group list.

Using -delete_groups With Ownership-Preserving Replicas

Rational ClearCase MultiSite customers who use ownership-preserving replicas (created with mkreplica -preserve) must take several additional steps when they migrate those replicas' hosts from Windows NT domains to Active Directory.

Because the changes in SIDs made by vob_sidwalk are not therefore not propagated by replication, the MultiSite administrator must run vob_sidwalk on each ownership-preserving replica in a replica family when the server that hosts the replica is migrated to Active Directory. When it is run on an ownership-preserving replica, vob_sidwalk preserves the original SIDs on VOB's group list, so that operations which require container creation continue to succeed whether or not all ownership-preserving replicas in a family have been updated. After all ownership-preserving members of a replica family have been updated, the administrator must run vob_sidwalk again using the -delete_groups option to remove these historical group SIDs. We recommend removing historical SIDs because a VOB has a limit of 32 groups on its group list. Keeping unused historical SIDs on the list may cause the list to overflow as new groups are added.

NOTE: This procedure assumes that you have already migrated user and group accounts for all users of all replicas to Active Directory, and that all users have set their CLEARCASE_PRIMARY_GROUP environment variable to the name of the ClearCase users group in the Active Directory domain.

1. Synchronize all replicas in the family to be sure that each replica includes the same set of user and group SIDs.

2. Follow the procedure in Migrating Individual ClearCase Hosts to migrate hosts. All ownership-preserving replicas in a family must be processed using the same vob_sidwalk options. If the -map option is used, you can save time by generating one mapping file and using it on all ownership-preserving replicas in a family.

3. After the replica has been synchronized again with other replicas whose SIDs have been updated as described in Step #2 of this procedure, run the command

vob_sidwalk -sid_history vob-tag SIDfile-path

and examine the resulting SID file to see whether any new SID mappings are needed (because new user or group identities have been added to the replica). If new SID mappings are required, run vob_sidwalk again using the options you used in Step #2 of this procedure.

4. After all ownership-preserving replicas have been updated as described in Step #2 of this procedure and the SID file generated in Step #3 of this procedure shows that no new SID mappings are needed, run vob_sidwalk -execute -delete_groups on each of the replicas. This deletes historical group SIDs from the VOB's group list.