A couple of LDAP issues - duplicate userIDs, error messages, and more! Please help!

jshatney
Mega Expert

I have been trying to overcome a difficulty we have with our LDAP setup within Service Now.

We currently have 4 domains being imported into the system. The current Query Field I have being used is by all 4 domains is sAMAccountName.
We have duplicate sAMAccountNames across the 4 domains.

This is obviously causing a couple of issues.

1. Because the sAMAccountName field changes, new user records are being created and old ones are not being updated when a rename occurs.
2. Only the first user alphabetically with a duplicate sAMAccountNames cannot login to the system because the other dupe accounts has not been imported at all (this makes sense)

To try and resolve the first issue, I changed the query field from sAMAccountName to objectSID because this is a unique identifier that never changes.
I expected at this point for all the duplicate sAMAccountName users to have records created in Service Now. This does not appear to be happening.

I need assistance with figuring out how to overcome both of these issues. I've also started to see error messages in the LDAP Log:

"No DN returned for" and "No user information found in ldap for"

This has been happening for both unique users and users with duplicate sAMAccountNames

4 REPLIES 4

michelek
Kilo Explorer

use the objectGUID of the user object in LDAP to coalesce. Set up the username in SN as the domain\username by adding a script to your LDAP import or use the user's email address as the username in SN. Otherwise the system will not know which jsmith from which domain is logging into the system. Also, you will want to modify your LDAP Server form layout to include DN field and set it to "source" (this is the value that SN will send to the LDAP server to find the correct user and validate credentials.

Let me know if you have any issues.

Michele


Is there a difference between the objectSID and the objectGUID?

Also, instead of using a script to concatenate domain/username is there a way I can add an additional dropdown box where my users can select which domain they are from? Or is it smart enough to see that there are multiple userIDs and prompt them to select which user they are? (I know I'm dreaming)

Up until this point (we've been live 5 weeks), I haven't had a DN field mapped in my LDAP server setup. There hasn't been any issues until this week. Is that something common in LDAP set because I didn't not see it in the documentation. I have the DN field being mapped to a Source field on the user record already.


Yes, the objectSID can change if the user record is moved to another OU (folder) but the objectGUID always remains the same for the user object.

Yes you are a dreamer but aren't we all.. if you want to allow the user to select the domain (like in Windows) and then build the username for them that would seem like a good plan. Either option will require modification to the Login Content Block. I know the internationalization plugin (like "I18N: French Translations") adds a dropdown on the Login block to allow the user to select the language so you should be able to do something similar for domain.

UI Macro: login_language_select to get an example of how to build the code to allow the user to select a domain.
Create a custom Welcome page and use a Login Content Block with the UI Macro.

This way you can leave the username in the SN user record like jsmith, then have a separate field for domain that you auto-populate based on which domain you are syncing that user record with. Coalesce on objectGUID so jsmith in multiple domains will remain separate identifyable user records in SN.


mev1
Giga Contributor

Hi Michele,



I read a similar configuration option here: Errors "No DN returned for XXXX" and "No User information found in ldap for XXXX" when user tries to...



In this thread they recommend setting the DN Field on the LDAP Server to a different value compared to "Source" (As you provided).   Is there a difference between the two?



Appreciate your insight.



Thanks,


Patrick