Ensure your RADIUS deployment is as robust as your Active Directory with this scripted solution.
If, like many organisations, Active Directory (AD) is a business critical component of your IT infrastructure, you should certainly consider the benefits of a redundant AD configuration using multiple, synchronised Domain Controllers (DC) at different geographic locations, if you haven't already.
Why multiple Domain Controllers?
The main advantage of running multiple DCs hosting your AD is, naturally, the introduction of redundancy, making authentication, login and security in your business resilient to failure. In addition, thanks to Multimaster Replication, any changes made to the AD configuration is automatically replicated across each DC.
Using Radius with Active Directory
Complex modern networks, however, also make use of multiple non-domain devices such as Linux servers, switches and firewalls. Making it all mesh together within a single authentication environment requires the use of a third party application such as the Remote Dial in User Service (RADIUS). There are lots of alternatives to RADIUS including the more complicated Lightweight Directory Access Protocol (LDAP) but RADIUS is simpler to configure in comparison so we focus on that here.
RADIUS is the client/server protocol which runs on the transport layer of the TCP/IP protocol stack using User Datagram Protocol (UDP). Gateway devices use the client element, which sends user access requests to the server component located, in this instance, on the DC. Credentials are then checked against the information stored within the AD and the appropriate response sent back to the users.
The issue with RADIUS and multiple Domain Controllers
There is a problem however. When the RADIUS configuration is changed on a DC, unlike the AD database, the changes are not replicated on the other DCs in the network. Therefore, it is necessary to update the configuration manually on each DC that is running RADIUS. This process is time consuming and open to human error, increasing the risk of disparity between DC. This effectively negates the benefits of having a redundant system since the master DC, or the one where RADIUS was last changed, effectively becomes a single point of failure again. In the event of a failure, critical devices may become inaccessible due to errors in the live RADIUS configuration.
A scripted solution to sync RADIUS
A more reliable solution is to use simple scripts, scheduled to run automatically, to replicate your RADIUS configuration across each DC running RADIUS.
First, here are the two scripts you will need.
To export the RADIUS configuration on the master server:
netsh nps export filename = “C:\radius\config.xml” exportPSK = YES
To import on another server:
netsh nps import filename = “\masterIP\radius\config.xml”. (Make sure to replace 'masterIP' with the IP address of your master DC.)
Next, to configure the scripts to be run regularly on each DC, follow this procedure:
Open up PowerShell and run the command:
This allows the script to be run.
Copy the import script from /your_radius_server/radius (where 'your_radius_server' is the local root folder) and place on the desktop for easy access.
Now configure the script to open with PowerShell and as a scheduled task.
Right click your script on the desktop and select Open with followed by Pick program. Next, either search for and select PowerShell or enter C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Save these settings and open the Windows Task Scheduler (found within Administration Tools). Create a scheduled task to run the script, we suggest, every three hours.
Forcing a manual update
In addition to the regular, automated updates you now have in place, you can always force an update using the scripts that are now conveniently located on the desktop of each DC. Just double click the script on each, starting with the master, to manually update each DC.