Azure Active Directory (Azure AD) provides an easy way for businesses to manage identity and access, both in the cloud and on-premises. Your users can use the same work or school account for single sign-on to any cloud and on-premises web application. Your users can use their favorite devices, including iOS, Mac OS X, Android, and Windows. Your organization can protect sensitive data and applications both on-premises and in the cloud with integrated multi-factor authentication ensuring secure local and remote access. Azure AD extends your on-premises directories so that information workers can use a single organizational account to securely and consistently access their corporate resources. Azure AD also offers comprehensive reports, analytics, and self-service capabilities to reduce costs and enhance security. The Azure AD SLA ensures that your business runs smoothly at all times and can be scaled to enterprise levels.
You must be the Account Owner of your PagerDuty account in order to make these changes. Additionally, SSO capabilities within PagerDuty are only available on our Standard and Enterprise plans. Please contact our sales team if you are interested in upgrading your plan.
In your Azure Management portal
- Click on the Azure Active Directory icon on the left menu and then click on Enterprise Applications.
- Click on New application.
- In Add from the gallery, search for and select PagerDuty. Give it a name and click Add.
- From back in the Azure Active Directory from the left menu, go to the All Applications and click on the new PagerDuty application.
- Configure the settings as follows:
- Single Sign-on Mode: set to SAML-based Sign-on
- Sign-on URL and Identifier: set both to the base URL of your PagerDuty login page, https://(your-subdomain).pagerduty.com
- User Identifier: set this to user.mail.
- Scroll down further to the User Attributes section and check the box View and edit all other user attributes.
- To ensure that user fields are properly populated when auto-provisioning, configure the user attributes as follows:
- Set the Namespace field to empty.
- Name name, value
user.displayname for the user’s full name
- Name emailaddress, value
user.mail for the user’s email
- Name jobresponsibilities, value
user.jobtitle for the user’s job title
- Click Save to save the current settings.
- Return to the Single sign-on settings page and scroll down to the bottom of the page, to the PagerDuty Configuration section, and click on Configure PagerDuty to get additional information for setup.
- Follow the instructions on that page. In particular, look for the the necessary pieces of information to put into the PagerDuty SAML settings page:
- X.509 SAML signing certificate,
- Login URL
- Logout URL
- Go to the Users and groups page of the PagerDuty app, and click Add user. This will take you to a page where you can grant your Azure Active Directory users and groups access to PagerDuty.
- Select the users (round icons) and groups (flag-shaped icons) that you wish to grant access to PagerDuty, click Select, then click Assign.
- As the Account Owner, click on Configuration and select Account Settings.
- Click Single Sign-On in the menu on the right side of the page.
- Select SAML as the login authentication type.
- Fill in the X.509 certificate, the login URL, logout URL with the values copied from Azure.
- Make sure the Require EXACT authentication context comparison option is checked.
- If you’d like to disable username and password authentication for your PagerDuty account for all users, except the Account Owner, you can uncheck the Allow username/password login check box.
- If you’d like PagerDuty to automatically create accounts for anyone who has access via Azure SSO upon their first login, check the box next to Auto-provision users on first login.
Why am I getting the error message “Authentication method ‘WindowsIntegrated’…doesn’t match the requested authentication method…”?
Part of the SAML request sent to Azure from PagerDuty during the first stage of authentication (when a user clicks “Sign in with my identity provider” and is redirected to Azure) is requested authentication context (the RequestedAuthnContext element), which is a stated preference for certain minimum level of security for user authentication in the identity provider. Our SAML service includes this when sending requests to every service provider, Azure included.
Per Azure’s SAML protocol implementation, only the “password” class of authentication type (urn:oasis:names:tc:SAML:2.0:ac:classes:Password) is supported when requesting an authentication context:
Azure AD supports only one AuthnContextClassRef value: urn:oasis:names:tc:SAML:2.0:ac:classes:Password.
Furthermore, Azure’s SAML service requires the service provider to specify that there must be an exact match between the requested and authentication context to exactly match the one requested by the service provider (this is enabled via the “Require EXACT authentication context comparison“ option); a different error stating that the context comparison must be exact will result otherwise.
- PagerDuty includes the RequestedAuthnContext element to request that the identity provider use, at the bare minimum, password authentication to identify users.
- Azure expects the service provider require an exact match between the authentication type provided with the one requested, whenever RequestedAuthnContext is provided.
- Azure only supports requesting Password type authentication when specifying RequestedAuthnContext.
Users can get around this issue by using a different web browser that does not attempt to authenticate with the identity provider via the WindowsIntegrated authentication method, and using password authentication to access their identity.
If your organization and IT workflow requires Integrated Windows authentication and your end users are affected by this known issue, please share your feedback to us in the PagerDuty Community or by sending us an email: email@example.com.
For further reference: