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.
300.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

Setup for MFA authentication through a 2016 WAP server

Votes:

0

Your Vote:

Up

Down

Recently I have been tasked with setting up MFA for various infrastructure servers with high-level or very broad access. I was able to do this with the PRTG server website by rehosting it on an internal 2016 WAP server and authenticating through AD FS with the Azure AD MFA extension.

This is not a supported scenario like the reverse proxy or load balancer setup (https://blog.paessler.com/take-advantage-of-reverse-proxies-and-load-balancers-for-prtg-how-it-works), but replacing the reverse proxy with a WAP server is basically the same concept. Unlike the reverse proxy, the WAP requires AD FS.

It takes two logins because I cannot figure out how to make PRTG take Integrated Windows Authentication so that it passes through, but it works.

adfs mfa prtg prtg-website wap

Created on Jan 2, 2020 8:47:35 PM by  Michael Finney (0) 1

Last change on Mar 2, 2020 12:43:08 PM by  Maike Guba [Paessler Support]



Best Answer

Accepted Answer

Votes:

1

Your Vote:

Up

Down

Enabling MFA for PRTG through a WAP server


Important notice: This approach is not officially supported by Paessler.
The configuration may have adverse effects on mini probes, remote probes, HTTP Push sensors, and connections with PRTG Desktop and mobile apps, since these cannot handle the additional request for authentication.


To enable multi-factor authentication (MFA) for PRTG through a Web Application Proxy (WAP) server, take the following steps:

  • Step 1: Install the Remote Access role on the WAP server
  • Step 2: Configure the WAP to connect to an AD FS server
  • Step 3: Add a new Relying Party Trust on the AD FS server
  • Step 4: Import external certificate into the WAP server
  • Step 5: Publish a new application through the Remote Access Management Console on the WAP server
    • Step 5a: Publish settings with different external and internal URLs

Step 1: Install the Remote Access role on the WAP server

  1. On the WAP server, open the Server Manager console.
  2. Click Manage.
  3. Click Add Roles and Features to open the Add Roles and Feature Wizard.
  4. On the Installation Type page, select Role-based or feature-based installation. Click Next.
  5. On the Server Selection page, select your AD FS server. Click Next.
  6. On the Server Roles page, enable the check box next to Active Directory Federation Services and next to Remote Access. Click Next.
  7. Click through the next pages until you reach the Role Services page.
  8. On the Role Services page, enable the check box next to Web Application Proxy and click Add Features. Click Next.
  9. On the Confirmation page, click Install and wait for the installation to finish.
  10. Click the Open the Web Application Proxy Wizard link and continue with Step 2: Configure the WAP to connect to an AD FS server.

Step 2: Configure the WAP server to connect to an AD FS server

  1. In the Web Application Proxy Configuration Wizard, go to the Federation Server page.
  2. Enter the fully qualified domain name (FQDN) of your AD FS server as federation service name and the credentials of a local administrator account on your AD FS server.
  3. On the AD FS Proxy Certificate page, select a certificate to be used by the AD FS proxy from the list of certificates that are installed on the WAP server. Click Next.
  4. On the Confirmation page, click Configure and wait for the configuration of the WAP to finish, then click Close.

Step 3: Add a new Relying Party Trust on the AD FS server

  1. On the AD FS server, add a new Relying Party Trust and select Claims aware. Click Start.
    Note: Selecting the option Non claims aware assumes Integrated Windows Authentication on the backend.
  2. On the Select Data Source page, select Enter data about the relying party manually. Click Next.
  3. On the Specify Display Name page, enter a display name, for example, PRTG. Click Next.
  4. Click through the following pages. Do not enable the check boxes for the WS-Federation Passive protocol or the SAML 2.0 WebSSO protocol.
  5. On the Configure Identifiers page, enter the URL of the PRTG core server as relying party trust identifier. If you have enabled SSL encryption for the PRTG website, the URL must start with https. Click Next.
  6. On the Choose Access Control Policy page, select an access control policy that requires MFA, if desired. Click Next.
  7. Finish.

Step 4: Import external certificate into the WAP server

Copy the certificate file in .pfx format from the PRTG core server to the WAP server and import it to the local certificate store there.

Step 5: Publish a new application through the Remote Access Management Console on the WAP server

  1. Open the Remote Access Management Console on the WAP server and click Web Application Proxy, then click Publish to open the Publish New Application Wizard. Click Next.
  2. On the Preauthentication page, select Active Directory Federation Services (AD FS) as preauthentication method. Click Next.
  3. On the Relying Party page, select the Relying Party Trust that you created in Step 3: Add a new Relying Party Trust on the AD FS server from the list of relying parties. Click Next.
  4. On the Publishing Settings page, enter a meaningful name, for example, PRTG, and the external URL for the application. In the list of external certificates, select the certificate that you imported into the WAP server in Step 4: Import external certificate into the WAP server. As backend server URL, enter the internal URL.
    Note: You can use the same external and internal URLs by having a CNAME in DNS point to the WAP server, then adding the same name to the hosts file on the WAP to point to the IP address of the PRTG core server. If the internal and external URLs are different, you need to take some additional steps. For more information, see Step 5a: Publish settings with different external and internal URLs. Click Next.
  5. On the Confirmation page, click Publish and wait for the application to be published successfully, then click Close.

Step 5a: Publish settings with different external and internal URLs

If you have different external and internal URLs, you need to run some PowerShell commands on the WAP server.

  1. Run a PowerShell prompt as administrator.
  2. Run the following command using the name that you entered when publishing the application in Step 5: Publish a new application through the Remote Access Management Console on the WAP server. In this example, the name is PRTG.
    Get-WebApplicationProxyApplication -Name "PRTG" | fl *
    You should see two properties that you need to change:
    DisableTranslateUrlInRequestHeaders : False
    DisableTranslateUrlInResponseHeaders : False
  3. Run the following commands to change the respective properties to true:
    Get-WebApplicationProxyApplication -Name "PRTG" | Set-WebApplicationProxyApplication - DisableTranslateUrlInRequestHeaders:$true Get-WebApplicationProxyApplication -Name "PRTG" | Set-WebApplicationProxyApplication - DisableTranslateUrlInResponseHeaders:$true

See also

Microsoft article: Install and Configure the Web Application Proxy Server

More

Enabling MFA for PRTG is also possible through an Azure Active Directory’s Application Proxy. For more information, see this Microsoft article: Remote Access to on-premises applications through Azure Active Directory’s Application Proxy.


Thanks to Michael Finney for sharing this approach with us.

Created on Mar 2, 2020 12:33:00 PM by  Maike Guba [Paessler Support]

Last change on Mar 2, 2020 12:46:04 PM by  Maike Guba [Paessler Support]



4 Replies

Votes:

0

Your Vote:

Up

Down

Obviously this is not a supported scenario just like the reverse proxy or load balancer setup https://blog.paessler.com/take-advantage-of-reverse-proxies-and-load-balancers-for-prtg-how-it-works but replacing the reverse proxy with a WAP server is basically the same concept. Possibly a little easier if you already have ADFS in the environment but the WAP requires ADFS unlike the reverse proxy being standalone.

On the ADFS server, make a new Relying Party Trust. I chose Claims Aware because Non Claims Aware assumes Windows Integrated Authentication on the back end. Enter the data manually. Enter a display name like "PRTG" or whatever you wish. Click through the options, don't select anything for WS-FED or SAML2. Enter the PRTG server URL for the identifier with https if you have it set up on the PRTG server. Choose an Access Control Policy with MFA if desired. Finish.

I copied the same .pfx certificate from the PRTG server to the WAP. I imported it in the local cert store there. Next, publish a new application through Remote Access Manager. Choose ADFS Pre-authentication. Choose the same Relying Party Trust created above. Enter a name, the external URL you want to use, pick the certificate, http-to-https if desired, and the internal URL. If the internal and external URLs are different there are some extra steps. I used the same external and internal by having a CNAME in DNS point to the WAP server, then adding the same name to the hosts file on the WAP to point to the IP address of the PRTG server. I have HTTPS for both URLs. It works perfectly so far.

If you have different URLs for external and internal, then you will need to run some powershell commands on the WAP. Open an admin powershell prompt and run this command using the published application name you used.
Get-WebApplicationProxyApplication -Name "PRTG" | fl *
You should see two properties that need to change.

DisableTranslateUrlInRequestHeaders : False
DisableTranslateUrlInResponseHeaders : False

Run these commands to change them to True.

Get-WebApplicationProxyApplication -Name "PRTG" | Set-WebApplicationProxyApplication -DisableTranslateUrlInRequestHeaders:$true

Get-WebApplicationProxyApplication -Name "PRTG" | Set-WebApplicationProxyApplication -DisableTranslateUrlInResponseHeaders:$true

That is it so far. If anyone can figure out a better way I would definitely appreciate it but this will work for now until we see what PRTG does for MFA within the application.

Created on Jan 3, 2020 7:15:49 PM by  Michael Finney (0) 1

Last change on Feb 7, 2020 5:15:29 PM by  Benjamin Day [Paessler Support]



Accepted Answer

Votes:

1

Your Vote:

Up

Down

Enabling MFA for PRTG through a WAP server


Important notice: This approach is not officially supported by Paessler.
The configuration may have adverse effects on mini probes, remote probes, HTTP Push sensors, and connections with PRTG Desktop and mobile apps, since these cannot handle the additional request for authentication.


To enable multi-factor authentication (MFA) for PRTG through a Web Application Proxy (WAP) server, take the following steps:

  • Step 1: Install the Remote Access role on the WAP server
  • Step 2: Configure the WAP to connect to an AD FS server
  • Step 3: Add a new Relying Party Trust on the AD FS server
  • Step 4: Import external certificate into the WAP server
  • Step 5: Publish a new application through the Remote Access Management Console on the WAP server
    • Step 5a: Publish settings with different external and internal URLs

Step 1: Install the Remote Access role on the WAP server

  1. On the WAP server, open the Server Manager console.
  2. Click Manage.
  3. Click Add Roles and Features to open the Add Roles and Feature Wizard.
  4. On the Installation Type page, select Role-based or feature-based installation. Click Next.
  5. On the Server Selection page, select your AD FS server. Click Next.
  6. On the Server Roles page, enable the check box next to Active Directory Federation Services and next to Remote Access. Click Next.
  7. Click through the next pages until you reach the Role Services page.
  8. On the Role Services page, enable the check box next to Web Application Proxy and click Add Features. Click Next.
  9. On the Confirmation page, click Install and wait for the installation to finish.
  10. Click the Open the Web Application Proxy Wizard link and continue with Step 2: Configure the WAP to connect to an AD FS server.

Step 2: Configure the WAP server to connect to an AD FS server

  1. In the Web Application Proxy Configuration Wizard, go to the Federation Server page.
  2. Enter the fully qualified domain name (FQDN) of your AD FS server as federation service name and the credentials of a local administrator account on your AD FS server.
  3. On the AD FS Proxy Certificate page, select a certificate to be used by the AD FS proxy from the list of certificates that are installed on the WAP server. Click Next.
  4. On the Confirmation page, click Configure and wait for the configuration of the WAP to finish, then click Close.

Step 3: Add a new Relying Party Trust on the AD FS server

  1. On the AD FS server, add a new Relying Party Trust and select Claims aware. Click Start.
    Note: Selecting the option Non claims aware assumes Integrated Windows Authentication on the backend.
  2. On the Select Data Source page, select Enter data about the relying party manually. Click Next.
  3. On the Specify Display Name page, enter a display name, for example, PRTG. Click Next.
  4. Click through the following pages. Do not enable the check boxes for the WS-Federation Passive protocol or the SAML 2.0 WebSSO protocol.
  5. On the Configure Identifiers page, enter the URL of the PRTG core server as relying party trust identifier. If you have enabled SSL encryption for the PRTG website, the URL must start with https. Click Next.
  6. On the Choose Access Control Policy page, select an access control policy that requires MFA, if desired. Click Next.
  7. Finish.

Step 4: Import external certificate into the WAP server

Copy the certificate file in .pfx format from the PRTG core server to the WAP server and import it to the local certificate store there.

Step 5: Publish a new application through the Remote Access Management Console on the WAP server

  1. Open the Remote Access Management Console on the WAP server and click Web Application Proxy, then click Publish to open the Publish New Application Wizard. Click Next.
  2. On the Preauthentication page, select Active Directory Federation Services (AD FS) as preauthentication method. Click Next.
  3. On the Relying Party page, select the Relying Party Trust that you created in Step 3: Add a new Relying Party Trust on the AD FS server from the list of relying parties. Click Next.
  4. On the Publishing Settings page, enter a meaningful name, for example, PRTG, and the external URL for the application. In the list of external certificates, select the certificate that you imported into the WAP server in Step 4: Import external certificate into the WAP server. As backend server URL, enter the internal URL.
    Note: You can use the same external and internal URLs by having a CNAME in DNS point to the WAP server, then adding the same name to the hosts file on the WAP to point to the IP address of the PRTG core server. If the internal and external URLs are different, you need to take some additional steps. For more information, see Step 5a: Publish settings with different external and internal URLs. Click Next.
  5. On the Confirmation page, click Publish and wait for the application to be published successfully, then click Close.

Step 5a: Publish settings with different external and internal URLs

If you have different external and internal URLs, you need to run some PowerShell commands on the WAP server.

  1. Run a PowerShell prompt as administrator.
  2. Run the following command using the name that you entered when publishing the application in Step 5: Publish a new application through the Remote Access Management Console on the WAP server. In this example, the name is PRTG.
    Get-WebApplicationProxyApplication -Name "PRTG" | fl *
    You should see two properties that you need to change:
    DisableTranslateUrlInRequestHeaders : False
    DisableTranslateUrlInResponseHeaders : False
  3. Run the following commands to change the respective properties to true:
    Get-WebApplicationProxyApplication -Name "PRTG" | Set-WebApplicationProxyApplication - DisableTranslateUrlInRequestHeaders:$true Get-WebApplicationProxyApplication -Name "PRTG" | Set-WebApplicationProxyApplication - DisableTranslateUrlInResponseHeaders:$true

See also

Microsoft article: Install and Configure the Web Application Proxy Server

More

Enabling MFA for PRTG is also possible through an Azure Active Directory’s Application Proxy. For more information, see this Microsoft article: Remote Access to on-premises applications through Azure Active Directory’s Application Proxy.


Thanks to Michael Finney for sharing this approach with us.

Created on Mar 2, 2020 12:33:00 PM by  Maike Guba [Paessler Support]

Last change on Mar 2, 2020 12:46:04 PM by  Maike Guba [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I've setup an Azure AD Application to punch a hole through our firewall to PRTG. To get the iOS app working, I had to disabled pre-auth, which means I'm relying on PRTG authentication only but not getting the Azure AD security features. (I have 2FA enabled on Azure AD)

What I would like it to do is utilise Azure AD auth on Azure app proxy but with support for the PRTG iOS app. Doesn't look like this works at present but it would enable great security if the app was given the ability to work with the auth.

Maybe this helps https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/application-proxy-secure-api-access

Any chance we can get this on the PRTG app roadmap?

Created on Mar 16, 2020 8:17:22 PM by  chrisproud (0)



Votes:

0

Your Vote:

Up

Down

Chris,

The best way to accomplish this would be to open a Feature Request for this.

PRTG Feature Requests

Thanks!

Benjamin Day
[Paessler Support]

Created on Mar 17, 2020 5:41:16 PM by  Benjamin Day [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.