Synchronization Conflicts: Examples

This section provides examples of the types of conflict that can occur during each phase of synchronization and describes how you might resolve.

Note: In the sections that follow, the examples assume that you are attempting federating from the local system; the remote system is the one to be federated.

Role conflicts

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

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

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

Available actions for roles conflicts:

  • Ignore: Choose this option if you know both systems have the same roles

  • Rename Remote: If the two roles are not the same but both have the same name, you will have to rename the role on the remote system. Choosing this action will allow you to specify a new name for the role. Be sure to assign a unique role name.

Before sync
Local System Remote System Action
BatchRole Role with name "BatchRole" does not exist No action required. This will not show up in the conflict resolution page since this is not a conflict.
Role with name "UserRole" does not exist UserRole No action required. This will not show up in the conflict resolution page since this is not a conflict.
EmployeeRole EmployeeRole

Rename Remote

New name for EmployeeRole on the remote system: RemoteEmpRole

AdminRole AdminRole

Ignore

These roles are the same.

After sync
Local System Remote System
BatchRole BatchRole
UserRole UserRole
EmployeeRole

RemoteEmpRole

Note: The remote system shows the renamed role.
AdminRole AdminRole

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

The roles that are assigned to actors are merged regardless of which action was chosen.

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

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.

  • 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:
Note: The full sync does not have the ability to remove roles from users.
  • 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.

Before sync
Local System Remote System Action

ID: adoe

Lastname: Doe

Firstname: Anna

Email:

User with ID "adoe" does not exist No action required. This will not show up in the conflict resolution page since this is not a conflict.
User with ID "bdoe" does not exist

ID: bdoe

Lastname: Doe

Firstname: Bert

Email: bdoe@yahoo.com

No action required. This will not show up in the conflict resolution page since this is not a conflict.

ID: cdoe

Lastname: Doe

Firstname: Cathy

Email: code@yahoo.com

ID: cdoe

Lastname: Doe

Firstname: Catherine

Email: cathyoe@yahoo.com

Update Remote

ID: ddoe

Lastname: Doe

Firstname: Dan

Email:

ID: ddoe

Lastname: Doe

Firstname: Dan

Email: ddoe@yahoo.com

Update Local

ID: edoe

Lastname: Doe

Firstname: Emily

Email:

ID: edoe

Lastname:

Firstname:

Email:

Update Remote

Lastname and Firstname are required fields in LSF. Choosing Update Local will result in an error.

ID: fdoe

Lastname: Doe

Firstname: Franz

Email: fdoe

ID: doe

Lastname: Doe

Firstname: Franz

Email:

Update Local

Landmark checks for correct email format. Choosing Update Remote will result in an error because "fdoe" is not a valid email format.

After sync
Local System Remote System

ID: adoe

Lastname: Doe

Firstname: Anna

Email:

ID: adoe

Lastname: Doe

Firstname: Anna

Email:

ID: bdoe

Lastname: Doe

Firstname: Bert

Email: bdoe@yahoo.com

ID: bdoe

Lastname: Doe

Firstname: Bert

Email: bdoe@yahoo.com

ID: cdoe

Lastname: Doe

Firstname: Cathy

Email: code@yahoo.com

ID: cdoe

Lastname: Doe

Firstname: Cathy

Email: code@yahoo.com

ID: ddoe

Lastname: Doe

Firstname: Dan

Email: ddoe@yahoo.com

ID: ddoe

Lastname: Doe

Firstname: Dan

Email: ddoe@yahoo.com

ID: edoe

Lastname: Doe

Firstname: Emily

Email:

ID: edoe

Lastname: Doe

Firstname: Emily

Email:

ID: fdoe

Lastname: Doe

Firstname: Franz

Email:

ID: fdoe

Lastname: Doe

Firstname: Franz

Email:

Service conflicts

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

During the sync, all services 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 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.

Before sync
Local System Remote System Action
SSOP Service with name "SSOP" does not exist No action required. This will not show up in the conflict resolution page since this is not a conflict.
Service with name "SSOPV2" does not exist SSOPV2 No action required. This will not show up in the conflict resolution page since this is not a conflict.
TestService TestService

Rename Remote

