Azure AD integration

ObserveID Azure AD integration receives cloud-based identity and infrastructure data for analysis and day-to-day security and access management tasks. The Integration communicates with the Azure AD target via Microsoft Graph API, Office 365 Exchange Online API. It is capable of importing integration data and operates in read-only mode or executes allowed operations. These operations include provisioning users with entitlements of various permission types, such as AD Groups, AD Roles, RBAC Roles, Exchange’s Distribution List Groups, and Licenses. Together with access control, the Azure AD integration is supplied with robust auditing capabilities, access detection, and more.

Azure AD is a cloud-based identity service that provides single sign-on, multi-factor authentication, user provisioning, and protection to meet access governance requirements. This section describes how to set up the Integration, including configuration and schema details for the Azure AD Integration Data.

In this section:

  • Overview
  • Azure AD integration operations
  • Pre-requisites to setup of Azure AD integration
    • App registration
    • API permissions
    • Admin consent
    • Azure RBAC Role
    • Azure AD Role
  • Minimum permission list
    • Privileges to access Exchange Online
  • Setup of Azure AD integration
  • First load of data from Azure AD target
  • Coding integration rules

Overview

The Azure AD integration allows one to manage Azure AD users, roles, groups, permissions, and control the access to the resources within an Azure AD tenant. From the high-level perspective, the following Integration Data is retrieved from Azure AD:

  • resources with basic information about them;
  • shells pre-configured to set up independent integrations, if needed;
  • lists of available permissions to govern access to each of the resources in the Azure Subscription\Resource Groups;
  • Distribution List Groups from the Exchange server;
  • AD Groups, AD Roles, RBAC Roles;
  • Azure AD users;
  • entitlements assigned to users, groups, and roles; and
  • the properties attributed to users, resources, and permissions.

To create an Azure AD integration in ObserveID and get it ready for the use, the base setup and configuration flow includes the following steps:

  1. Prerequisites must be implemented on Azure AD for ObserveID.
  2. Connection parameters must be set up on ObserveID for Azure AD.
  3. First load of data from Azure AD to ObserveID should be successfully completed.
  4. Coding integration rules according to the business case requirements is the final step before the system is ready.

Integration Operations

An Azure AD integration can perform the following operations on the Integration Data:

Integration Operation

Used by

General description

Integration-Specific Requirements

Account Management

Create Account

Permanent Access Request, Temporary Access Request, Onboarding, Reinstatement, Role Creation, Role Update, Identities Update

The Azure AD integration can create accounts. It requires Additional Properties to be established for accounts. The Additional Properties are coded with Provisioning Rules.

The Additional Properties mandatory on the creation of an Azure AD account are: - Name

  • Display Name

For any Azure AD requirements on what account properties are required and\or allowed to be set, refer to Provisioning Rules.

Credentials Update

Password Change Request, Privileged or Firecall Unlock Request

A password can be set for an account on Account Creation, or updated with a workflow according to the Password Policy. For Privileged or Privileged Service account types, the password can be rotated.

The password is rotated if ‘yes’ is established for an Azure account in its ‘Rotatable’ property.

The following Password Policies are available for the Azure AD integration: - Auto Generated Permanent Credentials

  • Auto Generated One Time Credentials
  • Set Specific One Time Credentials
  • Set Specific Permanent Credentials

Delete Account

Account Removal, the Finish action on Temporary Access Request

The Azure AD integration can delete accounts. The respective history records are stored for every Identity.

n/a

Offboarding, Emergency Deprovisioning

When an Identity is terminated, their Azure account(-s) are deprovisioned according to the Azure AD Leaver Rule.

During Identity Termination, the Azure AD integration Leaver Rule can set one of the following available options: - the Azure accounts can be locked;

  • the Azure accounts can be locked and deprovisioned of all or some Entitlements;
  • the Azure accounts can be deleted.

For coding the Azure Leaver Rule, refer to the Coding Integration Rules section below.

