Enabling MFA on Microsoft SSTP VPN

User Rating: 5 / 5

Star ActiveStar ActiveStar ActiveStar ActiveStar Active

By turning on MFA for the microsoft SSTP VPN solution you will greatly improve the security since it basically stops anyone on internet from trying to login, they will also need the second factor to get it. With O365 you can turn on MFA authentication for most services including VPN (for a fee of course).

First follow this page: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-vpn

Note that the Microsoft link for downloading the extension does not work, it only gives you a download to a release-notes file. This is a working link at time of writing this: https://www.microsoft.com/en-in/download/details.aspx?id=54688

Also during the running the ps-script you must select "yes" for trusting untrusted repos.

Problems that can occur:

If the script  .\AzureMfaNpsExtnConfigSetup.ps1, fails complaining it can not connect to MSOOnline, try to test that separate step by running from powershell:


If that fails complaining about not being able to connect to the powershell gallery, try the below:

 [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Another problem often occuring on windows servers is that IE, that is as the default html browser, is locked down so hard it can't open any pages at all. I suggest turning this off temporary during installtion for administrators. This is done via server manager -> "Configure this local server" and there turn off "IE Enhanced Security Configuration".

Something that microsoft kind of not mention so much is that you MUST use the authenticator app, not not use one-time passwords, but allowing access by accepting via the app. I struggled for month to get this working when I realized that this was the problem.

Make sure you follow the steps below:

1. The NPS must be running on another server than the machine running the RRAS. This is because the plugin for NPS otherwise causes an infinite loop of authentications.

2. You need to create a firewall rule to allow UDP-port 1812 through. Microsoft does create such a rule when NPS is installed, but as is tradition with Microsoft tools - that rule does not work. To be sure, create also an outbount rule.

3. On windows 2019 and later you need to add some magical registry hacks on the RAS server to allow it to talk to the DHCP for getting addresses for its connecting clients:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Dhcp" /v RequiredPrivileges /d "SeChangeNotifyPrivilege"\0"SeCreateGlobalPrivilege"\0"SeImpersonatePrivilege"\0 /t REG_MULTI_SZ /f

NOTE! Restart the server after adding this regkey.

Getting private key password for winacme

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

To copy whole Let'sEncrypt certificates including private keys created by acme can be done quite simple, even though the windows builtin export certificate does not support exporting private keys for those certs.

Just go to the ProgramData folder for winacme and copy the certs from the certificates subdirectory.

Then, run winacme, type L for list certificates and select the number for the certificiate you want to import. In the page that then shows up it lists the private key password. Then just import the certificate on the new computer and enter the corresponding password gotten above.

Modern hostname lookups in Linux

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive


Finding the IP-address for a host is not as simple as it used to be when lookups was just done via the /etc/hosts file and querying  name-servers listed in /etc/resolv.conf. Nowadays the nsswitch library and the module libnss_resolve.so is talking to systemd-resolved daemon via the system DBus bus. Its has become quite hard to follow and find any problems.

This "nss-resolve"-module then communicates with the systemd-resolved daemon via DBus which in turn will use various ways of looking up a server.

The resolvconf program

Some systems use this program (package openresolv in debian) is responsible to track all possible resolvers in use. When interfaces are started by dhcp for instance, the dhcp scripts will add what ever DNS servers and tell resolvconf about it.

Resolvconf keeps a updated database of all information under /run/resolvconf. In the subdirectory interfaces, all DNS-information from interfaces are kept in a file per interface.

When running "resolvconf -u", resolvconf reads all this data and updates /etc/resolv.conf. 

It then talks to the system DBus and inform about the changes to 

You can watch dbus-communication happen with the command "dbus-monitor --system".


This system too maintains possible resolver sources. This also the process that listens to the address on many systems. Performing lookup and caching of lookups. The tool to communicat with this services is the command resolvectl. You can for instance flush all caches by running "recolvectl flush-caches"

Sources for resolv.conf

The file /etc/resolv.conf is normally just a symbolink link to the file /run/systemd/resolved/resolve.conf

Some debugging tricks

This is a simple test to talk directly to the systemd-resolved sending a simple query via dbus-send:

dbus-send --system --dest=org.freedesktop.resolve1 --type=method_call --print-reply /org/freedesktop/resolve1 org.freedesktop.resolve1.Manager.ResolveHostname int32:0 string:kth.se int32:0 uint64:0

Tricks and Tips

Some DBus tricks:

Listen all connections to the system dbus:

dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.ListNames

Returns a list of names

dbus-send --system --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionUnixProcessID string::1.4

Get PID for owner of a name