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

How to integrate Microsoft Entra ID into PRTG?

Votes:

2

I want to use Microsoft Entra ID (formerly Azure AD) as SSO provider for PRTG. How can I do this? What steps are necessary?

active-directory azure-ad microsoft-entra-id prtg sso

Created on Sep 4, 2020 10:10:42 AM by  Brandy Greger [Paessler Support]

Last change on Oct 12, 2023 12:03:00 PM by  Jacqueline Conforti [Paessler Support]



64 Replies

Accepted Answer

Votes:

1

This article applies as of PRTG 23

Important notice: The following article only applies to PRTG Network Monitor. It does not apply to PRTG Hosted Monitor.

How to integrate Microsoft Entra ID into PRTG

As of PRTG 21.2.68, you can use Microsoft Entra ID as single sign-on (SSO) provider in PRTG. For the integration to work seamlessly, follow the steps in this article. For more information, see the PRTG Manual: Single Sign-On.


Steps to take:

  • Step 2: Configure SSO in PRTG
  • Step 3: Add a user group in PRTG

Step 1: Configure Microsoft Entra ID in the Azure Portal or Microsoft Entra admin center

Follow these steps to configure Microsoft Entra ID to work as SSO provider in PRTG.

  • Step 1.1: Register your app
  • Step 1.2: Create a client secret
  • Step 1.3: Add a platform
  • Step 1.4: Create a groups claim
  • Step 1.5: Add a scope
  • Step 1.6: Edit accessTokenAcceptedVersion

Step 1.1: Register your app

The only difference between the Azure Portal and the Microsoft Entra admin center is how you reach the App registrations tab. The rest of the process is exactly the same.

Using the Azure Portal

  • Select Microsoft Entra ID under Azure services in the Azure Portal.

Using the Microsoft Entra admin center

  • Click the New registration button.
  • Enter a name, for example My_Registration.
  • Select Accounts in this organizational directory only.

Optional: Enter the redirect URI if you already know it. If you do not know it yet, you can enter it later in step 1.3.

  • Click the Register button to register the new app.
  • Select the newly registered app My_Registration.
  • Copy the Application (client) ID and Directory (tenant) ID.
    Note: You need these to configure PRTG later.Client and tenantClick to enlarge.

Step 1.2: Create a client secret

Enter a Description, for example My_Client_Secret.

Enter the period after which the client secret expires.

Click the Add button to save the client secret.

Important notice: Make sure to note the client secret now because it will not be visible again and because you need it when you configure PRTG.

Step 1.3: Add a platform

Enter the redirect URI under Redirect URIs. Use the format https://IP_address or DNS name:port/cb. For example, https://192.0.2.0:443/cb.
Note: Make sure to add redirect URIs for the ports that PRTG uses, namely port 443 (default), port 8443 (fallback). If both 443 and 8443 are not available, PRTG sends a ticket that shows you the currently used port number. Add a redirect URI for this port until PRTG can switch back to 443 as soon as it is available again.

Click Continue.


Step 1.4: Add a groups claim

  • Click the Add groups claim button.Add claim

Click to enlarge.

Select Security groups and Directory roles.

Click Add to save the new groups claim.

Note: In larger organizations, the number of groups where a user is a member might exceed the limit that Microsoft Entra ID will add to a token. For workarounds to these limits, read more in Important caveats for this functionality.


Step 1.5: Add a scope

Click the Add a scope button.Add scopeClick to enlarge.

Enter an Application ID URI.

Click Save and continue.Scope settingsClick to enlarge.

Enter a name for the scope. By default, Azure uses the format api://<client-ID>/<scope-name> For our example, we will use api://<client-ID>/My_Scope_name


Step 1.6: Edit accesstokenacceptedversion

Change accessTokenAcceptedVersion = 0 to accessTokenAcceptedVersion = 2

You have now successfully configured Microsoft Entra ID.


Step 2: Configure SSO in PRTG

Now that you have configured Microsoft Entra ID, you now need to configure the SSO settings in PRTG accordingly. To do so, follow these steps.

Important notice: Make sure that PRTG uses a connection that is encrypted via SSL. For more information, see PRTG Manual: PRTG Administration Tool on Core Server Systems.
  • Log in to the PRTG web interface.
  • Under SSO Login, select Enable.
  • Under Provider, select Microsoft Entra ID from the dropdown list.
  • Click the Load Configuration button. This automatically fills in the values in the next four fields.
    Note: If this does not work, then you have to manually enter the values instead as follows. Also, make sure to replace <tenant-ID> with your directory (tenant) ID from Step 1.1.

Authorization Endpoint: https://login.microsoftonline.com/<tenant-ID>/oauth2/v2.0/authorize

