automation-suite
2024.10
true
UiPath logo, featuring letters U and I in white
Automation Suite Admin Guide
Last updated Nov 11, 2024

Setting up the Azure AD integration

If your organization is using Azure Active Directory (Azure AD) or Office 365, you can connect your Automation Suite organization directly to your Azure AD tenant to see existing accounts and groups in your Automation Suite environment.

With Azure AD integration, you can continue leveraging the local accounts model, while bootstrapping your organization with the additional benefits of using the Azure AD model. The Azure AD integration is designed such that activating it and rolling it out can happen gradually, with no disruption in production for your existing users.

If your organization has decided to use the Azure AD model, follow the instructions on this page to set up the integration.

Prerequisites

To set up the Azure AD integration, you need:

  • Admin permissions in both Automation Suiteand Azure AD (can be different people);
  • an Azure AD account with the same email address as the UiPath local account of the organization administrator who carries out the integration. Note that this Azure AD account is just for testing the integration and does not need to have admin permissions in Azure;
  • UiPath Studio and UiPath Assistant version 2020.10.3 or later;
  • UiPath Studio and UiPath Assistant to use the recommended deployment.

  • if you previously used local user accounts , make sure that all your Azure AD users have the email address in the Mail field; having the email address in the User Principle Name (UPN) field alone is not enough. The Azure AD integration links directory user accounts with the local user accounts if the email addresses match. This allows users to retain permissions when they transition from signing in with their local user account to the Azure AD directory user account.

Note: UiPath obeys the OIDC protocol for its integration with Azure AD. However, the integration does not support usage of application custom keys through claiming an appid query parameter in a dedicated URL, as described in Microsoft's access tokens documentation.

Configuring Azure for the integration

Your organization requires an app registration in your Azure AD tenant and some configuration so that it can view your AD members to establish account identity. The app registration details are also required to later connect your organization to your Azure AD tenant.

Permissions: You must be an administrator in Azure to perform the tasks in this section. The following Azure administrator roles have the required privileges: Global Administrator, Cloud Application Administrator, or Application Administrator.

There are two ways to set up your Azure tenant for the integration:

  • Follow the instructions below to manually configure an app registration for the integration.
  • Use the UiPath Azure AD scripts that we created for this task, which are available on GitHub: The configAzureADconnection.ps1 script performs all the actions described in this section and returns the app registration details. Then you can run the testAzureADappRegistration.ps1 script to make sure the app registration was successful.

To manually configure your Azure tenant, do the following in Azure Portal:

  1. Create an app registration for Automation Suite. For details, see Microsoft's documentation about Registering an application.
    During registration, select Accounts in this organizational directory only and set the Redirect URI to https://{yourDomain}/identity_/signin-oidc.
    Note: If you already have a registered application for your organization, there is no need to create a new one, but make sure that it is set up as described above.
  2. Open the application's Overview page, copy the Application (client) ID and Directory (tenant) ID, and save them for later use:


  3. Go to the Authentication page of your app:
    1. Under Redirect URIs, click Add URI to add a new entry.
    2. Add https://{yourDomain}/portal_/testconnection to the Redirect URIs list.
    3. At the bottom, select the ID tokens checkbox.
    4. Click Save.
    docs image
  4. Go to the Token configuration page.
  5. Select Add Optional Claim.
  6. Under Token type, select ID.
  7. Select the checkboxes for family_name, given_name, and upn to add them as optional claims:


  8. Go to the API permissions page.
  9. Click Add permission and add the following delegated permissions from the Microsoft Graph category:
    • OpenId permissions - email, openid, offline_access, profile;
    • Group member permissions - GroupMember.Read.All;
    • User permissions - User.Read, User.ReadBasic.All, User.Read.All (requires administrative consent).


    Permission

    What it allows you to do

    What we do with it

    email, openid, profile, offline_access, User.ReadAllows AAD to issue a user token to the system applicationAllow users to log into the system using an AAD login. This permits us to keep our user object updated, ensuring consistency of these attributes.
    User.ReadBasic.AllReads basic properties of all users in the directory that the logged in user is allowed to seeWhen a user assigns permissions to other users in the directory to their resources, they are able to search these users. The functionality for access management/authorization are in the system user experience.
    User.Read.All (requires admin consent) Reads all user properties in the directory that the logged in user is allowed to seeYour administrator may want to import these additional user properties to configure permissions or display custom information inside the system services. For Automation Hub, customers looking to obtain the full set of attributes from AAD, it is necessary to grant the User.Read.All permission to the app.
    GroupMember.Read.AllReads the group memberships of all the users that the signed in user has access toIf your organization is using groups to manage permissions in the system, then the platform needs to be able to list all the groups and discover the members of a group; that allows both management and enforcement of group assigned permissions.
  10. Select the Grant admin consent checkbox.
    Note: The administrator consents on behalf of all users in the tenant active directory. This allows the application to access the data of all users, without users being prompted to consent. For more information about permissions and consent, see Microsoft's Azure AD documentation.
  11. Go to the Certificates & secrets page.
  12. Create a new client secret. For more information, see Microsoft's documentation about Adding a new client secret.
    Note: The created client secret is not permanent. You must update the client secret after its validity period.
  13. Copy the client secret Value and save it for later use.


  14. Share the Directory (tenant) ID, Application (client) ID, and Client Secret values with the organization administrator so that they can proceed with the configuration.

