Настройка nps windows server 2019

Over the last few days, I have been playing around with a few switches and configuring some 802.1X authentication between the switches and a Microsoft RADIUS server. I wanted to throw a quick block post out there to step through getting a Microsoft Network Policy Server configured to serve as a RADIUS server for clients on the network and how to configure this in basic terms. The configuration is not difficult, but it is tedious. If you skip one small step or configuration, you can leave yourself scratching your head for hours trying to chase down issues. However, there are some troubleshooting tools to note with RADIUS that makes life easier with figuring out what is going on if authentication requests etc. Let’s take a look at Installing Configuring Troubleshooting Windows Server 2019 NPS as RADIUS to step through the installation and configuration and look at a few troubleshooting areas to note.

The process to install the Network Policy Server in Windows Server 2019 is very straightforward.  It is simply a matter of installing the Network Policy Server role in Windows Server.  This is simply a next, next, finish process without even having to perform a Windows reboot.  The NPS component is found under the Server Roles portion of the Add Roles and Features wizard.

Add the additional features that are required to install the role.

The role is now selected.

Click Next.

Confirm the installation of the NPS role.

The NPS Role installation finishes successfully.

Now that the role has been added successfully, we can start configuring the NPS role to serve as a RADIUS server for network devices.

Configuring and Troubleshooting Windows Server 2019 RADIUS server

One of the first things you want to do when getting the RADIUS server configured is to setup the Connection Request Policies and the Network Policies.  What is the difference between the two?

Connection Request Policies – Connection request policies are sets of conditions and settings that allow designating which RADIUS servers perform the authentication and authorization of connection requests recevied from RADIUS clients. They can also determine which RADIUS servers perform the accounting functions.

• The time of day and day of the week
• The realm name in the connection request
• The type of connection being requested
• The IP address of the RADIUS client

Network policies are sets of conditions, constraints, and settings that allow designating who is authorized to connect to the network and the circumstances under which they can or can’t connect. These can be viewed as an ordered set of rules. Each network policy has a Policy State setting that allows enabling or disabling the policy. These are processed from the top down.

Let’s look at the properties of the default connection policy Use Windows authentication for all users to see what settings are contained.  Note under the overview, the policy is set to enabled.  It is perfectly ok to use the default connection policy and edit it to customize the properties as needed.

The only conditions defined in the Conditions tab is Day and time restrictions that define when connections can be made.

Note under the Settings tab we see the Authentication configuration that allows configuring which requests are processed locally or sent on to another RADIUS server.

I am just going to use the default connection policy.  However, under the Network Policies container, I have created a new policy called TestPolicy and moved this to the top of the order for processing above the default network policies already there.

Under the TestPolicy network policy, we note it is set to enabled and the Access permission given is to Grant access.

As noted above, the network policy defines who is allowed to connect.  Below, I have added a Windows group under the Conditions tab to allow connection.

Under the Constraints tab, here is where you can define many important aspects of the network policy such as the Authentication Methods.  I have added Microsoft: Protected EAP (PEAP) and Microsoft: Secured password (EAP-MSCHAP v2) as authentication protocols

PEAP authentication is a jointly developed authentication protocol by Cisco, Microsoft and RSA Security that encapsulates EAP within an encrypted and authenticated TLS encryption tunnel.  this requires a certificate for providing the TLS tunnel.

Using PowerShell in Windows Server 2019, you can easily provision a self-signed certificate for use with the PEAP authentication protocol.

New-SelfSignedCertificate -dnsnae "<your server FQDN>" -KeyLength 2048 -CertStoreLocation cert:LocalMachineMy -NotAfter (Get-Date).AddYears(20)

Creating a new self-signed certificate for use with PEAP authentication

Now, if we go back and edit the properties of the PEAP authentication protocol in our network policy, you will see an acceptable certificate for use with the PEAP protocol.  The certificate that was just created will be used by default.

RADIUS can be time consuming and difficult to troubleshoot by trying the authentication request from a real client.  Thankfully, there are great RADIUS simulators that make this process much easier.  One that I really like to use is the NTRadPing utility which you can download here.  This makes simulating the traffic extremely easy.  One thing that needs to be done to allow testing with NTRadPing is to add the PAP authentication protocol which is unencrypted.  Once you place the RADIUS server into production, you want to remove this.  However, for testing, this is fine.

Add your workstation IP as a RADIUS client under the RADIUS Clients and Servers node.  This consists of enabling the client, giving it a friendly name, entering the FQDN or IP address, and choosing a test shared secret passphrase.

After downloading and launching NTRadPing, there are several areas of the app to make note of.  We need to enter the address of the RADIUS server to be tested, the port, the Shared secret key which on the screen is cleartext.  Then enter the user-name and password.  On the Request type choose the Authentication Request in the drop down box.  Then simply click the Send button.  In the RADIUS Server reply box, you should see the response: Access-Accept if you are using a user that fits both the connection and network policies configured.

As you can see below, after enabling the RADIUS server logging under the Accounting configuration, you will start to see log files created under the default location of c:WindowsSystem32LogFiles.

Thoughts

If you are in need of utilizing a RADIUS server in your environment, Installing Configuring Troubleshooting Windows Server 2019 NPS as RADIUS server is very straightforward.  The Network Policy Server role allows having a powerful RADIUS solution that allows providing authentication requests to network clients, switches, and other devices that support RADIUS server integration.  Using great little tools such as NTRadPing and the built-in logging allow for easy troubleshooting of the configuration.  Stay tuned for future posts where we will take this integration even further and show the process of authenticating and apply network policies to users based on RADIUS server authentication.

Overview:

Remote Authentication Dial-In User Service (RADIUS) is a client/server networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for computers that connect and use a network service.

In Windows Server 2019, Network Policy Server is the Microsoft implementation of the RADIUS standard specified by the Internet Engineering Task Force (IETF).

NPS role will install automatically with the installation of Remote Access Service as a prerequisite on Windows Server 2019.

Network Policy Server (NPS) allows you to create and enforce organization-wide network access policies for connection request authentication and authorization.

NPS allows you to centrally configure and manage network access authentication, authorization, and accounting with these three following features:

1. RADIUS Server: NPS performs centralized authentication, authorization, and accounting for wireless, remote access dial-up and virtual private network (VPN) connections.
2. RADIUS-Proxy: NPS acts as a RADIUS proxy to forward connection requests to a remote NPS or other RADIUS servers for load balancing.
3. RADIUS accounting: You can configure NPS to log events to a local log file or to a local or remote instance of Microsoft SQL Server.

In this guide, we will learn the steps to configure the Radius Server on Windows Server 2019. We will configure one NPS as a RADIUS server for VPN connection authentication and authorization.

Test Lab Setup:

Note: For this guide, we will use the virtual test lab created in VirtualBox.

• WS2K19-DC01: Domain Controller and DNS Server.
• WS2K19-RADIUS01: Member Server acts as a RADIUS Server.
• WS2K19-SRV02: Standalone Server acts as a VPN Server.

1. At first, we need to create a new security group in the Active Directory domain (for example, TestUsers) in which we will need to add all users that will be allowed to authenticate on VPN Server.

