Some Users that were imported via AD Import are not been removed from AD Filter after they were removed from Security Group


Article ID: 195188


Updated On:


Management Platform (Formerly known as Notification Server)


The customer has some Users that he is importing from AD (from a Security Group). However, when he deletes or moves some of those users out of the security group, the filter that was created on the Console still displays those users. AD Sync is turned on and running weekly.

We ran a full import for that Users AD Import Rule, run membership update and still nothing, those users remain in the AD filter.

If he adds a new User to the Security Group and runs the User AD Import Rule, those new users are added and removed as well. It seems that some previous Users got stale references to the AD Filter.


The affected Users lost their association to the original User AD Import Rule. So, when the regular User AD Import Rule runs, it doesn't see those Users as part of its evaluation. 
These Users got out of sync between "Inv_Security_Groups" and “Inv_Import_Rule_Imported_Items” tables.

Based on what we have seen, if a User is been removed from a security group and then the User AD Import Rule runs, we remove the Users (from my lab):

If it was removed, in the NS logs with the AD in Ultra verbosity and trace and verbose login, you should see an entry like this:

AD membership changed (Gone): CN=Tester1 User,CN=Users,DC=nefidom,DC=com (918c084f-f656-43e5-a99b-a41f907e006d)
 - CN=Testers,CN=Users,DC=nefidom,DC=com
Date: 6/30/2020 8:45:12 AM, Tick Count: 188572859 (2.04:22:52.8590000), Size: 370 B
Process: AeXSvc (2852), Thread ID: 49, Module: AeXSVC.exe
Priority: 16, Source: GroupMembershipChanges


Processed 1 previously known memberships, changes: leaves=1, known=1, unchanged=0, rule=0ff9d70f-0b2b-479a-a167-f5057cef7621
Date: 6/30/2020 8:45:12 AM, Tick Count: 188572859 (2.04:22:52.8590000), Size: 339 B
Process: AeXSvc (2852), Thread ID: 49, Module: AeXSVC.exe
Priority: 4, Source: DataClassMembership

The detection of membership changes is done with the usage of "spDirectoryRuleReadSecurityGroupsMembers" (the place to dig into), but as we have seen - we have no such User(s) in the "Inv_Import_Rule_Imported_Items", so there is no "change" anymore, as the SP only list users for the rule. Might be something failed once and the rule "loose" the user - so it will not sync it anymore...
If these users would be part of other security group rule imports, the membership will be eventually detected, but it seems that users are not part of any other imports.


ITMS 8.1 RU7


The simplest way is to re-associate the Users back to the User AD Import Rule and let the AD Import process take care of those Users. 

The following should help as a way to re-associate his imported Users to the desired AD Import Rule and then let the AD Import process remove any user that doesn't belong anymore to the Security Group:

1. Run this to get the GUID of the AD Import Rule we are going to use to populate missing data. Use part of the "name" of the AD Import Rule under '%User Import%':

select Guid, Name 
from vItem 
where ClassGuid = 'B2378265-2779-49E6-998D-8BE620B3D9D9'
and name like '%User Import%'

2. Grab the GUID of the desired User AD Import Rule from the result of the above query:

Declare @importRuleGuid as uniqueidentifier = 'GUID' --GUID CHOSEN FROM THE QUERY ABOVE
insert into Inv_Import_Rule_Imported_Items (_ResourceGuid, ImportRuleGuid, ResKey, IncludeInImportRule, uSNChanged)
select sg._ResourceGuid, @importRuleGuid, '{' + cast (newid () as nvarchar (50)) + '}', 1, isnull (ad.uSNChanged, (select min (uSNChanged) from Inv_Global_Active_Directory_Details))
from Inv_Security_Groups sg
left join Inv_Global_Active_Directory_Details ad on ad._ResourceGuid = sg._ResourceGuid
left join Inv_Import_Rule_Imported_Items ii on ii._ResourceGuid = sg._ResourceGuid
 and ii.ImportRuleGuid = @importRuleGuid
where ii.ImportRuleGuid is null

What this query does is to associate all Users that had been imported by any AD Import Rule to this specific one (it doesn't matter if those Users were or not imported by this AD Import Rule in the first place). We are forcing all Users to be associated temporarily to the desired User AD Import Rule and then, when AD Import runs for the desired User AD Import Rule, it will evaluate every User and remove them if they don't belong. It will make the import take longer because it has to go and evaluate all Users and remove them from the association that we did with the query above.