Skimming the surface: Network Policy Servers and the RADIUS Environment
In Windows Server 2012, Network Policy Servers (NPS) are used to enforce RADIUS (Remote Access Dial-In User Services) and NAP (Network Access Protection) protocol. If a remote client is trying to access the network, NPS makes sure they comply with the standing Network Policy, and if not, it sends them packing. Network Policy can relate to anything from traffic redirection to authentication requests to System Health Validators that ensure robust security standards on the client’s operating system. If clients don’t comply with these policies, they might be quarantined for remediation or denied access outright. Think of your NPServers as the security guards, school nurses, and crossing-guards of your network; nobody gets to class unless they’ve got a student ID and proof of vaccinations.
Now, not all NPS servers are NAP servers, and not all are even technically RADIUS servers (some are RADIUS Proxies who redirect connection requests), but all fulfill some role in the implementation of Network Policy, and together, they form the ecosystem of your RADIUS environment. With that said, let’s see what it takes to get your Network Policy Server up and running. This is a guide to starting up NPS and looking at basic features for those just getting their bearings with the service.
- When it comes to installing new features, Powershell is always the quickest and most efficient way. Typing Get-Windowsfeature *NPAS* should give you a good look at the available NPS features
2. In this scenario, you can grab all those features and pipe them into an Install-WindowsFeature cmdlet to assign them to this server: get-windowsfeature *npas* | install-windowsfeature (Note: you can always install an individual feature by using Install-WindowsFeature %featurename% -includemanagementtools).
3. Now that you’ve got all your NPAS features, let’s see what you can do with them. First, you need to register your server with Active Directory, which you can accomplish through a Netsh command: netsh ras add registeredserver
4. Now, you’ve got to give your NPS server some templates to use for authentication of the clients who want to access your server. Here, you are going to create one for your Shared Secret (the password used to access the network). Other common templates would be those intended for specific clients or those establishing health policy. You can have as many as you want, so go crazy.
5. Since Powershell doesn’t really have anything readily available to create templates with, you can make a graphical console by using the mmc command and adding a NPS snap-in. Just type mmc into PS and you’ll get a Management Console. Then, select File | Add/Remove Snap-in from the toolbar.
6. From here, you can select Network Policy Server, then Add, and then OK, to run the newly created NPS console.
7. Once you’re in the NPS MMC, expand NPS and Templates Management; Right click Shared Secret; select New.
8. You are prompted to choose a template name and shared secret. You can choose your own or have the system generate a random password. Then, just click OK. Congratulations, you are now the proud parent of a shared secret.
9. Back in Powershell, check to see if you successfully created the template by typing the get-npssharedsecrettemplate cmdlet.
There it is. For the purposes of this tutorial, we’ll leave it at that. You installed NPS, registered the server with Active Directory, and created your first template. At this point, you could create all the templates you needed in the mmc and start adding clients with the New-NPSradiusclient cmdlet (see below).
With Network Policies, you can control just when, where, and how outside clients can access your network. It’s a powerful, necessary tool for most network environments, and it goes a lot deeper than this. If you want to learn more on NPS, check out Technet here: Network Policy and Access Services.
Postscript: For a little bonus trivia, which ports does NPS communicate on?1812/1645 for authentication and 1813/1646 for accounting.
