LDAP - Manager Update

[Met]

Hi,

We had a support call with @Bob Dickinson  a few weeks ago to discuss how we currently use LDAP and what we can do to improve things, which was really helpful.

As part of this, I have suggested separating out the initial account creation into one LDAP config profile which queries the entire OU sub tree, and then having separate LDAP config profiles for each sub-OU. This would allow us to set account statuses (and other things) dependent on which OU the user sits in (e.g. if they are in a Parental Leave OU we might suspend their account and add a custom attribute, whereas if they are in the Leavers OU then we would archive their account). There would also be separate LDAP config profiles which include suspended accounts which exist in 'active' OU's - e.g. for accounts where we have applied a legal hold or had to manually suspend.

This has been implemented in our test environment.

As we are querying specific sub-OUs in our separate LDAP update configuration profiles, a problem is arising when a user’s manager exists in a different sub-OU. Hornbill is using the same data set returned from the LDAP query used to look up the user in order to look up the manager’s details. Where Hornbill is unable to link the manager to an existing account (because they don't exist in the returned LDAP data), it is populating the individual's manager with their display name which appears as “[{"id":"Firstname Lastname"}]” on the user's profile. This is also occurring in our live environment as we currently have a combined create & update LDAP config profile which excludes suspended accounts - if a user's manager is suspended, for whatever reason, then their manager is recorded as a display name rather than a user id.

A semi-fix for this is to enable “Search for Manager by ID” on each LDAP configuration update profile. As a final fall-back, Hornbill will take the manager’s name returned in the CN and attempt to locate an account with the display name matching this.

The problem is we have over 4,000 active employees and 3,000 'recent leavers', so some users in our organisation share the same display name.

If my understanding is correct then, mainly out of morbid curiosity,  I am wondering if anyone is able to answer the following:

• Where there is more than one manager with the same display name, how will Hornbill decide which account to choose? Will it return an error?
• Where the user already has the correct associated manager recorded against their account (because our "first time import" queries the entire sub tree and therefore includes all managers), will Hornbill still error out or will it leave the manager as the one that currently exists? (If it leaves the manager as it is currently set then the risk is significantly reduced – the only problem would be where a user’s manager has changed to a manager who shares the same name with another manager, and who both exist in an OU separate to the user....)
• Is there enough justification to have a second LDAP query which is used when looking up manager details?

A workaround (I think - not entirely tested) is to have yet another LDAP config profile which is solely responsible for updating manager information for a user which queries across the entire OU subtree.

It would be interesting to hear if anyone else has experienced something similar. We also have a number of other questions which we discussed in the meeting and which we will raise directly, including around employee name changes and how to deal with this in Hornbill when previous choices were made around what to use as someone's user id (a topic for another day...)

Thanks

Met.

[Steve G]

Hi @Met,

To answer your questions:

• Where there is more than one manager with the same display name, how will Hornbill decide which account to choose? Will it return an error?

  • No, it uses the first match it finds in the cache. I can see how this would be problematic though, and will review this code in more detail to see if there's a better solution (probably an error to the log as you mentioned)

• Where the user already has the correct associated manager recorded against their account (because our "first time import" queries the entire sub tree and therefore includes all managers), will Hornbill still error out or will it leave the manager as the one that currently exists?

  • No errors, but unless you specify __clear__ in the mapping for the manager then the manager against the user records will be left alone.

• Is there enough justification to have a second LDAP query which is used when looking up manager details?

  • That's probably one for the community to answer

Let me know if you need any more detail.

Cheers,

Steve

[Met]

Thanks @Steve G, that's really helpful. A separate LDAP config just for updating manager details seems to be working in our test environment, so all looking good.

Still just the issue of name changes, but that is mainly down to how our instance  was originally set up. Just requires manual account edits when it throws an error.

Thanks again

Met