Lock Account

Privileged Unlock Request, Firecall Unlock Request, Manage Access, Permanent Access Request

When the Azure AD integration unlocks Privileged or Firecall accounts, it sets the usage period for the account.

When an Azure account is locked, its Azure Account Status property on the Azure AD target changes from Enabled to Disabled.

Unlock Account

Privileged Unlock Request, Firecall Unlock Request

On the Finish button or on the end of the usage period, the unlocked account is locked back.

When an Azure account is unlocked, its Azure Account Status property on the Azure AD target changes from Disabled to Enabled.

Update Account Additional Properties

Identities Update

Azure AD account properties can be updated if an Identity’s property has changed. Provisioning Rules can be configured to pass an Identity’s property to the Azure AD account.

The Additional Properties allowed on the update of an Azure AD account are: - Display Name

For what information can be displayed for an Azure AD account, refer to the schema of Azure AD integration data.

Target Management

Pull Data

DataImport task, Identities Update, most workflows

Within the Azure AD integration, the Integration Data is imported from Azure AD to ObserveID.

For what the Integration Data is fetched from the Azure AD target, refer to the schema of Azure AD integration data.

Correlation and Customization Rules can be configured to recognize the Identity for an account and the account type.

Refer to the requirements to Correlation and Customization Rules.

DataImport task

The Azure AD Integration Data can also include extra resource and\or permission types.

Exchange’s Distribution List and Mail-Enabled Security Groups It requires additional privileges granted to the app registered in Azure AD for ObserveID.

  • Applications registered in Azure AD.
  • Application Roles associated with the Applications.

It requires additional API permissions to be added: Applications.ReadWrite.All

If an AD Group is assigned with a License, the License is pulled too, and available for viewing in the implicit entitlements of the group.

The Azure AD Integration Data can also include extra additional properties of accounts.
  • MFA enabled
  • Azure Account Status

Test Connection

DataImport task

It is possible to troubleshoot if there is a connection between ObserveID and the Azure AD target.

n/a

Import Resource

n/a

n/a

Within the Azure AD integration, a resource of the Azure VM resource type can be converted into an individual integration if it will be recognized as being either a Windows, or a Linux machine.

Entitlement Management

Grant Account Entitlements

Permanent Access Request, Temporary Access Request, Manage Access, Role Creation, Role Update, Identities Update

The Azure AD integration can assign an account with an entitlement.

The Azure AD entitlements that can be assigned are: - AD Groups

  • AD Roles
  • RBAC Roles
  • Licenses directly, and\or within AD Groups
  • Exchange’s Distributed List Groups
  • Application Role

For a License to be available for assignment, the Provisioning Rule for Usage Location should be set.

A License can be provisioned to an Azure AD account with established property: - Usage Location

Revoke Account Entitlements

Manage Access, Role Update, Role Deletion, Identities Update

The Azure AD integration can revoke an entitlement from the account.

The Azure AD entitlements that can be revoked are: - AD Groups

  • AD Roles
  • RBAC Roles
  • License directly, and\or within AD Groups
  • Exchange’s Distributed List Groups
  • Application Role

Access Detection

Detect Access

Audit Log report type of Analytics

The Azure AD integration can help one track the user’s sessions on the Target.

600 is the default period in seconds for the Consider Session Closed parameter.

User sessions detected on the Azure AD target can be compiled into a report. The detected session records are provided with extra details:

  • system properties, such as: session ID, start\end time, account name, type, etc.
  • Azure-specific additional properties.

Azure-specific additional properties of the detected sessions are as follows: - LoginTo

  • ClientEmail
  • MFAUsed
  • TextLogEventType
  • ClientName
  • ManagerName
  • WorkgroupName
  • AccountType
  • ActivityDisplayName
  • ClientNetAddress
  • ManagerEmail
  • UserAgent

Detect Access Text Logs

Information generated by Azure AD API endpoint.

