The rights needed to perform operations and scan computers are established by assigning a service account to the required domain.
The service account must already be created in Data Governance Edition to be assigned to a domain. For more information, see Adding and editing a service account.
To enable the Data Governance server to interact with computers in a domain
- In the Navigation view, select Data Governance | Service accounts.
- In the Service Accounts result list, right-click the service account, and select Tasks | Assign domains.
-
In the Add assignments pane (lower pane), double-click the required domain. You can also right-click the managed domain and select Assign or Assign all objects.
The managed domain now appears in the top pane.
- Click the Save toolbar button to save your selection.
Note: From the Managed hosts view, if you select a host computer on a domain that was not previously identified as a managed domain, the Domain Credentials dialog appears. Click the Set button to supply the credentials of an Active Directory user with administrative rights on the selected domain. Assigning the credentials for the domain registers the user as a Data Governance Edition service account, links the service account to the domain and adds it to the managed domains list.
A managed host is any network object that can host resources and can be assigned an agent to monitor security and resource activity. For more information, see Adding and configuring managed hosts.
Note: Any objects that you want to manage through Data Governance Edition must first be added to Active Directory.
Depending on the type of managed host, you may be deploying different agents. There are two types of agents — local and remote.
Table 14: Differences between local and remote agents
| Local agent |
Local agents reside on the same computer as the managed host.
When you deploy a local agent, it immediately scans all fixed volumes on the host computer by default. If you do not want everything scanned, you can define the paths to be scanned.
You can only use a single agent on a local managed host; however local agents provide the best performance and the most functionality. |
| Remote agent |
Remote agents reside on a remote computer other than the managed host, and require a service account with adequate credentials to read the security information.
Remote agents scan only the configured managed paths on a defined schedule, in order to maximize performance. The default security scanning schedule is daily at 2:00 A.M.
You can use remote agents on Windows computers, and you must use them on Windows clusters, NetApp devices (with CIFS or NFS file system protocols enabled), EMC devices (with CIFS or NFS file system protocols enabled), Generic host types, and Cloud host types.
Remote agents cannot collect resource activity on remotely managed Windows, Windows clusters, Generic, or Cloud host types. |
Note: SharePoint farm agents are remotely managed and require a service account for the agents. They must be installed on a SharePoint server. Ensure that the service account configured for the SharePoint managed host is a SharePoint Farm Account (same account that is used to run the SharePoint timer service).
Note: A DFS root managed host does not have an agent installed. Once a root is added as a managed host, the Data Governance server periodically synchronizes the DFS structure into the One Identity Manager database making the DFS path available within the Resource browser. You are able to quickly see where all the data has been replicated throughout your network.
You must have enough free space on the agent computer in the installation directory to store the data collected by the agent. Contact Software Support for details on estimating the disk space usage.
To optimize searches for access points, agents send security index information for resources under managed paths to the Data Governance server for storage in the One Identity Manager database. This allows clients to quickly determine the hosts where detailed access queries are to be directed.
Note: All detailed security information for resources placed under governance is sent to the Data Governance server and stored in the One Identity Manager database.
Detailed access information is maintained on the agent computer, only sending general access information to the server.
The server acts as an intermediary between the agents and the databases where information is stored. It coordinates all agent deployments and communication, and manages the security index for each managed host. Only indexing direct-access points is done for several reasons:
- Security information that is not explicit is, by definition, inherited from a resource higher in the hierarchy. Unless the resource is the managed path, the agent has already indexed the explicit security on the parent resource that is causing the inherited security to be present.
- Not including inherited access points greatly reduces the total size of the index.
- Resources with only inherited access are not interesting from a security standpoint. Data Governance Edition is interested in the resources that have had security applied directly to them.
Related Topics
Deployment best practices
Agent leases
Adding and configuring managed hosts
Managed host configuration settings
When deploying Data Governance agents, local agents are preferable to remote agents. Local agents reduce network bandwidth and increase responsiveness. When it is not possible to deploy local agents to a system (such as when using a network attached storage device, or a virtual cluster node), the following best practices should be considered:
-
When deploying multiple remote agents to an agent host computer, the number of agents a host computer can handle is limited by several factors:
-
The total number of resources being scanned by all hosted agents.
-
The total number of resources with explicit security being indexed by all hosted agents.
-
All the queries that are serviced by agents hosted concurrently are executed on that local hardware.
-
Overwhelming the host computer with too many agents can result in slow indexing performance and intermittent failures in agent queries or in indexing operations.
- When deploying remote agents, ensure that the agents are hosted on computers that have low latency, high-bandwidth connections to their targets. This ensures that agents that have real-time change watching enabled will not suffer from periodic watch failures.
- When possible, avoid deploying agents to the computer hosting the Data Governance service itself. The server requires significant network resources to perform its various operations. When agents are deployed to this system, they compete for these network resources. Leaving the server with as few agents as possible ensures that it will not suffer performance degradation due to resource scarcity.
- More than one remote agent may be used to scan remote Windows computers, Windows clusters, and NAS devices. This is useful if the managed host has a large set of managed paths. Multiple agents may not scan the same managed paths.
- Manually installing agents is not supported. You must use the Manager client to deploy and configure Data Governance agents because you need access to the Data Governance application roles within One Identity Manager.
-
When adding a remote agent, ensure that a trust exists between:
- When deploying multiple agents to manage a SharePoint farm, One Identity recommends that you manage the lowest resources in the SharePoint hierarchy that you plan on governing or reporting on. Also, divide these managed resources across as many agent services as your SharePoint server can handle. This will provide the fastest scanning and the least amount of downtime when running reports.
Once you have added a managed host, you can begin to manage the data contained within it.
Data Governance Edition includes a mechanism that enables the server to determine what agents are functioning without needing each agent to maintain a persistent connection to the Data Governance server.
Every few minutes the agent contacts the server to renew its lease. If the server has not received a lease renewal from an agent in the expected time frame, the agent goes into the "No communication from agent" state. This state indicates that the server is unable to receive information from the agent.
If an agent is in this state, you can attempt to restart the agent. For more information, see Restarting agents.. It is important to understand why the agent allowed its lease to expire. Leases may expire because the agent service stopped unexpectedly or the agent host computer lost its network connection so the agent could not contact the server to renew its lease.
Note: You can also review lease expiration information in the Data Governance server log (DataGovernanceEdition.Service.exe.dlog) in the Data Governance service installation directory (%ProgramFiles%\One Identity\One Identity Manager Data Governance Edition\Server\).
For a complete list of possible agent states, see Verifying managed host system status or Checking the agent status.
