Two-factor authentication through Windows Server 2008 NPS

Increasingly, whether due to regulatory requirements or a basic recognition that static passwords just don't provide adequate security, organizations are implementing some form of strong authentication. Like all new efforts, before you start you want to be reasonably assured that you will succeed. In this tutorial we will document how to add two-factor authentication to various Microsoft remote access solutions through the Windows Server 2008 Network Policy Server. For two-factor authentication, we will be using the WiKID Strong Authentication Server - Enterprise Edition. WiKID is a dual-sourced, software-based two-factor authentication system. While the document is product specific, the process is typically the same no matter the products.

Assume that you have a mixed OS environment with some Windows, some Linux/Unix. You have a new requirement for two-factor authentication to meet PCI requirements. You intend to protect all key systems, which are mostly linux and you are going to lock down your remote desktop with two-factor authentication too (though we will only discuss the SSH here). The plan is to create an SSH gateway server that is locked down with two-factor authentication. Admins can then jump from the gateway box to other servers using public key authentication.

SSH offers a highly secure channel for remote administration of servers. However, since you face an audit for PCI, you have become aware of some potential authentication related short-comings that may cause headaches in an audit. For example:

* There is no way to control which users have public key authorization

* There is no way to enforce passphrase complexity (or even be sure that one is being used)

* There is no way to expire a public key

Additionally, your intention is to add two-factor authentication to other services, such as RDP and a VPN. There is great benefit in having a single two-factor authentication service for all those services and SSH keys will not work for other services.

An overview

After everything is configured, the system will work like this: The user generates a one-time passcode from their WiKID software token. They enter it into the SSH password field. The credentials are passed from the SSH gateway to NPS via radius. NPS validates that the user is active in AD and in the proper group. If so, it sends the username and one-time password to the WiKID Strong Authentication Server still using Radius. If the OTP is valid, the WiKID server responds to the NPS, which in turn responds to the SSH gateway server and the user is granted access. Note that this process is only for authentication, session management is still handled by the SSH gateway or any other remote access service you are using.

First we will enable Windows Server 2008 Network Policy Server (NPS)

Add the "Network Policy and Access Services" role to your domain controller.

Enable these role services during installation:

* Network Policy Server

* Routing & Remote Access Services

* Remote Access Service

* Routing

Next we add a new RADIUS Client - The SSH Gateway in this case.

Page Break

Right click on Radius Clients and Select New

Add a name, the ip address of your remote access server (RAS, VPN, etc) and create a shared secret. You will enter the same shared secret on the WiKID server.

Click OK

Add a new Radius Server - The WiKID Strong Authentication Server

Right click on Remote RADIUS servers and name the group, something like "WiKID".

Click the Add button to add a new radius server in the group.

Enter the IP address of the WiKID server on the first tab. On the second tab, enter the shared secret. That should be all you need to change.

Creating a Network Policy

Now that we've created the radius client and radius server (WiKID), we need a new Network Policy that tells IAS which users to proxy to WiKID.

Enter a name and leave Type of network access server as Unspecified or choose your remote access system.

Click on the Conditions tab. I added a condition for all requests from my server's IP address.

Click on the Settings Page. Click on Authentication and Select the button for "Forward requests to the following remote RADIUS server group for authentication. Choose WiKID.

Configuring the WiKID Strong Authentication Server.

Now that we've configured the NPS to proxy authentications, we need to configure WiKID to accept them. See the WiKID installation manual for the details on how to install and configure the WiKID server. Here we're just going to be adding a radius network client for the NPS:

Log into the WiKIDAdmin web interface.

Click on the Network Clients tab.

Click on "Create New Network Client". Give the Network Client a name, specify the IP address, select Radius as the protocol and choose which WiKID Domain to use. (WiKID domains hold the users and specify certain security parameters such as PIN length, the lifetime of the one-time passcodes, max bad PIN/passcode attempts, etc.)

Click Add

On the next page, enter the Shared Secret. This is the same secret you entered in NPS above in the second tab of the 'Add Radius Server' step on the NPS. Be sure these match! WiKID support adding radius return attributes at the Network Client level and on a per-user group level, however, that is beyond the scope of this document.

You will get a notice that the network client has been added. You will need to restart the WiKID server from the command line. This loads the network client into the radius interface and opens the radius ports on the built-in WiKID firewall.

# wikidctl restart

Next: Configuring the SSH Gateway Server

Page Break

Configure the SSH Gateway