Token Endpoint: https://login.microsoftonline.com/<tenant-ID>/oauth2/v2.0/token

JSON Web Key Set (JWKS) URI: https://login.microsoftonline.com/<tenant-ID>/discovery/v2.0/keys

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

  • Under ClientID, enter the application (client) ID from Step 1.1.
  • Under Client Secret, enter the client secret from Step 1.2.
  • Under Available Callback URLs, select the URLs that your users will use to log in to PRTG. Here is an example what the URLs should look like: https://myprtg.domain.com:443/cb/.
    You will need to add these to the Azure app you configured in Step 1.3.
  • If the URL your users use to log in to PRTG is not listed because PRTG is reachable via a different URL (for example, myPRTG.example.com for login but PRTG lists myPRTG.internal.example.com), you can use the option Manually enter a URL. PRTG still lists all available endpoints if needed for forwarding. You then need to add the URL to the Azure app you configured in Step 1.3.
    Note: Microsoft Entra ID and PRTG both check whether or not the callback URLs are allowed. Make sure you configure each required URL on both ends; otherwise, you will not be able to log in.SSO settings
    Click to enlarge.

You have now configured SSO in PRTG.


Step 3: Add a user group in PRTG

Now that you have configured SSO, you need to add a new user group in PRTG.

Important notice: PRTG only supports the Microsoft Entra ID group type Security.
  • Log in to the PRTG web interface.
  • Go to Setup | System Administration | User Groups.

Under User Group Name, enter a name to identify the group, for example Microsoft Entra ID SSO.

Under Active Directory or Single Sign-On Integration, select Use single sign-on integration.

Under SSO Group Claim, enter the scope from step 1.5 or the object ID of an Azure group.


Note: To find an object ID, open the Azure portal or Microsoft Entra admin center, select Microsoft Entra ID, and go to the Groups tab. There you find a list of all groups and their object IDs. Find the object ID you need and enter it under SSO Group Claim. Alternatively, you can use the scope name you previously configured, for example My_Scope_name.


You have now successfully integrated Microsoft Entra ID as SSO provider in PRTG.

Created on Sep 4, 2020 11:15:58 AM by  Brandy Greger [Paessler Support]

Last change on Nov 16, 2023 2:09:57 PM by  Yasodhara Das [Paessler Support]



Votes:

0

Hello,

thank you the tutorial worked.

My question: How Can I restrict the API to a special group?

I tried it with the object ID but this didn't work.

Created on May 28, 2021 12:18:26 PM



Votes:

1

I've followed this and it works fine. The the post above mine, the Object ID does work. I have tested this and when creating a PRTG SSO Group, and inputting the Azure AD Group Object ID into the 'SSO Group Access Claim', when a user from that Group logs into PRTG via SSO, they will join that group.

All good here. Thanks very much for this long awaited feature.

Created on Jun 1, 2021 10:35:51 AM



Votes:

1

Also, can anyone confirm that the current mobile app is SSO/2FA compatible? I am having issues logging in with an SSO based account via cellular with a bad password hash error.

I have raised a case to check on this as well.

Created on Jun 2, 2021 9:54:46 AM



Votes:

1

Does this work in the iOS app yet? I don't see an option for SSO there.

Created on Jun 2, 2021 3:53:24 PM



Votes:

1

Mobile Apps (IOS/Android) currently do not support Azure SSO. They use the classic login and require credentials. We are looking into implementing this in the future, however there is no ETA for this.


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Jun 3, 2021 1:23:22 PM by  Sasa Ignjatovic [Paessler Support]



Votes:

8

@ Sasa Ignjatovic ^^ Please look to do that soon! Many of us use the mobile app on weekends, after-hours and SSO via the app is important functionality to be released/

Created on Jun 4, 2021 2:26:54 AM



Votes:

3

Can we use App Roles or any other form of permissions? Id like to assign different Azure AD users to different groups in PRTG.

Created on Jun 7, 2021 4:33:02 PM



Votes:

0

This is not possible. There are also currently no plans for this.


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Jun 11, 2021 10:05:33 AM by  Sasa Ignjatovic [Paessler Support]



Votes:

4

I'm having a similar issue when attempting to use a Azure group ID to target PRTG groups. I get an SSO logon failure. If I use the API name it works without issue, but doesn't allow me to restrict or target access. Any advice or way to troubleshoot?

Created on Jun 11, 2021 3:10:31 PM



Votes:

2

I have also the same problem. If I use the api name everyone in our Azure AD can login via SSO. If I use the Group ID of the Azure Group I get an error. Is there any special setting/type of AD Group?

Created on Jun 22, 2021 2:43:36 PM



Votes:

1