2. Check the users dial-in properties settings.

Install NPS server role on Windows Server 2019:

3. Logon to WS2K19-RADIUS01 server with a domain administrator account. Open Server Manager Console.

4. Click on Manage and select Add Role and Features.

5. On the Before you begin page, click Next.

6. Select Role-based or feature-based installation and click Next.

7. Select a server from the server pool on which you want to install the Network Policy and Access Service role, click Next.

8. On select server roles page, select the Network Policy and Access Services checkbox. Click Next.

9. Click the Add Features button to add the required feature for NPS. Click Next to continue.

10. On select features, click Next.

11. Read overview information about Network Policy and Access Services and click Next.

12. Click Install and complete the installation process.

Configure RADIUS Server on Server 2019:

Step:1 Register NPS Server in Active Directory:

13. Click Close to finish the installation.

14. After the Network Policy and Access Services role installation is complete, open the Network Policy Server in the Tools menu.

To use the RADIUS server in the Active Directory Domain, we must register it first in the Active Directory.

15. In the NPS management console, right-click on NPS and select Register server in Active Directory.

16. Click OK to confirm the successful registration of the RADIUS server in Active Directory.

17. Now the RADIUS server has the authority to read the properties of user accounts related to the remote access. The RADIUS server will be added to the built-in domain group RAS and IAS Servers.

Step:2 Add RADIUS Client (VPN) Entry and Create NPS Policies for RADIUS Server:

18. Under Getting Started, select RADIUS Server for Dial-Up or VPN Connection from the drop-down menu. Click on Configure VPN or Dial-Up link to add a new RADIUS client.

19. Select VPN Connections and specify a meaningful name. Click Next.

20. Click on the Add button to add remote VPN servers as RADIUS clients.

21. On New Radius Client console, specify the details as mentioned below:

• Friendly Name: To identify the RADIUS client.
• Address: IP Address or FQDN of VPN Server.
• Manual Shared Secret: Type the shared secret password and re-enter to confirm the password.

22. Click OK to save the changes.

23. Verify Radius client entry and click Next.

24. Select Extensible Authentication Protocol checkbox and from the drop-down menu select Microsoft: Secured password (EAP-MSCHAP v2). Click Next.

25. Click on Add to specify User Groups as a condition to apply this policy.

26. Add the security group TestUsers. Click on Next.

27. On Specify IP Filters console, click Next.

28. Choose the Strongest encryption (128 bit) and click Next.

29. Click Next.

30. Click Finish to add create NPS Policies on the RADIUS Server.

Step:3 Configure RADIUS Server Settings on VPN Server:

After creating the NPS policy, we can proceed to configure our VPN server for authentication on the newly installed RADIUS NPS server.

Already we have configured the VPN server role on Windows Server 2019. You can follow this post for How to Install and Configure the VPN server role on Windows Server 2019.

31. On VPN Server, open Server Manager Console. Click on Tools and select Routing and Remote Access.

32. Right-click on the server name and select Properties.

33. Click on Security Tab. Under the Authentication provider, select RADIUS authentication and then click on Configure.

34. Click Add.

35. Specify RADIUS Server IP Address. Click on Change

36. Specify Shared Secret password (which we have specified during adding radius client). Click OK.

37. Click OK.

38. Click OK.

39. Under the Accounting provider, select RADIUS Accounting and then click on Configure.

40. Follow the same steps again to specify the RADIUS Server IP Address and Shared Secret password.

41. Click on Apply and OK to save the changes.

Now our VPN server can use Windows Server 2019 NPS RADIUS server for authentication and accounting without any issue.

That completes the steps on how to configure NPS RADIUS Server for VPN Authentication on Windows Server 2019.

Related Articles:

• How to Install Remote Access Service on Windows Server 2019 Part-1
• How to Install and Configure VPN in Windows Server 2019 Part-2
• Configure NPS for VPN in Windows Server 2019 Part-3
• Configure Port Forwarding and Test VPN Connection on Windows 10 Part-4

Post Views: 4,201

In this post I will show how to set up a RADIUS server on Windows Server 2019 to provide 802.1X Wireless Connections through wireless access points.

Actually I want to set up a RADIUS server for IEEE 802.11 wireless networks, but its nearly the same as for wired (Ethernet) networks besides the NAS Port Type (type of media used) is IEEE 802.11 wireless instead of wired Ethernet.

IEEE 802.1X is an IEEE Standard for port-based Network Access Control (PNAC). It is part of the IEEE 802.1 group of networking protocols. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN.
Source: https://en.wikipedia.org/wiki/IEEE_802.1X
https://en.wikipedia.org/wiki/IEEE_802

Microsoft’s implementation of a Remote Authentication Dial-In User Service (RADIUS) server is for Windows Server operating systems later than Windows Server 2003 the Network Policy and Access Services (NPAS) server role.

NPAS replaces the Internet Authentication Service (IAS) from Windows Server 2003.
Source: https://en.wikipedia.org/wiki/Network_Policy_Server

So first I will install the Network Policy and Access Services (NPAS) server role either on a domain controller or member server.

Now as the Network Policy and Access Services (NPAS) server role is installed you will have a new console named Network Policy Server.

Open the Network Policy Server console and select the RADIUS server for 802.1X Wireless or Wired Connections template to configure NPS by using the wizard.

Click on Configure 802.1X to start the wizard.

Select Secure Wireless Connections

Here I need to add all my wlan access points as RADIUS clients.

• Friendly name
• IP address or FQDN
• Shared secret
  Use a unique RADIUS shared secret for each wireless AP unless you are planning to configure APs as RADIUS Clients in NPS by group. If you plan to configure APs by group in NPS, the shared secret must be the same for every member of the group. In addition, each shared secret you use should be a random sequence of at least 22 characters that mixes uppercase and lowercase letters, numbers, and punctuation.
  Source: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/e-wireless-access-deployment#to-configure-your-wireless-aps

For authentication I will use the Protected EAP (PEAP) protocol.

Click on Configure to select a certificate to prove the identity of the RADIUS server to the clients. You can use here the default computer certificate from your internal PKI.

The clients needs to trust that certificate, otherwise the user’s wont be able to connect to the wireless network.

It then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server’s public key. The ensuing exchange of authentication information inside the tunnel to authenticate the client is then encrypted and user credentials are safe from eavesdropping.

Simplifying WPA2-Enterprise and 802.1x

Client / Supplicant
In order for a device to participate in the 802.1x authentication, it must have a piece of software called a supplicant installed in the network stack. The supplicant is necessary as it will participate in the initial negotiation of the EAP transaction with the switch or controller and package up the user credentials in a manner compliant with 802.1x. If a client does not have a supplicant, the EAP frames sent from the switch or controller will be ignored and the switch will not be able to authenticate.

Fortunately, almost all devices we might expect to connect to a wireless network have a supplicant built-in. SecureW2 provides a 802.1x supplicant for devices that don’t have one natively.

Thankfully, the vast majority of device manufacturers have built-in support for 802.1x. The most common exceptions to this might be consumer gear, such as game consoles, entertainment devices or some printers. Generally speaking, these devices should be less than 10% of the devices on your network and are best treated as the exception rather than the focus.

