Safeguard for Privileged Passwords version 2.7 was simplified to allow for a separation of duties based only on identity management, asset management, access policy configuration, and appliance maintenance. In the migration to version 2.7 or later, greater flexibility is realized through these high-level assignments:

• Directories are migrated to assets.
• Accounts include both directory accounts and asset accounts.
• Each directory is assigned its own partition in the migration to version 2.7 or later.

The following information details the changes from version 2.6 to version 2.7 or later. The same information is generally true if you are upgrading from version 2.1 forward to version 2.7 or later.

Before you migrate

• Make sure you back up before migrating to version 2.7 or later.

• Be sure you have data you want to migrate and perform general clean up. For example, if you have entities that are not needed, remove them before migrating.

• Complete as many outstanding Access Requests as possible. This is especially important for Active Directory Access Requests because any outstanding Active Directory Access Requests will need to be recreated after the migration since they cannot be resubmitted.

• Save all necessary version 2.6 logs. Directory log history prior to the migration to version 2.7 or later is not available after the migration. Details follow.
  • Before the migration to version 2.7 or later, Directory Administrators, Asset Administrators, and Auditors can see audit log history for each of the directories, regardless of who created or changed them.
  • The migration takes Directories and turns them into directory assets. All associated relationships with directories are also migrated to the new directory assets. The Directory Administrator role is removed and users with Directory Administrator permission are assigned as a partition owners for directories that are migrated to assets.
  • After the migration to version 2.7 or later, the Asset Administrator can see the directory asset whose audit log history starts on the day of the migration. Events prior to migration are not available.
• We recommend two clients:
  • A version 2.6 client to connect to older appliances

  • A new version 2.7 or later client to get the new features of Directory Assets and Discovery

    This recommendation is made because a new client uses v3 endpoints. A version 2.6 appliance doesn't know how to respond to v3 calls. An new client pointed to an old appliance will get an error when trying to connect. You will see this message: The Safeguard desktop application is not compatible with this appliance. Please contact your administrator.

What to expect

The following lists entity changes you will note in the migration to version 2.7. or later.

Directories are migrated to Assets

• Directories are migrated to assets with the appropriate platform assignment.

• Directories are still synced with Safeguard.
• Migrated directory assets reflect any account dependencies with Windows services and task on other assets.

• You can select whether a directory asset manages the forest or a subset of the forest. Multiple assets can be assigned against the same forest.

• Every migrated directory has Managed Forest selected so the administrator can create a directory to manage a domain or part of a domain. As assets, directories can be shared and all domains in a forest can be managed from one instance of a domain. Navigate to Administrative Tools | Asset | Management tab | Managed Forest check box.

• Every migrated directory asset has Available for discovery across all partitions selected so the asset is available for asset and account aiscovery jobs beyond partition boundaries. Any partition that exists is able to use this directory asset. Navigation: Administrative Tools | Asset | Management tab | Available for discovery across all partitions check box.

• Discovery detail grids will identify migrated directory assets with a Partition value of Import.

• Each migrated directory asset is assigned to its own partition and includes the Account Discovery jobss, the check and change schedules, account password rules, password sync groups, and related functions.

  • To view the Account Discovery job assigned as the results of migration, navigate to Administrative Tools | Asset. Select the directory asset then Edit. Then navigate to | Account Discovery tab to see the selected Account Discovery job for the partition. If no schdule is selected, this message displays: No Account Discovery Chosen.
• Directory tags are migrated into the appropriate partition tag. To copy a tag to a new partition, change the description then copy the tag.

Administrative Tools | Directories removed and Discovery added

When Safeguard for Privileged Sessions version 2.7 is installed, directories, discovery jobs, and other related entities automatically migrate to the appropriate associations. The Administrative Tools | Directories selection is gone, and Administrative Tools | Discovery has been added. Functionality is reorganized and streamlined for better data control.

Discovery

