When you create an identity or application source, you will also create the collectors that you want to use for gathering specific identity, account, or permission data from that source. A collector is based on a collector template that is populated, when possible, with common data mappings for the selected data source type. Each collector has one or more views that allow you to specify which data you will collect from your identity or application source, and describe how that data will be linked together in the Identity Governance catalog.
When you configure the collector, you designate the incoming attributes that you want to map to the attributes in the Identity Governance catalog. Then you can map the permissions to the accounts. You can map a static value to any attribute in a collector configuration. This has the effect of assigning the same specified value for the selected attribute to all collected objects. The multivalue field allows you to collect multiple values for an attribute. If you collect multiple values for the attribute, you can statically map only a single value.
Every collector has the following configurable elements:
Collector templates include predefined attribute mappings and value transformation policies for specific data source types. Select a template that best suits the data source. For example, select AD Identity to collect identities from Active Directory. The templates support the following types of data sources:
Active Directory
Azure Active Directory
CSV file
eDirectory
Google Apps
Identity Manager
JDBC, such as Oracle or PostgreSQL
Resource Access Control Facility (RACF)
Salesforce.com
SAP HR
SAP User Management
ServiceNow
SharePoint
NOTE:Template name ending in with changes can be enabled for incremental change events processing.
The CSV collector support TSV file. You enter the word tab, in uppercase, lowercase, or any combination in the Column Delimiter field.
To see all the data source types, select Collector Template when you create the data source. To collect data from a JDBC or SAP source, Identity Governance needs the appropriate third-party connector libraries to be installed on the Identity Governance server. For more information, see Identity Governance Server System Requirements
in the NetIQ Identity Governance Installation Guide.
You can also customize an existing template or create your own. For more information, see Section 2.2, Customizing the Collector Templates for Data Sources.
These are the configurable parameters that allow the collector to connect and, if required, authenticate to the target data source. These typically include file locations, server host and port specifications, or service URLs.This section includes a Test connection button to verify the settings.
Select Test connection to verify the settings.
This option allows you to preview data before running a full collection, preserve the configuration for a data source, or create an emulation package for a data source. You can use generated files to validate and troubleshoot collections, send results to support engineers, and to import data source configurations to a different environment.
Identity sources provide core identity information to Identity Governance. When using multiple identity sources you can:
Specify the order of priority between different sources
Specify how identities from different sources will be matched and merged
Designate which source will be used for different identity attributes
Identity collectors populate the Identity Governance system with users. When using an LDAP-based One SSO Provider (OSP) system, such as eDirectory or Active Directory, ensure that the proper data source is providing the LDAP Distinguished Name attribute to the identities. This is the attribute that Identity Governance uses for single sign-on authentication.
Collector templates for an identity source can have the following elements:
To ensure that you can create a unique identity from the data that you collect, you tell Identity Governance how to map the data collected from an application to the data that you collect from identity sources. Collect as much information as you need to fulfill your business needs. Also ensure that you collect enough information to allow application account and permission to be joined to your identities. Some common join attributes that are available from most application sources include email address, workforceId, and name attributes.
An identity in the catalog can have attributes for one or more organizational group. For example, you might group employee identities by their department, such as Finance or Human Resources. You can use the collected group attribute to set the scope of a review, such as reviewing employees only in the Finance group. For example, Active Directory, eDirectory, and Identity Manager support this type of collection.
Identity Governance always uses the userID attribute for an identity to join to the membership of collected groups. If a data source does not support group collection, Identity Governance does not allow you to configure this option.
This view is used to collect the relationship that joins users to groups from identity sources that maintain these relationships separate from the basic group information. For example, the JDBC Identity collector runs a SQL query that parses the table that contains the links between groups and users.
This view is used to collect the relationship that joins groups to subordinate groups from identity sources that maintain these relationships separate from the basic group information. For example, the eDirectory Identity collector uses this view to obtain nested group members of groups.
An application source might contain account and permission collectors. Account collectors gather information about the application users, such as their name, account ID, login name, and login time. Permission collectors gather information about the application access rights of the account users. Since there is no universal method for linking accounts and permissions to identities, these collectors also provide the attributes and optional views necessary to join application accounts to Identity Governance identities and to join application permissions to either Identity Governance identities or to the application accounts as needed.
Depending on the type of data that you want to collect, the collector template might provide the following elements:
Accounts represent entities, such as a system, application, or data source, that an identity might access. For example, your employees might have an account that lets them log in to your company email system. An account in Identity Governance is similar to an association in Identity Manager.
Permissions can describe any of the following:
Actions that you can take within an application, such as running reports
Items that you possess, such as an identity badge
Things that you can access, such as a building
A permission in Identity Governance is similar to an entitlement in Identity Manager.
NOTE:If you use Permission-Account or User Mapping to join permissions to accounts or users, you must disable the optional Permission and Holders Mapping collections. Failure to do so could result in duplicate permission assignments in the catalog.
(Optional) These views exist to allow you to specify how a permission will be joined to either an Identity Governance identity or to an application account. In most application sources, such as Active Directory, the permissions (groups) are joined to Active Directory users (accounts). In this situation, you will use an Active Directory account and an Active Directory permission collector and join the permissions to the account using the distinguishedName attribute of the account. However, if your identities also came from the same Active Directory source, the account collector is not needed and the group permissions could be joined directly to the identities using the distinguishedName. The collector configuration page presents all available permission join attribute options. Due to differences in the holder/permission relationship management in different application sources, Identity Governance provides two optional views:
Permission to Holder Mapping where the relationship is best expressed by starting with the permission object and following the relationships to the holders of that permission. For example, the "member" attribute on an eDirectory permission group.
When Mapping permissions to holders in any application where it exists, you must use Account ID from Source not User ID from Source if you want the permission to be linked to the user (which is the usual expectation).
Holder to Permissions Mapping where the relationship is best expressed by starting with the user account and following the relationships to the permissions held by that user account. For example, the "groupMembership" attribute on an eDirectory user.
In some applications, the relationship can exist bidirectionally between the holder and permission. In this situation, use only one of the above views.
Applies only to Identity Manager data sources
Applies only to Identity Manager data sources
(Optional) When an application source organizes permissions in parent-child relationships, you can collect the relationship between the permissions. When gathering nested permissions, specify one of the following methods:
Child to parent where the collected permissions include an attribute that points to child permissions
Parent to child where the collected permissions include an attribute that points to a parent permission, such as eDirectory user
In Identity Governance, you associate user identities gathered from identity sources to the accounts and permissions assigned in the application sources. Many user identities are categorized by groups and have parent-child relationships with other identities or accounts. However, some application sources might define groups or parent-child relationships in a different way than Identity Governance. Also, some identity sources might be configured to generate incremental change events.
This section explains how to use the collector templates for the following application sources:
When your environment uses both Active Directory and Azure AD, some user identities might be unique to one of the applications while other identities might exist in both applications. If you use Active Directory and Azure AD with DirSync or AD Connect, you can create a single identity source for both applications by using the Azure AD User collector template.
In the collector template, specify an attribute that you want to use for merging duplicate identities and matching identities to accounts and permissions.The attribute for the matching rule should contain a value that is unique to each identity. For example, in AD and Identity Manager, each user tends to have a unique Distinguished Name.
If you are using the Active Directory Azure collector, complete the following steps:
Enable the Azure Active Directory Graph API for your site and grant the following permissions to an account to access the API:
Directory.Read.All
User.Read
Generate an OAuth2 client and secret for API access.
Check that you can browse your Azure domain with the graph explorer using the account from Step 1. For more information, see https://developer.microsoft.com/en-us/graph/graph-explorer.
A CSV file provides a simple method for storing user account or permissions information that cannot be collected from other data sources. You can include group, account, permission, or user data in the file.
If you use a CSV file as an identity source, you might want to instruct Identity Governance to map the collected users to their collected group memberships. The Group Members (Users and Groups) setting allows you to specify an attribute in the CSV file that you want to use for mapping users and groups to groups. However, you can use this setting only when a given value for the specified attribute is not used to identify both a user and a group. For example, if you export data from Active Directory to the CSV file, you can use DN as the Group Members attribute. Otherwise, you can use Collect Group to User Membership or Collect Parent Group to Child Group Relationships to map users or groups to groups. These two settings match the specified attribute in the collected user or group data, respectively.
In preparing a CSV file, ensure that any values written into a column of the file do not contain any carriage returns and line feeds, since these characters define record boundaries in the CSV file.
NOTE:The CSV collector support TSV file. You enter the word tab, in uppercase, lowercase, or any combination in the Column Delimiter field.
Google Apps manage users, groups, and organizational units, including assigned roles and privileges. Collecting identities from Google Apps is similar to other data sources. However, to collect permissions, Identity Governance pulls information from Google Groups, which resembles discussion-based groups similar to those available in Usenet.
To gather information about actual user groups, Identity Governance collects from the Organizations (organizational units) in Google Apps. These organizational units can contain nested units. The top level organization is always called ‘root.’ During collection, Identity Governance translates the organizational units into Identity Governance-style groups. In Identity Governance, the root group lists all the users in that organizational unit. If you select one of the nested groups under the root group, Identity Governance lists only the individuals assigned to that group.
Identity sources with change events provide incremental change events for user and group data from certain identity sources to incrementally update the identity catalog. To periodically pull change events and incrementally make changes to your identity catalog the following conditions must be met:
An identity source is configured as an identity event source, either by having created an identity source from a suitable template, or by having migrated a non-event-aware identity source by using the Identity Governance Migration Utility and selecting enabling event collection. For more information, see Creating Identity and Application Sources and Migrating an Identity Collector to a Change Event Identity Collector.
The identity source is the primary identity source, for example it is either the sole identity source or an unmerged identity source
The identity event source has been collected and published
The configuration of the identity source and its collector has not changed since the last publication
Identity event source collection, identity publication, or application publication is not in progress.
(Conditional) For eDirectory, the Change-Log module must be installed to support event processing. For more information, see Installing the Change-Log Module on a Remote eDirectory server
in the NetIQ Driver for Bidirectional eDirectory Implementation Guide.
(Conditional) For Identity Manager, the Identity Gateway Integration Module must be installed on the target Identity Manager server. Using Designer, install the following packages to support event processing:
Identity Gateway Integration Module Base
Identity Gateway Integration Module Default
Identity Gateway Identity Governance Integration Package
For more information, see the NetIQ Identity Manager Driver for Identity Gateway Integration Module Implementation Guide.
Once event collection is enabled, Identity Governance uses the global configuration parameters: com.netiq.iac.rtc.event.polling.interval and com.netiq.iac.rtc.max.polling.timeout settings to determine the identity context change event polling frequency and time limit for batch event collection. Typically, events are collected in batches of up to one hundred events. However, if the identity source’s Batch Size Limit as configured in the Service Parameters is less than one hundred, then that batch size is the upper limit for event collection also.
IMPORTANT:The identity source with change event collectors are not intended to handle large-scale changes to the source directory, such as changes to the user population resulting from mergers or spin-offs, major changes to group memberships, or major reorganizations of any kind. In such cases, you should disable event processing and enable it after the major change.
During event collection, a user record move in the underlying LDAP tree from outside of to inside of the scope of the configured Search Base is treated as an ADD event, and a user record move to the outside of the Search Base scope is treated as a DELETE event. The number of events of each type that were processed in the most recent event processing period is reported on the Data Sources > Activity page, as part of the detail of the most recent collection for that collector.
NOTE: For a more efficient event processing, change events are not generated for any dynamic changes in eDirectory or Identity Manager dynamic groups. Also, removing a member from an eDirectory or Identity Manager group will not remove that member from any of the group's super groups if those groups have been configured to report nested members in membership query.