I<m having the same issue too for logging in the Group claims on PRTG I tried the API name, the object id of the user group, and the claim group that is in Token menu of azure.

After i logging with sso on PRTG it sayd we cannot log you in with SSO contact your Admin

Created on Jun 30, 2021 2:08:55 PM



Votes:

0

Does the URL configured in Azure AD for PRTG need to be a publicly accessible URL, or can it be the internal URL?

Created on Jul 1, 2021 4:44:24 PM



Votes:

0

The Redirect- or Callback-URI does not have to be publicly acessible.


Kind regards,
Matthias Kupfer - Team Tech Support

Created on Jul 2, 2021 9:22:01 AM by  Matthias Kupfer [Paessler Support]



Votes:

1

Me too. I am having the same issue that @Gyslainh for logging in the Group claims on PRTG I tried the API name, the object id of the user group, and the claim group that is in Token menu of azure.

After I logging with sso on PRTG receive message text "Your login via SSO has failed. Please contact your administrator!"

by Eder Aprigio

Created on Jul 3, 2021 4:11:53 AM



Votes:

1

For those of you who would like to restrict the access via Azure-SSO, do as I did:

In Azure Portal go to "Enterprise Applications", search for your PRTG SSO app and open it. Under "properties" enable "user assignment". Then you need to go to "Users and Groups" and assign users or a groups you want to grant access. But still no way to assign users/groups to different roles.

@PRTG: It´s a shame that the Azure-Intigration is so rudimentary. Do you realy think I want to assign all 1300 Azure-Users admin-rights inside of PRTG. Group to Roll assignment is no nice-to have - it´s a must-have!!!

And please make mobile App and MFA happen. Same as role assignment - must-have.

THX!

Kai

Created on Jul 6, 2021 11:42:14 AM



Votes:

1

Hello,

when implementing features, we first aim to cover the most important things. Then we check if there is a lot of demand for further options. This way we make sure to meet market demand.

Features can be requested this way. I agree that a more thorough implementation of AD authentication options would be useful, however many items on our roadmap are currently in higher demand than MFA or more AD assignment options. As developer of off-the-shelf software, we have to carefully decide when to do what.

Regarding user mapping, you can map different AD groups to different PRTG user groups in which you set the respective set of rights, with copying in the respective claim.

Created on Jul 12, 2021 6:59:03 PM by  Arne Seifert [Paessler Support]

Last change on Jul 14, 2021 8:42:14 AM by  Arne Seifert [Paessler Support]



Votes:

2

I see a few posts on here about not being able to authenticate with sso and getting the error "Your login via SSO has failed. Please contact your administrator!", but I don't see any updates on where that issue is coming from.

Anyone resolve that issue?

I don't know where to find my "api name", maybe people mean the "scope name"?

I've tried the obect ID for the security group I set up in Azure AD, and still getting the error. I tried the "display name" for the app registration, and I've tried about every ID I could find, and still getting the error.

When I test the SSO connection (in the PRTG setup) it says OK (200), but I'm not sure of any other way to verify this is set up correctly.

I'm not finding any log info on Azure or PRTG that lets me know what is failing. Anyone find a way to see details on the failures?

Created on Jul 19, 2021 8:05:51 PM



Votes:

0

Thank you for implementing SSO, we have been keenly waiting for this. Unfortunately we are also unable to get the Azure group objectID to work. It allows you to enter your credentials but then gives an error "Your login via SSO has failed. Please contact your administrator!"

Created on Jul 19, 2021 11:38:43 PM



Votes:

0

Hello Jesse,

the api name is an alternative input for the groups claim. Normally, the groups claim is used, and can be setup in Azure AD.

More detailed logs can be written by adding the line

category.Core_LoginTrace=DEBUG

in PRTG_GlobalLoggingConfiguration.logcfg. Default location is "C:\ProgramData\Paessler\PRTG Network Monitor\Logs\PRTG_GlobalLoggingConfiguration.logcfg" on the PRTG core server. Make sure that the path is the same as the one displayed in PRTG Administration Tool, tab PRTG Core server. ​

Once the change is saved, reload the logging configuration in PRTG using Setup / System Administration / Administrative Tools, function "Reload Logging Configuration".

It is important do remove this line later on, otherwise the logs are filled quickly, making them more difficult to read for analyzing other issues.

Created on Jul 20, 2021 2:59:50 PM by  Arne Seifert [Paessler Support]



Votes:

0

Hello Roland,

for more detailed information about login issues, you can change the log level as described above.

Created on Jul 20, 2021 3:00:16 PM by  Arne Seifert [Paessler Support]



Votes:

0

Thank you, Arne! I'm getting this logging set up now.

When you say "groups claim", do you mean any security group in Azure AD?

Where do I find the API name?

