· The Directory Synchronization Schedule’s purpose is to delete any items in the Symantec_CMDB, imported by the Active Directory Connector Solution rule, that have been deleted, renamed or moved into a different organizational unit within Active Directory. This includes users, computers, subnets, sites, etc.
Below are a couple of scenarios that demonstrate how this works with users:
Scenario 1: User1 gets created in OU1 within Active Directory. A “full” or “update” “User” import rule runs and imports the users into the Symantec_CMDB database. The user associated with the default scope membership collection for “User” (BD77070C….). Once the Delta Resource Membership update schedule runs, the user is also associated with the scopecollectionguid for OU1 in the ScopeMembership table.
If the option “Create organizational unit filters” is selected within the rule, the user is also inserted into the OU1 filter that is created during the import process.
If User1 is then moved within AD into OU2 and then the Directory Synchronization schedule is ran, User1 will be deleted completely from the Symantec_CMDB database.
Scenario 2. : User1 gets created in OU1 within Active Directory. A “full” or “update” “User” import rule runs and imports the users into the Symantec_CMDB database. The user is associated with the default scope membership collection for “User” (BD77070C….). Once the Delta Resource Membership update schedule runs, the user is also associated with the scopecollectionguid for OU1 in the ScopeMembership table.
If User1 is then moved within AD into OU2 and then an AD Update process for the respective rule is ran, the user will be moved to the OU2 folder and OU2 filter. A Delta Resource Membership update process also needs to run after the import has finished for this to complete.
· The same information is valid for computers except that once a computer becomes managed the Directory Synchronization process will NOT delete them even if the computers were removed from AD all together.
· Users imported by a “User” import rule should not be mistaken for accounts that get created in the console manually and associated with a “Windows” user. An imported user and a created user account could theoretically have the same name. The user account in the console will maintain its association to the Windows account unless the user is removed from AD
· A “Role and Account rule” is used to import security groups and their membership as roles and accounts into the database. A ”Role and Account” rule will create roles for each imported security group and its membership as “Accounts”. These “Accounts” are also included in the role’s membership.
· The recommendation is to use the Directory Synchronization process on an infrequent basis such as monthly and a “Full” AD import more frequently if there is concern that the sync process will delete items that it shouldn't’t. If changes are made to AD, make sure that that an “Update” import rule runs prior to the Directory Synchronization to avoid the possibility of unexpected object deletion.
The AD Connector has been updated (with SMP 7.1 and 7.5 releases) and now supports creating Role and Account resources based on Groups and Users in Microsoft Active Directory.
Role resources are created for each Group imported from AD, and Account and Windows Credential resources are created for each User imported from AD.
Also, the memberships of the group in AD are also imported.
When performing AD imports the security resources that are created have the following resource keys:
• trusteename - This is the value of the sAMAccountName property in AD property prefixed with the domain name. e.g. testdom01\TestRole or testdom1\TestUser
• distinguishedname - This is the value of the distinguished name of the object in AD
• directoryid - This is the guid of the object in AD
• sid (WindowsCredential Resource Only) - This SID of the object in AD.
If any of the resources that are imported from AD match existing resources on ANY of these keys then the existing resources will be managed from AD from then on.
Using the above keys ensures that the following scenarios are covered:
• Created Account whose name matches a user in AD
• If a user creates an account whose name is testdom01\TestUser and this user exists in AD then the Account resource imported from AD will match on the trusteename key and will match the existing account
• Created Account & WindowsCredential whose SID matches a user in AD
• If a user creates a Windows Credential whose SID is in AD and assigns it to an a user created Account (whose name can be anything) then the WindowsCredential will match on the sid key and the existing account will renamed and updated to match the name of the user in AD.
• Created Role whose name matches a role in AD
• If a user creates an account whose name is testdom01\TestGroup and this group exists in AD then the Role resource imported from AD will match on the trusteename key and will match the existing role
• User or Groups are renamed in AD
• If a user or group is renamed in AD, but its guid does not change. Imported resources will match on the directoryid key and will update existing resources
• User or Groups deleted and re-created
• If a user or group is deleted from AD and re-created with the same name, the import will match on trusteename and distinguishedname
• User or Groups deleted
• If a user or group is deleted from AD the re-sync schedule will be unable to find objects in AD using the directoryid key and will then delete them from the NS.
AD is treated as the source of truth regarding group memberships. Any changes that are made to a role resource's members in the NS (assuming the role is matches a group AD) will be lost whenever the nextcomplete update is done. During a complete import the role resource's members will be updated to match the group's members that are in AD.
Account \ Credentials
Assume an account resource in the NS has multiple credentials, e.g. it has a windows credential and an internal credential. If this account resource matches a user in AD and an import is done the following will happen:
• The account resource and windows credential resources will be updated with information from AD
• The internal credential will be unassigned from the account resource
How AD Import Handles Roles and Accounts Imports
The Active Directory function in NS is split between a full import and an update import. The resync schedule is also important for when roles and accounts are deleted. Groups imported from AD are converted to roles in NS.
Subscribing will provide email updates when this Article is updated. Login is required.
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
This will clear the history and restart the chat.