Configuring Microsoft Entra ID for Integration

This section describes the various configurations to be performed to support the following features:

Microsoft Graph API

Microsoft recommends the use of Microsoft Graph API instead of the Azure Active Directory Graph API. Microsoft has stopped addition of new feature in the Azure Active Directory API. The Microsoft Entra ID connector has been enhanced to use the Microsoft Graph API completely.

• To enable using the latest attributes and features supported by Microsoft Graph API, set the value of useMSGraphAPI attribute to true.
• The default Microsoft Graph API version is "v1.0". To use another version, specify the version in the in msgraph-api-version attribute in the connector configuration. For example, you can set the API version by adding msgraph-api-version with a value of "v1.0".

For more information, refer to Additional Configuration Parameters.

SAML Request Body

The SAML Request Body must consists of the following:

• SAML Request must have MicrosoftOnline as the intended audience
• Username in the request must be replaced by the $username$ placeholder
• Password in the request must be replaced by $password$ placeholder

The following is an example of a SAML Request Body:

Authorization Endpoint: https://<YOUR_DOMAIN>/adfs/services/trust/2005/usernamemixed

SAML Request:

<s:Envelope xmlns:s='http://www.w3.org/2003/05/soap-envelope'
xmlns:a='http://www.w3.org/2005/08/addressing'
xmlns:u='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd'>
  <s:Header><a:Action s:mustUnderstand='1'>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue
  </a:Action>
<a:ReplyTo><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo>
        <a:To s:mustUnderstand='1'>https://<YOUR_DOMAIN>/adfs/services/trust/2005/usernamemixed</a:To>
          <o:Security s:mustUnderstand='1'
          xmlns:o='http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'>
            <o:UsernameToken u:Id='uuid-<user’s object id>'>
        <o:Username>$username$</o:Username>
        <o:Password>$password$</o:Password></o:UsernameToken>
    </o:Security>
    </s:Header>
    <s:Body>
            <trust:RequestSecurityToken xmlns:trust='http://schemas.xmlsoap.org/ws/2005/02/trust'>
            <wsp:AppliesTo xmlns:wsp='http://schemas.xmlsoap.org/ws/2004/09/policy'>
            <a:EndpointReference>
            <a:Address>urn:federation:MicrosoftOnline</a:Address>
            </a:EndpointReference>
            </wsp:AppliesTo>
            <trust:KeyType>http://schemas.xmlsoap.org/ws/2005/05/identity/NoProofKey</trust:KeyType>
            <trust:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</trust:RequestType>
            </trust:RequestSecurityToken>
  </s:Body>
</s:Envelope>

Assigning ServicePrincipal

While providing the role id from policy, if you have configured a policy for specifying role id, then this role id is used for provisioning of all ServicePrincipals in a request. Therefore, you must provision one ServicePrincipal in one request.

While providing an access to a ServicePrincipal, it is mandatory to provide an access role for the user. These access roles may differ depending upon the ServicePrincipal type. SailPoint uses one of the access roles it receives for each ServicePrincipal during the aggregation of ServicePrincipals.

Assigning Application Permissions

This section provides details about assigning application permissions from Portal and using PowerShell.

Assigning Application Permission from Portal

• Select API permissions section registered App in Microsoft Entra ID console. Select Add a permission.

• On the Request API permissions page a list of supported APIs is listed.

  • Microsoft Graph can be found under Commonly used Microsoft APIs.

• Select the type of permission as Delegated or Application under What type of permissions does your application require?

• Under Select permissions, select the required permissions.

• Select Add permissions.

In Grant consent, select Grant Admin Consent for your configuration and directory. On the pop-up dialog box, select Yes.

Assigning Application Role Using PowerShell

The following are the prerequisite for the PowerShell commands.

• Microsoft Online Services Sign-In Assistant for IT Professionals RTW
• Azure Active Directory Module for Windows PowerShell

After installing the prerequisites, open Azure Active Directory Module for Windows PowerShell console and execute the following commands:

• Connect-msolservice, press enter, provide Azure administrator credentials.
• Execute Get-MsolServicePrincipal | ft DisplayName, AppPrincipalId -Autosize
• Locate your application name and copy the ObjectId value.
• Execute$ClientObjID = '<copied objectId of the application in the previous step>'
• Execute $webApp = Get-MsolServicePrincipal -AppPrincipalId $ClientObjID
• Execute Add-MsolRoleMember -RoleName "Global Administrator" -RoleMemberType ServicePrincipal -RoleMemberObjectId $webapp.ObjectId

Service Plan Management (managing Licenses)

The Microsoft Entra ID connector supports assigning different Azure services licenses to the users. The connector provides options to assign license either by individual plan or as a whole license pack.

• Assigning license plan: Office 365 license pack consist of licenses for individual services. For example, Exchange Online or SharePoint Online.
• The connector models the assignedPlans attribute from account schema as an entitlement. It can be requested as an entitlement during Create or Update operations for Identities.
• Assigning license pack: To assign license pack, set the assignedLicenses attribute from account schema as Managed, Entitlement, or Multi-Valued, so that it is requestable as an entitlement.

Service Plan now has separate group schema attributes. For a detailed list of the attributes, refer to Service Plan.

The following operations are supported for the Service Plan object type:

• Aggregation
• View details of Service Plan (like object properties, members and so on)
• Assign and Revoke access request for Service Plan (entitlement attribute - assignedPlans or assignedLicenses)

