If you want to publish your Web App to the internet, you ideally should not directly NAT port 443 (or you custom HTTPS port) to you internal server. Instead, there should be a Reverse Proxy in a DMZ that accepts requests and then routes them to the internal server. You need to configure a Reverse Proxy with nginx or IIS.

Here is how you can do it with IIS.

Install IIS Role in Server Manager (Add Roles and Features > Web Server (IIS)

Download and install URL Rewrite and Application Request Routing (ARR)

https://iis-umbraco.azurewebsites.net/downloads/microsoft/url-rewrite

https://iis-umbraco.azurewebsites.net/downloads/microsoft/application-request-routing

In IIS Manager, stop Default Website:

Create a new Website:

Make sure you configure your parameters. The host name should be the public DNS name.

Now open URL Rewrite and create a new rule.

Enter the ip of the internal server along with the port.

View Server Variables and add HTTP_HOST and HTTP_Authentication-Context-Policy as a variable.

Go back to rules and double click on the rule you just created.

Open server variables and add the application’s host name under HOST_NAME.

Add another variable with the name HTTP_Authentication-Context-Policy and value of internet

You should have variables.

Apply settings at the top right.

Next, select the server and open Configuration Editor:

Go to section System.Webserver/Proxy

Set preserveHostHeader to true and reverseRewriteHostInResponseHeaders to false

Apply changes at the top right.

Bonus: Increase timeout if bigger data chunks are sent to the client.

On the site, open Configuration Editor

Open Section system.web/Sessionstate

In stateNetworkTimeout increase value to 01:00 or higher.

Don’t forger to apply changes and restart IIS.

Sophos SG/XG Firewalls use OpenVPN to create Site To Site SSL VPN tunnels, but the configuration file is specific to Sophos firewalls. This can be converted to a normal ovpn file though.

Here is how you can manually convert the APC configuration file into an OVPN file.

Take now of these things in your apc file:

Block 1 is the client certificate:

—–BEGIN CERTIFICATE—–

—–BEGIN CERTIFICATE—–

Block 2 is the CA certificate:

—–BEGIN CERTIFICATE—–

—–BEGIN CERTIFICATE—–

Block 3 is the private key:

—–BEGIN PRIVATE KEY—–

—–END PRIVATE KEY—–

Block 4: there is also a username and password:

Just above the private key is the user:

Just below the private key is the password:

So now here is the ovpn file:

client
dev tun
proto tcp
remote insert hostname or IP of the firewall here 443
route remote_host 255.255.255.255 net_gateway
resolv-retry infinite
nobind
persist-key
persist-tun
auth-user-pass
cipher AES-128-CBC
auth SHA256
comp-lzo
route-delay 4
verb 3
reneg-sec 0
<cert>

Insert certificate here from Block 1

</cert>

<ca>

Insert certificate here from Block 2

</ca>

<key>

Insert private key from Block 3

</key>

Here is a short test with OpenVPN client on Windows. The password has to be inserted manually, but normally the tunnel gets initiated from a firewall/network appliance, in that case you should be able to insert username and password in the command line.

If you get the error 0x0000011b on Windows 7 and later clients after updating your print server, here is a registry key that might help you:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Print
DWORD RpcAuthnLevelPrivacyEnabled 0

The key needs to be set on your print server. Remember that by setting this key, you will effectively re-open the print nightmare security flaw by downgrading your security level on the server. If you want a persistent fix, you should use type 4 printer drivers, which do not need admin rights on the client side. Admin rights are needed if you have type 3 printer drivers.

References:

https://docs.microsoft.com/en-us/answers/questions/563223/windows-cannot-connect-to-the-printer-error-0x0000.html

Azure AD App Proxy allows you to publish an internal website to the internet. It is easy to set up and does not require inbound firewall rules. Traditionally, you would publish a website with the help of a reverse proxy, for example with Citrix Netscaler/ADC, KEMP Loadbalancer or F5.

In the Azure AD Portal (aad.portal.azure.com) open Application Proxy and firstly install the software on a server in the corporate network. Domain join is not a requirement, but is needed if you use Kerberos authentication.

You will need to log in with your tenant admin (or a M365 user that has the appropriate role).

After the installation, you should see the server in Azure AD App Proxy:

To then publish your site, select + Configure an app

Provide the internal URL along with the protocol (HTTPS or HTTP). You could select Azure AD in Pre Authentication and work with conditional access policies and require MFA for example. This example is using Passthrough Authentication.

Also some basic settings can be changed. To publish the site, hit + Add

After a few minutes, your site should be available:

You can also configure custom domains by verifying your domain(s) in Microsoft 365 by uploading your public certificate with the private key (pfx) and configuring the appropriate DNS record. For detailed information, check out the Microsoft docs below.

References:

https://docs.microsoft.com/en-us/azure/active-directory/app-proxy/application-proxy

When syncing local AD users to Azure AD, you can configure Seamless Sign-On to automatically login to Microsoft 365 Apps like Sharepoint Online, OneDrive, or Exchange Online. This is very easy to do and will make logins for users less painful.

Assuming Azure AD Connect is already set up with Pass-through authentication (see https://www.ajni.it/2021/05/configuring-azure-ad-connect-for-user-synchronization/), just open Azure AD Connect and then hit “change user sign-in” and log in with an Azure AD Global admin. After that, select “Enable single sign-on”.

Enter Domain Admin credentials.

When the pre-checks is complete, hit configure and exit.

A Computer Account named AZUREADSSOACC will be created in Active Directory which allows the authentication validation between Azure AD and local Active Directory. The Kerberos decryption key is saved in the cloud and should be changed regularly. You can see that on the Computer account, service principal names are configured

Lastly, you can roll out the feature with Group Policy. The URL https://autologon.microsoftazuread-sso.com must be added to the intranet zone list, which allows the browser to send Kerberos tickets to that site.

The GPO can be found under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List.

Status bar updates via script must be also enabled. This GPO is located under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone > Allow updates to status bar via script.

You can test the feature by opening portal.office.com. After entering the username, login should be done automatically without needing to insert a password.

References:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start