Initial synchronization: Meaning of conflicts that might occur

Actor conflicts

An actor conflict occurs when an actor with the same ID exists on both the local system and remote systems but one of the following attributes is not the same:

• lastname

• firstname

• email

• roles assigned

During the synchronization, actors that do not exist on either the local or remote system are created on the system where they did not previously exist.

During a re-synchronization process, you normally will not get any additional conflicts unless you change the user’s lastname, firstname or email in either LSF or LMRK.

When choosing which action to take be aware of that:

• In LSF, aside from the actor ID the FirstName and LastName are required fields. In LMRK only the actor ID is required.

• LMRK requires the same fields as LSF with the addition of Email.

• LSF does not check for correct email formatting but LMRK does. The roles that are assigned to actors are merged regardless of which action was chosen.

Available actions for actors conflicts:

• Update Local: Choose this action if the remote system has the correct data and you want to update the local system with this data.

• Update Remote: Choose this action if the local system has the correct data and you want to update the remote system with this data.

Service conflicts

A service conflict occurs when a service with the same name exists in both the local and remote systems. All services included in the sync service list should exist in both systems.

During the sync, all services on the local system are created in the remote system and most services on the remote system are created on the local system.

During a re-synchronization process, it is normal for many service conflicts to occur. This is because the first time the sync was run, all the services that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most service conflicts during a re-sync. If you are unsure, use the compare button to view the conflict.

Available actions for actors conflicts:

• Ignore: Choose Ignore if you know that both services are the same.

• Rename Remote: If the two services are not the same but both have the same name, you will have to rename the service on the remote system. Choosing this action will allow you to specify a new name for the service.

Domain conflicts

A domain conflict occurs when a domain with the same name exists in both the local and remote systems.

During the sync, all domains on the local system are created in the remote system and all services on the remote system are created on the local system.

During a re-synchronization process, it is normal for many conflicts to occur. This is because the first time the sync was run, all domains that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most domain conflicts during a re-sync.

Available actions for domain conflicts:

• Ignore: Choose Ignore if you know that both domains are the same.

• Rename Remote: If the two domains are not the same but both have the same name, you will have to rename the domain on the remote system. Choosing this action will allow you to specify a new name for the domain.

Endpoint conflicts

An endpoint conflict occurs if an endpoint with the same FQDN, http port, and https port but with different domains exist on both the local and remote systems.

During the sync, all endpoints in the local system will be created on the remote system and all endpoints on the remote system will be created on the local system.

During a re-synchronization process, it is normal to receive many endpoint conflicts. This is because the first time the sync was run, all endpoints that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most domain conflicts during a re-sync.

Available actions for endpoint conflicts:

• Ignore: Choose Ignore if you know that the endpoints are the same.

• Update Local: Choose this action if the remote system has the correct data and you want to update the local system with this data.

• Update Remote: You choose this action if the local system has the correct data and you want to update the local system with this data.

Endpoint Group conflicts

An endpoint group conflict occurs if an endpoint group with the same name exists on both the local and remote systems.

During the synchronization, all endpoint groups on the local system will be created on the remote system and all endpoint groups on the remote system will be created on the local system.

During a re-synchronization process, it is normal to receive many endpoint group conflicts. This is because the first time the sync was run, all endpoint groups that were on the local system were created in the remote system and vice versa. This means that you can simply choose Ignore action for most domain conflicts during a re-sync.

Available actions for endpoint group conflicts:

• Ignore: Choose Ignore if you know that the endpoint groups are the same.

• Rename Remote: If both endpoint groups are not the same but ave the same name, you will have to rename the endpoint group on the remote system. Choosing this action will allow you to specify a new name for the endpoint group.

Identity conflicts

An identity conflict occurs when an actor with the same ID exists on both the local and remote systems but the identity values are not the same.

During the synchronization, all identities on the local system are created on the remote system and all identities on the remote system are created on the local system.

During a Resync process, you normally will not get any additional conflicts unless you change the identity or identity assignment in either LSF or LMRK.

Available actions for identities conflicts:

• Update Local: Choose this action if the remote system has the correct data and you want to update the local system with this data.

• Update Remote: Choose this action if the local system has the correct data and you want to update the remote system with this data.

Conflicts that can occur when setting primary service identities

When the primary authentication service is set (SetPAS), a synchronization is run on identities. This sync analyzes identities between the current primary service (source) and the new primary service (target) and then moves all identities from the target to the source.

An identity conflict during synchronization occurs when an actor contains an identity on both the source and target services.

Available actions for primary service change identities conflicts:

• Override: Choose this action if you want to "Override the Identity in the New PAS" (Primary Authentication Service). This means you want to continue to use the identity for the "Current PAS".

• Retain: Choose this action if you want to retain the identity in the New PAS. This means you want to use the identity in the "New PAS".

When you run an additional SetPAS procedure (after you have already performed SetPAS at least one time), you normally will not get any conflicts unless you change the identity or identity assignment on either local or remote system.

Example:

Current Primary Service: SSOPV2

New Primary Service: SSOP

All identities under SSOPV2 will be moved to SSOP. Moving of identities will be done in both Local and Remote Systems. Conflicts will be identified if an actor contains an identity in both SSOPV2 and SSOP service.

On both the local and remote systems, only the selected primary service will contain identities and these are the identities that the user will use when logging into the systems.