Jump to content

Most of our employee/logon ID's on Hornbill not matched with our logon IDs and the usernames in our on-premises Active Directory


Recommended Posts

Posted

Hi all, we are in the process of launching our employee portal but we've encountered an issue where many users in our organisation are unable to access it. The issue occurs from a mismatch between the employee/logon IDs and the usernames in our on-premises Active Directory. Specifically, the employee and logon IDs in Hornbill differ from the Pre-Windows 2000 logon names in AD, which is affecting access for a large portion of our users (though not everyone).

I wanted to ask if there is a way to sync or update these employee/logon IDs in Hornbill automatically, rather than manually updating each user. How does this process work, and is it something that can be easily fixed with an automated sync or update?

I’d appreciate any guidance you can provide on this.

 

Hornbill AD onprem.jpg

Posted

Hi @Sandip Bhogal,

By default our user import utilities match accounts on the User ID. By your screenshot, it looks to me that you have used the sAMAccountName as the User ID and now gone through an AD change whereby the sAMAccountName  HAS CHANGED.

Luckily our user import utilities can be reconfigured to match on a different field to the User ID - eg the email address, so you should be able to use that (and I hope you HAVE(*)).

One thing of note though, is that UNLESS the Employee ID and Logon ID are actively populated (whether manually or via the import utility) the field is ACTUALLY EMPTY BUT WILL DISPLAY as filled in with the User ID in the GUI.

ASSUMING that is what is showing in the left side of your screenshot AND (more importantly) you have configured the matching field correctly(*), you would just need to ensure that the user import configuration correctly populates the Logon ID by adding that extra mapping.

(*) if the matching field is NOT configured correctly, you WILL have duplication in your Hornbill User list: with the old JohnD accounts as well as the new JDoe accounts - because the matching fields (assuming sAMAccountName and User ID) would indicate to the utility to create the account. IF that has happened, one would need to use the Cleaner tool to remove the NEW accounts (because the OLD ones will likely have more old calls against them). I seriously hope you are NOT in that situation.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...