Switch / Access Point / Controller
The switch or wireless controller plays an important role in the 802.1x transaction by acting as a ‘broker’ in the exchange. Until a successful authentication, the client does not have network connectivity, and the only communication is between the client and the switch in the 802.1x exchange.

The switch/controller initiates the exchange by sending an EAPOL-Start packet to the client when the client connects to the network. The client’s responses are forwarded to the correct RADIUS server based on the configuration in the Wireless Security Settings. When the authentication is complete, the switch/controller makes a decision whether to authorize the device for network access based on the user’s status and possibly the attributes contained in the Access_Accept packet sent from the RADIUS server.

Successful mutual PEAP-MS-CHAP v2 authentication has two main parts:

• The client authenticates the NPS. During this phase of mutual authentication, the NPS sends its server certificate to the client computer so that the client can verify the NPS’s identity with the certificate. To successfully authenticate the NPS, the client computer must trust the CA that issued the NPS certificate. The client trusts this CA when the CA’s certificate is present in the Trusted Root Certification Authorities certificate store on the client computer.
• The NPS authenticates the user. After the client successfully authenticates the NPS, the client sends the user’s password-based credentials to the NPS, which verifies the user’s credentials against the user accounts database in Active Directory Domain Services (AD DS).

If the credentials are valid and authentication succeeds, the NPS begins the authorization phase of processing the connection request. If the credentials are not valid and authentication fails, NPS sends an Access Reject message and the connection request is denied.

The behavior requiring the client to validate the server certificate can be disabled, but disabling server certificate validation is not recommended in production environments.

Source: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/a-deploy-8021x-wireless-access#authentication

The server running NPS performs authorization as follows:

• NPS checks for restrictions in the user or computer account dial-in properties in AD DS. Every user and computer account in Active Directory Users and Computers includes multiple properties, including those found on the Dial-in tab. On this tab, in Network Access Permission, if the value is Allow access, the user or computer is authorized to connect to the network. If the value is Deny access, the user or computer is not authorized to connect to the network. If the value is Control access through NPS Network Policy, NPS evaluates the configured network policies to determine whether the user or computer is authorized to connect to the network.
• NPS then processes its network policies to find a policy that matches the connection request. If a matching policy is found, NPS either grants or denies the connection based on that policy’s configuration.

If both authentication and authorization are successful, and if the matching network policy grants access, NPS grants access to the network, and the user and computer can connect to network resources for which they have permissions.

Source: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/a-deploy-8021x-wireless-access#authorization

Keep in mind regarding the communication between the NPS server and client as described in both Microsoft articles about authentication and authorization above.

As mentioned further above in the great article from SECUREW2, the client cannot communicate directly with the RADIUS server to authenticate himself and the server, as it does not have network connectivity until a successful authentication. The communication between the client and RADIUS server is established through the access points (switches for wired networks), which will acting as a broker in the exchange between both.

Here I will add all groups which are allowed to access the network through my wlan access points.

For computer authentication you should create a security group which includes all computer accounts they should be able to authenticate against NPS and add it to your network policy (Conditions tab) as windows group. NPS uses then this policy to authorize the connection request.

Further each of those computers needs a computer certificate installed from your internal PKI (CA), which is by default published to the Enterprise NTAuth store.

The computers wlan profile also needs to be configured to enable computer authentication, I will show this further below in the section about configuring a group policy.

Btw. you can also use certificates from a third-party CA, but in that case you need to import the CA certificate into your Enterprise NTAuth store and the computer certificate needs to mapped to the computer account in Active Directory. About how you will find in the following article from Microsoft:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store

The Enterprise NTAuth store is used by your Active Directory domain to determine which certification authorities to trust for issuing certificates that are used to authenticate and authorize a user or computer.

To check which CAs are stored in the Enterprise NTAuth store, you can use the PKI Tool (PKIVIEW). On your CA server open the tool pkiview.msc, right click on Enterprise PKI and select Manage AD Containers… . Here you will see in the tab NTAuthCertificates which CAs are still trusted.

In the next dialog you can configure traffic control attributes (RADIUS tunnel attributes) to allow and deny traffic to user’s based on their assigned VLANs.

You can change all of theses settings later directly in the NPS console.

Here you can modify the RADIUS clients.

The wizard will create a Connection Request Policy and a Network Policy.

Connection Request Policies
https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-crp-crpolicies

Connection request policies are sets of conditions and settings that allow network administrators to designate which Remote Authentication Dial-In User Service (RADIUS) servers perform the authentication and authorization of connection requests that the server running Network Policy Server (NPS) receives from RADIUS clients. Connection request policies can be configured to designate which RADIUS servers are used for RADIUS accounting.

By default the wizard will set to process the authentication request locally on the server.

Network Policy

You can also configure Accounting for the NPS server.

Configure Network Policy Server Accounting
https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-accounting-configure

The wizard created our Network Policy and we do not need to change here anything.

By adding Windows Groups, it doesn’t matter if they were local groups on the server itself or domain groups, NPS will process both of them.

As mentioned further above you can use here the default computer certificate on the NPS server from your internal PKI.

The clients needs to trust that certificate, otherwise the user’s wont be able to connect to the wireless network.

It then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server’s public key. The ensuing exchange of authentication information inside the tunnel to authenticate the client is then encrypted and user credentials are safe from eavesdropping.

Configure your WLAN Access Points

On the wlan access points we have to configure the IP address from the NPS (RADIUS) server, port and shared secret.

The Radius Port for authentication by default is UDP 1812 or 1645.

Further we need to select a security mode our access points will use to authenticate users or devices (computer authentication as mentioned further above). When using a RADIUS server we want that users authenticate themselves by using their username and password for the network, therefore we need to select WPA2 or WPA3-Enterpise, also for computer authentication.

Keep in mind that even in the year 2022 not all devices support WPA3.

You can check the ports in the NPS console by right clicking on NPS(Local) and select properties. Here within the tab Ports, you can see on what ports the NPS server is listening for authentication and if used accounting.

The Radius Port for accounting by default is UDP 1813 or 1646.

Optionally we can also configure Radius Accounting as mentioned.

The RADIUS server also collects a variety of information sent by the NAS that can be used for accounting and for reporting on network activity. The RADIUS client sends information to designated RADIUS servers when the User logs on and logs off. The RADIUS client may send additional usage information on a periodic basis while the session is in progress. The requests sent by the client to the server to record logon/logoff and usage information are generally called accounting requests.

For more information on RADIUS accounting, see RFC 2866.

Source: https://learn.microsoft.com/en-us/windows/win32/nps/ias-radius-authentication-and-accounting

Configure Wireless Network (IEEE 802.11) Policies | Wi-Fi profiles

You can configure group policies in your network to define preferred networks and settings for the WLAN connection to your clients.

To activate default Wireless Network (IEEE 802.11) Policies
https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/e-wireless-access-deployment#to-activate-default-wireless-network-ieee-80211-policies

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Wireless Network (IEEE 802.11) Policies

Clients should connect automatically to this network when it is in range.

