What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

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 Azure Active Directory into PRTG?

Votes:

1

Your Vote:

Up

Down

I want to use Azure AD as SSO provider for PRTG. How can I do this? What steps are necessary?

active-directory azure-ad prtg sso

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



52 Replies

Accepted Answer

Votes:

1

Your Vote:

Up

Down

This article applies as of PRTG 22

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

How to integrate Azure Active Directory into PRTG

As of PRTG 21.2.68, you can use Azure Active Directory (Azure AD) as single sign-on (SSO) provider in PRTG. For the integration to work seamlessly, follow the steps in this article.

Steps to take:

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

Step 1: Configure Azure AD

Follow these steps to configure Azure AD 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

  • Log in to the Azure Portal under https://portal.azure.com.
  • Select Azure Active Directory under Azure services.
  • Go to the App registrations tab.
    App Registrations TabClick to enlarge.
  • 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.
      Register an AppClick to enlarge.
    • 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 ID and Tenant IDClick to enlarge.

Step 1.2: Create a client secret

  • Go to the Certificates & secrets tab.Certificates & Secrets TabClick to enlarge.
    Click the New client secret button.Add a Client Secret
    Click to enlarge.
    • 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: 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

  • Go to the Authentication tab.Add a PlatformClick to enlarge.
  • Click the Add a platform button.Configure PlatformsClick to enlarge.
  • Select Web.Configure WebClick to enlarge.
    • 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 the Continue button to continue.

Step 1.4: Add a groups claim

  • Go to the Token Configuration tab.Token Configuration TabClick to enlarge.
  • Click the Add groups claim button.Add Groups Claim Click to enlarge.
    • Select Security groups and Directory roles.
    • Click the Add button to save the new groups claim.

Step 1.5: Add a scope

  • Go to the Expose an API tab.Expose an API TabClick to enlarge.
    • Click the Add a scope button.Add a ScopeClick to enlarge.
    • Enter an Application ID URI.
    • Click the Save and continue button.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

  • Go to the Manifest tab.Edit ManifestClick to enlarge.
    • Change accessTokenAcceptedVersion = 0 to accessTokenAcceptedVersion = 2

You have now successfully configured Azure AD.


Step 2: Configure SSO in PRTG

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


Important: 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.


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.

  • Log in to the PRTG web interface.
  • Go to Setup | System Administration | User Groups.
  • Hover over the blue + button and select Add User Group.User Group SettingsClick to enlarge.
    • Under User Group Name, give the group a meaningful name, for example Azure AD 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, select Azure Active Directory, 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 Azure AD as SSO provider in PRTG.

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

Last change on Jun 30, 2022 12:07:20 PM by  Brandy Greger [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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 by  Rixius (10) 1



Votes:

1

Your Vote:

Up

Down

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 by  AuRiSmith (90)



Votes:

1

Your Vote:

Up

Down

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 by  AuRiSmith (90)



Votes:

1

Your Vote:

Up

Down

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 by  Mike Garb (24) 1



Votes:

1

Your Vote:

Up

Down

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:

7

Your Vote:

Up

Down

@ 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 by  AuRiSmith (90)



Votes:

3

Your Vote:

Up

Down

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 by  dbekker (30)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  LWUsername (40)



Votes:

2

Your Vote:

Up

Down

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 by  Michael Schneider (44) 2



Votes:

1

Your Vote:

Up

Down

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 by  Gyslainh (10) 1



Votes:

0

Your Vote:

Up

Down

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 by  jbuschSLWSD (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  TI-INFRASERVIDORES (10)



Votes:

1

Your Vote:

Up

Down

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 by  KaiDzialas (10)



Votes:

1

Your Vote:

Up

Down

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:

1

Your Vote:

Up

Down

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 by  Jesse (10)



Votes:

0

Your Vote:

Up

Down

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 by  RolandJ (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  Jesse (10)



Votes:

0

Your Vote:

Up

Down

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 by  Jesse (10)



Votes:

0

Your Vote:

Up

Down

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 by  PJ Campos (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  ABS (0) 1

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



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  ATP (0) 1



Votes:

0

Your Vote:

Up

Down

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 by  ATP (0) 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  moncloud-prtg (10)

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



Votes:

0

Your Vote:

Up

Down

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 by  cb1ocker (0)



Votes:

1

Your Vote:

Up

Down

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 by  Alon Or (10)

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



Votes:

1

Your Vote:

Up

Down

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 by  MohnJcAfee2 (10)



Votes:

0

Your Vote:

Up

Down

Is there a timeframe for SSO support for PRTG Desktop?

Created on Dec 17, 2021 3:47:02 PM by  Ismael J. Carlo (55) 2 1



Votes:

0

Your Vote:

Up

Down

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 by  robydago (0) 1



Votes:

0

Your Vote:

Up

Down

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 by  robydago (0) 1

Last change on Dec 31, 2021 10:57:39 AM by  robydago (0) 1



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  AlexU (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  LWUsername (40)

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



Votes:

0

Your Vote:

Up

Down

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 by  jps75 (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  Pieter_G (0)



Votes:

0

Your Vote:

Up

Down

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

Your Vote:

Up

Down

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 by  JosephAM (10)

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



Votes:

0

Your Vote:

Up

Down

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:

1

Your Vote:

Up

Down

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 by  JosephAM (10)



Votes:

0

Your Vote:

Up

Down

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 by  danieboog (0)

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



Votes:

0

Your Vote:

Up

Down

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]



Please log in or register to enter your reply.


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.