• During migration, existing partition account discovery jobs are separated by platform type, for example, Unix, Windows, or Directory. As a result, you will see discovery jobs with the same name and a different prefix which denotes the platform. For example, you may see:
  • (Unix) AD-Asset Discovery account discovery job

  • (Windows) AD-Asset Discovery account discovery job

  Each discovery job is assigned the appropriate asset and settings that apply to the platform.

  You can rename or delete jobs, as needed. Navigate to: Administrative Tools | Discovery.

• In version 2.6, you can have several directory account discovery jobs assigned to the same directory. During migration, all the directory account discovery jobs assigned to a directory are put in a single account discovery job with multiple rules, one for each prior job. The job schedule follows the directory sync interval.

• In version 2.7, you can assign a profile to the account or a sync group using the account template in the Account Discovery job rule. For more information, see Adding an Account Discovery rule.

Account changes

• Accounts include directory accounts and asset accounts.
• Directory accounts are migrated into accounts and are assigned to the appropriate asset.
• Accounts identify the dependent assets.

• Every migrated account has Available for use across all partitions selected. For example, if you create an asset service account with this check box selected, the service account could be used from anywhere.

  Navigate to Administrative Tools | Account | Management tab | Available for use across all partitions check box.

• You cannot add the same account to multiple partitions from the same domain.

• You can select a directory account and view the assets that have dependency on the directory account.

  Navigate to Administrative Tools | Accounts | Dependent Assets.

Dynamic account group changes

The rules for dynamic asset groups and dynamic account groups include attributes for directory assets.

Identity and authentication provider migration

A directory identity provider is managed by creating a directory asset which points to the same directory. The directory identity provider can be created and, optionally, put under management or not.

During migration from earlier versions of Safeguard for Privileged Passwords, if there are Active Directory users and user groups, SPP determines if Active Directory should be the identity provider or not. To see the result of the migration:

1. Navigate to Administrative Tools | Settings.
2. Select the directory then the General tab.
3. Scroll down to Available Domains for Identity and Authentication to view the domains selected for the directory. Directory groups require the forest root domain to be visible and available for identity and authentication set on Administrative Tools | Settings | External Integration | Identity and Authentication. For more information, see Available Domains for Identity and Authentication (for Active Directory).

After the initial migration to version 2.6, add the identity provider.

Entitlements and access request policies

• Entitlement access request policies are migrated. If the access configuration for the asset-based session asset is a directory and you are using the version 2.6 desktop client, the name of the directory account may be blank since version 2.6 understood only one assignment and version 2.7 or later handles multiple assignments. To verify this, navigate to the Entitlements | Access Request Policy | Access Config tab. For directory accounts, the Asset-Based Session Access is correctly identified as a Directory Account, however, the directory account name is blank.

Management

Directories can be subdivided so administrators can be assigned to manage portions of a directory. For example, Admin A may only manage objects in the Finance organizational unit (OU) of the directory, and Admin B may only manage objects in the Engineering OU of the directory. This is possible via the settings on Assets including the asset Name, Domain Name, and whether to Manage Forest. This way, multiple assets can govern the same domain.

Directory accounts can be service accounts to other assets to run windows services/tasks on assets to keep password changes in sync.

Administrator role changes

• The Directory Administrator role is removed, and users with Directory Administrator permission are assigned as partition owners for directories that are migrated to assets. This role does not include the ability to manage identity providers.
• An Authorizer Administrator can now add an Active Directory forest only for identity to use as an unprivileged service account for connection.
• An Asset Administrator can now:
  • Use service accounts to manage Active Directory. The service accounts can have limited permissions within a single domain.
  • Use multiple service accounts for managing the same Active Directory domain with different limited permissions within the domain. For example, the administrator can add the domain as a managed asset multiple times with different service accounts.
  • Use a service account from Active Directory to manage an asset from a different partition so that the administrator does not have to add that Active Directory to each of the administrator’s partitions.
  • Set up a dependent system for a service running as an Active Directory account that isn’t in the administrator’s partition. This avoids having to add the Active Directory asset or the account to the partition.
  • Add Active Directory for authentication to Safeguard for Privileged Passwords without managing any of the accounts in Active Directory.
  • Set up multiple assets for the same domain.