New name for TestService on the remote system: QAService

ProdService ProdService

Ignore

These services are the same.

After sync
Local System Remote System
SSOP SSOP
SSOPV2 SSOPV2
TestService TestService
QAService

QAService

Note: The remote system shows the renamed service.
ProdService ProdService

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.

Before sync
Local System Remote System Action
LSFDomain Domain with name "LSFDomain" does not exist No action required. This will not show up in the conflict resolution page since this is not a conflict.
Domain with name "LMRKDomain" does not exist LMRKDomain No action required. This will not show up in the conflict resolution page since this is not a conflict.
TestDomain TestDomain

Rename Remote

New name for TestDomain on the remote system: ExternalDomain

InternalDomain InternalDomain

Ignore

These domains are the same.

After sync
Local System Remote System
LSFDomain LSFDomain
LMRKDomain LMRKDomain
TestDomain TestDomain
ExternalDomain

ExternalDomain

Note: The remote system shows the renamed domain.
InternalDomain InternalDomain

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.

Before sync
Local System Remote System Action

FQDN: lsf.lawson.com

HttpPort: 1111

HttpsPort: 2222

Domain: LSFDomain

Endpoint does not exist No action required. This will not show up in the conflict resolution page since this is not a conflict.
Endpoint does not exist on this system

FQDN: lmrk.lawson.com

HttpPort: 1111

HttpsPort: 2222

Domain: LMRKDomain

No action required. This will not show up in the conflict resolution page since this is not a conflict.

Although an endpoint in the local system has the same http and https ports, the FQDN is different for both so they are treated as unique endpoints.

FQDN: lsf.lawson.com

HttpPort: 3333

HttpsPort: 4444

Domain: LSFDomain

FQDN: lsf.lawson.com

HttpPort: 3333

HttpsPort: 4444

Domain: LSFDomain

No action required. This will not show up in the conflict resolution page since this is not a conflict.

This domain is already in sync.

FQDN: lsf.lawson.com

HttpPort: 9898

HttpsPort: 9999

Domain: LMRKDomain

FQDN: lsf.lawson.com

HttpPort: 9898

HttpsPort: 9999

Domain: LSFDomain

Update Local

FQDN: lmrk.lawson.com

HttpPort: 7878

HttpsPort: 8888

Domain: LMRKDomain

FQDN: lmrk.lawson.com

HttpPort: 7878

HttpsPort: 8888

Domain: LSFDomain

Update Remote
After sync
Local System Remote System

FQDN: lsf.lawson.com

HttpPort: 1111

HttpsPort: 2222

Domain: LSFDomain

FQDN: lsf.lawson.com

HttpPort: 1111

HttpsPort: 2222

Domain: LSFDomain

FQDN: lmrk.lawson.com

HttpPort: 1111

HttpsPort: 2222

Domain: LMRKDomain

FQDN: lmrk.lawson.com

HttpPort: 1111

HttpsPort: 2222

Domain: LMRKDomain

FQDN: lsf.lawson.com

HttpPort: 3333

HttpsPort: 4444

Domain: LSFDomain

FQDN: lsf.lawson.com

HttpPort: 3333

HttpsPort: 4444

Domain: LSFDomain

FQDN: lsf.lawson.com

HttpPort: 9898

HttpsPort: 9999

Domain: LSFDomain

FQDN: lsf.lawson.com

HttpPort: 9898

HttpsPort: 9999

Domain: LSFDomain

FQDN: lmrk.lawson.com

HttpPort: 7878

HttpsPort: 8888

Domain: LMRKDomain

FQDN: lmrk.lawson.com

HttpPort: 7878

HttpsPort: 8888

Domain: LMRKDomain

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.

Before sync
Local System Remote System Action
LSFHepGrp HEP group with name "LSFHepGrp" does not exist. No action required. This will not show up in the conflict resolution page since this is not a conflict.
HEP group with name "LMRKHepGrp" does not exist. LMRKHepGrp No action required. This will not show up in the conflict resolution page since this is not a conflict.
InternalHepGrp InternalHepGrp

Rename Remote

New name for hte InternalHepGrp on th remote system: LMRKIntenralHepGrp

ExternalHepGrp ExternalHepGrp

