Azure SSO Configuration

PGP Single Sign-On (SSO) with Azure

This guide sets up single sign-on between Microsoft Entra ID (Azure) and the Praetorian Guard Platform (PGP). You configure an app registration in Azure, then add it as a provider in PGP. You need three values from Azure:

• Client ID
• Client Secret
• Issuer URL

Domain Verification

The first step is to verify ownership of your domain by adding a DNS TXT record. Access your domain's DNS settings or management interface where you'll need to add a TXT record. The record has the format chariot=<verification-id>, where <verification-id> is your account's verification ID. The Add SSO Provider dialog on Settings → Organization shows the exact value to copy.

Add the TXT record at the root of your domain. For example, for YourDomain.com, add it at the root level (@) with the value from the Add SSO Provider dialog.

Once set, your DNS TXT record might look something like this:

To verify that your record has been published, you can run the command dig +short TXT YourDomain.com if on a Mac or nslookup -type=TXT YourDomain.com if using Windows, and look for your record in the output.

Creating the Azure Application Registration

Start by visiting the Azure Portal and creating a new Single Tenant App Registration.

On the App registrations page, follow these steps:

1. Supply the name of the application to Azure, such as "PGP SSO".
2. Make and implement decisions on who will be able to access PGP SSO through Azure.
3. Configure a "Web" Redirect URI with this URI:

https://sso.guard.praetorian.com/oauth2/idpresponse

Get the Client ID and Secret

Navigate to the newly created application Overview. Note the Application (client) ID and Directory (tenant) ID on the overview page. Copy these. The Application (client) ID will be used as the Client ID and the Directory (tenant) ID will be used in the Issuer URL in the PGP application.

In the left menu, click Certificates & secrets.

On the Certificates & secrets page, click to add a New client secret. Generate a new client secret, and copy the value. Once you create the New client secret this value will not be visible again.

The newly generated secret value will show up in the table below Description. Again, remember to copy the secret value as you will need for PGP SSO Setup as the Secret. The Secret ID (separate from the Application (client) ID, above) should not be needed for the PGP - Azure integration.

Get the Issuer URL

Your issuer URL will be:

https://login.microsoftonline.com/<tenant-id>/v2.0

...where <tenant-id> is the Directory (tenant) ID listed on the application overview page.

PGP Integration Configuration

1. In PGP, go to Settings → Organization.
2. In the Single Sign-On section, click Add Provider. If a provider already exists, click Add Another Provider.
3. In Add SSO Provider, fill in:
   • Domain: your email domain, for example acme.com.
   • Client ID: the Azure Application (client) ID.
   • Secret: the client secret value you generated under Certificates & secrets.
   • Issuer URL: https://login.microsoftonline.com/<tenant-id>/v2.0, using your Directory (tenant) ID.
   • Default Role for SSO Users and Role Claim Name (Optional): see User Provisioning and Role Assignment.
4. Click Integrate.

Managing Access Permissions

Access to your PGP account will be granted to users based on the account group specified in your Azure tenant. For detailed information about configuring these access permissions, consult the Azure Documentation.

User Provisioning and Role Assignment

Once SSO is configured, all users are managed through your Entra tenant. New users do not need to be provisioned in PGP ahead of time — an account is created automatically the first time an Entra user signs in.

During SSO setup, choose how roles are assigned. If the Add SSO Provider dialog shows no role fields, every SSO user is given the Admin role.

• Default role — Every SSO user is granted the same role on first sign-in. After sign-in, the role for an individual user can be adjusted under Settings > User Management. We recommend setting the Default Role to Read Only so any user whose role claim is missing or invalid lands in the least-privileged state.
• Role claim — Map an Entra role claim to PGP's three roles: Read Only, Analyst, and Admin. For Entra, the supported source is Entra App Roles defined on the Guard SSO application registration.

When configuring a role claim, the following details apply:

• Source — Use Entra App Roles, not Entra groups, raw user attributes, or other custom sources.
• Token type — PGP enforces RBAC from the ID token only. Access-token claims are not inspected.
• Claim format — The value PGP reads must be a single string. Entra's built-in roles claim is emitted as an array and will be silently ignored. Use a claims-mapping policy or token transformation to emit the user's assigned App Role as a single-string custom claim (for example, app_role).
• Claim name — Pick any name for that custom claim and enter the same name in PGP as the Role Claim Name.
• Accepted values — Each App Role's Value must be exactly admin, analyst, or readonly (lowercase, case-sensitive). Any other value is logged as invalid and falls back to the Default Role.
• Mapping location — Role mapping is configured only in Entra. PGP has only the Role Claim Name and Default Role for SSO Users fields, with no separate role-mapping screen.

Each user should be assigned to exactly one of the Guard App Roles; multiple assignments will produce a multi-valued roles claim that PGP cannot resolve.

For step-by-step instructions (defining App Roles, assigning users, and emitting the single-string custom claim), see Role-Based Access Controls (RBAC).

Once the setup is complete, users sign in with Sign in with SSO on the PGP login page.

You can remove the DNS TXT record after setup, but add it back before you change the SSO configuration, for example with Rotate Credentials on the provider.

If you need help, contact support@praetorian.com.