Defining Network Policies

Network policies let you specify who is authorized to connect to a network. They also define the conditions under which a connection can be established. To create a network policy, click the Policies node, select Network Policies , and choose New from the context menu. Give the new policy a name and specify the type of network access server, as with the connection request policy.

The next job is to define the conditions that must be met for users and computers to connect to the network. Conditions include Windows groups, computer groups, day and time restrictions, and connection properties such as IPv4 addresses, authentication types, tunnel types, and RADIUS client properties.

After you have configured the conditions, you can then specify whether to grant or deny access if the client or user matches the policy properties. The third option is the special feature that lets you override NPS policies if user dial-in is explicitly allowed or denied in the properties of the user object in AD.

The next step is to configure the authentication methods (Figure 3). You can choose from legacy and possibly insecure protocols, such as MS-CHAP (Challenge-Handshake Authentication Protocol), MS-CHAP v2, or PAP (Password Authentication Protocol). You can also specify EAP. EAP types include, for example, protected EAP (PEAP), secured password (EAP-MSCHAP v2), and smart card or other certificate-based authentication. If several EAP types are configured, they are processed in the order displayed. Next, you can set constraints such as Idle Timeout , Session Timeout , Day and time restrictions , and allowed NAS Port Type .

Figure 3: A network policy defines the permitted client authentication methods.

At the end, you determine whether channel bundling can be used for dial-up connections or whether the Bandwidth Allocation Protocol (BAP) is used. You can also configure IP filters that act as simple firewall rules to direct incoming and outgoing traffic. Other settings, such as Microsoft Point-to-Point Encryption (MPPE), can be specified and defined, as well as whether a client can use its own IP addresses or they are assigned by a DHCP server or by server settings.

Managing Templates

If you maintain extensive RADIUS server implementations, Templates Management allows you to use a PSK from a template for recurring activities, such as creating RADIUS clients. NPS Management lets you create templates for:

• Shared Secrets
• RADIUS Clients
• Remote RADIUS Servers
• IP Filters

To create a new template for a PSK, click the desired template in the Templates Management node and select New from the context menu. You can then use the created templates at a later date.

High-Availability NPS

Highly available RADIUS implementations [3] are achieved a couple of ways. You can operate several NPS servers and distribute the RADIUS clients equally among them, or you can use several RADIUS proxies that distribute the RADIUS requests equally among the RADIUS servers.

The problem with high availability is that NPS cannot store the configuration centrally. Therefore, if you are using many policies and RADIUS clients, you have to complete the configuration manually on each NPS server. Furthermore, changes to the settings always have to be made on all NPS servers. One more-or-less convenient option is to export the NPS configuration with a console command and to import it on the target system. With the help of a task planner, the configuration can then take place at certain times.

Exports and imports rely on netsh.exe or PowerShell cmdlets. The netsh command for exporting settings is

netsh nps Export filename=C:\NPS-Config\NPS.XMLExportPSK=Yes

whereas the

netsh nps Import filename=C:\NPS-Config\NPS.XML

command imports the configuration.