Ignore

These HEP groups are the same.

After sync
Local System Remote System
LSFHepGrp LSFHEPGrp
LMRKHepGrp LMRKHepGrp
InternalHepGrp InternalHepGrp
LMRKInternalHepGrp

LMRKInternalHepGrp

Note: The renamed HEP group.
ExternalHepGrp ExternalHepGrp

Identity conflicts

The full sync does not have the ability to remove roles from users.

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.

Before sync
Local System Remote System Action

Service: SSOP

Identity User: anna

Actor: adoe

Identity does not exist No action required. This will not show up in the conflict resolution page since this is not a conflict.
Identity does not exist

Service: SSOPV2

Identity User: bert

Actor: bdoe

No action required. This will not show up in the conflict resolution page since this is not a conflict.

Service: OSService

Identity User: lawson

Actor: adoe

Service: OSService

Identity User: lawson

Actor: adoe

No action required. This will not show up in the conflict resolution page since this is not a conflict.

Although the identity is assigned to multiple actors, this will NOT be flagged as a conflict because this identity is for an OS service.

Service: TestService

Identity User: qaUser

Actor: ddoe

Service: TestService

Identity User: qaUser

Actor: fdoe

Update Local

The identity qaUser is assigned to multiple actors. This will be flagged as a conflict because this is an identity for non-OS service.

Service: TestService

Identity User: cathy

Actor: cdoe

Service: TestService

Identity User: catherine

Actor: cdoe

Update Remote

Only one identity can be assigned to an actor. The administrator will need to choose whether the actor will use the identity "cathy" or "catherine".

After sync
Local System Remote System

Service: SSOP

Identity User: anna

Actor: adoe

Service: SSOP

Identity User: anna

Actor: adoe

Service: SSOPV2

Identity User: bert

Actor: bdoe

Service: SSOPV2

Identity User: bert

Actor: bdoe

Service: TestService

Identity User: cathy

Actor: cdoe

Service: TestService

Identity User: cathy

Actor: cdoe

Service: OSService

Identity User: lawson

Actor: adoe

Service: OSService

Identity User: lawson

Actor: adoe

Service: TestService

Identity User: qaUser

Actor: fdoe

Service: TestService

Identity User: qaUser

Actor: fdoe

Note: Choosing "Update Local" means the identity qaUser is assigned to "fdoe".

Service: TestService

Identity User: cathy

Actor: cdoe

Service: TestService

Identity User: catherine

Actor: cdoe

Note: Choosing "Update Remote" means the actor "cdoe" will be assigned the identity "cathy".

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.

Before sync
Local System Remote System Action
Actor "adoe" does not have an identity for SSOPV2

Service: SSOP

Identity User: anna

Actor: adoe

No action required. This will not show up in the conflict resolution page since this is not a conflict.

Service: SSOPV2

Identity User: bert

Actor: bdoe

Actor "bdoe" does not have an identity for SSOP No action required. This will not show up in the conflict resolution page since this is not a conflict.

Service: SSOPV2

Identity User: cathy

Actor: cdoe

Service: SSOP

Identity User: catherine

Actor: cdoe

Override identity in new primary service.

The actor "cdoe" has different identities in both SSOPV2 and SSOP.

Choosing this action means you want the actor "cdoe" to override the identity in the new primary service (SSOP) and use the identity in the current primary service (SSOPV2) which is "cathy".

Service: SSOPV2

Identity User: dan

Actor: ddoe

Service: SSOP

Identity User: dan

Actor: ddoe

Retain identity in new primary service.

The actor "ddoe" has different identities in both SSOPV2 and SSOP.

Choosing this action means you want the actor "ddoe" to use the identity in the new primary service (SSOP) which is "danny".

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.

After sync
Current primary service (SSOPV2) New primary service (SSOP)

Service: SSOP

Identity User: anna

Actor: adoe

Service: SSOP

Identity User: bert

Actor: bdoe

Service: SSOP

Identity User: cathy

Actor: cdoe

The actor "cdoe" will use the identity "cathy" when logging in.

Service: SSOP

Identity User: danny

Actor: ddoe

The actor "ddoe" will use the identity "danny" when logging in.