One Identity Active Roles · 2020-02-19 · Azure AD domain: rd4.qsftdemo.com Azure AD Connect:...

1

One Identity Active Roles

Azure AD, Office 365, and Exchange Online

Management

Version 1.0

One Identity Active Roles | Azure AD, Office 365, and Exchange Online Management

Version History Date Version Explanation of Change

8/21/2019 0.1 Initial Draft

9/20/2019 0.2 Restructured the white paper content into a template

10/14/2019 0.3 Updated white paper to include back synchronization content

10/21/2019 0.4 Finalized the white paper content

11/04/2019 1.0 Finalized content for 1.0 version

Table of Contents 1. Introduction ...................................................................................................................................................................... 3

2. Active Roles and supported Azure environments............................................................................................................. 4

3. Azure object management supported in various Azure environments ............................................................................ 5

4. Azure Object management in a Non-Federated environment ......................................................................................... 6

5. Azure Object Management in Federated and Synchronized Identity environments ....................................................... 7

6. Azure object management flow charts ............................................................................................................................. 8

3

1. Introduction Active Roles (formerly known as ActiveRoles®) is an administrative platform that facilitates administration

and provisioning for Active Directory, Exchange, and Azure Active Directory (Azure AD) in a hybrid

environment. Active Roles allows the organization to manage through the Web Interface and to develop a

flexible administrative structure that suits their needs while ensuring secure delegation of tasks as well as

reduced workloads and lower costs.

Active Roles enables synchronization of the on-premises Active Directory objects to Azure AD. It also allows

you to create Microsoft Office 365 cloud users, groups, and contacts for your on-premises Active Directory

users, groups, and contacts that allows their properties to be synchronized from Active Roles to the cloud.

This section provides detailed information on the Azure AD operations.

The Office 365/Azure AD capabilities of Active Roles support the following administrative tasks:

Create an Office 365 user account associated with a given Active Directory user account.

Synchronize user properties from Active Directory user accounts to their associated Office 365 user

accounts.

View or change the properties of the Office 365 user account associated with a given Active Directory

user account.

Assign Office 365 licenses to the Office 365 user account associated with a given Active Directory user

account.

Delete the Office 365 user account associated with a given Active Directory user account.

Create an Office 365 security group or distribution group associated with a given Active Directory

group.

Synchronize group properties, including the member’s list, from Active Directory groups to their

associated Office 365 groups.

View or change the properties of the Office 365 group associated with a given Active Directory group.

Delete the Office 365 group associated with a given Active Directory group.

Create an Office 365 external contact associated with a given Active Directory contact.

Synchronize contact properties from Active Directory contacts to their associated Office 365 external

contacts.

View or change the properties of the Office 365 external contact associated with a given Active

Directory contact.

Delete the Office 365 external contact associated with a given Active Directory contact.

View Office 365 domain and license information.

Create Office 365 users. When you create an Office 365 user, you can choose whether to license that

user for Exchange Online.

Create security groups and distribution groups in Office 365. You can choose the type of Office 365

group that you want to create.

Assign licenses to Office 365 users. When creating or administering a user, you can choose the Office

365 licenses that you want to assign to that user.

Restrict the licenses for Office 365 users. You can configure a policy to specify what Office 365 licenses

can be assigned depending on user location in Active Directory.

View or change the Office 365 specific object properties. You can edit Office 365 users, groups, and

contacts.

Examine Office 365 licenses and license usage. For each of your license subscriptions, you can view

how many licenses are valid, expired, assigned, and available. This information is displayed on the

Azure License Report in Azure Configuration.

Examine Office 365 domains. Azure Domains are listed in Azure Domains in Azure Configuration.


Associate existing Office 365 users with on-premises Active Directory users. This can be achieved using

the back-synchronization workflow by mapping an existing Office 365 user to the appropriate on-

premises Active Directory user and updating its Azure ObjectID in Active Roles.

2. Active Roles and supported Azure environments This section explains the different types of Azure environment configurations supported by Active Roles and

examples of each configuration. Active Roles supports the following Azure environment configurations.

2.1 Non-Federated

