Context and Objectives
Privileged Remote Access, or PRA, allows for multiple Security Providers. Organizations want to be able to automate provisioning of PRA accounts and permissions, while providing an efficient User Experience to different categories of end-users, starting with Single Sign-On or SSO. This guide provides a comprehensive combination of integrations to achieve the goals below, featuring Microsoft Entra ID for SSO and SailPoint Identity Security Cloud or ISC for provisioning.
• Leverage Entra ID for SSO
• Leverage SailPoint ISC or IdentityIQ for Access Governance
• Provide all End-Users an effective User Experience
PRA and Entra ID - SSO
We want to be able to provision accounts and permissions via the PRA SCIM Identity Provider and API, and allow provisioned Users to be able to Single Sign-On via Entra ID. Before we create the Entra ID Security Provider in PRA, we need to create the SCIM Security Provider, so we can reference it during the creation of the Entra ID Security Provider.
Login to the PRA web console as an administrator, and navigate to Users & Security, then Security Providers. Create a new SCIM Security Provider.
PRA SCIM Security Provider. We can assign the Default Group Policy to a Group Policy that grants no or minimal permissions.
Create a new SAML Security Provider and select SCIM for User Provision.
Now we also need to login to Entra ID as an Administrator, and navigate to Enterprise Applications. Click New Application.
Search for and select BeyondTrust SAML.
Configure Single Sign-On for the new BeyondTrust SAML Application.
Configure Basic SAML Configuration using the information from the PRA SAML Security Provider found under Service Provider Settings.
Configure Attributes and Claims. We are using user.userprincipalname for Email, but this can be changed to another attribute like mail, as long as it contains the email address for Users.
For all attributes, set Name format to Unspecified.
We need to download the Certificate (Base64) so we can import it within the PRA SAML Security Provider configuration. We also need to copy the Login URL and Microsoft Entra Identifier into the PRA SAML Security Provider configuration.
Import the Certificate and copy the Login URL into Single Sign-On Service URL. Also copy the Microsoft Entra Identifier into Entity ID.
We can keep the above for User Attribute Settings, and Authorization Settings.
Now in PRA web console, we need to navigate to Management, then API Configuration. We need to create a new API account.
Select SCIM API Allow Access and Allow long-lived bearer token. Generate New Client Secret and save the value for the next section.
Entra ID Single Sign-On
The recommended strategy is to use an Entra ID Group to allow specific users to be able to see the PRA SSO App within their Entra ID App portal.
Access to the PRA SSO App is granted via a Group.
Users that are members of the Entra ID PRA App Group can see the App via https://myapps.microsoft.com
SCIM and provisioning
The recommended provisioning strategy when it comes to SCIM and PRA is leverage SCIM Groups, and to add those Groups to PRA Group Policies. For each Group Policy for which we plan to provision access, we can create a corresponding (one-to-one mapping) SCIM Group.
SCIM Group added for Policy Members for a specific PRA Group Policy.
Note: All permissions or privileged permissions are granted via SCIM Group and not via Entra ID, which eliminates the concern that an Entra ID administrator or compromised administrator account could allow privileged permissions to be granted into PRA.
Note: We need to use the SCIM API to create the SCIM Groups before we can assign them as members within Group Policies.
Note: While the client credentials (Client ID and Client Secret) can be used to obtain a Bearer token for the PRA SCIM API, that Bearer token is not usable. This is a known limitation for the PRA SCIM API and it has been reported to the Product team. Meanwhile, the workaround is to use the Client Secret as the Bearer token.
Using Postman to create SCIM Groups: Use SCIM Client Secret as the Bearer token.
Note: The PRA SCIM URL is {instance URL}/api/scim/v2
Using Postman to create SCIM Groups.
The POST body for Create Group:
{
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:Group"
],
"displayName": "SCIM - External Vendor 1",
"members":[
]
}
SailPoint Identity Security Cloud and Provisioning
Note: For IdentityIQ, see SailPoint IdentityIQ section below.
We need to have a configured Entra ID Source or Connector in SailPoint to be able to provision Users into Entra ID and the PRA App Group. Refer to SailPoint documentation for configuring and deploying the Entra ID Source or Connector: https://documentation.sailpoint.com/connectors/microsoft/entra_id/help/integrating_entra_id/introduction.html
Entra ID: PRA App Group after aggregation.
Entra ID Source or Connector in SailPoint ISC with Access Profile for PRA App Group.
The Access Profile contains the PRA App Group entitlement.
SailPoint ISC Source for PRA (SCIM)
Login to SailPoint ISC as an administrator, navigate to Connections/Sources, and create a New Source.
We can search for SCIM and select SCIM 2.0 SaaS.
Note: For an on-prem PRA appliance, you can select SCIM 2.0 so communication will happen via a SailPoint VA (Virtual Appliance).
Provide a Name, Description and Source Owner. Click Save.
Under Connection settings, provide the PRA SCIM API URL, and use the API Client Secret as the API Token.
Toggle the slider for Non-Compliant Server. This is required because the PRA SCIM API implementation does not include discovery and schema endpoints.
You should now be able to successfully test the connection.
Configure an Account Correlation rule, for example using Work Email.
Create Account configuration.
Create Account configuration.
At this point, you are ready to aggregate Accounts and Entitlements (Groups).
Example of an aggregated account that is a member of one PRA SCIM Group.
Mark the SCIM Groups as Requestable.
Create an Access Profile for each SCIM Group.
Provisioning example – Request Center and Applications
Note: While it is possible to add the Access Profiles to Roles, we will use Applications for testing the configuration.
We need 2 Applications to test the configuration: One for the Entra ID Account and PRA App, and one for the PRA SCIM Group.
Application for the Entra ID Account and PRA App.
Application for the PRA SCIM Account and Group.
Now let’s go to Request Center and request both Applications for a test user that does not have a PRA or Entra ID account yet.
Request Center: Request for Others.
Add Entra ID Application to the request.
Add PRA Application for SCIM Group to the request.
Review Request for the 2 Applications then click Submit Request.
Request Center: View Requests shows both requests completed successfully.
Now we can login to Entra ID myapps as the test User and try to access PRA.
Entra ID myapps portal for test User.
Click the PRA App and provide the Test User Email. Click Login.
The Test User has access to PRA via Single Sign-On.
As a PRA administrator, we can see the test User for the SCIM Security Provider.
We can see that the test User has been created and added to the correct Group Policies.
SailPoint IdentityIQ and Provisioning
Note: We need to have a working IdentityIQ Application for Entra ID. See https://documentation.sailpoint.com/connectors/identityiq/microsoft/entra_id/help/integrating_entra_id/introduction.html
In this section, we will cover how to create the PRA SCIM Connector for IdentitIQ. IdentityIQ 8.3 or above is required.
As an IdentityIQ administrator, navigate to Applications, Application Definition, and click the Add New Application button:
Select SCIM 2.0 for the Application Type.
Check the box for Non-compliant Server, and provide SCIm URL and API Token (Client Secret).
Configure Schema attributes for User.
Configure Schema attributes for Group.
Create a new Provisioning Policy called Create Account. Add userName with a Script Value of identity.getAttribute(“email”);
Add name.givenName with a Script Value of identity.getAttribute(“firstname”);
Add name.familyName with a Script Value of identity.getAttribute(“lastname”);
Add displayName with a Script Value of identity.getAttribute(“displayName”);
Add emails.work.primary.value with a Script Value of identity.getAttribute(“email”);
Add active with a Value of true.
Assign a Correlation rule for Account as shown.
Now we need to access the debug interface to set Use PATCH to false. While PATCH /Users is supported by the PRA SCIM API, PATCH /Groups is not, and there is no option within the interface in IdentityIQ 8.3 to disable Use PATCH.
Use the /debug interface to find the Application. To access the /debug interface, append /debug to the IdentityIQ URL, e.g. https://iiq_server:8443/identityiq/debug
Search for the UsePatch setting with CTRL-F, and set the Boolean value to false.
Create and Execute the 2 Tasks for Aggregating Accounts and Groups.
You should now be able to see the Accounts via the Application.
Note: email address is not aggregated when Non-compliant Server option is checked.
You should be able to see the Requestable SCIM Groups (created via Postman or another API tool, see above section).
Now you should be able to request access for both Entra ID PRA Application Group and PRA SCIM Group for IdentityIQ Users.
Troubleshooting
If you run into some issues, it is possible to access the log for either the SAML or SCIM Security Provider:
SCIM Provider – View Log