Unable to pull user record from LDAP

[ohhgr]

Hello All,

Currently I'm facing an issue to pull an user record from LDAP. User's AD account is correct and it satisfies all the conditions pu in the OU filter. However, the record is not pulled from LDAP data source.

I updated the filter, removed all the existing filter conditions and put only sAMAccountName to be the same as that of user, and still it did not return the record. I searched on wiki and found below point.

If newly created users on the LDAP server are not imported into the instance, there might be an issue with the user attributes. The first time the user is identified, if it does not have all the attributes necessary to meet the OU filter requirements, it is flagged as being not valid. The instance ignores the user and does not create a user record.

Also, it couldn't be confirmed if the user record was created with incomplete details or not, but it seems the only possible explanation right now. I wanted to know, if anyone faced similar problem before, and how to mark the record "Valid" again?

Thanks,
Mandar

[Deepak Ingale1]

Hi Mandar,

Your AD is setup on windows servers. We call it as Domain Controllers to which AD user gets authenticated while connecting to network via laptop / desktop

Our AD user accounts are nothing but the Objects in active directory organizational units (OU).

Normally, there are always more than 1 domain controller in your organization. This is required for redundancy.

AD DS: All domains should have at least two functioning domain controllers for redundancy

Now let us assume that   organization has around 20 DC (Domain Controller). I have created user object on DC1. I would certainly require this user object to be available on other 19DCs as well for synchronization of data. This is done by replicating the user object created on DC1 to other remaining 19DCs. This normally takes some time to happen.

Now, in your case, it might happen that the AD team connected to DC1 can see the user object, because user is created on that DC itself.

Whereas, you might be connect to lets say DC4 which is yet to receive a user object via replication.

I would suggest to check what IP address of LDAP (AD / DC) you are connected to. Ask AD team to get the corresponding server name against the IP address and connect to the same server to check whether user Object appear there

[wcw]

The advice of the LDAP explorer is the right approach.   What the wiki is saying is that if a user is created in such a way that the search criteria doesn't find it, it won't be imported. Since you can't see it via the LDAP explorer, this could be the problem.

For example, let's say the user was created in the OU=Accounting instead of say OU=ServiceNow_Users. If your search filter/criteria for LDAP is to only look only in ServiceNow_Users, then it won't see the users created in OU=Accounting.

So, if you go to your LDAP servers, there should be an entry under the server for user import.   There is a RDN field, a query field, and a filter.   Give this info to your AD admins and see if they created the user so that these attributes would find the user in Active Directory.   If you click on 'Browse', the LDAP search window will allow you to change the filter and RDN and you could look to make the query more permissive and see if that shows up.

[ohhgr]

Thanks for your comments guys, those are really helpful.

One point though, I tried to "Browse" the user as Berny suggested earlier and I removed all the filters put in place, just searched for samaccountname containing that user's actualy samaccountname. Still, I couldn't search for the user. So, I'm guessing it has nothing to do with ServiceNow filters after all.

I will check with the AD team if the user record is duplicated in other DCs.

- Mandar

[David Whaley]

I recently had a problem with our LDAP import were one user was not being imported and causing the rest of the import to fail.   I was getting a "Row size too large (>8126)" error.   I recreated the import/transform map with a new name for the the import table so ServiceNow would create the import table.   Once the import was recreated the import ran fine.   I hope this helps.

David

[sivaranjani3]

HI David ,

Even i have the same issue for some 5 user records, but my rest of the import was successful. except those records other user records got inserted. Can you please suggest what can be done for this issue.

Thanks,

Sivaranjani