Chat now with support
Chat with Support

Identity Manager 9.1.2 - Administration Guide for Connecting to Azure Active Directory

Managing Azure Active Directory environments Synchronizing an Azure Active Directory environment
Setting up initial synchronization with an Azure Active Directory tenant Adjusting the synchronization configuration for Azure Active Directory environments Running synchronization Tasks following synchronization Troubleshooting Ignoring data error in synchronization Pausing handling of target system specific processes (Offline mode)
Managing Azure Active Directory user accounts and employees Managing memberships in Azure Active Directory groups Managing Azure Active Directory administrator roles assignments Managing Azure Active Directory subscription and Azure Active Directory service plan assignments
Displaying enabled and disabled Azure Active Directory service plans forAzure Active Directory user accounts and Azure Active Directory groups Assigning Azure Active Directory subscriptions to Azure Active Directory user accounts Assigning disabled Azure Active Directory service plans to Azure Active Directory user accounts Inheriting Azure Active Directory subscriptions based on categories Inheritance of disabled Azure Active Directory service plans based on categories
Login information for Azure Active Directory user accounts Mapping of Azure Active Directory objects in One Identity Manager
Azure Active Directory core directories Azure Active Directory user accounts Azure Active Directory user identities Azure Active Directory groups Azure Active Directory administrator roles Azure Active Directory subscriptions and Azure Active Directory service principals Disabled Azure Active Directory service plans Azure Active Directory app registrations and Azure Active Directory service principals Reports about Azure Active Directory objects
Handling of Azure Active Directory objects in the Web Portal Recommendations for federations Basic configuration data for managing an Azure Active Directory environment Troubleshooting Configuration parameters for managing an Azure Active Directory environment Default project template for Azure Active Directory Editing Azure Active Directory system objects Azure Active Directory connector settings

Speeding up synchronization

The Azure Active Directory connector supports delta synchronization to speed up Azure Active Directory synchronization. The method is based on the delta query function from Microsoft Graph. It supports the schema types User (user account), Group (group), and DirectoryRole (administrator role). Delta synchronization is not enabled by default. It is a custom setup.

Implementing delta synchronization
  1. Set up a regular Azure Active Directory synchronization project.

  2. Run initial synchronization.

  3. Modify the TargetSystem | AzureAD | DeltaTokenDirectory configuration parameter.

    The configuration parameter contains the directory where the delta token files are stored. In the Designer, modify the value of the configuration parameter. Ensure that the One Identity Manager Service user account has write access to the directory.

  4. (Optional) Modify the AAD_Organization_DeltaSync process.

    The process is made up of three process steps. Each process step handles on of the three supported schema types. Each process step is configured such that it synchronizes all supported delta properties of the schema types. Furthermore, each of these process step adds its own delta token file. The order of process steps is as follows:

    • Synchronize user accounts (Synchronize User process step)

    • Synchronize groups (Synchronize Group process step)

    • Synchronize administration roles (Synchronize DirectoryRole process step)

    If customized, ensure that the process is only generated if there is no other similar process is in the Job queue. In the same way, the process may not start during a regular synchronization.

  5. (Optional) Customize processing scripts for supporting schema types.

    • Process user accounts (AAD_ProcessDeltaQueryUser script)

    • Process groups (AAD_ProcessDeltaQueryGroup script)

    • PRocess administration roles (AAD_ProcessDeltaQueryDirectoryRole script)

    The AAD_ProcessDeltaQueryGroup script has had comments added to it to simplify editing and custom development.

  6. Adjust and enable the Azure Active Directory delta synchronization schedule

    The schedule ensures regular delta synchronization of the Azure Active Directory tenants. The schedule is run by default at 15 minute intervals. You can change this interval in the Designer if necessary. Enable the schedule.

The delta synchronization sequence
  1. An initial query is run for a schema type (user account, group, administrator role). The initial query returns a complete list for the schema type, such as all user accounts, including the queried properties. This also returns a state token. This token represents the state of the data at the time of the query in Azure Active Directory.

    The state token and the queried properties are written to a delta token file. By default, there is no initial processing of the data.

    Delta token file storage structure

    <Directory in TargetSystem | AzureAD | DeltaTokenDirectory configuration parameter>\<UID_AADOrganization>_<SchemaTyp>Query.token

    Example:

    C:\Temp\OneIM\DeltaToken\2da43fd4-ce7b-48af-9a00-686e5e3fb8a5_UserQuery.token

  2. The rest of the queries use the state token of the previous query. Apart from the new state token, they only return the objects that have changed since the last query.

    • Tries to add new objects if all mandatory properties have been queried.

    • Objects deleted in the target system are generally marked as Outstanding.

    Objects that fail during processing are logged in the process step's messages.

    The new state token is written in the delta token file.

