6.2 Understanding the Variations for Identity Sources

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 sources:

6.2.1 Collecting from Active Directory with Azure Active Directory

When your environment uses both Active Directory and Azure AD, user identities might be unique to one of the applications or 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 for 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.

IMPORTANT:Microsoft will end support for Azure AD Graph in June 2022. We recommend that you start using the Azure AD MS Graph templates. We have disabled the 3.6.2 Azure AD User templates. If you are still using the old Azure AD templates, you can reconfigure your template to map to the Microsoft Graph API by changing Azure AD Service Resource default value to https://graph.microsoft.com/v1.0. For differences between the previously supported API and Microsoft Graph API, see https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-property-differences.

When using the Azure AD MS Graph collector, complete the following steps :

  1. Enable the Azure Microsoft Graph API for your site and grant the following permissions to an account to access the API:






    Read all applications



    Read all devices



    Access directory as the signed in user


    Application and Delegated

    Read directory data



    Read domains


    Application and Delegated

    Read all groups


    Application and Delegated

    Read group memberships



    Read role management data for all RBAC providers



    Read Cloud PC RBAC settings



    Read directory RBAC settings



    Sign in and read user profile


    Application and Delegated

    Read all user profiles



    Read all users’ basic profiles

  2. 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.

6.2.2 Collecting from a CSV File

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. In the Column Delimiter field, you enter the word tab in uppercase, lowercase, or any combination. Test connection is not supported when the CSV collector is accessed via an HTTP or HTTPS connection.

6.2.3 Collecting from Google Apps

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.

6.2.4 Collecting from Identity Sources with Change Events

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:

Identity Governance allows you to configure multiple non-merging identity source collectors to collect change events. You can set the polling interval and maximum polling time for each collector so that they can function independently. If you do not set the polling values while configuring the collector, Identity Governance uses the globally set preconfigured values to determine the polling frequency. However, the polling values set at the collector level takes precedence over the globally set values. You must perform at least one collection and publication before Identity Governance launches into the polling cycle, or the Enable change event processing flag will remain blocked.

The Identity Change Event Productions allows you to see details of the change events that occurred during the polling time, such as, entities that were added, modified, or deleted. Depending on your requirement, you can select or sort the columns, or use event data to search events. You can also filter event data based on specific event type.

If you collect for one of the data sources after enabling event collection, Identity Governance suspends polling for that source but continues polling for the other identity sources with change event collection. Polling for the suspended source does not resume until the collection is published by the next identity publication.

NOTE:When an identity publication is in progress, polling for all identity sources change event collectors is temporarily suspended until the publication completes.

uses the global configuration parameters: com.netiq.iac.rtc.event.polling.interval and com.netiq.iac.rtc.max.polling.timeoutTypically, events are collected in batches of up to 100 events. However, if the identity source’s Batch Size Limit as configured in the Service Parameters is less than 100, then that batch size is the upper limit for event collection.

IMPORTANT:The identity source with change event collectors is 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 changes.

During event collection, Identity Governance treats a user record move in the underlying LDAP tree from outside of to inside of the scope of the configured Search Base as an ADD event. Likewise, Identity Governance treats a user record move to the outside of the Search Base scope as a DELETE event. The Data Sources > Activity page reports the number of events of each type that were processed in the most recent event processing period as part of the detail of the most recent collection for that collector.

For more efficient event processing, Identity Governance does not generate change events 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.

If you have upgraded from a previous version of Identity Governance, use the Identity Source Migration utility to update your Active Directory data collector, eDirectory data collector, and Identity Manager data collector to accept change events. For more information, see Section 6.4, Migrating an Identity Collector to a Change Event Identity Collector.

6.2.5 Collecting from Microsoft SharePoint

Microsoft SharePoint is a browser-based collaboration and document management tool that allows administrators to grant specified access rights to individual users and groups.

To gather information from SharePoint, the Service Account you use to configure SharePoint collection must be a member of the WSS_ADMIN_WPG local group on the SharePoint server.

NOTE:You cannot use the SharePoint collector for SharePoint Online.

6.2.6 Collecting from SCIM Compatible Applications

The System for Cross-domain Identity Management (SCIM) is a protocol for identity exchange, especially across SaaS products. SCIM connectors enable Identity Governance to integrate with applications seamlessly. The collector supports the following authentication methods.

Authentication type

Credential Set

Basic Auth

  • User Name

  • Password

Access Token

  • Access Token Header

  • Access Token

Bearer Token

  • User Name

  • Password

  • Client ID

  • Client Secret

Note that for access token, the user provides the token to connect to the SCIM compatible application, whereas for bearer token, the connector generates the token.

Additionally, you might need to change attribute mapping when configuring the template. SCIM supports singular, complex singular, complex multi-valued attributes, and extensions. However, if your application supports any other attributes or extensions different from those mentioned in the SCIM protocol, you can change the attribute mapping in the template by using delimiters. You can use ‘:’ (colon) for attributes, for example, emails:work:value and ‘+’ (plus) for extensions, for example, urn:ietf:params:scim:schemas:extension:enterprise:2.0:User+department.