Organisations can make it easy to authenticate remote users using a RADIUS server. However, it is not always easy to properly configure RADIUS. But there is no need to worry – there are certain best practices you can follow to make it easy.
Generally, Integrated Windows Authentication (IWA) is the preferred authentication system for Windows Servers, in certain circumstances, it falls short. For instance, if the users wish to connect to your network from a remote location, such as a VPN, or a wireless network, or even a dial-in connection, you might have to authenticate those users through a RADIUS server.
What is a RADIUS Server?
Popularly known as RADIUS, the Remote Authentication Dial-In User Service, has been around for a long time in one form or another. Most ISPs (Internet service providers) use RADIUS Server authentication, making it the most commonly used authentication mechanism.
Even Microsoft included a RADIUS server in its Windows in 2000. However, the RADIUS Server Windows name was changed to Internet Authentication Service or IAS in 2003. IAS is reasonably easy to configure, but it might need some extra security on IAS authentication.
Read on to understand the working of IAS and how to configure it for better security and optimum performance.
Understanding IAS in RADIUS
Before configuring IAS, it is necessary to understand IAS and its working. The technical terms can be a bit confusing to start with, but once you get familiar with the setup, it becomes easy.
So, whether you are in a Microsoft environment or a RADIUS environment, you’ll have a remote client looking to access a resource on a private network. These remote clients are known as ‘access clients’ in Microsoft parlance.
However, the access client can connect to the private network only through some mechanism that makes the connection possible. It could be a VPN, a dial-in server, or a wireless access point. No matter which device or mechanism you use, it is called the ‘access server’ or RADIUS client.
It could be confusing – but when you realise that access clients treat the device you use to connect as a server, things become a little clearer. The device will then communicate with the RADIUS server. In this scenario, the device acts as a server to access clients but acts as a client to the RADIUS server and hence the confusing name RADIUS client or access server.
In a simple IAS application, the IAS server is the next component in the chain. Please note that Microsoft usually uses the term RADIUS server interchangeably. Nevertheless, the IAS server is a mechanism that processes the requests from the access clients, based on certain rules.
As soon as the IAS server receives a request, it compares it to the rules and then sends back an Access-Accept or an Access-Reject message to the access client. Even where an Access-Accept message is sent by the IAS, the message might contain certain connection restrictions.
Even if the IAS server actually performs the Access-Accept or Access-Reject decision, it must still consult a database to determine the validity of the user’s credentials. IAS can use many databases for this.
The supported databases include the local Security Accounts Manager (SAM), a Windows domain, or Active Directory. Usually, these database types are used if the IAS server and the database server belong to the same domain, or if a two-way connection exists between the domains if they are separate.
In a larger environment with multiple RADIUS servers, there will be an additional RADIUS component – the RADIUS proxy. For example, if a business has a single VPN connection but multiple RADIUS servers connecting to different private network segments, a RADIUS proxy will route RADIUS messages between the access client and its RADIUS server.
Here is a representation of a simple IAS setting. In case there are several RADIUS servers, a RADIUS proxy will be put between the Access Client and RADIUS server.
Best practices for deploying RADIUS
The first best practice is building the network one step at a time and performing tests at each step. So, if you wish to use RADIUS to authenticate users accessing your network through a VPN network, you should test the access server even before you put the RADIUS server. As the access server is a wireless connection, connect the access point of the network for a few minutes to ensure that the wireless client can go through the access point to gain access to your network.
Some might argue that it is foolish to connect the wireless network without any authentication, but ensuring the wireless hardware works properly before you put RADIUS in place makes things easier. Unless you deal with extremely vulnerable or delicate data, connecting an access point for a few minutes to verify connectivity shouldn’t be a major security crisis.
Deploying an NPS Radius Server
If you deploy Network Policy Server (NPS) as a RADIUS server, the NPS performs authentication, authorization, and accounting for connection requests. This is true for the local domain as well as the domains that trust the local domain. However, if you use NPS as the RADIUS proxy, it will relay the connection request to a server running NPS or another RADIUS server in remote domains.
Deploying an NPS include planning for:
- NPS configuration
- RADIUS clients
- Use of authentication methods
- Network policies
Preventing multiboot troubles
You should run only on single Windows Server on your RADIUS server. Using a multiboot configuration isn’t advisable as it could overwrite your system configuration, which might lead to further complications. If at all you have to install multiple servers, make sure you install separate operating systems on separate volumes. Alternative is to run multiple servers using Hyper V.
Accounts database location
An IAS server uses the local SAM, a Windows domain, or Active Directory. However, you may not be able to choose the database type randomly. You can work around the problem by placing the IAS in the windows server and putting a RADIUS proxy server in the other domain and use it to forward requests to an IAS server in the Windows domain.
Back up the RADIUS configuration
Much of the security issues associated with RADIUS occur because of using shared secrets. The shared secret is an encryption key known to the RADIUS client, the access client, and the RADIUS server or the RADIUS proxy. It is used to encrypt authentication credentials and data.
You mustn’t use the Password Authentication Protocol (PAP) along with RADIUS because RADIUS is so designed that not all connection uses the same shared secret
However, it is important to use a secure shared secret as establishing a secure shared secret is akin to creating a secure password. The ideal shared secret must be a random combination of upper- and lower-case letters, numbers, and symbols. Also, you must change your shared secret regularly.
Don’t assume that shared secrets and passwords are the same. They differ mainly in length. If a password is over eight characters long, it is considered secure. Shared secrets must be at least 22 characters long to be considered secure. If you are looking for maximum security, make your shared secret up to 128 characters long.
In this context, you must be aware that you can define access clients by IP address or by a fully qualified domain name. If you use the latter, and it maps to multiple IP addresses, only the first address will be used.
If you take care of all the above points and plan accordingly, the implementation of the RADIUS server will not only be a meticulous process but also smooth and hassle-free. At the same time, you should also bear in mind that all these are general pointers that work with RADIUS servers, NPS servers, and AWS servers, certain situations might need few tweaks from the experts for smooth implementation. You can take this as a starting point or guide and proceed further according to your specific needs and situations.