| Document number | Revision |
| :-------------- | -------- |
| DOCU12351       | 1        |

***



# Ldap Replication conflict


[TOC]

## Background

When creating and adding new users to Highstage, you might encounter Ldap replication errors. The root cause is that a new user have been added to Highstage with the same user id as an existing user. This existing user might not be active anymore, however there might exists record both in Highstage or in produced documents which has this identity of a previous user linked to certain actions. Due to this problem, a username cannot and should not be re-used in Highstage.



## Technical details

Especially one Highstage data column is very critical - the ts_role LogonName column. The LogonName column contains the Active Directory pre-Windows 2000 user logon name including domain, which uniquely identifies the user.

The LogonName is mapped to a User ID, the User ID is stored in the ts_role Obj column. Highstage ensures that only one instance of the User ID may exist in rs_role table, ensuring that the User ID is unique. The User ID is the identity of the user as known to the user and the organization.

By default, the User ID is the same as the pre-Windows 2000 user logon name (without the domain part). The User ID may be changed by modifying the Obj column. Data columns throughout Highstage will be updated to reflect the new User ID. Information stored outside the SQL database will not be updated. Documents, file system etc may contain conflicts since they are not updated.

The safest will be to have User ID’s never be reused. Even if one employee leaves the company and a new employee with the same name joins the company the new employee will get a new pre-Windows 2000 Logon name and a new User ID, this procedure must be handled by company policy.



## Resolve

There are a number of ways to resolve Ldap replication conflicts in Highstage depending on each instance of the issue:

### Solution 1 - Same user, new account

Sometimes the affected user have had a previous account and now using a newer account. In some directory systems there are no restrictions on re-use of User-Id's and therefore Highstage will be the first system to acknowledge this breach.

However if this is the case, locate the affected user in the user search grid and remove the content of the GUID and SID on the user. Thereafter replicate, and now the problem should be gone, as this will update the Highstage user with the new and right information from the directory service. 



### Solution 2 - Reuse of user ID

If it is accepted by company policy to reuse old UserID’s, meaning that the new user can take the identity of a previous user, then the ts_role Obj column value and the ts_role LogonName column value of the previous user must be changed before the new user can be imported from the Directory service and have the User ID and LogonName of the previous user.

Modifying the data columns can be done as AdminWrite userlevel and looking at the TS_user basetype in Search.aspx. Since the previous user is inactive, the filter has to be set to inactive to find the previous user.



### Solution 3 - Change new user's ID

Delete or inactivate the problematic account in the directory service, Give the new user a new unique ID, and replicate Highstage again.



### Solution 4 - Change old users' records

> This solution is not recommended, as document at time of changing and stamping have the old users credentials.

It is possible to change these records in the database, however traces in old documents can not be recalled and/or changed. These will carry the old ID forever. by changing the old users ID and making room for the new user to use the new ID there will be introduced a gap between what's in Highstage and generated reports. If this solution is chosen anyways it is possible to rename a user.

Please Contact Highstage support in order to get details about this change. 



***

![highstage_footer](.\Highstage\highstage_footer.png)