An environment in which the on-premises domains are not registered in Azure AD and Azure AD Connect,

or any third-party synchronization tools that are not configured in the domain for synchronization, is

called a Non-Federated environment. The changes made in Active Roles are immediately replicated to

Azure or Office 365 using Graph API calls or cmdlet calls. Users are typically created in Azure with the

onmicrosoft.com UPN suffix. It is less likely to have this type of environment in production, and it can be

used only for testing.

Examples of Non-Federated configuration:

On-premises domain: test.local

Azure AD domain: ARSAzure.onmicrosoft.com

Azure AD Connect: Not present in the domain

The domain is not registered in Azure. The user is created in Active Roles with an ID,

[email protected], and in Azure as [email protected].

The user is created in Azure simultaneously when it is created in Active Roles using a Graph API call.

Synchronized Identity In a Synchronized Identity, the on-premises domain may or may not be registered in Azure AD. Here,

Azure AD Connect is configured to synchronize the local AD objects to Azure. Users may typically be

created with selected on-premises domains or an onmicrosoft.com UPN suffix.

Examples of Synchronized Identity configuration

On-premises domain: test.local

Azure AD domain: rd4.qsftdemo.com

Azure AD Connect: Performs the synchronization task.

The on-premises domain may or may not be registered in Azure. The user will be created in Active

Roles with the [email protected] ID and in Azure as [email protected].


2.2 Federated In a Federated environment, the on-premises domain is registered in Azure AD. Azure AD Connect and

ADFS are configured to facilitate synchronization. Users are typically created with the UPN suffix of the

selected on-premises domain.

Examples of Federated configuration:

On-premise domain: rd4.qsftdemo.com

Azure AD domain: rd4.qsftdemo.com

Azure AD Connect and AD FS are configured.

The domain is registered and verified in Azure. The user is created in Active Roles and Azure AD with

the same id: [email protected].

3. Azure object management supported in various Azure

environments

This section provides information about the supported operations and methods for performing the

operations for Azure objects in various Azure environments using the Active Roles Web Interface, such

as Federated, Synchronized Identity, and Non-Federated environments.

In the Active Roles Web Interface, you can select the required Azure environment configuration during

the Azure tenant creation. The specified configuration can be modified later if needed by changing the

Azure properties of the tenant. Active Roles identifies the environment based on the Azure Tenant type

and applies the changes to the Web Interface.

Active Roles uses different technologies such as Graph API and Exchange Online cmdlets to work with

O365/Azure/Exchange Online. The Graph API (Unified Graph/Azure AD Graph) does not provide WRITE

capability for certain attributes in the Federated and Synchronized Identity environment. To be

consistent with the behavior of the Microsoft API in Active Roles, we have intentionally disabled these

property fields in the Web Interface. These fields cannot be manually enabled. However, Microsoft allows

certain Exchange Online attributes to be modified using Exchange Online cmdlets in Federated and

Synchronized Identity environments. These property fields are editable in the Active Roles Web Interface

in the Exchange Online property wizard.

In a Non-Federated environment, there is no restriction for Graph API or Exchange Online cmdlets to

perform any of the operations. For this reason, in the Active Roles Web Interface, all the property fields

are editable and can be modified.

More capabilities like Office 365 License assignment, Roles assignment can be performed for Azure

users in Active Roles web interface.


To perform this, separate tabs with list of licenses and roles are available during new Azure user

creation and modification.

Note: In case of Office 365 Roles not getting listed in the Web Interface, Use below commands to

enable directory roles against your tenant

$psCred=Get-Credential

Connect-AzureAD -Credential $psCred

roleTemplate = Get-AzureADDirectoryRoleTemplate | ? { $_.DisplayName -eq "Directory Writers" }

# Enable an instance of the DirectoryRole template

Enable-AzureADDirectoryRole -RoleTemplateId $roleTemplate.ObjectId

In the above example, the Directory Writers role is enabled. To get the list of Office 365 Roles, use the

following command:

$psCred=Get-Credential Connect-AzureAD -Credential $psCred Get-AzureADDirectoryRoleTemplate