Deploying the integration to Automation Suite

After Azure setup is complete, you can prepare for the integration, activate it, and then clean up old accounts. The process is broken down in stages so that there is no disruption for your users.

Note:

You must be an organization administrator in Automation Suite to perform the tasks in this section.

Clean up inactive users

When you connect Automation Suite to Azure AD by activating the integration, accounts with matching email addresses are linked, so that the Azure AD account benefits from the same permissions as the matching UiPath local account.

If your organization practices email recycling, meaning that an email address that was used in the past could be assigned to a new user in the future, this could lead to a risk of elevated access.

Let's say you once had and employee whose email address was john.doe@example.com and this employee had a local account where he was an organization administrator, but has since left the company and the email address was deactivated, but the user was not removed.
When a new employee who is also named John Doe joins your company, he receives the same john.doe@example.com email address. In such a case, when accounts are linked as part of the integration with Azure AD, John Doe inherits organization administrator privileges.

To prevent such situations, make sure you remove all users who are no longer active from the Automation Suite organization before proceeding to the next step. You can skip this step if inactive email addresses are not reused in your organization.

Activate the Azure AD integration

Note:

Before you begin:

  • make sure that Azure configuration is complete;
  • obtain the Directory (tenant) ID, Application (client) ID, and Client Secret values for the Automation Suite app registration in Azure from your Azure administrator.