Generating a Refresh Token

Perform the following steps to generate the Refresh Token:

1. Obtain the authorization code using the following request. This process involves user consent.

   client_id=<clinetId>
   &response_type=code
   &redirect_uri=<redirect_uri>
   &response_mode=query
   &scope=offline_access%20https://graph.microsoft.com/.default
   &state=<randomnumber>
   

   Parameters details:

   Parameter	Description
   client_id	Client ID of the registered application.
   response_type	For authorization code the value must be code.
   redirect_uri	This should be redirect uri configured while registering the application. This should be pointed to localhost and any unused port.
   response_mode	To get the code to in string parameter on your redirect URI, it should be query.
   scope	Here multiple scopes can be added for defining the required API.

   The default added scope is https://graph.microsoft.com/.default.

   The refreshToken parameter is also required for configuration. The offline_access scope must be added.

   Parameter	Description
   state	This can be any random number. Same value will be returned along with authorization code.

   The Response in browser address bar would be displayed as follows:

   https://localhost:44320/?code=OAQABAAIAAAAm-06blBE1TpVMil8KPQ41U9-...&state=1234566&session_state=9557b1f1-0fd8-4e12-a39f-213cfcd12153

   Copy the code present between code= and &state.

   Note

   The received Authorization Code can be used only once and is valid for a short duration.

2. Obtain the Refresh Token as follows using the Auth Code obtained in the above step:

   The Auth Code received from the previous steps must be passed in the following request along with other parameters in following request:

       POST https://login.microsoftonline.com/{{Your Domain name}}/oauth2/v2.0/token
        Content-Type: application/x-www-form-urlencoded
   client_id=<clinet id >
   &scope=offline_access%20https://graph.microsoft.com/.default
       &code=OAAABAAAAiL9Kn2Z27UubvWFPbm0gLWQJVzCTE9UkP3pSx1aXxUjq3n8b2JRLk4OxVXr...
       &redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
       &grant_type=authorization_code
       &client_secret=JqQX2PNo9bpM0uEihUPzyrh
   

   Following are the newly added parameters:

   Parameter	Description
   code	Authorization code obtained in previous steps.
   grant_type	As you intend to redeem the Auth Code it should be authorization_code.
   client_secret	Client Secret of the registered application.

   Response:

   {
       "token_type": "Bearer",
       "scope": "https://graph.windows.net/Directory.Read.All
       https://graph.windows.net/User.Read https://graph.windows.net/.default",
       "expires_in": 7199,
       "ext_expires_in": 7199,
       "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IlNzWnNCT
       mhaY0YzUTlTNHRycFFCVEJ5TlJSSSIsImtpZCI6IlNzWnNCTmhaY0YzUTlTNHRycFFCVEJ5TlJSSSJ9
       .eyJhdWQiOiJodHRwczovL2dyYXBoLndpbmRvd3MubmV0Iiwia...",
       "refresh_token": "OAQABAAAAAAAm-06blBE1TpVMil8KPQ410LOG6EPVxGfgH8rHUXApUs5fPFtel9FsKTXo2oN8Rw
       _ngEOpKNt1hfufYyJJnG39XxfscpcW...."
   }
   

   Copy the Refresh Token received in the response.

Support for Provisioning Operations of manager Attribute

The Microsoft Entra ID connector supports the manager attribute for the following:

• Account Aggregation (Full and Delta): On Account Aggregation, the manager attribute for a user populates for a non-null (blank) value on the Microsoft Entra managed system. Add the manager attribute in the account schema with the string type. For more information on adding attributes to the account schema, refer to Editing an Account Schema.
• Provisioning: The manager attribute is supported for the Add, Remove, and Set operations where the value of the manager can be set as either objectId or the userPrincipalName. Add the manager attribute in the Provisioning policy. The blank value in the Set operation is applicable to remove the manager value at the Microsoft Entra managed system.

Sponsors for Guest User (B2B) and External Member (B2B)

The sponsor feature helps manage B2B users in your directory by tracking who is responsible for each guest user. While entitlement management can monitor guests from certain domains, it does not cover guests outside of these specific areas. With the sponsor feature, you can assign a person or group to every guest user, which helps track who invited them and promotes accountability.

The Sponsors field on the user object identifies the person or group tasked with managing and overseeing the user's lifecycle, ensuring they have the correct access to resources. Being a sponsor does not confer administrative powers to the sponsor user or group. However, it can be utilized for approval processes in entitlement management and for custom solutions, but it provides no other built-in directory powers.

Supported Features

Aggregation and provisioning of sponsors for Guest User (B2B) and External Member (B2B).

Adding Sponsors to the Source

To use this feature, you must manually add the sponsor attributes to the Account Schema for the Microsoft Entra source.

For more information, refer to Editing an Account Schema.

Provisioning

When provisioning a Microsoft Entra user as a sponsor, add the sponsors.users attribute to the Account Schema and provide the user's User Principal Name (UPN). For example, someone@example.com.

When provisioning a Microsoft Entra group as a sponsor, add the sponsors.groups attribute to the Account Schema and provide the group's Object ID.

Both attributes support Add, Remove, and Set operations. A Set operation on sponsors.users replaces only the user-type sponsors, leaving any group sponsors intact, and vice versa for sponsors.groups.

Documentation Feedback

Feedback is provided as an informational resource only and does not form part of SailPoint’s official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.