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.

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.

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.

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

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

@ 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/

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

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

Kind regards,
Sasa Ignjatovic, Tech Support Team

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?

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?

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

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

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

Kind regards,
Matthias Kupfer - Team Tech Support

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

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

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.

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?

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!"

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.

Hello Roland,

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

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?

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!

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!

Hello Jesse,

the group claim can be configured in AzureAD.

Nice to hear that you got SSO to work.

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>

Hello PJ,

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

Hello ABS,

thank you for the input.

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

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!

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

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

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

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.

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.

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.

Is there a timeframe for SSO support for PRTG Desktop?

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.

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.

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

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

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

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

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.

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

Hello JPS,

Yes, the local user accounts and settings persist.

Kind regards,
Felix Saure, Tech Support Team

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.

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

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?

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

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!

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

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

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.

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

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.

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.

@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

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?

@Rich_Stevens,

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

Kind regards,
Sasa Ignjatovic, Tech Support Team

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!

@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

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?

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

@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