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:

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 11, 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.