Created on Jul 20, 2021 6:07:27 PM



Votes:

0

Update on my issue. The debug logging for login was exactly what I needed. It showed "Invalid client secret is provided".

In my case I got the secret ID and Value mixed up. Once I had the actual secret value in the SSO setup for PRTG it worked right away.

Thanks again for all your help, Arne!

Created on Jul 20, 2021 7:42:42 PM



Votes:

0

I was initially having issues with my SSO configuration, and it turned out that I was using the wrong Client Secret (I was using the Secred ID instead of the Value). Once I corrected that, I was able to log in using the API name and also using group ID's. I haven't thoroughly tested it, but it looks like I was able to assign admin and standard user privileges in PRTG correctly. I've only tested with a couple of users, but here's what I did. I created 2 separate user groups in PRTG, and I used the Azure group object ID for each of them. The first group was named Azure SSO Admins, and I used the group object ID for an Azure group named PRTG Admins. The second group was named Azure SSO Regular Users, and I used the group object ID for the Azure group named PRTG Users. When I tried SSO as an admin for my own account, it correctly identified me as such. When one of my staff tried SSO as a regular user, it also correctly identified him as such. I tested using Microsoft Edge and Google Chrome. Please keep in mind that when you're logging in, you should not be putting in any user creds (username and password are both BLANK), but just hitting the "Log in with single sign-on" button. There are plenty of scenarios I haven't tested yet, but I hope this helps somebody, as I was getting frustrated when trying to configure this. The tip about enabling the logs in a previous post is what helped me identify the issue with the secret, which also reminds me of something else. I used category.CoreLoginTrace=DEBUG (NO UNDERSCORE) which followed the standard of the other parameters in that log config file. It didn't seem to work with the underscore in it. Have fun!

Created on Jul 20, 2021 8:43:29 PM



Votes:

0

Hello Jesse,

the group claim can be configured in AzureAD.

Nice to hear that you got SSO to work.

Created on Jul 21, 2021 10:07:33 AM by  Arne Seifert [Paessler Support]



Votes:

0

I was wrong. Did not work!

I managed to assign different PRTG groups to different Azure AD groups.

Add both groups as scope in "Expose an API" in Azure App registrations with the Azure group Object Id as name.

The part that I missed first: Add both groups to the scope in the SSO Config in PRTG.

openid profile offline_access email api://<applicationId>/<group1Id> api://<applicationId>/<group2Id>

Created on Jul 21, 2021 3:09:58 PM

Last change on Jul 22, 2021 12:32:12 PM by  Felix Wiesneth [Paessler Support]



Votes:

0

Hello PJ,

the correct line should contain the underscore, even though the other categories have none.

Hello ABS,

thank you for the input.

Created on Jul 21, 2021 5:04:06 PM by  Arne Seifert [Paessler Support]



Votes:

0

Hello Peassler Team,

could you please integrate the important information from my colleague ABS regarding configuration of several access groups with group id in section "scope" to the knowledgebase article above?

I think adding that information with an example would help lot of other people.

Yours

Created on Jul 22, 2021 9:48:35 AM



Votes:

0

additional information for the post from my colleague ABS:

we have tested the solution, and now all SSO users are associated to both groups (admin and user groups) in PRTG. We checked the azure ad group, and there affected users are only member of one group! So it seems that SSO with different rights dependent on membership of azure ad group is not possible at the moment. Please paessler team solve this issue. Thanks!

Created on Jul 22, 2021 10:00:09 AM



Votes:

0

Hello ATP,

Thank you for your comment.

However, please note that this option is already possible.

Yet there is one way of configuring SSO in a way, that members will end up in both PRTG groups: using the exposed API name as an SSO claim - which is what you did in this case. Problem here is that any Azure user logging in will be assigned both claims.

Instead of that, you should add a groups claim to the app in Azure, then the users' associated group IDs will be part of the claims list and can be used to assign Azure user accounts to different PRTG groups.

Best regards

Created on Jul 28, 2021 9:29:17 AM by  Isidora Jeremic [Paessler Support]



Votes:

0

Hello ATP,

Thank you for your comment.

However, please note that this option is already possible.

Yet there is one way of configuring SSO in a way, that members will end up in both PRTG groups: using the exposed API name as an SSO claim - which is what you did in this case. Problem here is that any Azure user logging in will be assigned both claims.

Instead of that, you should add a groups claim to the app in Azure, then the users' associated group IDs will be part of the claims list and can be used to assign Azure user accounts to different PRTG groups.

Best regards

Created on Jul 28, 2021 9:29:18 AM by  Isidora Jeremic [Paessler Support]



Votes:

1

Hello,

I wanted to add different groups based on my Azure group. My SSO was working but with a single group. I got it working following the different comment.