4. Azure Object management in a Non-Federated

environment A Non-Federated environment is generally used for testing purposes. In a Non-Federated environment,

most of the Azure properties can be modified, other than attributes such as UserPrincipalName and

ObjectId that identify the object uniquely.

The following table provides information about the operations and methods of operation that can be

performed on Azure Objects in a Non-Federated environment.

Object Operation Non-Federated : Method

User Create Using GRAPH API

Read Using GRAPH API and Exchange Online Command-lets

Update Using GRAPH API and Exchange Online Command-lets

Delete Using GRAPH API

Security Group

Create Using GRAPH API

Read Using GRAPH API

Update Using GRAPH API


Mail Enabled Security Group

Create Using Exchange Online Command-lets




Distribution Group Create Using Exchange Online Command-lets





Native Office 365 Group (Cloud-only*)





Contacts

Create Using Exchange Online Command-lets


Update Using Exchange Online Command-lets


*Active Roles provides cloud-only support only for O365Groups management.

5. Azure Object Management in Federated and Synchronized

Identity environments Synchronization methods are applicable only in Synchronized and Federated environments, and AAD

Connect is used to perform the synchronization. An Azure Non-Federated environment does not require

synchronization, and direct GRAPH API calls are used to make the Azure or Office 365 object

management.

Object Operation Commands Tabs Federated/Synchronized : Method

User Create Created by GRAPH API

Read Using GRAPH API and Exchange Online Command-lets

Update

Azure properties

Identity Synced using AAD Connect

Settings Using GRAPH API

Job Info Synced using AAD Connect

Contact Info Synced using AAD Connect

Licenses Using GRAPH API

O365 Admin Roles

Using GRAPH API

OneDrive Created by OneDrive Policy using PowerShell cmdlets

Exchange Online properties

Mail flow Settings

Using Exchange Online cmdlets

Delegation Using Exchange Online cmdlets


Email Address Synced using AAD Connect

Mailbox Features

Using Exchange Online cmdlets

Mailbox Settings Using Exchange Online cmdlets


Security Group

Create Created in Azure, Back Synchronized to Active Roles, Synced using AAD Connect


Update Synced using AAD Connect


Mail Enabled Security Group

Create Created in Azure, Back Synchronized to Active Roles, Synced using AAD Connect


Update Synced using AAD Connect


Distribution Group

Create Created in Azure, Back Synchronized to Active Roles, Synchronized using AAD Connect


Update Synchronized using AAD Connect


Native Office 365 Group(Cloud-only*)





Contacts

Create Synchronized using AAD Connect


Update Synchronized using AAD Connect


Note:

* Active Roles provides cloud-only support only for Native Office 365 Group management.

Synced using AAD Connect referenced in the table specifies that the object operation is

initially performed on the on-premise object. After a Microsoft Azure AD Connect

synchronization cycle, the object is updated in Azure AD or Office 365.

For more information on how to perform Back-Sync operation refer Active Roles Configuration

to synchronize existing Azure AD objects to Active Roles in the Active Roles Administration

Guide.

6. Azure object management flow charts 6.1 Create Azure user

1. Configure the Azure Tenant and application though Active Roles Web Interface. Consent must be

requested through the application.


2. Apply the Azure policy on the container where Azure users are going to be provisioned and set the

edsvaAzureOffice365Enabled virtual attribute to TRUE on the container.

Note: Check the All child organizational units

(edsvaAzureOffice365EnabledIncludeChildOUs) attribute as applicable.

3. Make sure that the userPrincipalName suffix is set appropriately (most likely edsaUPNSuffix)

o The new user gets created in the on-premises Active Directory.

o On successful creation of the on-premises AD User, the user gets created in Azure.

o Populate edsaAzureUserUsageLocation to the appropriate value.

o The Built-in Policy - Azure - Default Rules to Generate Properties populates the following

required attributes: edsaAzureUserUPNPrefix, edsaAzureUserPassword,

edsaAzureUserDisplayName, edsaAzureUserAccountEnabled, edsaAzureUserGivenName, eds

aAzureUserSurname, and edsaAzureUserUsageLocation.

o Additional attributes for group and contact are: edsaAzureGroupDisplayName,

edsaAzureGroupDescription, edsaAzureContactDisplayName.

o All the licenses subscribed are present in edsaAzureSubscribedSkus and are available for

assignment on the license assignment page in the Web Interface.

o Office 365 roles can be assigned to the user from the Office 365 Roles tab.

4. In the Federated/Synchronized Identity environment, the on-premises user’s ObjectId is read and

used to set Azure AD user’s ImmutableId property. (The native sync tool also does the same.)

Once the user in Azure AD is created, the Azure object’s ID is also set into the Active Roles

edsvaAzureObjectId virtual attribute so that Active Roles can talk to the Azure AD object, as shown

in the following flowchart.



6.2 Azure Group creation (Distribution and Mail Enabled Groups)

1. Configure Azure Tenant and the application through the Active Roles Web Interface. Consent must be


2. Apply the Azure policy to the container where Azure groups will be provisioned and set the

edsvaAzureOffice365Enabled virtual attribute to TRUE on the container.

Note: Check the All child organizational units

(edsvaAzureOffice365EnabledIncludeChildOUs) attribute as applicable.

3. In a Non-Federated environment, for Group creation, provide the group name (cn) and choose the

desired Group Type from the selections provided.

o The new Group gets created in the On-Premises Active Directory.

o Upon successful creation of the On-Premises AD Group, the Group is provisioned in Azure by

Active Roles.

o edsaAzureGroupDisplayName, edsaAzureGroupDescription are validated with the built-in-

policy.

o Universal Distribution groups and Mail Enabled security groups are created with the

Exchange online cmdlets by connecting to a remote PowerShell