For the network authentication method I have to select Protected EAP (PEAP) as used on the NPS server and for the authentication mode I will use User or Computer authentication.

Even the most common method of authentication with PEAP-MSCHAPv2 is user auth, in which clients are prompted to enter their domain credentials, the Windows NPS server role also supports computer authentication by using the PEAP-MSCHAPv2 protocol.

In order to use computer authentication, you also have to install a computer certificate on the clients and issued from your internal PKI as mentioned further above.

For computer authentication you can configure certificate auto-enrollment for the client computers as shown in my following post: https://blog.matrixpost.net/configure-certificate-auto-enrollment/

In the advanced settings you can enable single sign-on for the wireless network, by checking this your password to logon to your computer will also be passed and used to establish the wireless connection with the access points.

Further if you select Perform immediately before User Logon as show in the figure below, the computer will first try to connect to the wireless access points when the user is entering its password and then subsequently will get logged on to its computer after the wireless connection is established.

In case computer authentication will be performed, the computer already connects at the logon screen to the network, as it doesn’t matter which user will get logged on.

Therefore in both cases the computer can perform a network login against the domain controllers and logon scripts and group policies will be applied to the computer.

If the wireless connection couldn’t be established, the user will get logged on to its computer by using the local cached credentials as usual but without processing the logon scripts and applying the group policies from the domain controller.

At the logon screen you will see the wireless network to which Windows tries to connect after providing your password for the logon.

User vs. Machine Authentication
The most common method of authentication with PEAP-MSCHAPv2 is user auth, in which clients are prompted to enter their domain credentials. It is also possible to configure RADIUS for machine authentication, in which the computers themselves are authenticated against RADIUS, so the user doesn’t need to provide any credentials to gain access. Machine auth is typically accomplished using EAP-TLS, though some RADIUS server options do make it simple to accomplish machine auth using PEAP-MSCHAPv2 (including Windows NPS, as outlined in the example config below).

The following example configuration outlines how to set up Windows NPS as a RADIUS server, with Active Directory acting as a userbase:

Add the Network Policy Server (NPS) role to Windows Server.
Add a trusted certificate to NPS.
Add APs as RADIUS clients on the NPS server.
Configure a policy in NPS to support PEAP-MSCHAPv2.
(Optional for machine auth) Deploy PEAP-MSCHAPv2 wireless network settings to domain member computers using Group Policy.

Source: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise

Create Wi-Fi profiles using the System Center Configuration Manager (SCCM) or Microsoft Intune.

You can also use SCCM or Microsoft Intune to configure Wi-Fi profiles. This topic is well documented from Microsoft in the following articles.

Manage Wi-Fi profiles on local computer by using the netsh command

You can also use the netsh command line tool to manage the Wi-Fi profiles on a local computer.

• netsh wlan show profile -> list profiles located on the local computer
• netsh wlan show profiles interface=”wi-fi” -> list profile for specific interface
• netsh wlan show drivers -> list driver information about the wireless adapter
• netsh wlan show wirelesscapabilities -> list capabilities of the wireless adapter
• netsh wlan show interfaces -> list all wireless interfaces on the local computer
• netsh wlan show profile name=”myAP” key=clear -> will display the security key in plaintext
• netsh wlan set profileparameter name=”myAP” connectionmode=manual -> will disable connect automatically
• netsh wlan set profileparameter name=”myAP” connectionmode=auto -> will enable connect automatically
• netsh wlan delete profile name=”myAP” -> will delete the myAP wlan profile
• netsh wlan delete profile name=* -> will delete all wlan profiles on the local computer
• netsh wlan export profile name=”WiFiNetwork” key=clear folder=”C:path” key=clear -> Export a wlan profile
• netsh wlan add profile filename=”C:pathprofileFile.xml” user=all -> Import a wlan profile for all user’s -> user=current only for the current user
• netsh wlan show wlanreport -> will create a wireless adapter report will ->
  Analyze the wireless network report
  https://support.microsoft.com/en-us/windows/analyze-the-wireless-network-report-76da0daa-1db2-6049-d154-7bb679eb03ed

Troubleshooting

In case something went wrong and your clients won’t connect to the the wireless network, you can investigate several logs to get more details about the problem.

You can search in two locations for logs to investigate the reason why clients can’t connect to the network.

For general configuration problems between the NPS server and the RADIUS clients, you can investigate the Event Viewer.

Custom Views -> Server Roles -> Network Policy and Access Services

For problems regarding authentication from the user’s itself, you should use the Accounting logs. Here you can see the default path from them.

To investigate them I would suggest to use a specific log viewer like the IAS Log Viewer from DeepSoftware LLC. You can use this viewer also to investigate VPN logging from the Windows Routing and Remote Access servers.

IAS Log Viewer
https://www.deepsoftware.com/iasviewer/

IAS_SUCCESS -> the user or computer authenticated successfully against the NPS server, formerly Internet Authentication Service (IAS)

NPAS replaces the Internet Authentication Service (IAS) from Windows Server 2003.
Therefore you will see IAS_SUCCESS messages in the logs from NPS.
Source: https://en.wikipedia.org/wiki/Network_Policy_Server

Reason for rejecting a user. Can be:

Field (26) Reason-Code Number

• 0 = IAS_SUCCESS
• 1 = IAS_INTERNAL_ERROR
• 2 = IAS_ACCESS_DENIED
• 3 = IAS_MALFORMED_REQUEST
• 4 = IAS_GLOBAL_CATALOG_UNAVAILABLE
• 5 = IAS_DOMAIN_UNAVAILABLE
• 6 = IAS_SERVER_UNAVAILABLE
• 7 = IAS_NO_SUCH_DOMAIN
• 8 = IAS_NO_SUCH_USER
• 16 = IAS_AUTH_FAILURE
• 17 = IAS_CHANGE_PASSWORD_FAILURE
• 18 = IAS_UNSUPPORTED_AUTH_TYPE
• 32 = IAS_LOCAL_USERS_ONLY
• 33 = IAS_PASSWORD_MUST_CHANGE
• 34 = IAS_ACCOUNT_DISABLED
• 35 = IAS_ACCOUNT_EXPIRED
• 36 = IAS_ACCOUNT_LOCKED_OUT
• 37 = IAS_INVALID_LOGON_HOURS
• 38 = IAS_ACCOUNT_RESTRICTION
• 48 = IAS_NO_POLICY_MATCH
• 64 = IAS_DIALIN_LOCKED_OUT
• 65 = IAS_DIALIN_DISABLED
• 66 = IAS_INVALID_AUTH_TYPE
• 67 = IAS_INVALID_CALLING_STATION
• 68 = IAS_INVALID_DIALIN_HOURS
• 69 = IAS_INVALID_CALLED_STATION
• 70 = IAS_INVALID_PORT_TYPE
• 71 = IAS_INVALID_RESTRICTION
• 80 = IAS_NO_RECORD
• 96 = IAS_SESSION_TIMEOUT
• 97 = IAS_UNEXPECTED_REQUEST

Source: https://www.radiusreporting.com/IAS-DB-Attribute-Format-Table.html