First you need to

  • create an Azure group (security for example) and copy it's ID
  • Add a user to this group
  • Then you create a group in PRTG and past the group ID in SSO Group Access Claim

And, what I had forgotten to do :

  • Login to your Azure portal
  • Go to your application
  • Go to Token configuration
  • Add a group claim and choose the type of group you want (in my case security)

Now the specific ID you had put in your SSO Group Access Claim is recognize and should be working when you login with a member of the Azure Group you had created

Good luck

Created on Aug 4, 2021 4:19:58 AM

Last change on Aug 5, 2021 6:55:14 AM by  Florian Lesage [Paessler Support]



Votes:

0

Just for awareness, there doesn't seem to be a way to apply SSO sign in to existing users. Once SSO is configured, it creates a new user account for the user which has none of their original permissions. For my environment, where we have many users and groups configured with different permissions across thousands of devices, the only way I can get SSO integrated would be to completely rebuild my PRTG environment and recreate all the different permissions using the new groups and users. Hopefully one day there will be a way to apply it to existing users, but until then this integration isn't of much use unless you have a very simple deployment or are starting from scratch.

Created on Aug 4, 2021 2:00:58 PM



Votes:

1

Jut want to inform that I was able to integrate on premises ADFS : in your onprem ADFS go to "Application groups", add... , choose from template "server application accessing a web API", name it, next, under "redirect uri " enter one of the "Available Callback URLs" from your servers sso settings page i.e. https://<prtg server FQDN>:443/cb , take note of the "client identifier" on this page, next, under "Configure application credentials" mark "generate a shared secret", take note of the generated secret, next, configure Web API identifier : https://<prtg server FQDN>, add, next ,next, in "Configure Application Permissions / Permitted Scopes " make sure openid is selected, next and finish. Now back to yor PRTG SSO settings page in configuration endpoint : https://<ADFS fqdn>/adfs/.well-known/openid-configuration click "load configuration" it should populate most fields, but you need to replace "Scope" field with "openid profile offline_access email api:<client-ID>/AnAPIName" as is , now enter the client id and the secret we took note from ADFS, select the "Available Callback URLs" and test it, it should give you "OK (200)" , save and you are done. This is just a basic ADFS setup, you can tweak it to make it more secure.

Created on Aug 31, 2021 9:07:37 AM

Last change on Aug 31, 2021 1:00:14 PM by  Felix Wiesneth [Paessler Support]



Votes:

2

Just in case anyone also has a larger azure tenant where some users might have over 200 groups assigned:

Be aware that, at least for now, prtg can't handle these with previously mentioned setups!

This is due to a hard limit for groups in a claim. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims In larger organizations the number of groups a user is a member of may exceed the limit that Azure Active Directory will add to a token. 150 groups for a SAML token, and 200 for a JWT.

You can quite easily adapt previously mentioned setups like this (where you filter claims by a group id to have different priviledges in prtg based on group membership) by doing these steps:

  • Within app registrations: Select your app and create an app role for each group you need. The "value" property for roles, at least for now, doesn't seem to matter.
  • Within enterprise applications: Select your appand and assign all ad/azure groups you need within the "Users and Groups" menu. Select the according app role counterparts you've created before for each group.
  • Within app registrations: Finally, go to "Token configuration", select "add a groups claim" and only select "Groups assigned to the application" and nothing else.

The ID you'll set in each SSO Group within PRTG will still be the Object ID of the according azure group.

There is one major downside though:
Claims by app roles will ignore nested group members meaning that each and every member has to be a direct member of the ad/azure group. If your environment wouldn't allow for this (or you simply don't want to assign each user directly) you could:

  1. Use a dynamic azure group which automatically assigns users to itself based on rules/properties you provide (like a specific string in an extenionattribute). Unfortunatley you cannot create groups based on current group membership as the memberOf property is not available for dynamic groups.
  2. Assign Users via a script/scheduled task/etc.

Created on Oct 14, 2021 6:01:22 PM



Votes:

1

Is there a timeframe for SSO support for PRTG Desktop?

Created on Dec 17, 2021 3:47:02 PM



Votes:

0

I'm one of the unlucky ones not able to login when using a group claim.

This gets logged on the server:

LoginTrace> Core.BL.Users.Security.AuthorizationProvider.SSO.IsAuthorized: user <[email protected]:........> is no member of SSO groups allowed by PRTG

But the user is in the Azure group I used (copying the group ID) in the "SSO Group Access Claim" setting of the PRTG group. The exact same user and group work perfectly with PRTG AD integration (we have our local AD in sync with Azure AD).

