Managing least privilege access for Active Directory tasks using DRA has many components and processes that need to be configured. These include general and client component configurations. This section provides information for the general components and processes that need to be configured for DRA.
An MMS environment uses multiple Administration servers to manage the same set of domains and member servers. An MMS consists of one primary Administration server and multiple secondary Administration servers.
The default mode for the Administration server is Primary. As you add secondary servers to your MMS environment, keep in mind that a secondary Administration server can belong to only one server set.
To ensure that each server in the set is managing the same data, periodically synchronize the secondary servers with the primary Administration server. To reduce maintenance, use the same service account for all Administration servers in the domain forest.
IMPORTANT:
While installing the secondary server, select Secondary Administration Server in the installer.
The DRA version of the new secondary must be the same as the primary DRA server so that all features that are available in the primary server will be available in the secondary server.
You can add a secondary Administration server to a existing MMS in the Delegation and Configuration client. To add a secondary server, you must have the appropriate powers, such as those included in the built-in Configure Servers and Domains role.
NOTE:To successfully add a new secondary server, you must first install the Directory and Resource Administrator product on the Administration server computer. For more information, see Install the DRA Administration Server.
To add a secondary Administration server, right-click Administration Servers in the Configuration Management node, and select Add Secondary Server.
You can promote a secondary Administration server to a primary Administration server. When you promote a secondary Administration server to a primary Administration server, the existing primary Administration server becomes a secondary Administration server in the server set. To promote a secondary Administration server, you must have the appropriate powers, such as those included in the built-in Configure Servers and Domains role. Before promoting a secondary Administration server, synchronize the MMS so that it has the latest configuration.
For information about synchronizing the MMS, see Scheduling Synchronization.
NOTE:A newly promoted primary server can only connect to secondary servers that were available during the promotion process. If a secondary server became unavailable during the promotion process, contact Technical Support.
To promote a secondary Administration server:
Navigate to Configuration Management > Administration Servers node.
In the right pane, select the secondary Administration server you want to promote.
On the Tasks menu, click Advanced > Promote Server.
IMPORTANT:When the Service account of the Secondary Server is different from the Primary Server or the Secondary Server is installed in a different domain than the Primary Server (Trusted domains/untrusted domains), and you promote the Secondary Server, ensure you delegate the following roles before promoting the Secondary Server: Audit All Objects, Configure Servers and Domains, and Generate UI Reports. Then verify that the MMS synchronizations succeeded.
You can demote a primary Administration server to a secondary Administration server. To demote a primary Administration server, you must have the appropriate powers, such as those included in the built-in Configure Servers and Domains role.
To demote a primary Administration server:
Navigate to Configuration Management > Administration Servers node.
In the right pane, select the primary Administration server you want to demote.
On the Tasks menu, click Advanced > Demote Server.
Specify the computer you want to designate as the new primary Administration server, and click OK.
Synchronization ensures that all Administration servers in the MMS use the same configuration data. Although you can manually synchronize servers any time, the default schedule is set to synchronize the MMS every 4 hours. You modify this schedule to tailor it to your enterprise needs.
To modify the synchronization schedule or to manually synch MMS servers, you must have the appropriate powers, such as those included in the built-in Configure Servers and Domains role.
To access the synchronization schedule or for manual syncs, navigate to Configuration Management > Administration Servers and use the Tasks menu or right-click options on a selected server. The synchronization schedule is in a selected server’s Properties.
Understanding synchronization options
There are basically four different options for synchronizing MMS servers:
Select the primary server and synchronize all secondary servers “Synchronize All Servers”
Select a secondary server and synchronize just that server
Configure the synchronization schedule for primary and secondary servers independently
Configure the synchronization schedule for all servers. This option is enabled when you have the following setting selected in the primary server synchronization schedule:
Configure secondary Administration servers when refreshing the primary Administration server
NOTE:If you uncheck this option, the configuration files are copied to the secondary servers on the primary schedule but they will not be loaded by the secondary at that time; they will be loaded based on the schedule configured on the secondary server. This is useful if the servers are in different time zones. For example, you could configure all servers to refresh their configuration in the middle of the night, even though that may be a different time because of time zones.
Clone exceptions enable you to define properties for users, groups, contacts, and computers that will not be copied when one of these objects is cloned.
With the appropriate powers, you can manage clone exceptions. The Manage Clone Exceptions role grants powers to view, create, and delete clone exceptions.
To view or delete an existing clone exception, or to create a new clone exception, navigate to Configuration Management > Clone Exceptions > Tasks or right-click menu.
When you create custom tools, you may need to install supporting files used by the custom tool on the DRA Delegation and Configuration Console computer before the custom tool can run. You can use DRA file replication capabilities to quickly and easily replicate custom tool support files from the primary Administration server to secondary Administration servers in the MMS, as well as to DRA client computers. File replication can also be used to replicate trigger scripts from primary to secondary servers.
You can use custom tools and file replication together to ensure DRA client computers can access custom tool files. DRA replicates custom tool files to secondary Administration servers to ensure DRA client computers connecting to secondary Administration servers can access custom tools.
DRA replicates the custom tool files on the primary Administration server to secondary Administration servers during the MMS synchronization process. DRA downloads the custom tool files to DRA client computers when the DRA client computers connect to the Administration servers.
NOTE:DRA downloads the custom tool files to the following location on the DRA client computers:
{DRAInstallDir} \{MMS ID}\Download
MMSID is the identification of the Multi-Master Set from which DRA downloads the custom tool files.
When you upload files to the primary Administration server, you specify the files you want to upload and replicate between the primary Administration server and all secondary Administration servers in the MMS set. DRA allows you to upload library files, script files and executable files.
The Replicate Files role allows you to replicate files from the primary Administration server to the secondary Administration servers in the MMS as well as DRA client computers. The Replicate File role contains the following powers:
Delete Files from Server: This power enables DRA to delete files that no longer exist on the primary Administration server, on secondary Administration servers, and on DRA client computers.
Set File Information: This power enables DRA to update file information for files on secondary Administration servers.
Upload Files to Server: This power enables DRA to upload files from the DRA client computer to the primary Administration server.
NOTE:You can upload only one file for replication at a time using the File Replication user interface in the Delegation and Configuration Console.
To upload a custom tool file to the primary Administration server:
Navigate to Configuration Management > File Replication.
On the Tasks menu, click Upload File.
To search for and select the file you want to upload, click Browse.
If you want to download the selected file to all DRA client computers, select the Download to all client computers check box.
If you want to register a COM library, select the Register COM library check box.
Click OK.
NOTE:
DRA uploads the script file or supporting files that need to be replicated to other secondary Administration servers to {DRAInstallDir}\FileTransfer\Replicate folder in the primary Administration server. The {DRAInstallDir}\FileTransfer\Replicate folder is also referred as {DRA_Replicated_Files_Path}.
DRA uploads the script file or supporting files that need to be replicated to DRA client computers to {DRAInstallDir}\FileTransfer\Download folder in the primary Administration server.
The custom tool file uploaded to the primary Administration server is distributed to secondary Administration servers during the next scheduled synchronization or by manual synchronization.
If you have multiple files you want to upload and replicate between the primary Administration server and secondary Administration servers in your MMS, you can manually upload these files for replication by copying the files to the primary Administration server replication directory, which is in the following location:
{DRAInstallDir}\FileTransfer\Replicate
The replication directory is created when DRA is installed.
The Administration server automatically identifies the files in the replication directory and replicates the files between Administration servers during the next scheduled synchronization. After synchronization, DRA displays the uploaded files in the File Replication window in the Delegation and Configuration console.
NOTE:If you want to replicate files that contain COM libraries that must be registered, you cannot manually copy the files to the Administration server replication directory. You must use the Delegation and Configuration console to upload each file and register the COM library.
If you have multiple files you want to replicate between the primary Administration server and DRA client computers, you can copy the files to the client replication directory on the primary Administration server, which is in the following location:
{DRAInstallDir}\FileTransfer\Download
The client replication directory is created when DRA is installed.
The Administration server automatically identifies the files in the Download folder and replicates the files to the secondary Administration servers during next scheduled synchronization. After synchronization, DRA displays the uploaded files in the File Replication window in the Delegation and Configuration console. DRA downloads the replicated files to the DRA client computers the first time the DRA client computers connect to the Administration servers after replication.
NOTE:If you want to replicate files that contain COM libraries that must be registered, you cannot copy the files into the Administration server download directory. You must use the Delegation and Configuration console to upload each file and register the COM library.
Azure Sync enables you to enforce invalid characters and character length policies to prevent directory synchronization failures. Selecting this option will ensure that any properties that are synchronized with Azure Active Directory will restrict invalid characters and enforce character length limits.
To enable Azure Sync:
In the left pane, click Configuration Management.
Under Common Tasks in the right pane, click Update Administration Server Options.
On the Azure Sync tab, select Enforce online mailbox policies for invalid characters and character length.
When you enable support for multiple managers to manage a group, one of two default attributes is used to store the group’s managers. The attribute when running Microsoft Exchange is the msExchCoManagedByLink attribute. The default attribute when not running Microsoft Exchange is the nonSecurityMember attribute. The latter option can be modified. However, we recommend that you contact Technical Support to determine an appropriate attribute if you need to change this setting.
To enable multiple manager support for groups:
In the left pane, click Configuration Management.
Under Common Tasks in the right pane, click Update Administration Server Options.
On the Enable Support for Group Multiple Managers tab, select the Enable support for group’s multiple managers check box.
This function allows you to enable or disable use of encrypted communication between the Delegation and Configuration client and the Administration server. By default, DRA encrypts account passwords. This feature does not encrypt Web Client or PowerShell communications, which is handled separately by server certificates.
Using encrypted communications can impact performance. Encrypted communication is disabled by default. If you enable this option, data is encrypted during communication between the user interfaces and the Administration server. DRA uses the Microsoft standard encryption for Remote Procedure Call (RPC).
To enable encrypted communications, navigate to Configuration Management > Update Administration Server Options > General tab and select the Encrypted Communications check box.
NOTE:To encrypt all communications between the Administration server and user interfaces, you must have the appropriate powers, such as those in the built-in Configure Servers and Domains role.
Using virtual attributes, you can create new properties and associate these properties with users, groups, Dynamic Distribution groups, contacts, computers, and OUs. Virtual attributes allow you to create new properties without requiring you to extend the Active Directory schema.
Using virtual attributes, you can add new properties to objects in Active Directory. You can only create, enable, disable, associate, and disassociate virtual attributes on the primary Administration server. DRA stores the virtual attributes you create in AD LDS. DRA replicates virtual attributes on the primary Administration server to secondary Administration servers during the MMS synchronization process.
With the appropriate powers, you can manage virtual attributes. The Manage Virtual Attributes role grants powers to create, enable, associate, disassociate, disable, and view virtual attributes.
You need the Create Virtual Attributes power to create virtual attributes and the View Virtual Attributes power to view virtual attributes.
To create a virtual attribute, navigate to Configuration Management > Virtual Attributes > Managed Attributes node, and click New Virtual Attribute in the Tasks menu.
You can associate only enabled virtual attributes with Active Directory objects. Once you associate a virtual attribute with an object, the virtual attribute is available as part of the object properties.
To expose virtual attributes through the DRA user interfaces, you need to create a custom property page.
To associate a virtual attribute with an object, navigate to Configuration Management > Virtual Attributes > Managed Attributes node, right-click the virtual attribute you want to use, and select Associate > (object type).
NOTE:
You can only associate virtual attributes with users, groups, dynamic distribution groups, computers, contacts, and OUs.
When you associate a virtual attribute with an object, DRA automatically creates two default custom powers. Assistant administrators require these custom powers to manage the virtual attribute.
You can disassociate virtual attributes from Active Directory objects. Any new object that you create does not display the disassociated virtual attribute as part of the object properties.
To disassociate a virtual attribute from an Active Directory object, navigate to Configuration Management > Virtual Attributes > Managed Classes > (object type) node. Right-click the virtual attribute, and select Disassociate.
You can disable virtual attributes if they are not associated with an Active Directory object. When you disable a virtual attribute, administrators cannot view or associate the virtual attribute with an object.
To disable a virtual attribute, navigate to Configuration Management > Managed Attributes. Right-click the desired attribute in the list pane, and select Disable.
The Administration server builds and maintains an accounts cache that contains portions of the Active Directory for the managed domains. DRA uses the accounts cache to improve performance when managing user accounts, groups, contacts, and computer accounts.
To schedule a cache refresh time or view the cache status, you must have the appropriate powers, such as those included in the built-in Configure Servers and Domains role.
NOTE:To perform incremental accounts cache refreshes in domains that contain managed subtrees, ensure the service account has read access to the Deleted Objects container as well as all objects in the domain of the subtree. You can use the Deleted Objects Utility to verify and delegate the appropriate permissions.
An incremental accounts cache refresh updates only the data that changed since the last refresh. The incremental refresh provides a streamlined way to keep up with your changing Active Directory. Use the incremental refresh to quickly update the accounts cache while incurring the least impact on your enterprise.
IMPORTANT:Microsoft Server limits the number of concurrent users connected to the WinRM/WinRS session to five and the number of shells per user to five, so ensure that the same user account is limited to five shells for DRA secondary servers.
An incremental refresh updates the following data:
New and cloned objects
Deleted and moved objects
Group memberships
All cached object properties for modified objects
A full accounts cache refresh rebuilds DRA’s accounts cache for the specified domain.
NOTE:While a Full Accounts Cache Refresh is running, the domain will be unavailable to DRA users.
To refresh the accounts cache, you must have the appropriate powers, such as those included in the built-in Configure Servers and Domains
role.
To perform an immediate full accounts cache refresh:
Navigate to Configuration Management > Managed Domains.
Right-click the desired domain, and select Properties.
Click Refresh Now in the Full refresh tab.
How often you should refresh the accounts cache depends on how often your enterprise changes. Use the incremental refresh to update the accounts cache often, ensuring that DRA has the most up to date information about the Active Directory.
By default, the Administration server performs an incremental accounts cache refresh at the following times:.
|
Domain Type |
Default Scheduled Refresh Time |
|---|---|
|
Managed Domains |
Every 5 minutes |
|
Trusted Domains |
Every hour |
You cannot schedule a FACR; however, DRA runs an automatic FACR under the following circumstances:
After you configure a managed domain for the first time.
After you upgrade DRA to a new full version from a previous version.
After you install a DRA service pack.
Performing a full accounts cache refresh can require several minutes.
You must periodically refresh the accounts cache to ensure DRA has the latest information. Before performing or scheduling an accounts cache refresh, review the following considerations:
To perform an incremental accounts cache refresh, the Administration server service account or access account must have permission to access deleted objects in the Active Directory of the managed or trusted domain.
When DRA performs an accounts cache refresh, the Administration server does not include domain local security groups from trusted domains. Because the cache does not contain these groups, DRA does not allow you to add a domain local security group from the trusted domain to a local group on the managed member server.
If you omit a trusted domain from an accounts cache refresh, the Administration server also omits that domain from the domain configuration refresh.
If you include a previously omitted trusted domain in the accounts cache refresh, perform a full accounts cache refresh for the managed domain. This ensures that the accounts cache on the Administration server for the managed domain correctly reflects group membership data in your managed and trusted domains.
If you set the incremental accounts cache refresh interval to Never, the Administration server performs full accounts cache refreshes only. A full account cache refresh may take some time, during which you cannot manage objects in this domain.
DRA cannot automatically determine when changes are made through other tools, such as Microsoft Directory Services. Operations performed outside DRA can affect the accuracy of the cached information. For example, if you use another tool to add a mailbox to a user account, you cannot use Exchange to manage this mailbox until you update the accounts cache.
Performing a full accounts cache refresh deletes the last logon statistics maintained in the cache. The Administration server then collects the latest logon information from all the domain controllers.
The AD Printers collection is disabled by default. To enable it, navigate to Configuration Management > Update Administration Server Options > General tab, and select the Collect Printers check box.
You can configure the AD LDS cleanup refresh to run on a schedule for specific domains. The default setting is “Never” refresh. You can also view the cleanup status and view specific information related to the AD LDS (ADAM) configuration.
To configure the schedule or view the status for AD LDS Cleanup, right-click the desired domain in the Account and Resource Management > All My Managed Objects node, and select Properties > Adlds Cleanup Refresh Schedule or Adlds Cleanup status, respectively.
To view the AD LDS (ADAM) configuration information, navigate to Configuration Management > Update Server Options > ADAM Configuration.
A dynamic group is one whose membership changes based on a defined set of criteria that you configure in the group’s properties. In Domain Properties, you can configure the Dynamic Group refresh to run on a schedule for specific domains. The default setting is “Never” refresh. You can also view the refresh status.
To configure the schedule or view the status for Dynamic Group refresh, right-click the desired domain in the Account and Resource Management > All My Managed Objects node, and select Properties > Dynamic group refresh or Dynamic group status, respectively.
For more information about dynamic groups, see DRA Dynamic Groups.
You can enable or disable the Recycle Bin for each Microsoft Windows domain or objects within each domain and configure when and how you want Recycle Bin cleanup to occur.
For detailed information about using the Recycle Bin, see Recycle Bin.
You can enable the Recycle Bin for specific Microsoft Windows domains and for objects within those domains. By default, DRA enables the Recycle Bin for each domain it manages and all of the domain’s objects. You must be a member of the DRA Admins or DRA Configuration Admins group to enable the Recycle Bin.
If your environment includes the following configuration, use the Recycle Bin Utility to enable this feature:
DRA is managing a subtree of this domain.
The Administration server service or access account does not have permission to create the Recycle Bin container, move accounts to this container, and modify accounts in this container.
You can also use the Recycle Bin Utility to verify the Administration server service or access account permissions on the Recycle Bin container.
To enable the Recycle Bin, right-click the desired domain in the Recycle Bin node, and select Enable Recycle Bin.
You can disable the Recycle Bin for specific Microsoft Windows domains and for objects within those domains. If a disabled Recycle Bin contains accounts, you cannot view, permanently delete, or restore these accounts.
You must be a member of the DRA Admins or DRA Configuration Admins assistant administrator group to disable the Recycle Bin.
To disable the Recycle Bin, right-click the desired domain in the Recycle Bin node, and select Disable Recycle Bin.
The default setting for Recycle Bin cleanup is daily. You can change this configuration to clean up the domain Recycle Bin every x days. During the scheduled cleanup, the Recycle Bin deletes objects that are older than the number of days you have configured for each object type. The default setting for each type is to delete objects older than 1 day. You can customize the behavior of Recycle Bin cleanup by disabling, re-enabling, and setting the age of objects for deletion for each object type.
To configure Recycle Bin cleanup, select the desired domain in the Delegation and Configuration console and go to Tasks > Properties > Recycle Bin tab.
The following sections provide conceptual information about DRA Management reports and the report collectors that you can enable. To access the wizard where you can configure the collectors, navigate to Configuration Management > Update Reporting Service Configuration.
The Active Directory Collector collects a specified set of attributes from Active Directory for each managed user, group, contact, computer, OU, and Dynamic Distribution group in DRA. These attributes are stored in the reporting database and are used to generate reports in the Reporting Console.
You can configure the Active Directory Collector to specify which attributes are collected and stored in the reporting database. You can also configure which DRA Administration server the collector will run on.
The DRA Collector collects information about your DRA configuration and stores that information in the reporting database, which is used to generate reports in the Reporting Console.
To enable the DRA Collector you must specify which DRA Administration server the collector will run on. As a best practice, you should schedule the DRA Collector to run after the Active Directory Collector successfully runs and during times when the server is least loaded or outside of normal working hours.
The Azure Tenant Collector collects information about Azure users and groups that are synced to Azure Active Directory tenant and stores that information in the reporting database, which is used to generate reports in the Reporting Console.
To enable the Azure Tenant Collector, you must specify which DRA Administration server the collector will run on.
NOTE:The Azure tenant can only run a successful collection after its corresponding domain’s Active Directory Collector runs a successful collection.
The Management Reports Collector collects DRA audit information and stores that information in the reporting database, which is used to generate reports in the Reporting Console. When you enable the collector, you can configure how often the data is updated in the database for queries run in the DRA Reporting tool.
This configuration requires that the DRA Service account has the sysadmin permission in SQL Server on the Reporting server. The configurable options are defined below:
Audit Export Data Interval:This is the time interval when Audit data from the DRA trace log (LAS) is exported to the "SMCubeDepot" database in SQL Server.
Management Report Summarization Interval: This is the time interval when Audit data from the SMCubeDepot database is pumped into the DRA Reporting database where it can by queried by the DRA Reporting tool.
You can configure DRA to collect last logon statistics from all domain controllers in the managed domain. To enable and schedule last logon statistics gathering, you must have the appropriate powers, such as those included in the built-in Configure Servers and Domains role.
By default, the last logon statistics gathering feature is disabled. If you want to gather last logon statistic data, you must enable this feature. Once you enable last logon statistics gathering, you can view last logon statistics for a particular user or display the status of the last logon statistics gathering.
To gather last logon statistics:
Navigate to Configuration Management > Managed Domains.
Right-click the desired domain, and select Properties.
Click the Last logon schedule tab to configure last logon statistics collection.
To manage Workflow, assign the Workflow Automation Server Administration role or the applicable powers below to assistant administrators:
Create Workflow Event and Modify All Properties
Delete Workflow Automation Server Configuration
Set Workflow Automation Server Configuration Information
Start Workflow
View All Workflow Event Properties
View All Workflow Properties
View Workflow Automation Server Configuration Information
To delegate Workflow Automation server configuration powers:
Click Powers in the Delegation Management node, and use the search objects feature to find and select the Workflow powers that you want.
Right-click one of the selected Workflow powers and select Delegate Roles and Powers.
Search for the specific user, group, or assistant administrator group that you want to delegate powers to.
Use the Object Selector to find and add the objects that you want, and then click Roles and Powers in the Wizard.
Click ActiveViews, and use the Object Selector to find and add the ActiveViews that you want.
Click Next and then Finish to complete the delegation process.
To use Workflow Automation in DRA, you have to install the Workflow Engine on a Windows Server and then configure the Workflow Automation server through the Delegation and Configuration console.
To configure the Workflow Automation server:
Log in to the Delegation and Configuration Console.
For Workflow Automation powers, see Delegating Workflow Automation Server Configuration Powers.
Expand Configuration Management > Integration Servers.
Right-click Workflow Automation, and select New Workflow Automation Server.
In the Add Workflow Automation Server wizard, specify the details such as server name, port, protocol, and access account.
Test the server connection, and click Finish to save the configuration.
For information on installing the Workflow Engine, see the Workflow Automation Administrator Guide.
DRA enables you to search for LDAP objects in on-premises Active Directory domains such as users, contacts, computers, groups, and OUs from the LDAP server. The DRA server still handles the operation and it is the domain controller where the search is executed. Use the search filters for more efficient and effective searches. Also, you can save the search query for future use and it can be shared with public or use it for your own by marking it as private. You can edit the saved quires.The LDAP Advanced Queries role grants assistant administrators powers to create and manage LDAP Search queries. Use the following powers to delegate the creation and management of LDAP Search queries:
Create Private Advanced Query
Create Public Advanced Query
Delete Public Advanced Query
Execute Advanced Query
Execute Save Advanced Query
Modify Public Query
View Advanced Query
To delegate LDAP Query powers:
Click Powers in the Delegation Management node, and use the search objects feature to find and select the Advanced LDAP Queries powers that you want.
Right-click one of the selected LDAP powers and select Delegate Roles and Powers.
Search for the specific user, group, or assistant administrator group that you want to delegate powers to.
Use the Object Selector to find and add the objects that you want, and then click Roles and Powers in the Wizard.
Click ActiveViews, and use the Object Selector to find and add the ActiveViews that you want.
Click Next and then Finish to complete the delegation process.
To access the search feature in the Web Console, navigate to Management > LDAP Search.
When NTLM is disabled in your environment, perform the following steps for correct functioning of DRA:
Enter the following command at the administrator command prompt to create the Service Principal Names (SPNs) in the DRA Server:
setspn -u -A QueryHost/<FQDN of DRA server> <DomainName>\<service account name>
Enable delegation for the DRA Service account:
From Microsoft Active Directory, locate the DRA Service account and open its properties.
From the Delegation Tab, select Trust this user for delegation to specified services only and Use any authentication protocol.
Click Add. From the Add Services window, search for and select the SPN created in step 1.
Go to the DRA installation folder and update the following configuration in the NetIQ.DRA.RestService.exe.config file:
<customAppSettings hostServerSpn="QueryHost/<FQDN of DRA server>" />
Restart the NetIQ Administration Service.