To activate the Azure AD integration, follow these steps in Automation Suite
  1. Go to Admin and, if not already selected, select the organization at the top of the left pane
  2. Select Security to open security settings.
  3. On the Authentication Settings tab, select Configure SSO.
    docs image
  4. Select Azure Active Directory from the SSO configuration panel.


  5. Fill in the fields with the information received from your Azure administrator.

  6. Select the checkbox for I understand & accept added users and Azure AD users with matching email addresses will have their accounts linked. After you save your changes, matching accounts are automatically linked.​
  7. Select Test Connection to validate the integration has been configured correctly.
  8. When prompted, sign in with your Azure AD account.
    A successful sign in indicates that the integration has been configured correctly.In case it fails, ask your Azure administrator to check that Azure is correctly configured and then try again.
  9. Select Save to activate the integration for your organization.
  10. Sign out.
  11. Navigate to the organization URL (https://{yourDomain}/organizationID/) and sign in using your Azure AD account.

Now you can work with the users and groups in the linked tenant's Azure AD. Directory accounts and groups are not listed in either the Users or Groups pages under Admin > Accounts & Groups, you can only find them through search.

Test the Azure AD integration

To check that the integration is running, sign in as an organization administrator with an Azure AD account and try to search for Azure AD users and groups on any related page, such as the Edit Group panel in the Automation Suite (Admin > Accounts and Groups > Groups > Edit).

If you can search for users and groups that originate in Azure AD, it means the integration is running. You can tell the type of user or group by its icon.

If you encounter an error while trying to search for users, as shown in the example below, this indicates that there is something wrong with the configuration in Azure. Reach out to your Azure administrator and ask them to check that Azure is set up as described earlier in the documentation on Configuring Azure for the Integration.

Tip: Ask your Azure administrator to confirm that they selected the Grant admin consent checkbox during Azure configuration. This is a common cause why the integration fails.

Completing the transition to Azure AD

After the integration is active, we recommend that you follow the instructions in this section to ensure that user creation and group assignations are handed off to Azure AD. This way you can build on top of your existing identity and access management infrastructure for easier governance and access management control over your UiPath resources in Automation Suite.

Configure groups for permissions and robots (optional)

You can do this to ensure that the Azure administrator can also onboard new users with the same permissions and robot configuration you had set up prior to the integration. They can do this by adding any new users to an Azure AD group if the group has the required roles already assigned.

You can map your existing user groups from Automation Suite to new or existing groups in Azure AD. You can do this in several ways, depending on how you use groups in Azure AD:

  • If users with the same roles in Automation Suite are already in the same groups in Azure AD, the organization administrator can add these Azure AD groups to the user groups that these users were in. This ensures that users keep the same permissions and robot setup.
  • Otherwise, the Azure administrator can create new groups in Azure AD to match the ones in Automation Suite and add the same users that are in the UiPath user groups. Then the organization administrator can add the new Azure AD groups to the existing user groups to ensure the same users have the same roles.

Ensure to verify any roles specifically assigned to users, in all instances. If feasible, remove these direct role assignments, and add these users into groups already assigned with these roles.

For example, let's say the Administrators group in Automation Suite includes the users Anna, Tom, and John. These same users are also in a group in Azure AD called admins. The organization administrator can add the admins Azure group to the Administrators group in Automation Suite. This way, Anna, Tom, and John, as members of the admins Azure AD group, all benefit from the roles of the Administrators group in Automation Suite.

Because admins is now part of the Administrators group, when you need to onboard a new administrator, the Azure administrator can add the new user to the admins group in Azure, thus granting them administration permissions in Automation Suite without having to make any changes in Automation Suite.

Note:

Changes to Azure AD group assignments apply in the Automation Suite when the user logs in with their Azure AD account, or if already logged in, within an hour.

Migrate existing users

For the permissions assigned to Azure AD users and groups to apply, users must sign in at least one time. We recommend that, after the integration is running, you communicate to all your users to sign out of their local account and sign in again with their Azure AD account. They can sign in with their Azure AD account by:

  • Navigating to the Automation Suite organization-specific URL, in which case the sign in type is already selected. The URL must include the organization ID and end in a forward slash, such as https://{yourDomain}/orgID/.

  • By selecting Enterprise SSO on the main login page. Make sure you provide your organization-specific URL for Automation Suite to all your users.

Migrated users receive the combined permissions directly assigned to them in Automation Suite along with those from their Azure AD groups.

To set up Studio and Assistant to connect with Azure AD accounts:

  1. In Assistant, open Preferences and select the Orchestrator Connection tab.
  2. Select Sign Out.
  3. For the connection type, select Service URL.
  4. In the Service URL field, add the organization-specific URL The URL must include the organization ID and end in a forward slash, such as https://{yourDomain}/orgID/. Otherwise the connection fails saying that the user does not belong to any organization.
  5. Sign back in with the Azure AD account.
Important: Permissions from Azure AD groups don't influence the automations from classic folders or the robots that are connected using the machine key. To operate under group-based permissions, configure the automations in modern folders and use the Service URL option to connect to UiPath Assistant or Studio.

Discontinue use of UiPath local accounts (optional)

We recommend that you remove the use of local accounts to maximize the core compliance and efficiency benefits of the complete integration between Automation Suite and Azure AD.

Important: Only remove non-administrator accounts. It is recommended to retain at least one organization administrator local account to be able to change authentication settings in the future.

After all users have been migrated, you can remove the non-admin users from the Users tab, so that your users won't be able to sign in using their local account anymore. You can find these accounts based on their user icons.

You can also clean up individual permissions in the UiPath services, such as the Orchestrator service, and remove individual users from groups so that permissions rely exclusively on Azure AD group membership.

Advanced features

Here are a few useful pointers for advanced features you can leverage now that you have the Azure AD integration set up.

Restrict access to your organization

Because the integration with Azure AD is performed at the level of the Azure tenant, by default all Azure AD users can access Automation Suite. The first time an Azure AD user signs in to their UiPath organizaton, they are automatically included in the UiPath group Everyone, which grants them the User role in the organization which provides the basic level of access within the UiPath ecosystem.

If you want to only allow certain users to access your organization, you can activate user assignment for the UiPath app registration in Azure. This way, users need to be explicitly assigned to the app to be able to access it. For instructions, see how to restrict your app to a set of users in Microsoft's Azure AD documentation.

Restrict access to trusted networks or devices

If you want to only allow your users to access Automation Suite from a trusted network or a trusted device, you can use the Azure AD Conditional Access feature.

Governance for groups in Azure AD

If you have created groups in Azure AD for easy UiPath onboarding directly from Azure AD, as described earlier in Configure groups for permissions and robots, you can use the advanced security options of privileged identity management (PIM) for these groups to govern access requests for UiPath groups. For details, see the Microsoft documentation on PIM.

FAQs

What changes for my users after the integration is active?

Users can immediately sign in using their existing Azure AD account and benefit from the same permissions they had on their local account.

If you have not removed their local accounts, users can also continue to sign in with their local account, both methods work.

To use their Azure AD account, they must navigate to your organization-specific URL, which is of the formhttps://{yourDomain}/orgID/, or select Enterprise SSO on the main login page.

Another change users might notice is that if they are already signed in to their Azure AD accounts from using another application, they are automatically signed in when they navigate to this URL.

What roles does each account have?

Azure AD account: When a user signs in with their Azure AD account, they immediately benefit from all the roles they had on their local account, plus any roles assigned within UiPath to the Azure AD account or to the Azure AD groups to which they belong. These roles can come from the Azure AD user or the Azure AD group being included in groups, or from other services where roles were assigned to the Azure AD user or Azure AD group.

Local account: With the Azure AD integration active, for local accounts, it depends:

  • If the user hasn't signed in at least once with their Azure AD account, they have only the roles of the local account.
  • If users login using their Azure AD account, the local account has all roles that the AAD user has within UiPath, either explicitly assigned, or inherited from group memberships.

Do I need to re-apply permissions for the Azure AD accounts?

No. Because matching accounts are automatically linked, their existing permissions apply when logged in with the Azure AD account as well. However, if you decide to discontinue use of local accounts, make sure the appropriate permissions have been set for users and groups from Azure AD beforehand.

Was this page helpful?

Support and Services
Get The Help You Need
UiPath Academy
Learning RPA - Automation Courses
UiPath Forum
UiPath Community Forum
Uipath Logo White
Trust and Security
Terms of Use
Privacy Policy
Cookies Policy
© 2005-2024 UiPath. All rights reserved.