If I change the "SSO Group Access Claim" setting of the PRTG group to the API name instead of the group ID, then the user can login but (didn't test it) with no groups restrictions now anyone can login.

So I have to keep using the local AD integration until Azure groups work.

Created on Dec 30, 2021 8:26:00 PM



Votes:

0

Just tested it again and I've found out that it actually works with groups clams!

What I didn't understand is that the "Log in with single sign-on" button really means single.

What I did wrong was typing the Login Name and Password in the login form and then pressing the sing-on button. Leaving those fields empty and just pressing the sign-on button it works! Actually entering anything in those fields seems to break the login even if the browser cached credentials are correct (i.e. the cached user is in a group allowed to login to PRTG)

One big warning is that if the browser has any Azure login cached (like I have), it will use it transparently and if that cached user is not one allowed to login to PRTG, you'll get the "Your login via SSO has failed. Please contact your administrator!" error, with no redirection to microsoft to logout from azure and login with different credentials.

The only solution I've found is to go the microsoft url where the Azure login credentials were cached (e.g. office.com or azure.com) and perform a logout. Going back to PRTG and just pressing the sign-on button will redirect the browser to microsoft and you'll get prompted for the Azure credentials.

Created on Dec 30, 2021 9:03:04 PM

Last change on Dec 30, 2021 9:03:04 PM



Votes:

0

Hello Rob,

Thanks for this information.

Yes, the intended scenario is to access PRTG webpage and click in "Log in with single sign-on" to be redirected to Azure to authenticate. As you mentioned if there are credentials cached most likely the same browser will use them to attempt to login to PRTG.

Hope this helps.

Regards,

Miguel Aikens

Created on Jan 3, 2022 10:52:07 PM by  Miguel Aikens [Paessler Technical Support]



Votes:

0

Is there a timeframe for SSO support for PRTG Desktop?


Hello @Ismael,

We are aware that PRTG Desktop is missing this feature, but there are currently no plans to implement it this year. This doesn't mean that it doesn't come in general, but that other features and tasks are more prioritized.

Best,
Sebastian

Created on Jan 5, 2022 11:39:34 AM by  Sebastian Kniege [Paessler Support]



Votes:

0

Hello all,

I'm receiving the following error: Your login via SSO has failed. Please contact your administrator! In the core.log I found this reference: 5896 Core> TLogonSSOProxy.CheckAuthentication: token validity checks failed: 5896 Core> TLogonSSOProxy.CheckAuthentication: Validation from AccessToken failed! 5896 Core> TLogonSSOProxy.CheckAuthentication: TSSOValidatorCommandSignature: Signature <jS1Xo1OWDj_52vbwGNgvQO2VzMc> could not verified! 5896 Core> TLogonSSOProxy.CheckAuthentication: TSSOValidatorCommandIssuer: The iss of the JWT does not match the Issuer in the configuration! 5896 Core> TLogonSSOProxy.CheckAuthentication: aborting due to failed checks

Anyone know what I did wrong? I have double and tripple check the app settings and got our global admin to approve the app for the company.

Kind regards, Alex

Created on May 6, 2022 1:40:12 AM



Votes:

0

Hi Alex,

Based on our experience, the error message leads to step 1.5 (Add a scope) or step 1.6 (Edit accessTokenAcceptedVersion) of the how-to guide above and I would recommend checking the settings here once again.
I've also seen cases where creating a new Scope solved the issue.

Best,
Sebastian

Created on May 13, 2022 9:39:27 AM by  Sebastian Kniege [Paessler Support]



Votes:

0

It's a shame there doesn't appear to have been any refinements of this process. Following further investigations my issue relates in particular to use of accounts that don't use our default azure/365 domain, accounts using the .onmicrosoft domain work fine, anything outside of that fails with the "Your login via SSO has failed. Please contact your administrator!" error.
Does anybody have a fix for this, or where I might be going wrong?
Outside this, 365 group to PRTG role is working fine.

Created on May 19, 2022 8:25:15 AM

Last change on May 23, 2022 11:55:55 AM by  Sebastian Kniege [Paessler Support]



Votes:

0

When you finally integrate SSO O365 with azure, does the local users remain intact and enable to access the prtg web portal?, or you have to configure again that users with new azure users to login and manage again? thanks

Created on Jun 3, 2022 10:47:58 AM



Votes:

0

Hello JPS,

Yes, the local user accounts and settings persist.


Kind regards,
Felix Saure, Tech Support Team

Created on Jun 9, 2022 9:07:43 AM by  Felix Saure [Paessler Support]



Votes:

0

Got SSO working for the webpage but I get a 'can't receive passhash' on the android app. Is SSO supported on the android and IOS app? This is a bit of a showstopper because our IT security department demands that we enable MFA on PRTG.

Created on Jul 28, 2022 10:07:08 AM



Votes:

0

Hello Pieter_G,

I'm afraid that our mobile apps do not support MFA in the current version. Using the web interface on the mobile device would be the only way to force MFA at the moment.

Kindly also take a look at this Feature Request you can vote on: https://kb.paessler.com/en/topic/90177-multi-factor-authentication-mfa-for-prtg-mobile-apps


Kind regards,
Felix Saure, Tech Support Team

Created on Jul 29, 2022 6:24:02 AM by  Felix Saure [Paessler Support]



Votes:

0

After setting all of this up, I'm getting a login failure.

I've set up the Login Trace Debugging, and I'm getting the following in core.log:

Core.BL.Users.Security.AuthorizationProvider.SSO.IsAuthorized: user <[email protected]:RandomString> is no member of SSO groups allowed by PRTG.

I'm not sure what I'm doing wrong here. Could someone point me in the right direction?

Created on Aug 3, 2022 9:28:39 PM

Last change on Aug 4, 2022 5:48:31 AM by  Felix Wiesneth [Paessler Support]



Votes:

0

Hello Joseph,

This basically means that the Azure Scope was deleted / renamed, or at least does not match with an existing user group which is configured to use Azure.

So I recommend to check if the scope is configured correctly and to then see if this matches with the user group created in PRTG.


Kind regards,
Felix Saure, Tech Support Team

Created on Aug 4, 2022 8:23:20 AM by  Felix Saure [Paessler Support]



Votes:

2

I figured it out, I was putting in the full api:<client-ID>/<scope-name> instead of just the OID of a group in Azure, or just the scope name. Thanks for your help!

Created on Aug 4, 2022 3:24:46 PM



Votes:

0

Hi,

i made all the settings and testing the SSO settings results in a http 200 ok. I turned on debugmode.

When login with a SSO-user it says: Your login via SSO has failed. Please contact your administrator!

Debugpart: 2022-08-31 14:15:08.314017 ERRR TId 15276 Core> TLogonSSOProxy.CheckAuthentication: extract json values failed: 2022-08-31 14:15:08.314017 ERRR TId 15276 Core> refreshToken not received 2022-08-31 14:15:08.314017 DEBG TId 15276 LoginTrace> Core.BL.Users.Security.AuthenticationProvider.TAuthenticationProviderSSO.Authenticate: user <> could not be parsed in token, exiting... 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> Core.BL.Users.Security.OverloadProtection.RecordAuthenticationResult: start 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> Core.BL.Users.Security.OverloadProtection.RecordAuthenticationResult: got login identification 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> Core.BL.Users.Security.OverloadProtection.RecordAuthenticationResult: authentication was NOT successful, record attempt in tracking information 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> Core.BL.Users.Security.OverloadProtection.RecordAuthenticationResult: record attempt in tracking information done 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> Core.BL.Users.Security.OverloadProtection.RecordAuthenticationResult: end 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> Core.BL.Users.Authentication.Authenticate: authentication result recorded for overload protection 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> Core.BL.Users.Authentication.Authenticate: authentication done, duration: 687 ms 2022-08-31 14:15:08.329639 DEBG TId 15276 LoginTrace> login finished at 31-8-2022 14:15:08, took 687 ms

Created on Aug 31, 2022 2:23:13 PM

Last change on Sep 2, 2022 4:55:55 AM by  Sasa Ignjatovic [Paessler Support]



Votes:

0

Hello danieboog,

We would need to take a closer look at your configuration in order to troubleshoot this. Because of that please open a support ticket for this issue. If your PRTG server has internet access, you can do that by going to Setup>Contact Support. Otherwise you can send us a email at [email protected].


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Sep 2, 2022 5:06:41 AM by  Sasa Ignjatovic [Paessler Support]



Votes:

0

Hi,

I need clarity on the setting up the SSO in Azure: Step 1.4: Create a groups claim Step 1.5: Add a scope

Our current setup is that we have PRTG, with local ad user group. One is a admin group and the other is read-only.

Once I create new SSO PRTG admin and Read-only group, how do I reference these? do these need to be added in step 1.5?

Also will the current setp, will the users continue to work even if SSO is enabled? As I do not want to lock out users.

Created on Jan 9, 2023 10:15:04 AM



Votes:

0

Hello Andor,

When you create a SSO group in PRTG you can use the "Scope" that you defined as the "SSO Claim" in which case all Azure SSO users will be able to login. Or you can use the object ID of the Azure user group as the "SSO claim", then only users from that group will be able to login.

As for your other question. Your other users (AD or local PRTG users) will still be able to login like before.


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Jan 10, 2023 9:32:30 AM by  Sasa Ignjatovic [Paessler Support]



Votes:

0

Hi Sasa

Thank you for your reply. I have figured out why I could not get the Object ID of the group when entered working compared to using the scope name for a new group.

As pointed out by another member above, you need to configure Token Configuration within Azure app registration you created, add a groups claim, then select security groups. save this

Now new groups with the SSO claim being the Object ID of the group will work, allowing you to distinguish between admin and view only users if required.

Created on Jan 10, 2023 1:01:08 PM



Votes:

0

Like many here, I appreciate that SSO is now an option, however implementing in this byzantine SAML claim method rather than using the well-known App Roles method in Azure is baffling to me. Was there a specific reason it wasn't implemented the "tried and true" way? Some sort of limitation? I should be able to define groups as roles, tie my roles to my Azure AD users/groups, like I do every other app, why does it need to query my groups directly and require me to maintain hard objectID reference matches?

Not to mention it would make the setup process a lot simpler than all these extra steps.

Created on Jan 27, 2023 1:18:14 AM



Votes:

0

@jgrote,

Do I understand you correctly that you want to utilize Azure Roles to "tie" Azure accounts to PRTG groups?


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Jan 31, 2023 1:28:45 PM by  Sasa Ignjatovic [Paessler Support]



Votes:

0

Hi there,

I've followed this documentation however when I get to the end of the SSO configuration within PTRG and hit the 'Test Single Sign On Authorization Endpoint' button I get an error 'Ajax Error PE1002'

We've looked at the firewalls and can't see anything being blocked, also I can reach login.microsoftonline.com

Any suggestions as to what this could be?

Created on Feb 1, 2023 12:07:08 PM



Votes:

0

@Rich_Stevens,

Did you make sure that you entered your "Authorization Endpoint" in PRTG correctly?


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Feb 6, 2023 6:37:19 AM by  Sasa Ignjatovic [Paessler Support]



Votes:

0

Hello! I have two questions.

  1. Does enabling SSO disable local sign in?
  2. If a user is present in PRTG locally with username: username and email: [email protected] and the matching user in Azure tries to log in with SSO, will PRTG create a new user for this person and delete the local user, create a new user and leave the local user intact, or use SSO for login without creating a new user but instead logging in as the matching local user?

Thanks!

Created on Apr 20, 2023 8:34:59 PM

Last change on Apr 21, 2023 1:35:28 PM by  Felix Wiesneth [Paessler Support]



Votes:

0

@mruvalcaba

1. SSO does not disable the other login options. So even if you have SSO enabled, you can still login using your local accounts, or AD accounts.

2. Login names need to be unique in PRTG. So if your SSO account would have the same login name as a local account, the login with the SSO account would most likely fail. In such cases we recommend to change the login name for the local account.


Kind regards,
Sasa Ignjatovic, Tech Support Team

Created on Apr 24, 2023 7:31:24 AM by  Sasa Ignjatovic [Paessler Support]



Votes:

0

I'm still receiving the following error even if the scope and manifest are configured correctly: Your login via SSO has failed. Please contact your administrator! In the core.log the following lines: 5896 Core> TLogonSSOProxy.CheckAuthentication: token validity checks failed: 5896 Core> TLogonSSOProxy.CheckAuthentication: Validation from AccessToken failed! 5896 Core> TLogonSSOProxy.CheckAuthentication: TSSOValidatorCommandSignature: Signature <jS1Xo1OWDj_52vbwGNgvQO2VzMc> could not verified! 5896 Core> TLogonSSOProxy.CheckAuthentication: TSSOValidatorCommandIssuer: The iss of the JWT does not match the Issuer in the configuration! 5896 Core> TLogonSSOProxy.CheckAuthentication: aborting due to failed checks

Does someone know what i am doing wrong? Tried creating a new scope, edited the manifest from 2 back to null and back again. Am I missing something?

Created on May 22, 2023 12:38:25 PM



Votes:

0

Hello there
Please open a ticket with us to further evaluate this issue with more information

Created on May 29, 2023 7:20:05 PM by  Luis Quesada (Paessler Technical Support)



Votes:

0

@sasa

Sorry for the delay in reply. Correct, I would like a radio option for group selection for access token to use the roles claim rather than the groups claim. The reasons for this are many-fold:

1. The complicated API and scope setup is not necessary as PRTG does not need to interrogate the groups nor need permissions, they are right there available.

2. Roles are app-local and can consist of users, groups, and applications

3. Groups in and of themselves can be added to the role claim via a setting in the application, so having groups specifically isn't even necessary.

Please see this article for more detail and consult with your dev team, shouldn't be much of a lift (you simply get a list of roles from the roles claim and then match those to the SSO claim field for the user) https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-apps

Created on Sep 20, 2023 5:37:01 PM




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.