Restrictions

With respect to the stability of repetitions, the difference query method has certain limitations. If a state token has been used once, it is generally invalid and the query cannot be run again. If an error occurs processing the return date, the respective change cannot be loaded until the next time synchronization is scheduled to run. For example, this happens to new group memberships if the member themselves has not been loaded yet.

Another disadvantage is the runtime of the initial query and initial data processing. This process is not recommended. However, because initial processing is meant to be carried out during scheduled synchronization, it is recommended to set the DoNotProcessOffset parameter in the process steps to True (default).

You should also take into account that not all properties can be queried using the Microsoft Graph API delta query.

If the data in the delta token file does not match the calling parameters of a query, the existing file is renamed to <alterName>.backup in order not to lose the state token and a new file is created. In this case, a new initial query is run. This also happens if the file does not exist or is empty.

Supported schema types

The following tables contain the supported schema types and their supported properties. As long as new objects are imported into the database, the mandatory properties in the delta synchronization must be queried.

Table 6: Supported properties for user accounts (schema type: User)

Property

Mandatory

Remark

AccountEnabled

 

 

AgeGroup

 

 

BusinessPhones

 

 

City

 

 

CompanyName

 

 

ConsentProvidedForMinor

 

 

Country

 

 

Department

 

 

DisplayName

X

 

ExternalUserState

 

 

ExternalUserStateChangeDateTime

 

 

GivenName

 

 

ID

X

 

JobTitle

 

 

LastPasswordChangeDateTime

 

 

LegalAgeGroupClassification

 

 

Licenses

 

When this property is queried, another query runs about the user account's assignment status (LicenseAssignmentStates). This increases the runtime massively.

Contains a list of objects with the DisabledPlans, SkuId, AssignedByGroup, State, and Error properties.

Mail

 

 

MailNickname

 

 

Manager

 

 

MobilePhone

 

 

OfficeLocation

 

 

OnPremisesDistinguishedName

 

 

OnPremisesDomainName

 

 

OnPremisesImmutableId

 

 

OnPremisesLastSyncDateTime

 

 

OnPremisesSamAccountName

 

 

OnPremisesSecurityIdentifier

 

 

OnPremisesSyncEnabled

 

 

OnPremisesUserPrincipalName

 

 

PostalCode

 

 

PreferredLanguage

 

 

ProxyAddresses

 

 

State

 

 

StreetAddress

 

 

Surname

 

 

UsageLocation

 

 

UserDomain

x

 

UserPrincipalName

x

 

UserType

x

 

Table 7: Supported properties for groups (schema type: Group)

Property

Mandatory

Remark

Description

 

 

DisplayName

x

 

GroupTypes

x

 

ID

x

 

Licenses

 

Contains a list of objects with the DisabledPlans and SkuId properties.

Mail

 

 

MailEnabled

x

 

MailNickName

x

 

Members

 

The property is not available in an initial query. The result contains the schema type and the ID.

OnPremisesSecurityIdentifier

 

 

OnPremisesSyncEnabled

 

 

Owners

 

The property is not available in an initial query. The result contains the schema type and the ID.

ProxyAddresses

 

 

SecurityEnabled

x

 

Table 8: Support properties for administration role (schema type: DirectoryRole)

Property

Mandatory

Remark

Description

 

 

DisplayName

x

 

ID

x

 

Members

 

The property is not available in an initial query. The result contains the schema type and the ID.

Configuring the provisioning of memberships

Memberships, such as user accounts in groups, are saved in assignment tables in the One Identity Manager database. During provisioning of modified memberships, changes made in the target system may be overwritten. This behavior can occur under the following conditions:

  • Memberships are saved as an object property in list form in the target system.

    Example: List of user accounts in the Member property of an Azure Active Directory group (Group)

  • Memberships can be modified in either of the connected systems.

  • A provisioning workflow and provisioning processes are set up.

If one membership in One Identity Manager changes, by default, the complete list of members is transferred to the target system. Therefore, memberships that were previously added to the target system are removed in the process and previously deleted memberships are added again.

To prevent this, provisioning can be configured such that only the modified membership is provisioned in the target system. The corresponding behavior is configured separately for each assignment table.

To allow separate provisioning of memberships

  1. In the Manager, select the Azure Active Directory > Basic configuration data > Target system types category.

  2. In the result list, select the Azure Active Directory target system type.

  3. Select the Configure tables for publishing task.

  4. Select the assignment tables that you want to set up for single provisioning. Multi-select is possible.

  5. Click Merge mode.

    NOTE:

    • This option can only be enabled for assignment tables that have a base table with a XDateSubItem column.

    • Assignment tables that are grouped together in a virtual schema property in the mapping must be marked identically.

      Example: AADUserInGroup and AADGroupInGroup

  6. Save the changes.

For each assignment table labeled like this, the changes made in One Identity Manager are saved in a separate table. Therefore, only newly added and deleted assignments are processed. During modification provisioning, the members list in the target system is compared to the entries in this table. This means that only modified memberships are provisioned and not the entire members list.

NOTE: The complete members list is updated by synchronization. During this process, objects with changes but incomplete provisioning are not handled. These objects are logged in the synchronization log.

You can restrict single provisioning of memberships with a condition. Once merge mode has been disabled for a table, the condition is deleted. Tables that have had the condition deleted or edited are marked with the following icon: . You can restore the original condition at any time.

To restore the original condition

  1. Select the auxiliary table for which you want to restore the condition.

  2. Right-click on the selected row and select the Restore original values context menu item.

  3. Save the changes.

NOTE: To create the reference to the added or deleted assignments in the condition, use the i table alias.

Example of a condition on the AADUserInGroup assignment table:

exists (select top 1 1 from AADGroup g
where g.UID_AADGroup = i.UID_AADGroup
and <limiting condition>)

For more information about provisioning memberships, see the One Identity Manager Target System Synchronization Reference Guide.

Configuring single object synchronization

Changes made to individual objects in the target system can be immediately applied in the One Identity Manager database without having to start a full synchronization of the target system environment. Individual objects can only be synchronized if the object is already present in the One Identity Manager database. The changes are applied to the mapped object properties. If a membership list belongs to one of these properties, the entries in the assignment table will also be updated. If the object is no longer present in the target system, then it is deleted from the One Identity Manager database.

Prerequisites
  • A synchronization step exists that can import the changes to the changed object into One Identity Manager.

  • The path to the base object of the synchronization is defined for the table that contains the changed object.

Single object synchronization is fully configured for synchronization projects created using the default project template. If you want to incorporate custom tables into this type of synchronization project, you must configure single object synchronization for these tables. For more information about this, see the One Identity Manager Target System Synchronization Reference Guide.

To define the path to the base object for synchronization for a custom table

  1. In the Manager, select the Azure Active Directory > Basic configuration data > Target system types category.

  2. In the result list, select the Azure Active Directory target system type.

  3. Select the Assign synchronization tables task.

  4. In the Add assignments pane, assign the custom table for which you want to use single object synchronization.

  5. Save the changes.
  6. Select the Configure tables for publishing task.

  7. Select the custom table and enter the Root object path.

    Enter the path to the base object in the ObjectWalker notation of the VI.DB.

    Example: FK(UID_AADOrganization).XObjectKey

  8. Save the changes.
Related topics

Accelerating provisioning and single object synchronization

To smooth out spikes in data traffic, handling of processes for provisioning and single object synchronization can be distributed over several Job servers. This will also accelerate these processes.

NOTE: You should not implement load balancing for provisioning or single object synchronization on a permanent basis. Parallel processing of objects might result in dependencies not being resolved because referenced objects from another Job server have not been completely processed.

Once load balancing is no longer required, ensure that the synchronization server runs the provisioning processes and single object synchronization.

To configure load balancing

  1. Configure the server and declare it as a Job server in One Identity Manager.

    • Job servers that share processing must have the No process assignment option enabled.

    • Assign the Azure Active Directory connector server function to the Job server.

    All Job servers must access the same Azure Active Directory tenant as the synchronization server for the respective base object.

  2. In the Synchronization Editor, assign a custom server function to the base object.

    This server function is used to identify all the Job servers being used for load balancing.

    If there is no custom server function for the base object, create a new one.

    For more information about editing base objects, see the One Identity Manager Target System Synchronization Reference Guide.

  3. In the Manager, assign this server function to all the Job servers that will be processing provisioning and single object synchronization for the base object.

    Only select those Job servers that have the same configuration as the base object's synchronization server.

Once all the processes have been handled, the synchronization server takes over provisioning and single object synchronization again.

To use the synchronization server without load balancing.

  • In the Synchronization Editor, remove the server function from the base object.

For more information about load balancing, see the One Identity Manager Target System Synchronization Reference Guide.

Detailed information about this topic
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating