Working with Users, Role and Accounts Microsoft Active Directory Import Rules

Products

• IT Management Suite

Issue/Introduction

Administrators of IT Management Suite (ITMS) often face complexities when synchronizing directory information from Microsoft Active Directory (AD) into the ITMS Database (Symantec_CMDB). Common issues include imported users disappearing randomly, duplicate entries, or deleted AD objects remaining visible in the Symantec Management Console

Active Directory Import (AD Import) allows ITMS to integrate users, computers, groups, and organizational units (OUs) from AD into the database. This integration is critical for accurate asset data and reliable targeting for ITMS policies. While "Users" import rules focus on bringing in user resources, "Role and Account" rules (earlier versions may be called "Trustee Resources" AD Import)  are used to assign AD groups or accounts to ITMS security roles for console access. Discrepancies often arise from misconfigured base DNs, stale synchronization schedules, or connection issues like the transition from standard LDAP to secure LDAPS.

Administrators often confuse User AD Import Rules with Role and Account AD Import Rules. A common misconception is that importing a user via a "User Import" rule automatically grants them access to the Symantec Management Console, or that a "Role and Account" rule is sufficient for targeting software to that user. This KB clarifies the distinct technical purposes of these two mechanisms and how they interact.

Environment

 

IT Management Suite (ITMS) 8.x

Connectivity: LDAP (Port 389) or LDAPS (Port 636)

 

Cause

In ITMS, there is a fundamental distinction between a Resource (something you manage) and an Account (someone who manages).

• User Import Rules create "User Resources" in the CMDB for inventory, reporting, and policy targeting.

• Role and Account Import Rules create "Security Entities" that allow AD users to log into the console and perform actions based on assigned permissions. While they can import the same AD object, they populate different underlying tables in the CMDB and serve entirely different functional roles.

Resolution

The confusion typically stems from the fact that both rules point to Active Directory. However, a user can exist as a "Resource" but be unable to log in, or conversely, have "Console Access" but not appear in organizational views for software targeting if the rules are not synchronized correctly.

Technical Comparison: How They Work

Feature	User AD Import Rule	Role and Account AD Import Rule
Primary Goal	Asset Management & Targeting.	Security & Console Access.
CMDB Destination	vUser / RM_ResourceUser	SecurityEntity / SecurityRole
Visibility	Found under Manage > All Resources > User.	Found under Settings > Security > Account Management.
Key Function	Used for "Primary User" assignment on computers.	Used to grant Admin or Helpdesk rights.
Cleanup Logic	Managed by "Directory Synchronization."	Managed by AD membership (real-time check at login).

Functional Relationship: How They Work Together

Although these rules operate independently, they relate in two critical ways:

1. The "User" Link: If a user is imported via both rules, the SMP attempts to link the Security Account to the User Resource using the SID (Security Identifier). This allows an administrator to see which "Resource" belongs to which "Login."

2. Resource Scoping: If you use "Role and Account" rules to bring in an AD Group as a Helpdesk role for example, that group's permissions are applied to the "User Resources" brought in by the "User Import" rules.

Step-by-Step Guidance: Implementing Both Rules

Task A: Importing Users for Targeting

1. On the SMP Console, navigate to Actions > Discover > Import Microsoft Active Directory
   

2. Click "+" icon and select User from the Resource Type dropdown list.
   
   
   
   

3. Specify the Domain or Server (Domain Controller), as well add the desired OU
   
   
   

4. Note: Ensure "Match computers with primary users" is checked if you want to automatically link devices to these users.
   
   

5. Repeat the same steps1-3 above but change the resource Type to "Role and Account" and select Security Group(s) from the desired OU.

Task B: Granting Console Access

1. Navigate to Settings > Security > Account Management.

2. Select de desired Account.

3. Click Add Role under "Member Of" tab to select a specific Role (e.g., "Symantec Supervisors"). Save changes.
   
   

 

Things to consider when Users / Role and Account AD Imports may be failing

Administrators may experience timeouts, SQL performance spikes, or unexpected results (such as cross-domain memberships) when running Role and Account or User AD Import rules. These issues typically occur in large environments or multi-domain forests where the scope of the import is not properly optimized.

The technical challenge with AD Import is not usually a product defect, but a mismatch between the Import Scope and SQL/SPM Server Performance.

• Performance: Importing an entire "Users" OU triggers massive recalculations in the ResourceAssociation table. The process uses intensive queries to manage memberships:

  DELETE FROM ResourceAssociation JOIN #ResourceAssociationDelete

  This triggers row locks and high CPU usage when processing large batches.

• Visibility: In multi-domain environments, ITMS leverages AD trust relationships. Seeing users or groups from trusted forests is expected behavior as queries often operate against the entire forest.
  AD uses Foreign Security Principals. When ITMS queries AD, it follows trust paths, causing groups/users from Domain B to appear in rules configured for Domain A.

• Processing: "Full Imports" are expensive operations that delete and rebuild associations, leading to high I/O and locking. Importing a top-level OU (e.g., "Users") can force the processing of tens of thousands of memberships. Logs often show large-scale "removals detected" and "memberships processed" even if the data hasn't changed.

 

Technical Comparison: User vs. Role Import

Feature	User AD Import	Role & Account AD Import
Logic	Imports objects as managed resources.	Imports objects as security entities.
SQL Impact	Moderate (Resource creation).	High (Membership/Permission recalculation).
Best Practice	Targeted OUs.	Specific Security Groups only.
Trust Behavior	Usually restricted to specified Base DN.	Often pulls nested/foreign members from trusted domains.

Support Guidance

1. Optimize Rule Scope (Critical)

To prevent timeouts and SQL spikes, avoid importing entire OUs for Roles and Accounts.

• Bad Practice: Importing the "Users" OU (All users in the domain).

• Best Practice: Point the rule to specific Security Groups (e.g., "SMP_Admins" or "HR_Target_Group").

2. Understand Full vs. Delta Import Impact

• Full Import: Rebuilds every association from scratch. Use this only during initial setup or after major AD restructuring.

• Delta Import: Only processes changes. This significantly reduces SQL locking and CPU overhead.

3. Diagnostic Steps

If the import is "stuck" or timing out:

1. Check NS Logs (a.log): Look for Altiris.DirectoryImporter. If you see for example "Processed 40,000+ memberships," your scope is too large.

   Processed 46,378 previously known memberships, changes: joins=627, leaves=46249, known=46378, unchanged=29, rule=5e88bf3d-c701-456a-9bd9-7c660715de4f

   -----------------------------------------------------------------------------------------------------

   Process: AeXSvc (1540), Thread ID: 92, Module: AeXSVC.exe

   Priority: 4, Source: RoleAccountMembership

2. Monitor SQL Activity: Open SQL Server Activity Monitor. Identify queries hitting ResourceAssociation with high "Wait Time."

3. Validate AD Memberships: Use the "memberOf" attribute in an LDAP tool (like Softerra LDAP Browser) to confirm if the "unexpected" cross-domain memberships exist in AD before troubleshooting ITMS.

Note:

In some cases, administrators may observe that the Role and Account AD Import Rule does not import accounts into the expected role.

This behavior can occur if the service account used for the import has permission to read the Organizational Units (OUs), but lacks sufficient rights to read the attributes of the objects within those OUs.

Ensure that the account has appropriate permissions to read both the OUs and the attributes of the contained objects in Active Directory. Updating these permissions has been shown to resolve the issue.

Additional Information

Role and Account AD Import Rule: Users imported are gone randomly