(https://outlook.office365.com/PowerShell-LiveID) using the same credentials as configured

in the tenant through the Web Interface.

The ObjectID attribute of the group in Azure is mapped to the edsaAzureObjectId

attribute of the group in Active Roles.

o Normal Security groups are created using the Graph API call.

4. In a Federated/Synchronized Identity environment, creating Azure Groups is not allowed. The Group

created on-premise will be synced to Azure using Microsoft Azure AD Connect. Back Synchronization

operation has to be performed to associate the above synchronized groups in Azure to the Active

Roles and further manage it from the Web Interface.

https://outlook.office365.com/PowerShell-LiveID



6.3 O365 Groups creation 1. Configure Azure Tenant and the application through the Active Roles Web Interface. Consent must

be requested through the application.

2. Upon successful Azure configuration, a new container with the name of the configured tenant

appears under the Azure link in Views.

3. O365 Groups can be created in the Office 365 Groups container under the Azure link.

4. edsaAzureGroupDisplayName, mailNickName (Alias), and Description must be provided to

create an O365 group.

5. A Graph API call is used to create a new Office 365 group in Azure (https://graph.microsoft.com/).

6. The AzureO365Groups table in the configuration database is updated to reflect any changes made

to the Office 365 Groups (CRUD).

Note: The schedule task Sync Azure O365 Groups runs to sync groups from Azure to Active

Roles.

https://graph.microsoft.com/


6.4 Azure Contact creation

1. Configure Azure Tenant and application though the Active Roles Web Interface. Consent must be


In a Non-Federated environment, For Azure contact creation: Apply the Azure policy on the

container where Azure contacts are going to be provisioned and set the

edsvaAzureOffice365Enabled virtual attribute to TRUE on the container. Check the All child

organizational units (edsvaAzureOffice365EnabledIncludeChildOUs) attribute as applicable.

Make sure that the contact name and external email address are provided.

The new contact is created in the on-premises Active Directory.


Upon successful creation of the on-premises AD contact, the contact is provisioned in Azure

by Active Roles.

edsaAzureContactDisplayName is validated using Built-in Policy - Azure - Default

Rules to Generate Properties.

Azure Contacts are created using the Exchange online cmdlets by connecting to a remote

PowerShell (https://outlook.office365.com/PowerShell-LiveID) using the same credentials as

configured in the tenant through the Web Interface.

The ExternalDirectoryObjectId attribute of the contact in Office 365 is mapped to the

edsaAzureObjectId attribute of the contact in Active Roles.

2. In the Federated/Synchronized Identity environment, creating an Azure Contact is not allowed. The

Contacts are created in on-premise AD and is synchronized to Azure using Microsoft Azure AD

Connect. Back Synchronization operation has to be performed to associate the above synced contacts

in Azure to Active Roles and further manage it from the Web Interface.

https://outlook.office365.com/PowerShell-LiveID



6.5 Exchange Online properties

1. Exchange PowerShell Run space connection is made to execute the exchange cmdlets

(https://outlook.office365.com/PowerShell-LiveID).

2. A check is made to see if ExchangeGuid exists. Then the Azure user is assigned an Exchange

online mailbox.

3. The Exchange Online Properties command in the Active Roles Web Interface shows the Exchange

Online properties from the Azure portal.

4. Any modify operation in the Exchange Online Properties wizard is reflected in the Azure portal, as

well.



6.6 Active Roles Azure policies 6.6.1 Office 365 License retention

Configure and enforce the policy on the container.

Upon successful deprovision of the Azure user, the licenses configured through the policy are

not removed from the user and remain assigned to the deprovisioned user.


6.6.2 Office 365 License management

Create an Office 365 License Management provisioning policy and apply it on the container.

The license can be assigned to an Azure user at the time of creation or modification operation.

You can select any number of licenses as part of the policy. When creating or modifying an

Azure user, if the licenses are not selected as per the applied policy, it leads to a policy violation

and the license assignment will fail.


6.7 OneDrive provisioning

6.7.1 OneDrive Create or Modify Create and configure the OneDrive provisioning policy and apply it on a container as follows:

1. Upon creation of an Azure user in the container as described in the previous section, the user is

provisioned with OneDrive as per the policy parameters. A OneDrive URL and storage quota will

be allocated to that user.

2. Upon modification of the user properties, if there is any change in the OneDrive policy parameters,

the user will be reapplied with the changed policy parameters.


6.7.2 OneDrive Scheduled Task OneDrive Scheduler is a synchronization tool that runs on a set of users or users under an OU as per the

policy conditions. It checks each user and verifies if the user has OneDrive set as per the policy

parameters. This is a synchronization mechanism that can be scheduled at the user’s convenience.


6.8 Remote Mailbox management 6.8.1 Hybrid environment with Remote Mailbox creation

1. Create an Azure User Account with Active Roles.

2. Exchange server should be installed in the domain and the Azure user should be assigned an Exchange Online

license. The user should also be mail-enabled and not have an Exchange on-premises mailbox.

3. The ExchangeGuid of the Exchange online user is fetched and populated in the on-premises ExchangeGuid to

communicate with the Azure cloud user through AAD Connect. 4. The Exchange Online Get/Modify properties remain the same.



6.8.2 Remote mailbox for existing users

In Active Roles, you can create a remote mailbox for existing users with the Automation workflow. The exact

data flow for creating a remote mailbox for an existing on-premises user is based on the user’s mailbox state

(migrated/non-migrated mailboxes, mail-enabled users, and so on).

To create a remote mailbox, certain actions must be taken based on the user’s mailbox state. You can easily

achieve this using the Active Roles Automation workflow where Active Roles allows interactions with O365

sessions and Exchange.

To make the process easy, Active Roles has a built-in sample workflow and a sample script that you can copy

and modify based on your environment. The default remote mailbox workflow and script help create the

remote mailbox for users with an Exchange mailbox with no on-premises existence.

Workflow: RemoteMailbox

1. O365 script execution configuration. You can provide the configuration related options here.

2. SearchAzureUsers. As this is an automation workflow, you need to filter the users on which the

workflow is applied, so that users can edit the search filters based on their requirements.

3. Run Script RemoteMailbox. This step will run the remotemailbox.ps1 script against all the filtered

users from the above step.

Script: RemoteMailbox

1. The customer must edit the Exchange-related information in the script.

2. The script contains two functions: EnableRemoteMailbox() and DisableRemoteMailbox().

3. The script performs the actions based on the function specified in the workflow activity.

4. In EnableRemoteMailbox():

An exchange session is created based on the credentials provided.

Iterate through all the users in the search scope.

Check if the user contains the Exchange online mailbox.

Check if the user has an on-premises existence.

o If not, enable the remote mailbox.

o If so, the customer should edit the script based on their requirements (an example is

given in the script).

5. In DisableRemoteMailbox():

This loops through all the users in the search scope and disables the remote mailbox.



6.9 Active Roles Configuration to synchronize existing Azure AD objects to

Active Roles

In any hybrid environment, on-premises Active Directory objects are synchronized to Azure AD using some

means such as Azure AD Connect. When Active Roles is deployed in such a hybrid environment, the

existing users and groups' information, such as Azure objectID, must be synchronized back from Azure AD

to on-premises AD to continue using the functionality. To synchronize existing AD users and groups from

Azure AD to Active Roles we must use the back-synchronization operation.

The back-synchronization operation can be performed automatically or manually using the Active Roles

Active Roles Synchronization Service Console.

6.9.1 Configuring Sync Workflow to back-synchronize Azure AD Objects to Active

Roles automatically

The Azure Backsync Configuration feature allows you to configure the backsync operation in Azure with on-

premises Active Directory objects through the Synchronization Service Console.

The hybrid environment must have Azure AD Connect installed and configured.

The user account used to perform Back sync configuration must have the following privileges:

User Administrator

Privileged Role Administrator

Exchange Administrator

Application Administrator

Configure Azure Backsync in Active Roles Synchronization Service from settings with the valid Active

Roles account details and Azure domain valid Account ID credentials.

BackSync operation will register Azure application and required connections, mappings, and workflow steps

will be created automatically.

The Forward Sync Rules to synchronize the following are automatically configured and displayed in the

synchronization update steps for user and group:

Azure ObjectID property of a user or group is mapped to the Active Roles user or group

edsvaAzureObjectID property.

The edsvaAzureOffice365Enabled attribute in Active Roles user or group is set to True.

The Forward Sync Rule to synchronize the following are automatically configured and displayed in the

synchronization update steps for contacts:

Azure ExternalDirectoryObjectID property of a contact is mapped to the Active Roles contact

edsaAzureContactObjectId property.

The edsvaAzureOffice365Enabled attribute in Active Roles user or group is set to True.



6.9.2 Configuring Sync Workflow to back-synchronize Azure AD Objects to Active

Roles manually

Manual Back Synchronization is performed by leveraging the existing functionality of Synchronization

Service component of Active Roles. Synchronization workflows are configured to identify the Azure AD

unique users, groups and contacts and map them to the on-premises AD users, groups and contacts. After

the back-synchronization operation is completed, Active Roles displays the configured Azure attributes for

the synchronized objects.

The hybrid environment must have Azure AD Connect installed and configured.

Synchronization Service Component must be installed and configured for Active Roles.

Azure AD configuration and the Administrator Consent for Azure AD application through web

interface must be complete.

Azure AD built-in policy must be enforced and the attribute edsvaazureOffice365enabled must be

set to true for the container where the back-synchronization is performed.

To configure sync workflow to back-synchronize perform the following steps:

1. Create Connection to Office 365 in the hybrid environment

2. Create Connection to Active Roles in the hybrid environment

3. Create Sync Workflow 4. Create a Sync Workflow using the Office 365 and Active Roles connections. Add a Synchronization

step to Update Office 365 Contacts to Active Roles Contacts. Configure the Forward Sync Rule to

synchronize the following:

o Azure ExternalDirectoryObjectId property of a contact to the Active Roles contact edsaAzureContactObjectId

property.

o Set the edsvaAzureOffice365Enabled attribute in Active Roles contact to True.

5. Create Mapping

Create a Mapping Rule, which identifies the contact in Office 365 and on-premises AD uniquely and map

the specified properties from Office 365 to Active Roles appropriately.


Date post:	22-May-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times

One Identity Active Roles · 2020-02-19 · Azure AD domain: rd4.qsftdemo.com Azure AD Connect:...

Documents