Change of Name Managed by LDAP

[Michael Sharp]

We have a user that has had their name changed (married) on AD however we now have two entries on the Hornbill user list.  There doesn't seem to be an option to either merge or edit the accounts?  We want to retain the ticket information for this user so ideally don't want to delete the old one.

[Guest]

Hi Mike,

So did the user have their SAMAccountName changed in AD (the unique reference that we used to map the users into Hornbill)? If so, then this will create a new record as it doesn't know to update the existing one. 

Unfortunately, we a new account has been created, there isn't a way to merge it with another one currently. The only suggestion I would make is to open any existing requests that are against the users old account and use the "Change Customer" option on the request to reassign it to the new account so they retain visibility of it on the portal and when your analysts view it. 

Kind Regards

Bob

[Steve Giller]

On this topic, is the mapping to sAMAccountName hard coded into the product?
We've found that mapping to the sID to be more effective, as that very rarely changes when user details are ordered.
This does produce other issues, mainly that the sID is not exactly a field that you ever want to be visible, but that's relatively easy to work around.

[Guest]

8 minutes ago, DeadMeatGF said:

On this topic, is the mapping to sAMAccountName hard coded into the product?
We've found that mapping to the sID to be more effective, as that very rarely changes when user details are ordered.
This does produce other issues, mainly that the sID is not exactly a field that you ever want to be visible, but that's relatively easy to work around.

No, its not a hardcoded mapping - we use a simple executable and conf file to perform all the mappings (documentation regarding this can be found here) so in theory any attribute could be used at the login ID.

Regards,

Bob

[Steve Giller]

Excellent, I'll check that out before we (eventually) migrate

Thanks.

[Michael Sharp]

13 hours ago, bob_dickinson said:

Hi Mike,

So did the user have their SAMAccountName changed in AD (the unique reference that we used to map the users into Hornbill)? If so, then this will create a new record as it doesn't know to update the existing one. 

Unfortunately, we a new account has been created, there isn't a way to merge it with another one currently. The only suggestion I would make is to open any existing requests that are against the users old account and use the "Change Customer" option on the request to reassign it to the new account so they retain visibility of it on the portal and when your analysts view it. 

Kind Regards

Bob

Hi Bob,

The SAMAccountName has to be changed to service correct login details e.g. jmw\MichaelSharp would become JMW\MichaelJones when a name is changed.  This presents the best visual experience.

Won't this have a detrimental impact on reporting?  I agree with DeadMeatGF's suggestion in that regard.  Unless the SAMAccountName is used for SSO purposes?

Regards,

Mike.

 

[Guest]

Hi Mike,

The login ID is typically your unique identifier for your users. Many customers use the sAMAccount name in LDAP for this purpose - but if you are changing that on a user by user basis then it could cause the duplication issue you have mentioned above, as if it is not constant then there is not a way to identify this when creating/updating Hornbill accounts automatically. 

SSO authentication in Hornbill does not necessarily have to be performed against the sAMAccount name - the lookup against the Hornbill variable could be performed against another attribute.

But back to your issue - it depends on what reports you are looking to run. If you change the customer, and are building a report that is called "Top 10 Customers Logging Incidents Last Month" then this wouldn't be affected. 

Regards

Bob

[Michael Sharp]

2 hours ago, bob_dickinson said:

Hi Mike,

The login ID is typically your unique identifier for your users. Many customers use the sAMAccount name in LDAP for this purpose - but if you are changing that on a user by user basis then it could cause the duplication issue you have mentioned above, as if it is not constant then there is not a way to identify this when creating/updating Hornbill accounts automatically. 

SSO authentication in Hornbill does not necessarily have to be performed against the sAMAccount name - the lookup against the Hornbill variable could be performed against another attribute.

But back to your issue - it depends on what reports you are looking to run. If you change the customer, and are building a report that is called "Top 10 Customers Logging Incidents Last Month" then this wouldn't be affected. 

Regards

Bob

Hi Bob,

Thanks for the heads up on this.  My thoughts are if the reports are run against live users in a department for example, it would show as two entries for one person?

Regards,

Mike.

[Guest]

20 minutes ago, Michael Sharp said:

Hi Bob,

Thanks for the heads up on this.  My thoughts are if the reports are run against live users in a department for example, it would show as two entries for one person?

Regards,

Mike.

Hi Mike,

Yes, you would certainly need to archive the "old" account ideally by setting its status to archived (if not done by LDAP) and then removing any associations to departments/companies/teams.