EAP authentication exchange for wireless clients through the access point and RADIUS server stuck by using a route-based IPSec in pfSense during the SSL handshake and here exactly after the Client Hello

If you ran into that issue, you can read my following post about how to set up a lean Branch Office Network without any Servers and DCs inside by using an IPSec S2S VPN Tunnel connected with the Headquarters Network.

Links

This is the third post in my series on setting up a basic Always On VPN deployment. In this post I will be covering the configuration of the VPN server and the NPS server. I will also talk about the network and firewall configuration. Links to each individual post in this series can be found below.

Always On VPN – Basic Deployment Guide
Always On VPN – Certificates and Active Directory
Always On VPN – User Tunnel
Always On VPN – Device Tunnel
Always On VPN – Troubleshooting

In this deployment, the role of the VPN server will be filled by Windows Server 2019 running the Routing and Remote Access Server role. This post will provide instructions for both domain-joined and non-domain-joined VPN servers. For the best security, the recommendation is to not join the VPN server to the internal AD domain.

Network Placement

The server will be located in a perimeter network. If a perimeter network or DMZ is not available, the server could be placed on a separate VLAN where access to the rest of the corporate network is controlled by ACLs. The server could also be placed directly on the corporate network, but this is the least secure option.

Network Configuration

The server will have 2 network adapters, 1 internet facing adapter and 1 intranet facing adapter.

• External Adapter
  • Assigned a static IP Address and Gateway IP
  • Only the IPv4 and IPv6 protocols should be enabled
• Internal Adapter
  • Assigned a static IP Address
• Additional Notes
  • The IP addresses assigned to the adapters must be from different subnets
  • The gateway IP should only be configured on the external adapter
    • Access to internal resources should be configured using static routes

#Create a new static route
New-NetRoute -AddressFamily IPv4 -DestinationPrefix 10.0.0.0/8 -InterfaceAlias 'Internal' -NextHop 192.168.1.254

#View existing static routes
Get-NetRoute -InterfaceAlias 'Internal'

• If the VPN server is domain-joined, the DNS servers should be specified on the internal adapter
  • While this guide assumes a dual-interface configuration, it is possible to configure the VPN server with a single network interface. For more information about network interface configuration on the VPN server, refer to this post.

Firewall Configuration

• Traffic allowed from the internet facing firewall to the external network adapter of the VPN server
  • If using IKEv2
    • UDP 500 (IKE)
    • UDP 4500 (IPSec NAT Traversal)
  • If using SSTP
    • TCP 443 (SSL)
• Traffic allowed to and from the internal network adapter of the VPN server to the internal network
  • UDP 1812 (RADIUS Authentication)
  • UDP 1813 (RADIUS Accounting)
    • RADIUS traffic can also use UDP 1645 and UDP 1646, however, these are legacy ports and should not be needed when using modern clients and servers

If the VPN server is domain-joined, the server will need to be able to communicate with a domain controller. If there is not a read-only domain controller in the perimeter network, then these ports will need to be opened to domain controller on the internal network. Note that this is a potential security risk.

• TCP and UDP 53 (DNS)
• TCP and UDP 88 (Kerberos)
• TCP 135 (RPC Endpoint Mapper)
• TCP and UDP 389 (LDAP)
• TCP 445 (SMB)
• TCP 636 (LDAPS)
• TCP 3268 (LDAP GC)
• TCP 3269 (LDAPS GC)

Feature Installation and Configuration

These steps will walk through the installation and configuration of the Routing and Remote Access Server role. These steps should be preformed on the VPN server.

• Open an administrative PowerShell window and run this command to install the Routing and Remote Access Server role

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools

• Open the Server Manager and click Open the Getting Started Wizard
  • A refresh of the server manager may be required for the notification to appear

• In the Configure Remote Access window that opens, select Deploy VPN only
• The Routing and Remote Access console should now be open
• Right click on the VPN server and select Configure and Enable Routing and Remote Access

• The Routing and Remote Access Server Setup Wizard should open
  • At the Welcome page, click Next
  • Select Custom configuration and click Next
  • Select VPN access and click Next
  • Click Finish to complete the setup wizard
  • When prompted to start the Routing and Remote Access service, click Start service
    • If no prompt to start the service appears, right click on the VPN server, select All Tasks, and click Start
• Right click on the VPN server and select Properties
  • Security tab
    • Change the Authentication provider to RADIUS Authentication and click Configure
      • In the window that opens, click Add
      • Enter the FQDN of the NPS server
      • Enter a shared secret
        • This should be a long random string of characters. Save this password somewhere safe. It will be needed again during the NPS server configuration
      • Optionally change the time-out or port settings and click OK twice
    • Optionally change the Accounting provider
  • IPv4 tab
    • Choose to use DHCP or a static address pool for allocating IP addresses
      • If using DHCP, ensure an IP Helper and firewall rules have been created to allow clients to find and communicate with the DHCP server.
      • If using a static address pool, ensure the IP addresses have been excluded from being used by the DHCP server
    • Set the adapter to the internal network interface
• Click OK to close the Properties window
• In the Routing and Remote Access console, right click on Ports and select Properties

• Select WAN Miniport (IKEv2) and click Configure
  • Ensure Remote access connections (inbound only) is checked
  • Ensure Demand-dial routing connections (inbound and outbound) is checked
  • Optionally modify the maximum ports setting and click OK
• Configure the other unused RAS/Routing ports (L2TP, PPTP, SSTP)
  • Uncheck both checkboxes

This concludes the main setup of the Routing and Remote Access role. However, there are additional steps that can be done to improve security as well as add support for device tunnels.

Improve IKEv2 Security

The default security settings for an IKEv2 connection in the Routing and Remote Access configuration are not as good as they could be. The settings used for the IKEv2 connections can be set to a more secure level on the server. If these settings are set on the server, the same settings will need to be configured on the client side before the tunnel will connect.

• Connect to the VPN server and open an administrative PowerShell window
• Run this command to update the IPsec security parameters for IKEv2

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SADataSizeForRenegotiationKilobytes 102400

• Restart the Remote Access Management service to allow the changes to take effect

This PowerShell command is sourced from this post.

Enable IKEv2 Fragmentation

It’s possible that the IKEv2 traffic can be split apart if the IP packets are too large. Windows 10 will support IKEv2 fragmentation by default, however this support needs to be manually enabled in Windows Server. Note that this feature only works in Windows Server 1803 and newer. To enable support for IKEv2 fragmentation, run this PowerShell command:

New-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesRemoteAccessParametersIkev2" -Name EnableServerFragmentation -PropertyType DWORD -Value 1 -Force

To read more about IKEv2 fragmentation, refer to this post.

Enable Support for Device Tunnels

The default configuration of the Routing and Remote Access server role does not allow machine certificate authentication. If device tunnels will be used, this needs to be enabled.

• Connect to the VPN server and open an administrative PowerShell window
• Run this script to enable machine certificate authentication
  • Modify the first line of the script with the common name of the root CA before running the script

$VPNRootCertAuthority = "Common Name of trusted root certification authority"
$RootCACert = (Get-ChildItem -Path cert:LocalMachineroot | Where-Object {$_.Subject -Like "*$VPNRootCertAuthority*" })
Set-VpnAuthProtocol -UserAuthProtocolAccepted Certificate, EAP -RootCertificateNameToAccept $RootCACert -PassThru

