Skip to main content

Data import

Connection details

To specify connection details:

  1. In the Tenant ID field, type or paste the Tenant ID by using the Directory ID of the directory for which you configured the application. You can find the Directory ID in the Microsoft Azure Portal under the Properties section for the relevant directory.

  2. In the Application ID, type the ID of the Omada Identity Azure application that you created in the Microsoft Azure Portal. You can find the Application ID under Settings in the Azure Portal.

  3. In the Client Secret, type or paste the key that you created when you created the Omada Identity application in the Azure Portal. If you have not copied the key, you cannot return to Azure and find the key again.

  4. In the API Version field, enter the version of the Microsoft Graph API that you want to employ for this connectivity.

  5. Optionally, configure the Headers field. In it You can provide JSON document specifying custom headers, for example:

    {"Request": {"Accept": " text/html","contenttype":
    "application/json","SomeCustomHeaderWithValue":
    "custom value", "SomeCustomHeaderWithoutValue":
    null}}
  6. Optionally, enable the Test connection setting to make sure that the details that you have entered are correct. If you have made any errors, you receive an error message.

Queries and mappings

When you onboard an Microsoft Azure Active Directory, a number of default queries are already set up.

To specify queries and mappings:

  1. Verify that the default Microsoft Azure Active Directory mappings are set up for your Microsoft Azure Active Directory directory.
  2. Consider if you need to set up special account rules. Remember that no identity data is imported from Azure. If you want to make any changes to the queries, click New, then select the object type to create a query for.
  3. In the New query and mapping dialog box, under the Parameters heading, specify a valid URL.
  4. Optionally, use the Filter field under the Parameters heading. Thanks to this feature, you can use a Dynamic Expresso expression to filter the data imported into Omada Identity. It returns a TRUE/FALSE result for each imported data row. If the expression returns FALSE for the given row, that row is skipped during import.
  5. Optionally, type a Description. If you do not type anything in the Base DN field, the system uses the Base DN that you specified under Connections details.
  6. Under the Mappings header, map the relevant Destination properties in the left column to a value in the Source on the right side. You can specify whether the Operator is a Map, a Constant, an Expression, or a Lookup. You must always specify the required properties. The number of these properties depends on the selected mappings.
  7. Optionally, you can also add other extension attributes if you click the Add extension button. In such a case, you must type both a name for the extension attribute under the Destination column and a value in the Source column.
  8. For any manually typed extension attributes, select the History checkbox if you want to enable recording the history of the relevant extension attribute.
  9. When you return to the Queries and mappings dialog box, you can copy one or more object types in the overview by selecting the individual object type. Then click … > Copy.
  10. When you have added the queries and mappings you require, click OK to close the dialog box. The system validates your details. If there are no errors, the status in the Status column changes to OK.

Default attributes mappings for objects

The table below presents the default fields selected for the object mappings.

Object typeMicrosoft Azure Active Directory objectDefault selected fields
Accountusersid, userPrincipalName, displayName, accountEnabled, lastPasswordChangeDateTime, mail, givenName, surname
Resourcegroupsid, displayName, description, mailNickname
Resource assignmentgroups/deltaid, members
ResourcedirectoryRolesid, displayName, description
Resource assignmentdirectoryRoles/deltaid, members
ResourcesubscribedSkusskuId, skuPartNumber
Resource assignmentusersid, assignedLicenses
ResourcesubscribedSkusservicePlans
Resource assignmentusersid, assignedPlans
Resource parent/childgroups/deltaid, members

Adding new fields to the mappings

To add new fields to the object mappings, you need to add desired fields to the comma separated list in the OData URL in the Queries and mappings dialog.

Mapping of resource owners

If you create a query to import resource owners, it is possible to specify the resource's owner in two ways. You can do it either by directly importing the UID of the identity or by specifying the account from which the resolved owner is imported as a resource owner.

When mapping directly to the UID of identity, make sure that identities are already imported to Omada Identity.

When mapping to an owned account, it is possible to either specify the business key of the account or the composed business key. The former should be used if the account is in the same system as the resource; the latter should be used if the account is imported into any of the trusted systems.

When the account stems from another system, you should use a Lookup mapping.

Advanced settings

To specify advanced settings:

  1. Enable Perform unfolding to unfold access to users given to resources that use groups to assign membership, and where a user is a member of one of these groups. For example, if a user is a member of Active Directory 1, there are certain rights assigned to this user. If Active Directory 1 is a member of Active Directory 2, the user can get the rights to both Active Directory 1 in addition to Active Directory 2. This inheritance of rights is not enabled by default, but if you enable the resource parent-child hierarchy, you can enable it.

    You can also provide Microsoft Office 365 licenses and access to applications in MyApps through groups.Omada recommends that you make this setting enabled to ensure that license and application access is unfolded.

  2. The Timeout in seconds field allows you to specify how long the collector should wait for a response of the REST service. The default value is set to 3600 seconds (1 hour).

  3. In the optional Row count per batch field you can set the number of objects that will be collected and staged as a batch when paging is implemented in the collector.The default value is 100000.