Now we will configure the central SSH gateway. This linux box is the gateway/proxy to all the production servers in the farm. It should be locked down tight with no extraneous software or services running on it. It should have an external interface for in-bound connections and an internal interface for internal connections. First, we will configure the gateway box to use WiKID for strong authentication of SSH users.

Start by installing PAM Radius. The PAM Radius home page is here.

Download the tar file (as of this writing 1.3.17 was the latest).

Run:

$ make

Copy the resulting shared library to /lib/security.

$ sudo cp pam_radius_auth.so /lib/security/

Edit /etc/pam.d/sshd to allow Radius authentication.

$ sudo vi /etc/pam.d/sshd

N.B.: Distributions of linux have different pam.d file formats. Please check with your distribution for specific suggestions. These instructions work for Fedora/Redhat/Centos.

Go to the first line of the file, hit the Insert key or the i key and insert this line.

auth sufficient /lib/security/pam_radius_auth.so

The 'sufficient' tag indicates that if the Radius authentication succeeds then no additional authentication will be required. However, if the Radius authentication fails, a username and password from the system will work. Use 'Required' to require strong authentication.

Write the file and quit. Hit the Esc key to exit insert mode and type ':wq'

Edit or create your /etc/raddb/server file. There is a sample here.

vi /etc/raddb/server

Below the line:

127.0.0.1 secret 1

Add this line, substituting your routableIPAddress:

routableIPaddress shared_secret 1

The routeableIPaddress is the IP address of your NPS server.

Edit your /etc/pam.d/sshd file thusly:

#%PAM-1.0

auth sufficient /lib/security/pam_radius_auth.so

auth include system-auth

account required pam_nologin.so

account include system-auth

password include system-auth

session include system-auth

session required pam_loginuid.so

Add your WiKID server to the /etc/raddb/server file, using the internal IP Address of the WiKID server and the shared secret you entered in the Network Client creation page:

# server[:port] shared_secret timeout (s)

127.0.0.1 secret 1

xxx.xxx.xxx.xx wikidserver_secret 3

Let's add some security to SSH configuration here too. Open your /etc/ssh/sshd_config (not the nearby ssh_config file). Add these configuration options:

#Protocol 2,1

#Check that only protocol 2 is allowed:

Protocol 2

#Disallow root login:

PermitRootLogin no

#Disallow accounts without passwords:

PermitEmptyPasswords no

If you want to change the port you can. It won't stop an attacker, but it might cut down on log events caused by script kiddies. This gateway box is now set to use WiKID one-time passwords for SSH authentication. All users have to be registered with the WiKID server and no one can login as root. Before we leave this box, we'll do something that is a little bit different - we will have the users create their RSA private key on the gateway. Once each users is signed into the box with WiKID, have them create their keys:

class="command">ssh-keygen -t rsa

In my opinion, passphrases for these keys are redundant. They are here only to create a single sign on functionality into the server farm. Obviously, you must be careful to be sure that users do not have access to other keys.

Configure the target servers

Obviously, we configure these servers to only accept incoming SSH requests from the gateway. We do this by restricting access on port 22 to our internal addresses. Edit /etc/sysconfig/iptables and add or edit the line for SSH on port 22:

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 22 -j ACCEPT

Running the WiKID Software token

Start the WiKID token and select the Domain associated with the SSH Gateway. Then enter the PIN and you will get back the one-time passcode. The OTP is time-bounded, but the time can be set on the WiKID server to whatever you want.

The user simply enters the one-time passcode when prompted by SSH.

The token can also be run from the command line, which is quote convenient for SSH:

java -cp jWiKID-3.1.3.jar:jwcl.jar com.wikidsystems.jw.JWcl domainid

Were domainid is the 12 digit domain identifier.

Conclusion

Many organizations are facing increased compliance and regulation. Additionally, environments are becoming more and more heterogenous and the Internet is becoming more and more dangerous. At the same time, users need more access and want to telecommute more, which is good from a disaster recovery perspective.

While this tutorial has focused on adding two-factor authentication to SSH, an un-stated concept is that you have chosen Radius as a network authentication standard. And it's a good one. Most VPNs, remote desktop systems, web servers and other remote access services support Radius. Now when you want to add a new service with two-factor authentication, all you have to consider is "Does it support Radius?". If it does, then all you need to do is point it to your NPS server. The same holds true if you use Freeradius or some other Radius server.

For more information on WiKID's two-factor authentication system, please visit our website.