LDAP group members not importing

[rickseidencdi]

Hello all.

I have what I believe is a common problem, but the common solutions aren't working.   Simply put, we import LDAP users, and then LDAP groups, and the group membership is not populated.

Build information from our instance:

        Build name: Jakarta

        Build date: 09-05-2017_1648

        Build tag: glide-jakarta-05-03-2017__patch3-08-23-2017

On the LDAP User import table, I expanded the u_memberof field to 4000, and the u_source field to 255.

On the LDAP Group import table, I expanded the u_members field to 4000 to get all the users in the groups, and I expanded the u_source field to 255.

My transform maps are not the out of the box transform maps, but I followed them as closely as possible.   For both the user and the group mappings, I copied and pasted the scripts in the transform and the onStart/onAfter scripts exactly from the out of the box ones (although our LDAP doesn't have managers so the onStart/onAfter for the managers information is marked Active=false).   I am mapping u_source to source on both group and user.

I even checked that the information in the u_members field in the group import contains actual users that are in our Users table with the correct source information.

I just don't know what else to check, or what else I'm missing.

Any help would be greatly appreciated.

Thank you!

Rick

[corina]

Hello Rick.

First thing: in the LDAP server, goto browse and make sure the user is there , if you take the specific path you have in the source and place it in the search, will it return a specific user?

If yes, then it is imported into the staging table? From your description it seems you have them in the stagin table.

If the answer is also yes, then you check the transform history for this import set. Any errors?

[Michael Fry1]

although our LDAP doesn't have managers - how do you identify who is a manager in AD if you're not using the manager attribute?

[rickseidencdi]

That's a very good question that we don't have the answer to yet.

[rickseidencdi · Accepted solution]

I came up with the solution while falling asleep last night.

Since I recreated the transform map, I, of course, used "best practices" and enclosed my code for my onStart/onAfter scripts in the function structure that ServiceNow likes us to use.   That means that the variable created in the onStart script was scoped just inside that function, and wasn't available to the onAfter script.   When I removed the function structure, that scoped the variable correctly, and it was available to the onAfter script, and the membership populated no problem.

Thanks to everyone how looked and helped.

Rick