If you wanted a report that simply showed "All users in Hornbill, grouped by a department" then you are quite right - if you didn't remove the association, two entries would show. But I would also add the criteria in the report in general that states "....AND h_status = 'Active'" so it would only return the current active users anyway, which may negate this issue.

Kind Regards

Bob

 

[Michael Sharp]

1 hour ago, bob_dickinson said:

Hi Mike,

Yes, you would certainly need to archive the "old" account ideally by setting its status to archived (if not done by LDAP) and then removing any associations to departments/companies/teams.

If you wanted a report that simply showed "All users in Hornbill, grouped by a department" then you are quite right - if you didn't remove the association, two entries would show. But I would also add the criteria in the report in general that states "....AND h_status = 'Active'" so it would only return the current active users anyway, which may negate this issue.

Kind Regards

Bob

 

Hi Bob,

Wouldn't we lose the data for the old tickets attached to that user though?  So this information wouldn't be included in the report?

Mike.

[Guest]

4 minutes ago, Michael Sharp said:

Hi Bob,

Wouldn't we lose the data for the old tickets attached to that user though?  So this information wouldn't be included in the report?

Mike.

Hi Mike,

Again, this really depends on the report you are looking for. If you were running a report that was for "All Tickets Logged By the Finance Department Last Month" then even with your duplication, you would change any active requests from the old customer to the new customer, and any closed requests would still be associated to the old user (who is still associated to the department, but they are archived).

As your report is against the department, rather than individual users, it would still show all the requests. 

Do you have a specific report in mind you are looking to run? It may make it a little clearer.

Kind Regards

Bob 

[Michael Sharp]

16 hours ago, bob_dickinson said:

Hi Mike,

Again, this really depends on the report you are looking for. If you were running a report that was for "All Tickets Logged By the Finance Department Last Month" then even with your duplication, you would change any active requests from the old customer to the new customer, and any closed requests would still be associated to the old user (who is still associated to the department, but they are archived).

As your report is against the department, rather than individual users, it would still show all the requests. 

Do you have a specific report in mind you are looking to run? It may make it a little clearer.

Kind Regards

Bob 

Hi Bob,

Whilst I haven't got a report that I need to run immediately, if I needed to run a report to show a breakdown and tally of faults per person for a department head.  This will certainly be a requirement going forwards.  For example, we would have a report for our Commercial Litigation department which shows all tickets (open or closed) for the past month which shows all users and a tally for each?

Regards,

Mike.

 

[Guest]

On 7/28/2016 at 10:19 AM, Michael Sharp said:

Hi Bob,

Whilst I haven't got a report that I need to run immediately, if I needed to run a report to show a breakdown and tally of faults per person for a department head.  This will certainly be a requirement going forwards.  For example, we would have a report for our Commercial Litigation department which shows all tickets (open or closed) for the past month which shows all users and a tally for each?

Regards,

Mike.

 

Hi Mike,

In that scenario then it might be an issue - but only if you are performing the grouping on the User ID. A way around it if reporting on individuals may be to group it on email address (though thats assuming that doesn't change as well). 

Its an interesting issue - they way Hornbill and many other systems are designed is to have a unique record per user, and the unique identifier is the login ID. This unique identifier should not change, even if other user attributes do - which is why its read only after its been created. If the only unique identifier you have is for example, a number, this would work but there are places within Hornbill that this will be displayed (so you can tell the difference between those with the same name) and also without SSO, the users would need to know this number to sign into any self service portal. Many users use the sAMAccountName as their unique identifier as it remains unique and is often eligible text, for example mine is BobD. But I am aware of other customers opting to use other attributes (such as email address) - or even attributes they have created specifically in AD for this purpose . 

In your scenario, it would be a judgement on how big an issue this may be - for example, how often are people changing their User IDs, and how many requests are being raised. If its a monthly report, perhaps this is not going to be such an issue in comparison to a 6 monthly/yearly report. But in theory, you can change the customer on closed requests as well if necessary (though I do appreciate this would be an admin overhead). 

Kind Regards

Bob

[Michael Sharp]

Thanks Bob - it does look like I'm making a mountain out of a mole hill if you put it that way.  It is a bit odd that the original user is not renamed as part of the import however - this would be rectified if the unique identifier used the SSID which NEVER changes in AD unless the user is deleted and re-created.  I understand this would have an enormous affect on other instances if implemented so wouldn't be surprised if this suggestion was rejected on technical terms.

Mike.