This PowerShell script is sourced from this page.

In this deployment, the role of the NPS server will be filled by Windows Server 2019 running the Network Policy Server role. This server should be domain-joined.

Network Placement and Configuration

The server will be located behind the internal firewall on the internal network. The server should have a single network adapter with a static IP address or a DHCP reservation.

Firewall Configuration

The following ports should be allowed through the internal firewall and the Windows firewall between the VPN server and the NPS server.

• UDP 1812 (RADIUS Authentication)
• UDP 1813 (RADIUS Accounting)
  • RADIUS traffic can also use UDP 1645 and UDP 1646, however, these are legacy ports and should not be needed when using modern clients and servers

Windows Server 2019 has a bug where the Windows Firewall rules for the NPS role will appear as active but not actually be working. If communication on these ports does not seem to be making it through the Windows Firewall, open an administrative command prompt and run this command.

sc.exe sidtype IAS unrestricted

For more information about this bug and the solution, see this post.

Feature Installation and Configuration

These steps will walk through the installation and configuration of the Network Policy Server role. These steps should be preformed on the NPS server.

• Open an administrative PowerShell window and run this command to install the Network Policy Server role

Install-WindowsFeature NPAS -IncludeManagementTools

• Open the Network Policy Server console
• Right click on the NPS server and select Register server in Active Directory
  • Click OK at the confirmation dialog and again at the success dialog

• In the Network Policy Server console, expand RADIUS Clients and Servers
• Right click on RADIUS Clients and select New

• Ensure Enable this RADIUS client is checked
• In the Friendly name box, enter the name of the VPN server
• In the Address (IP or DNS) box, enter the IP address of the internal network interface on the VPN server
• Shared Secret
  • Ensure the Manual box is checked
  • Enter the Shared Secret that was created during the VPN server setup
• Click OK to close the window
• Select the RADIUS server, ensure RADIUS server for Dial-Up or VPN Connections is selected, and click Configure VPN or Dial-Up

• In the window that appears, select Virtual Private Network (VPN) Connections and click Next
• Select the VPN server and click Next
• On the Authentication Methods page
  • Uncheck Microsoft Encrypted Authentication version 2 (MS-CHAPv2)
  • Check Extensible Authentication Protocol
  • Set the Type to Microsoft: Protected EAP (PEAP)
  • Click Configure
    • Select Secured password (EAP-MSCHAP v2) and click Remove
    • Click Add, select Smart Card or other certificate, and click OK
    • Click Next

• At the User Groups page
  • Click Add and select the AOVPN Users AD group
  • Click Next
• At the IP Filters page, click Next
• At the Encryption Settings page, click Next
• At the Realm Name page, click Next
• Click Finish to complete the wizard

This completes the VPN and NPS server configuration portion of the deployment. The next post in the series is Always On VPN – User Tunnel.

  Microsoft Network Policy Server

1. Overview

In that documentation, we will explain how to configure OpenOTP multi-factor authentication on your Microsoft Network Policy Server. As a practical example, we will configure NPS with Microsoft Remote Access Server for VPN use.

For this recipe, you will need to have a WebADM, OpenOTP and Radius Bridge installed and configured. Please refer to WebADM Installation Guide, WebADM Manual and Radius Bridge Manual for instructions on these.
Your Microsoft Network Policy Server and Remote Access Server should be installed and configured for VPN (PPTP, SSTP) use.

Note that only two multifactor authentication methods can be used to authenticate your Windows VPN client with OpenOTP: Simple push “Accept/Reject” or concatenated LDAP+OTP password. NPS supports RADIUS challenge, but Windows VPN Client does not, so you can not prompt additional credentials during the authentication request to ask for the OTP.

2. Configure MS VPN with NPS

Open the Routing and Remote Access console from your Windows VPN server

Right click on your VPN > Properties

Click on Security tab

We will now change the Authentication Provider from Windows Authentication to RADIUS Authentication and click on Configure button.

On the following screen, configure the IP of your NPS server and a secret.
Adjust the timeout according to the screenshot. If you are using Simple Push based authentication, it is important that the timeout exceeds the push timeout configured in WebADM.

3. NPS Configuration

3.1 Add your VPN server as RADIUS Client

On NPS your VPN server is configured as a Radius client.

The secret must be the same as the one you configured on your VPN server.
Go back to your VPN properties and click on Authentication Methods button.
Configure PAP as Authentication Method like below:

Apply the configuration. This concludes the VPN server part.

3.2 Add a new Remote RADIUS Server

Open the NPS console, we will now configure a Remote RADIUS Server. Right click on Remote RADIUS Server Group > New

Click Add button

On the next page, add the IP address of your Radius Bridge.

On the next tab, you have to configure the secret, which must match a client definition in your RADIUS bridge clients.conf:

NPS server IP needs to configured as Radius client in /opt/radius/conf/clients.conf :

client NPS_Server {
        ipaddr = 192.168.3.189
        secret = testing123
}

On the Load Balancing tab, you need to configure the timeouts like below. Again they must exceed the push timeout:

Click Ok twice when your configuration is done.

3.3 Connection request Policies

Now we need to configure a Connection Request Policy in order to forward authentication request to Radius Bridge.
Right click on Connection Request Policy > New

Name your policy, define the Type of Network access server to Remote Access Server and then click Next.

On the next page, define your Access Conditions.

On my side, I only defined the NAS Port Type to VPN(Virtual). This means the policy is applied to VPN connections.

Click Next when all of your conditions are defined.

Next page we finally define the Authentication mechanism for the requests.
On the Authentication tab switch to Forward requests to the following RADIUS server group for authentication and choose the Server group we defined earlier.

The accounting part can be kept by default because Radius Bridge does not support RADIUS accounting.
Click Next.

On the next page, there is one small but important setting to be concidered. If you wish to implement Network Policies (for exampple user/group specific netowork access rules) in NPS, you must configure the following RADIUS attribute set to True. This attribute means NPS sends the defined Network Policies back to VPN server. Without it all Network Policies are ignored.

Click Next and finish.

4. VPN client configuration

On the VPN Client configuration we need to configure PAP as supported protocol.
Edit your VPN Connection Properties and configure it as below :

That concludes the VPN client configuration.

5. WebADM Client Policy

As mentioned, Windows VPN client doesn’t support RADIUS Challenge. For this reason, you have to create a WebADM client policy for your VPN, disabling the challenge mode support for the requests from MS VPN server.

Login on WebADM Admin GUI > Admin tab > Client Policy

Click on Add Client button, name your client policy and click Proceed button :

Click on Create Object :

You are now on the configuration page of your client policy. Scroll down to find the Forced Application Policies section :

Enable the setting and click Edit button :

In the Application box on the top left, select MFA Authentication Server switch the Challenge Mode Supported setting to No:

On the same page you can also configure Push Login setting to yes if you have a push login infrastructure available and wish to use this method.

Scroll down to apply the configuration and you will be redirected to the client policy configuration page. You should have the following :