info

Remember that applying a low value (e.g., 50 or 500) to this setting may result in extended import time.

Default collected data

When you register the first Microsoft Azure Active Directory system, six new resource types are created:

Resource typeDescription
_[system name]_ AccountThis is the default Account resource type. Two standard account resources are also created. One resource is for personal accounts and the other resource is for orphan accounts with no primary owner.

The name of this resource depends on the name of the system.
MS Azure AD GroupThis is a Permission resource type. When you import groups in the directory, this type is used.
MS Azure AD SkuThis is a Permission resource type. When you import purchased O365 SKUs, this type is used.
MS Azure AD ServiceThis is a Permission resource type. When you import services that are a part of a purchased SKU, this type is used.
MS Azure AD Directory RoleThis is a Permission resource type that contains the role definitions in the AD.

Default data imports from queries and mappings

When you run an import, the system imports the data defined by queries and mappings. The default data is listed in the Default attributes mappings for objects in the Queries and mappings section.

Below you can find more details on the imported data.

Users

To import Users the application must be given User.Read.All application permission.

The collector imports Microsoft Azure Active Directory Users as Accounts; by default, the displayName, givenName, surname, userPrincipalName, mail, and the lastPasswordChangeDateTime are imported.

The state of the account is determined by the accountEnabled property.

givenName and surname are imported as extension attributes and are added to the set of attributes specified for the Account Resource Type. These two attributes are used for reconciliation.

Groups

To import Groups the application must be given Group.Read.All application permission.

The collector imports Groups as Resources with the Microsoft Azure Active Directory Group resource type. Note that all groups, Office, Security, Security (mail enabled) and distribution are imported as the same type.

info

The MS Graph API does not support a distinct way to separate the groups. Note that some groups can only be imported and not managed in terms of memberships, etc.

The id of the group is imported as ShortName that in a default configuration means the id is also the resource id.

You can find more information on different Group types in the Microsoft documentation.

Directory roles

To import Directory roles the application must be given RoleManagement.Read.Directory application permission.

The collector imports Directory roles as Resource with the Microsoft Azure Active Directory Directory Role resource type. The id of the directory role is imported as ShortName that in a default configuration means the id is also the resource id.

Note that only activated directory roles are imported.

You can find more information on Directory roles in the Microsoft documentation.

Assignments between Users and Groups

To import Assignments the application must be given Group.Read.All application permission.

Resource assignments between Users and Groups are imported using the delta functionality of the MS Graph API. However, the collector performs an initial query on each import and, in that sense, not utilizes the full delta functionality.

Assignments between Users and Directory roles

To import Assignments the application must be given RoleManagement.Read.Directory application permission.

Resource assignments between Users and Directory roles are imported using the delta functionality of the MS Graph API. However, the collector performs an initial query on each import and, in that sense, not utilizes the full delta functionality.

Parent/child relationships between Groups

To import relationships the application must be given Group.Read.All application permission.

In Microsoft Azure Active Directory, if a group is a member of another group, these memberships are imported as Parent/child relationships in Omada Identity. This means that if a User A is member of a group Child, and the group Child is member of a group Parent, then the User A have an implicit direct membership of the group Parent.

info

Role and Policy Engine (RoPE) does not calculate implicit direct memberships out of the box. To calculate such memberships, set the Ignore indirect ODW assignments customer setting to False.

In addition, you can instruct ODW to not unfold these assignments in the Advanced settings of the system onboarding described in the Advanced settings section.

Office 365 information

The collector also imports data related to Office 365 licenses.

  • Stock Keeping Units - to import SKUs the application must be given Organization.Read.All application permission. Stock Keeping Units or licenses are imported as resources with the Microsoft Azure Active Directory SKU resource type. The resources are categorized as Resource in the ODW.

  • Service Plans - to import service plans the application must be given Organization.Read.All application permission. The Service plans contained in an SKU are imported as separate resources with the Microsoft Azure Active Directory Service resource type. The resources are categorized as Resource in the ODW.

  • Assigned licenses - to import service plans the application must be given User.Read.All application permission. Assigned licenses or assignments between a User and an SKU are imported as Resource assignments.

  • Assigned service plans - to import service plans the application must be given User.Read.All application permission. Service plans assigned to a User through an Assigned service license are imported as Resource assignments.

Configure thresholds

The Configure thresholds function allows you to set the amount of changes that cannot be exceeded, relevant to the last import.

In the Configure import thresholds view, type a number (integer) in percentage for New objects, Modified objects, and Deleted objects to enable thresholds for the import of objects from this system.

The value for each operation is by default set to 0, which means that no threshold calculations take place for the operations until you change the integer.

For more information, refer to the Thresholds document in the Import and Onboarding section.

info

For all .NET-based collectors, thresholds are calculated in the following relation:

  • If the system category is set to Identity data, the thresholds are calculated.
  • If the system category is set to Access data, the thresholds are calculated.
  • If the system category set to Both, the thresholds only apply to Access data, that is, Accounts, Resources, and ResourceAssignments.