Azure AD provides log events for every detected session with the following json-data schema:

  • ActivityDateTime
  • ActivityDisplayName
  • AdditionalDetails
  • Category
  • CorrelationId
  • InitiatesBy
  • LoggedByService
  • OperationType
  • Result
  • ResultReason
  • TargetResources
  • Id
  • ODataType
  • AdditionalData

Single Sign-On

Authentication

ObserveID Login form

Given that the Azure AD integration is enabled as an SSO Source, Identities can log in to ObserveID with Azure user credentials.

Azure SSO uses OpenID Connect, which requires for the ObserveID application in the Azure portal, or the Microsoft Entra admin center, to be provided with the following: - Redirect URI

  • ID token

For more information on Azure SSO, refer to: Azure OIDC SSO configuration

Prerequisites

There are prerequisite activities that are required to be performed on the Azure portal before the Azure AD integration is configured on the ObserveID side. Below is a short overview of the prerequisites followed by a list of minimum permissions required for the integration to operate in the read-only mode or the read-write mode.

Prerequisite

Description

App registration

App registration results in creating an application object of ObserveID in Azure AD. It is used by ObserveID to interact with the Azure AD.

API permissions from Microsoft Graph API

The ObserveID application on Azure AD must be provisioned with API permissions from Microsoft Graph API. Below is the list of the minimum permissions for the integration to read and write data with the Azure target.

API permissions from Office 365 Exchange Online

Optional. In case the integration is expected to provision membership in Distribution Lists of Office 365 Exchange Online, then ObserveID application on Azure AD must be provisioned with API permissions from Office 365 Exchange Online. Below is the list of the minimum permissions for the integration to read and write data with the Exchange server.

Admin consent

Azure AD requires getting consent from the Administrator on granting the API permissions to the application of ObserveID.

Azure RBAC Role

Optional. The access to resources within a subscription is governed by Azure RBAC Roles. The ObserveID application on Azure AD should be assigned with RBAC roles in case the integration is expected to pull Azure resources among the integration data or provision users with access to the Azure subscription resources. The minimum required Azure RBAC Roles are specified in the list of Minimum Permissions below.

Azure AD Role

The access to the Active Directory resources, and if needed, the access to the Exchange server are governed by Azure AD Roles. The ObserveID application on Azure AD should be assigned with some roles, specified in the list of Minimum Permissions below.

Minimum permissions

The list of permissions presented in the table below specifies the minimum permissions needed to set up the integration in one of the following modes:

  • the read-only mode without any access provisioning, or

  • the read-write mode which allows one to make provisioning.

Permission type

Permission

Description

Microsoft Graph API permissions for read-only access
  • AuditLog.Read.All (Application)
  • Directory.Read.All (Application)
  • Group.Read.All (Application)
  • GroupMember.Read.All (Application)
  • Reports.Read.All (Application)
  • RoleManagement.Read.All (Application)
  • User.Read.All (Application)
  • UserAuthenticationMethod.Read.All (Application)

The service principal of ObserveID in the Azure Portal is expected to be provided with permissions in case of the read-only level of access.

Microsoft Graph API permissions for read-write access
  • AuditLog.Read.All (Application)
  • Directory.ReadWrite.All (Application)
  • Group.ReadWrite.All (Application)
  • GroupMember.ReadWrite.All (Application)
  • Reports.Read.All (Application)
  • RoleManagement.ReadWrite.Directory (Application)
  • User.ReadWrite.All (Application)
  • UserAuthenticationMethod.ReadWrite.All (Application)

The service principal of ObserveID in the Azure Portal is expected to be provided with permissions in case of the read-write level of access.

Microsoft Graph API permissions for Application Roles

Application.ReadWrite.All (Application)

The service principal of ObserveID in the Azure Portal is expected to be provided with the API permissions in case if it is needed to (de)provision Application Roles

Office 365 Exchange Online API permissions for DLs

Exchange.ManageAsApp (Application)