For OpenOTP match the policy with NPS and your VPN, you must configure the IP addresses of your VPN and NPS servers in the Client Name Aliases setting. On my side, both are running on the same server so I configured only one IP address:

Press Apply to save your client policy.

Configuration is now complete.

With this policy, when your users will try to login from the VPN client, they must use the push login to be able to login (if push login infrastructure is configured with OpenOTP) or use LDAP and OTP passwords concatenation :

• LDAP Username : Administrator

• LDPA Password : password

• OTP : 123456

• LDAP Password+OTP concatenation : password123456

6. OpenOTP logs

6.1 Push login logs

[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] New openotpSimpleLogin SOAP request
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] > Username: administrator
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] > Password: xxxxxxxx
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] > Source IP: 192.168.3.189
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] > Options: RADIUS,-U2F
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Enforcing client policy: Microsoft NPS (matched client IP)
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Registered openotpSimpleLogin request
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Resolved LDAP user: CN=Administrator,CN=Users,OU=TESTING,DC=yorcdevs,DC=com (cached)
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Resolved LDAP groups: group policy creator owners,domain admins,enterprise admins,schema admins,administrators,denied rodc password replication group
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Started transaction lock for user
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Found user fullname: Administrator
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Found 46 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=Yes,ExpireNotify=MAIL,ChallengeMode=No,ChallengeTimeout=90,ChallengeRetry=Yes,OTPLength=6,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,PasswordReset=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,DeviceType=FIDO2,SMSType=Normal,SMSMode=Ondemand,SecureMail=No,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Found 5 user data: TokenType,TokenKey,TokenState,TokenID,TokenSerial
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Found 1 registered OTP token (TOTP)
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Challenge mode disabled (checking concatenated passwords)
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] Requested login factors: LDAP & OTP
[2019-09-19 16:50:33] [192.168.3.54] [OpenOTP:8ENCNNEB] LDAP password Ok
[2019-09-19 16:50:34] [192.168.3.54] [OpenOTP:8ENCNNEB] Sent push notification for token #1
[2019-09-19 16:50:34] [192.168.3.54] [OpenOTP:8ENCNNEB] Waiting 27 seconds for mobile response
[2019-09-19 16:50:37] [192.168.3.56] [OpenOTP:8ENCNNEB] Received mobile authentication response from 192.168.3.192
[2019-09-19 16:50:37] [192.168.3.56] [OpenOTP:8ENCNNEB] > Session: SeNAdV4FltKKVKIJ
[2019-09-19 16:50:37] [192.168.3.56] [OpenOTP:8ENCNNEB] > Password: 16 Bytes
[2019-09-19 16:50:37] [192.168.3.56] [OpenOTP:8ENCNNEB] Found authentication session started 2019-09-19 16:50:33
[2019-09-19 16:50:37] [192.168.3.56] [OpenOTP:8ENCNNEB] PUSH password Ok (token #1)
[2019-09-19 16:50:37] [192.168.3.54] [OpenOTP:8ENCNNEB] Updated user data
[2019-09-19 16:50:37] [192.168.3.54] [OpenOTP:8ENCNNEB] Sent login success response

6.2 Concatened LDAP password and OTP logs

[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] New openotpSimpleLogin SOAP request
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] > Username: administrator
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] > Password: xxxxxxxxxxxxxx
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] > Source IP: 192.168.3.189
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] > Options: RADIUS,-U2F
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Enforcing client policy:  Microsoft NPS (matched client IP)
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Registered openotpSimpleLogin request
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Resolved LDAP user: CN=Administrator,CN=Users,OU=TESTING,DC=yorcdevs,DC=com (cached)
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Resolved LDAP groups: group policy creator owners,domain admins,enterprise admins,schema admins,administrators,denied rodc password replication group
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Started transaction lock for user
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Found user fullname: Administrator
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Found 46 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=No,ExpireNotify=MAIL,ChallengeMode=No,ChallengeTimeout=90,ChallengeRetry=Yes,OTPLength=6,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,PasswordReset=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,DeviceType=FIDO2,SMSType=Normal,SMSMode=Ondemand,SecureMail=No,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Found 5 user data: TokenType,TokenKey,TokenState,TokenID,TokenSerial
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Found 1 registered OTP token (TOTP)
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Challenge mode disabled (checking concatenated passwords)
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Requested login factors: LDAP & OTP
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] LDAP password Ok
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] TOTP password Ok (token #1)
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Updated user data
[2019-09-19 16:37:23] [192.168.3.54] [OpenOTP:232F08T0] Sent login success response

The term “RADIUS server” will probably be mentioned at some point in any conversation regarding wired or wireless authentication. Within a WPA-2 Enterprise network, RADIUS (also referred to as a “AAA server“), performs the crucial tasks of Authentication, Accounting, and Authorization. As you might anticipate, Microsoft has made improvements to its RADIUS server over time to satisfy the demands of its vast customer base for authentication.

Since the release of the Windows 2003 server, Microsoft has proactively updated its RADIUS servers. In our past blogs, we went into great detail on configuring Windows 2008/12/16 servers. In this blog post, we’ll help you set up Windows 2019, the ninth edition of the venerable Windows RADIUS server.

Before configuring the Windows Server 2019, ensure that you meet the following requirements for successfully configuring the Windows 2019 server.

Prerequisites for Windows RADIUS Server 2019:

❖   System Requirements:

• Processor: You need a processor of at least 1.4 GHz clock frequency for x64 processors.
• RAM: The minimum requirement of RAM is 512 MB. But Microsoft recommends using 2GHz for smooth functioning and Servers with a Desktop Experience installation option.
• Disk space: You need a minimum disk space of 32 GB or more, but Microsoft usually recommends using 40 GB or more disk space. Also, the disk space requirements vary with the processor and RAM used in the system.

❖   Active Directory Setup:

You must update the Active Directory environment before adding the domain controller.

❖   Server Core Installation:

Unlike Windows Server 2008, the admin need not select the Full Installation or Server Core Installation option beforehand in Windows Server 2012/16/19.

These features are merged in the 2012/16/19 version to give three optional features which the admin can install or uninstall at will.

❖   Network adapter requirements:

• An Ethernet adapter with a minimum throughput of 1 Gigabit per second.
• An Ethernet adapter that conforms to the PCI Express architectural standard.

❖   Miscellaneous Requirements:

• System and firmware that is based on UEFI 2.3.1c and support secure boot.
• A graphics card and a display with at least Super VGA (1024 x 768) resolution.
• Turn off your antivirus software, as the installation process can be hampered by virus protection software. For instance, checking each file copied locally to your computer might significantly slow the installation.
• Ensure that the Windows Firewall is enabled by default.
• Ensure that all the relevant data and information are appropriately backed up before the configuration.

Overview of Windows RADIUS Server 2019 Configuration:

• Install and set up Windows Server 2019.
• Install Active Directory Domain Services (ADDS) to configure the new domain.
• Install Certificate Authorities (CA) with Active Directory Certificate Services (ADCS).
• Install NPS ( Network Policy Server).
• Configure Certificate Authorities (CA), i.e., Active Directory Certificate Services (ADCS) for Certificates.
• Configure NPS ( Network Policy Server) for the authentication protocol.
• Configure RADIUS.
• Define Network policies for users/devices.
• Configure Access Point.
• Set up zero clients, and select 802.1x authentication.
• Configure Wireless Connection Request.

Configure Windows 2019 RADIUS Server:

Now we will see each step involved in configuring Windows 2019 server in detail:

Install and Configure AD DS:

For configuring ADDS, follow the given instructions:

• Navigate to Windows Server 2019.
• Click Start.
• Click Server Manager.
• Navigate to Role Summary.
• Click Add Roles and Features.
• Select Role-based or Feature-based installation.
• Navigate to the Before You Begin page and click Next.
• Navigate to the Select Server Roles page.
• Select the Active Directory Domain Services.
• Click Next.
• Click Install on the Confirm Installation Selections.
• Navigate to the Installation Results page and click Close.

ADDS is installed.

Install AD CS and NPS :

For configuring ADDS, follow the given instructions:

• Navigate to Server Manager.
• Select Roles and Click Add Roles.
• Click Next on the Before you Begin page.
• Select Active Directory Certificate Services (AD CS) and Network Policy and Access Services.
• Click Next.
• Click Next on Network Policy and Access Services
• Navigate to Role Services and select Network Policy Server.
• Click Next.
• Select Create a self-signed certificate for SSL encryption and click Next.
• Click Next on the Introduction to Active Directory Certificate Services
• Select Certification Authority on the Select Role Services page and click Next.
• Select Enterprise on Specify Setup Page and Click Next.
• Select Root CA on Specify CA Type Page and Click Next.
• Select Create a new private key on the Set Up Private Key Page and Click Next.
• Click Next on Configure Cryptography for CA.
• Enter details on Configure CA Name page and click Next.
• Enter the validity period on the Set Validity Period page and click Next.
• Click Next on Configure Certificate Database page.
• Click Next on the Web Server (IIS) page.
• Click Next on the Select Role Services page.
• Click Install on the Confirm Installation Selection page.
• Click Close.

Now the AD CS (Active Directory Certificate Services), Web Server (IIS), and NPS are installed successfully.

Configure NPS ( Network Policy Server) and RADIUS authentication.

• Click on the Start button and select Administrative tools.
• Click NPS on the Network Policy Server.
• Select Register Server in Active Directory and click OK.
• Click OK.
• On the NPS (Local) page, select RADIUS server for 802.1x Wireless or Wired Connections.
• Click Configure 802.1x.
• Select Secure Wireless connections on the Configure 802.1x page.
• Type Name and click Next.
• Add RADIUS clients on the Configure 802.1x page and click Next.
• Type the following details on the New RADIUS Client page.
  • Name
  • IP Address
  • Shared Secret (Manual)
• Click OK and click Next.
• Select Microsoft Protected EAP (PEAP) on the Configure 802.1x
• Click Configure.
• Select Secured password on the Edit Protected EAP Properties page and click Edit.
• Enter the Number of authentication retries and click OK and click Next.
• Select Groups and click Next.
• Click Next again and click Finish.
• Restart NPS again.

Define Network Policies for users/devices.

You can follow the given steps for Defining the network policies.

• Navigate to the NPS console and click NPS (local).
• Click and expand Policies.
• Select Network Policies.
• Click New.
• Enter a Policy Name.
• Select the Type of Network Access Server to Unspecified while using Netscaler or RCdevs OpenLDAP while using OTP.
• Click Add in Specify Conditions
• Select Windows Groups and click Add.
• Click Add Groups and click OK.
• Select NAS Identifier in the Select Conditions
• Enter a Name and select Next to continue.
• Select Access Granted in Specify Access Permission
• Under Configure Authentication Method, select MS-CHAP v2 for maximum security.
• Click Next.
• Select RADIUS attributes as Standard in Configure Settings.
• Click Add.
• Enter the attribute value in String and click OK.
• Click Next and click Finish.

You can use the Network Policy Wizard to create and add new conditions, constraints, and setting to the network policies.

Administrators can define and implement a wide range of policies using our Cloud RADIUS, including lookup policies applied at the moment of authentication. For instance, depending on the time of day, you can decide whether to accept or reject people and devices. You may also restrict access to devices running a specific operating system.

Set up Zero Clients, and Select 802.1x Authentication

• Navigate to the Control panel and open the Network and Sharing center.
• Click Change adapter settings.
• Select Local Area Connection and click Properties.
• Select Authentication and click Enable IEEE 802.1x authentication.
• Select the desired protocol in the dropdown button.

Configure Wireless Connection Request

• Navigate to the Control panel and open the Network and Sharing center.
• Click Manage Wireless Networks.
• Select Manually Create a network profile.
• Enter your SSID in Network Name and click Next.
• Click Change Connection settings.
• Select Security and click Settings.
• Select the Trusted Root CA and click OK.
• Navigate to Advanced Settings.
• Select Specify Authentication Mode and click OK.

Windows RADIUS Servers are not Cloud Compatible

NPS’s primary drawback is that it is designed to be an on-premise RADIUS solution for Active Directory environments. Cloud integration of NPS also has other significant downsides, even with other Microsoft-owned cloud-based solutions like Azure AD. If you want to use Azure with NPS, you will require a separate authentication server or proxy to achieve cloud authentication. These operations are not only challenging to configure and maintain but time-consuming and relatively expensive.

Furthermore, the traditional RADIUS servers installed on-site are prone to several security issues and vulnerabilities. Windows RADIUS servers have a number of vulnerabilities of their own that hackers frequently take advantage of in zero-day attacks. In addition, they require a lot of time and expertise to set up and maintain.

Due to its physical accessibility, the NPS server’s on-premise presence makes it vulnerable to various physical security threats, from intruders to disasters – or just power outages. Given the costs of maintaining highly-secure physical locations, there’s rarely a circumstance in which on-prem works out to be cheaper than cloud RADIUS.

Cloud RADIUS: Admins’ First Choice

For years, network administrators have relied on Windows Server for network authentication, but due to modern-day technological advancements, it is difficult to ignore its shortcomings.

There are several advantages to moving to the cloud over staying in an on-premises system, and no product exemplifies those benefits more than our revolutionary Cloud RADIUS. You can avoid the shortcoming of on-premise authentication by utilizing a cloud-based NAC like SecureW2’s Cloud RADIUS.

With our Cloud RADIUS, you may restrict or enable access to users depending on various factors, including user/device characteristics, time of day, and more. Additionally, you may use our Cloud RADIUS with any IDP because it is built for vendor neutrality. An industry-unique feature is the ability to enforce policies using real-time user lookups against Azure, Okta, and Google Workspace.

Integrating with Securew2 gives you more customization options through our many innovative features like Azure MFA auth, Intune auto revocation, Windows Hello for Business login, and many more. Besides not needing lengthy setups, Cloud RADIUS is resistant to on-site risks like outages and burglars. It doesn’t need to be installed at each location of your company because it is hosted in the cloud and has built-in redundancy.

If you are interested in taking that first step towards security for your organization, look no further and click here to inquire about pricing.