LDAP: Adding Users to Group

[justin_drysdale]

I am running into an issue with group imports and adding users to groups.   I am using ldapUtil.addMembers(source,target) in an on-after transform script which works for the most part.   Users are being added to groups.   However it looks like it is also adding users to non-existent phantom groups.

In 'sys_user_grmember' after the import, I see ~300 records where there is a valid user and an invalid group.   I've queried some of the phantom groups and they report back with:

"Get for non-existent record: sys_user_group:d6c2c871ad2e6100998001b56318c5f8, initializing".

Odd how the non-existent group has a sys_id.   If I take the sys_id and query 'sys_user_group' the group doesn't exist.   Any idea what could cause this behavior?

I also checked deleted records and did not find any matching sys_ids.

[justin_drysdale]

Here is what sys_user_grmember looks like after the import:

[conmic · Accepted solution]

Are you sure these groups have been created with the import?

I had this behavior when I cloned an instance and added the sys_user an sys_user_group to the exclusion list, causing all the references to be maintained, but links still pointing to the old sys_ids of users. This messed up all the tables used to link a user to a group, a role or basically anything...

I think in your case it messes up, because it probably tries to link to a group that is not yet existing or your script that returns the group to link to, returns a faulty value. Try to add an if-statement, verifying the group you try to link your user to.

I'm not really into using 'ldapUtil.addMembers(source,target)' as I got no or wrong results. Unfortunately there is no real documentation on how to use it, and retracing the source-code of it made me think to use an easier method.

I found a really simple script written by Mark Stanger (Crossfuze) and explained in this discussion:

Can you add users to Groups with script?

I slightly modified the script to be used also in an onAfter transform script (on a transform map that is importing Users from our Active Directory), it works like a charm:

//Create a new group relationship record for this user

var addUsr = target.sys_id;

var toGrp = 'Your_Group_SysID_here';



var rec1 = new GlideRecord('sys_user_grmember');

rec1.addQuery('user',addUsr);

rec1.addQuery('group',toGrp);

rec1.query();

if(!rec1.next() && !addUsr.nil() && !toGrp.nil()){

   rec1.initialize();

   rec1.user = addUsr;

   rec1.group = toGrp;

   rec1.insert();

}

Kind Regards,

Michel Conter

[Inactive_Use309]

I have seen a similar situation, but I am not sure that is has any relevance to your situation.   In this case, the nightly LDAP import (custom built) would load a group's membership, delete all the existing users, the recreate each record (I inherited that process, so no comments on that approach, please).   This would occasionally leave users in phantom groups (over time, we actually had some users with over 1000 of these phantom memberships, 4700 was the highest I saw).

The ultimate cause of this was found to be the LDAP import process, where a group would go inactive in LDAP, and then if it was re-activated, the import process treated it as a new group, but in order to avoid naming conflicts the old group was deleted, but the group membership in that group still remained.

Not sure if that helps you any, but as a band-aid we put a business rule in to catch group deletions and remove the membership, this worked until the LDAP import process could be fixed.

[JBark]

You do have coalesce set to true for u_samaccountname in the field map for your group import?