The service principal of ObserveID in the Azure Portal is expected to be provided with the API permissions in case if it is needed to (de)provision AD Groups of Distribution type, i.e. Distribution Lists.

Admin Consent

n/a

The API permissions added to the registered application of ObserveID in the Azure portal must have authorization from the Administrator.

Azure RBAC Role for read-only access

Reader

The registered application of ObserveID in the Azure portal, needs to be granted a RBAC Role to read and provision access to the Azure Subscription resources.

Azure RBAC Role for read-write access

Contributor

Azure AD Role for read-only access

n/a

The registered application of ObserveID in the Azure portal does not need any Azure AD Role to: - to do data import according to the schema without fetching RBAC entitlements.

Azure AD Role for read-write access

User Administrator

The registered application of ObserveID in the Azure portal, needs to be granted an Azure AD Role to be able to: - create accounts;

  • delete some accounts;
  • unlock \ lock accounts;
  • provision entitlements of such permission types as:
    • AD Group;
    • App Roles;
  • update credentials.

Privileged Authentication Administrator

The registered application of ObserveID in the Azure portal, needs to be granted an Azure AD Role to be able to: - delete all accounts.

Privileged Role Administrator

The registered application of ObserveID in the Azure portal, needs to be granted an Azure AD Role to be able to: - provision entitlements of such permission types as: - AD Roles.

Attribute Assignment Administrator

The registered application of ObserveID in the Azure portal, needs to be granted an Azure AD Role to be able to: - if needed, to assign, edit and delete attribute assignment to user.

Privileges to access Exchange Online

For managing Distributed List and Mail-Enabled security Groups from Exchange Online environment in in Microsoft 365, the privileges include:

  • Any of the following licenses:
    Microsoft 365 for business
    Microsoft 365 for enterprise
    a standalone Exchange Online plan
  • API permission from Office 365 Exchange Online API: Exchange.ManageAsApp
  • AD Role: Exchange Administrator

For more information on the setup of the connection to Exchange Online, see: App-only authentication in Exchange Online PowerShell and Security & Compliance PowerShell | Microsoft Learn

The registered application of ObserveID in the Azure portal, must be granted these permissions in case if Exchange’s Distribution Groups need to be managed.

API Permissions of a registered app in the Azure portalAPI Permissions of a registered app in the Azure portal

Setup of integration

The connection parameters specified below must be populated in ObserveID for the Universal Connector to connect to the Azure AD as a Target. The connection parameters are established in: ObserveID > Identity Automation > Integrations > {specific AzureAD integration} > Details.

Azure integration configAzure integration config

Connection parameter

Description

Environment Type

Environment the new integration pertains to. The Na option establishes no environment.

Integration Name

Automatically generated name for the new integration. The name is created by combining the Integration Type with what is established as Environment Type, Alternate Name, and Description for the new integration.

Alternate Name

Any preferred name for the new integration.

Description

Any valid text to differentiate one integration from another. This text is displayed in addition to the integration name in several UI elements, e.g., dropdown lists, in the system.

Client Id*

Client ID generated by the Azure Active Directory for the service principal of ObserveID application in the Azure portal.

Client Secret*

Client secret generated for the service principal of ObserveID application in the Azure portal.

Tenant Id*

Directory (Tenant) ID specified for the service principal of ObserveID application in the Azure portal. And this is the tenant from which the users will be imported to ObserveID as part of the Azure AD Integration Data.

Login URL*

The URL should be the one Identities will use to log in to Azure. E.g: https://portal.azure.com

UC Managed Shell User Name*

The user name of the account that will be created on one of the Azure resources in case if the resource is imported as a shell. For uniqueness purposes the user name can be added with an incremented number at the end in case if it already exists.

IP Address for Windows Import Shell

The IP address of the Universal Connector machine. It will be set for the WinRM service on the target machine (i.e. a Windows VM running on the Azure cloud) to allow inbound connections from the UC.

Should Import Resource-Based Access Control Policies

If enabled, the data import fetches RBAC entitlements from the Azure target. If disabled, the data import fetches everything in line with the schema, except RBAC entitlements.

Configure Win Rm for Windows

If enabled, configures the WinRM service on a Windows VM running on the Azure cloud. The WinRM service should be configured to import the Windows target as one of the shells on the Azure cloud. The configuration of WinRM includes: the start of the WinRM service, the specification of the IP address of the UC’s VM among trusted hosts on the Windows VM, and creating an allowed outbound connection rule on the Firewall for a specific port.

Should Setup Win Rm Over Https for Windows Import Shell

If enabled, the WinRM service on the Windows VM is enforced to communicate over HTTPS protocol. In this case, the respective HTTPS certificate is needed to be available on the Windows VM.

Consider session closed if no action for seconds.

Timeout in seconds that determines when the Universal Connector should generate the closed session event to mark the end of an active session due to the absence of any activity detected on the target. The default value for the Oracle integration is 600.

Once the Details are filled out, remember to click Save. And then to click Test Connection. Both should be successful. Otherwise, use the Access Log to troubleshoot the configuration.

First load of data

After the connection parameters are established for Azure AD in ObserveID, and the connection test is successfully completed, next is the first load of data. It allows the systems to set up an initial point starting from which it is possible to determine and synchronize deltas later. For what data is loaded, refer to the schema of Azure AD integration data.

There is a DataImport task that is used to perform the first load, as well as other data imports since then.

The DataImpor task is created for the Azure AD integration automatically when the integration gets saved. However, if anything, it is possible manually to create a DataImport task in:

  • ObserveID > Identity Automation > Requests > Tasks

The DataImport task is considered finishing successfully, if the integration data (i.e. accounts, entitlements, resources, and additional properties) is imported and shows up for the Azure AD integration in ObserveID.

Integration Rules

By C#-coding the integration rules, the functional capabilities of the Azure AD integration become ad-hoc configured to meet the requirements of a specific business case. In addition to flexibility, an important factor of the data management is the possibility to make it consistent across multiple systems in the organization infrastructure. The integration rules help to determine identity data in relation to the Azure AD integration.

Below with the code samples and the Dependable variables \ parameters presented are the examples of how the integration and identity data can be defined.

Functional area

Integration Rules

Description

Dependable variables \ Parameters

Identity correlation

Correlation Rule

With the Name property being mandatory for an account and having the format of an email address, it can be compared with the email address of an Identity and thus, utilized for the correlation rule, unless business-driven needs require otherwise. The correlation establishes the Identity as the owner of an account.

Account’s Name; Identity’s Email

Differentiating accounts by type

Customization Rule

Given that Azure AD uses the Name property as an internet-style login name, this property can also be used for differentiating the accounts by the type.

Account’s Name

Account Creation

Provisioning Rules

Provisioning Rules set additional properties for the Azure AD accounts created or updated in ObserveID. The following additional properties of an Azure AD account are set with the Provisioning Rules:

  • Name
  • Display Name
  • Usage Location
  • Alternate Email
  • Business Phones
  • City
  • Company Name
  • Country
  • Department
  • Fax Number
  • E-Mail
  • Employee ID
  • Given Name
  • Job Title
  • Mobile Phone
  • Office Location
  • Postal Code
  • State
  • Street Address
  • Surname
  • User Type

Code samples are provided in the next sections for some of the Provisioning Rules.

Identity’s Name

Identity Termination

Leaver Rule

Azure AD integration has no constraints on how the accounts should be deprovisioned in case of the termination of an Identity. And all Leaver Rule options are applicable. The Leaver Rule defines how to treat the Azure AD accounts if an Identity gets terminated.

A code sample of the Leaver Rule is presented in the next sections. And to change one option into another, it is enough to set the needed value for the object: AccountTerminationBehavior.
  • .LockAndRemoveAllEntitlements
  • .Delete
  • .Lock
  • .TransferOwnership
  • .DoNothing