<%NUMBERING1%>.<%NUMBERING2%>.<%NUMBERING3%> PRTG Manual: Single Sign-On
On the Single Sign-On tab, you can select an single sign-on (SSO) provider and configure other related settings.
This documentation refers to an administrator that accesses the PRTG web interface on a master node. Other user accounts, interfaces, or failover nodes might not have all of the options in the way described here. In a cluster, note that failover nodes are read-only by default.
If 15 minutes (900) seconds have passed since your last credential-based login and you open a setup page from a different setup page, PRTG asks you to enter your credentials again for security reasons. A dialog box appears. Enter your Login Name and Password and click OK to continue.
You must first configure Azure Active Directory (Azure AD) or Okta accordingly before you can integrate it into PRTG for SSO. For example, you must register PRTG as an application.
If you want to further improve the security for sign-in events, we recommend that you enable multi-factor authentication for Azure AD. For more information, see the Knowledge Base How can I enable Azure AD multi-factor authentication?
Single Sign-On Settings
Single Sign-On Settings
|
|
SSO Login
|
Define if you want to enable login via SSO:
|
Provider
|
This setting is only visible if you select Enable above. Select an SSO provider from the dropdown list:
- Azure Active Directory: Use Azure Active Directory as the SSO provider.
- Okta: Use Okta as the SSO provider.
|
Configuration Endpoint
|
This setting is only visible if you select Enable above. Enter the configuration endpoint URL.
Click Load Configuration to automatically fill in the values for Authorization Endpoint, Token Endpoint, JSON Web Key Set (JWKS) URI, and Issuer. If this does not work, then manually enter the values.
Azure AD URL format example:
https://login.microsoftonline.com/<tenant-ID>/v2.0/.well-known/openid-configuration
Make sure to replace <tenant-ID> with the directory (tenant) ID from Azure Active Directory.
Okta URL format example:
https://<your-Okta-domain>/oauth2/<authorization-server-ID>/.well-known/oauth-authorization-server
You can find the URL in the field Metadata URI under Security | API in the Okta administrator console.
|
Authorization Endpoint
|
This setting is only visible if you select Enable above. Enter the entire endpoint URL for authorization purposes, not only the server part.
Azure AD example:
https://login.microsoftonline.com/<tenant-ID>/oauth2/v2.0/authorize
Make sure to replace <tenant-ID> with the directory (tenant) ID from Azure Active Directory.
Okta example:
https://<your-Okta-domain>/oauth2/default/v1/authorize
Make sure to replace <your-Okta-domain> with the Okta domain of your application from the Okta administrator console.
|
Token Endpoint
|
This setting is only visible if you select Enable above. Enter the entire token endpoint URL, not only the server part.
Azure AD example:
https://login.microsoftonline.com/<tenant-ID>/oauth2/v2.0/token
Make sure to replace <tenant-ID> with the directory (tenant) ID from Azure Active Directory.
Okta example:
https://<your-Okta-domain>/oauth2/default/v1/token
Make sure to replace <your-Okta-domain> with the Okta domain of your application from the Okta administrator console.
|
JSON Web Key Set (JWKS) URI
|
This setting is only visible if you select Enable above. Enter the URI of the JWKS, not only the server part.
Azure AD example:
https://login.microsoftonline.com/<tenant-ID>/discovery/v2.0/keys
Make sure to replace <tenant-ID> with the directory (tenant) ID from Azure Active Directory.
Okta example:
https://<your-Okta-domain>/oauth2/default/v1/keys
Make sure to replace <your-Okta-domain> with the Okta domain of your application from the Okta administrator console.
|
Issuer
|
This setting is only visible if you select Enable above. Enter the SSO issuer.
Azure AD example:
https://login.microsoftonline.com/<tenant-ID>/v2.0
Make sure to replace <tenant-ID> with the directory (tenant) ID from Azure Active Directory.
Okta example:
https://<your-Okta-domain>/oauth2/default
Make sure to replace <your-Okta-domain> with the Okta domain of your application from the Okta administrator console.
|
Scope
|
This setting is only visible if you select Enable above. Enter the scope for SSO.
Azure AD example:
openid profile offline_access email api://<client-ID>/<scope-name>
Make sure to replace <client-ID> with the application (client) ID from Azure Active Directory and the <scope-name> with a scope name.
Okta example:
openid offline_access email profile
|
Application (Client) ID
|
This setting is only visible if you select Enable above. Enter the application (client) ID from Azure AD or the Client ID of your application from the Okta administrator console.
|
Client Secret
|
This setting is only visible if you select Enable above. Enter the client secret to verify the integrity of the SSO token.
|
Group Claim Retrieval
|
This setting is only visible if you select Azure Active Directory above. Select if you want to use an access token or GraphQL to retrieve the group claims from Microsoft Graph.
If you select GraphQL to retrieve the group claims, PRTG automatically adds user.read to the scope.
If you select GraphQL and log in for the first time, a window opens and asks for the needed permissions. Click Accept to grant the permissions.
|
Endpoint Handling
|
This setting is only visible if you select Enable above. Define whether to select the callback from a list of callbacks or to manually enter a callback:
- Select from a list of endpoints (default): Select an endpoint from a list of available endpoints.
- Manually enter a URL: Manually enter an endpoint URL below.
You need to enter a manual callback if you access PRTG via a different DNS name. For example, if you access PRTG via myPRTG.example.com but the actual DNS name of the PRTG core server is myPRTG.internal.example.com, you need to enter a manual callback.
|
Available Callback URLs
|
This setting is only visible if you select Enable and select Select from a list of endpoints (default) above. This list shows the available callbacks of this PRTG instance. Select the callbacks that your users use to connect to PRTG.
If you define an HTTPS endpoint in this field, you need to configure the HTTPS endpoint as a valid redirection URI in your SSO provider's settings.
|
External Callback URL
|
This setting is only visible if you select Enable and select Manually enter a URL above. If you access PRTG via a different DNS name, define the HTTPS endpoint.
This is necessary if the DNS name that you configured under Setup | System Administration | User Interface does not appear in the Available Callback URLs list. For example, if you access PRTG via myPRTG.example.com but the actual DNS name of the PRTG core server is myPRTG.internal.example.com, then enter myPRTG.example.com. Also make sure to add the port used by PRTG for HTTPS and the endpoint in the URL, for example: myPRTG.example.com:PORT/cb.
If you define an HTTPS endpoint in this field, you need to configure the HTTPS endpoint as a valid redirection URI in your SSO provider's settings.
|
Available Callback URLs (for reference)
|
This setting is only visible if you select Enable and select Manually enter a URL above. This list shows the available callbacks URLs of this PRTG instance for reference purposes.
|
Test Single Sign-On Authorization Endpoint
|
Click Test Single Sign-On Authorization Endpoint to call the authorization endpoint to check if starting the single sign-on process will succeed.
In case of errors, check the answer from the endpoint.
|
Save your settings. If you change tabs or use the main menu without saving, all changes to the settings are lost.
Notes and Restrictions
- SSO is not available for PRTG Hosted Monitor.
- SSO is not available for the Freeware Edition.
- SSO users do not have access to the PRTG API.
- When an SSO user logs in to the PRTG web interface, PRTG automatically creates a corresponding local account on the PRTG core server.
- Changing the Login Name in PRTG for SSO users is not supported.
- By default, no access rights for monitoring objects, libraries, maps, or reports are set for the new user group in PRTG. This is why, initially, users in this user group do not see monitoring objects, libraries, maps, or reports. This does not apply if the new user group has administrative rights. Edit the monitoring object's settings and the settings of libraries, maps, and reports, and set access rights for the newly created user group in the respective Access Rights section.
We recommend that you set these access rights in the root group settings and use the inheritance of settings.
- A local user account for an SSO user is only created if this SSO user has successfully logged in to PRTG. If you want to send email notifications to an SSO group in PRTG, using the option Send to User Group in the notification settings, a member of this SSO group has to log in to PRTG at least once to receive email notifications. To avoid this, enter the email address of the SSO group in the Send to Email Address field in the notification settings and select None for the Send to User Group option.
- If you want to delete an SSO group from PRTG, you must delete all users that are in this user group first. This is because SSO users always have this user group set as their primary group, and user accounts cannot be without a primary group.
- If a license is not valid, is temporarily unavailable, or is being updated, SSO does not work during this time.
- SSO users cannot log on to a failover node in a cluster.
More
Knowledge Base
How to integrate Azure Active Directory into PRTG?
How to integrate Okta SSO into PRTG?
How can I enable Azure AD multi-factor authentication?
Others
There are some settings that you must make in the PRTG Administration Tool. For more details, see the sections: