What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general.

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags

View all Tags

Azure AD SSO and groups for notification templates



I have read through several past KB articles regarding configuring PRTG with Azure AD SSO, managing SSO user groups, and using notification templates to send notifications to SSO users. Some of these go back several years, so I'm not sure what the current status of development is related to what we are trying to do.

Our intention was to use Azure AD groups for two purposes:

1. To have one Azure AD group for PRTG Administrators and another Azure AD group for PRTG Read Only users.

2. To have around ten Azure AD groups identifying different sets of SSO users that need to be notified when specific alarm conditions occur so we can manage membership of these groups in Azure AD and reference these SSO groups in PRTG Notification Templates.

We have this currently set up in our PRTG instance, but we are running into issues. For example, some users are getting assigned to multiple SSO user groups, and others are not. Also, changing user membership in Azure AD for user groups doesn't get reflected in Azure AD for some time, presumably until the users with changed group membership log in to PRTG with SSO.

Based on reading through all the KB questions and answers around these topics, it seems this is not a design pattern supported by PRTG for the following reasons:

A. PRTG only "synchronizes" with Azure AD when an SSO user logs in, so things like changes to Azure AD group membership are not reflected by PRTG. For example, if a user is removed from an Azure AD group, they will still get PRTG notifications because PRTG still thinks they are a member of that SSO group (and like will continue until that user logs in to PRTG next.)

B. PRTG only supports SSO users belonging to a single Azure AD group identified in PRTG. If a user belongs to multiple Azure AD groups, they may only be assigned to one of them in PRTG, and will get PRTG permissions according to whichever group they get assigned to. If an SSO user in PRTG ends up in more than one SSO User Group in PRTG with different permissions, they may get permissions of one or the other group, not resolving permissions based on most or least restrictive security or anything like that.


So my two part question is...

Are the assumptions above from past KB questions and answers still accurate, or have these been resolved in recent versions of PRTG such that our original plan above can be implemented?

If the original plan above cannot be implemented, our fallback plan is to use two Azure AD groups, one for PRTG Admins and one for PRTG Read Only users, and to maintain the lists of SSO users that should be notified as individual users selected in PRTG Notification Templates. Is this the approach PRTG would recommend for managing who should be notified for different alert conditions in PRTG using Azure AD SSO users?

azure-ad group notification sso template user

Created on Jul 26, 2023 4:01:53 PM

3 Replies



Regarding your question about the different access rights, you have the possibility to create different SSO groups with administrator rights or not and with specific access within the device tree. However, note that this requires a few modifications on Azure that we do not cover in the knowledge base article and do not provide official support for. To implement restricted access, I invite you to follow the steps below: ​ First of all, on Azure open your application from the Enterprise application menu

Enterprise app

Afterwards, open the menu Properties and configure the option User assignment required to "Yes":


User assigment

Then, assign the groups you desire to provide SSO access in the menu Users and groups of the same page:

User and groups

Now, only the users who belong to these groups should be able to log in via SSO in PRTG. ​ After you have done that, open the settings of each SSO group in PRTG (Setup > System Administration > User Groups (/systemsetup.htm?tabid=6)), provide them the object ID of their corresponding group in Azure in the field "SSO Group Claim", and define their rights: ​ SSO

​ Finally, in the device tree simply configure the access rights of the SSO groups in the settings of the object (probes, groups, devices, etc.) depending on your needs. When a user logs in via SSO PRTG will automatically assign it to the group it corresponds to, restricting the access to the objects it is allowed to see/modify in the device tree.

Regarding the configuration of the access rights, can you please try to configure the new SSO groups created and let us know if you encounter the same issue you mentioned in your email. If this is the case, please provide us the following: Name of the SSO group you want to modify the access rights Name of the concerned object (device/group/probe) Screenshots of the Settings tab from that object with the Access Rights section visible

Created on Aug 3, 2023 3:17:39 PM by  Ricardo Sanchez [Paessler Technical Support]



I think with the method you suggested above, it still requires that each user belong to a single AD group associated with PRTG. This means instead of creating 2 AD groups for PRTG access and 10 AD groups for PRTG notifications, we would need to create 20 groups (an admin and non-admin version of each notification group), and we wouldn't be able to have users be in more than one notification group, unless we create even more groups to cover combinations of notification groups, and this is just unmanageable.

Am I incorrect on the idea that PRTG only supports AD users being in a single AD group registered with PRTG?

Created on Aug 7, 2023 12:05:39 PM




It is possible to configure separated groups in Azure within a single application with the process mentioned above but if a user belongs to many of them, it will automatically show up in PRTG. What I was mention is a workaround but not officially supported by us as this is a configuration that should be done from the customer side


Created on Aug 8, 2023 12:51:53 PM by  Ricardo Sanchez [Paessler Technical Support]

Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.