✓ Configure Network Policy Server (NPS)
■ Configure a NPS server including RADIUS proxy
■ Configure RADIUS clients
■ Configure NPS templates
■ Configure RADIUS accounting
■ Configure certificates
✓ Configure NPS policies
■ Configure connection request policies
■ Configure network policies for VPN clients (multilink and bandwidth allocation, IP filters, encryption, IP addressing)
■ Import and export NPS policies
✓ Configure Network Access Protection (NAP)
■ Configure System Health Validators (SHVs)
■ Configure health policies
■ Configure NAP enforcement using DHCP and VPN
■ Configure isolation and remediation of non-compliant com- puters using DHCP and VPN
■ Configure NAP client settings
Overview of Wireless Access
In today’s computer world, it seems like everyone has a laptop. We all do a lot of traveling, and at any airport it seems like everyone is working on a laptop while waiting for a plane. Because laptops have grown in popularity, IT professionals must account for them on their networks. Laptops offer IT administrators a unique set of challenges that must be dealt with on a day-to-day basis. One major concern for IT administrators is security. Years ago, we never had to worry about users copying documents to a desktop computer and then walking out with the computer. However, today users can copy company documents to laptop computers and then walk out the door with the computer and the documents. So, I will discuss wireless networks, protocols, and security. Windows 8, Windows 7, Windows Vista, Windows 2008/2008 R2, Windows Server 2012, and Windows Server 2012 R2 have enhanced the IEEE 802.11 wireless support to include some of the following changes: ■ Single sign-on ■ 802.11 wireless diagnostics ■ WPA2 support ■ Native Wi-Fi architecture ■ User interface improvements for wireless connections ■ Wireless Group Policy enhancements ■ Changes in wireless auto-configuration ■ Integration with Network Access Protection when using 802.1X authentication
■ EAP host infrastructure ■ Command-line support for configuring wireless settings ■ Network location awareness and network profiles ■ Next-generation TCP/IP stack enhancements for wireless environments
Configuring Wireless Access Windows 8, Windows 7, Windows Vista, Windows XP, and Windows Server 2003, 2008/2008 R2, and 2012/2012 R2 provide built-in support for 802.11 wireless LAN networking. Inside the Network Connections folder, an installed 802.11 wireless LAN network adapter appears as a wireless network connection. The following are some of the items you can configure: Operating Modes There are two types of operating modes: Infrastructure Mode This mode uses at least one wireless access point (WAP) and/or a device that bridges the wireless computers to each other. Ad Hoc Mode Using this mode, wireless network computers connect directly to each other without the use of an access point (AP) or bridge. Wired Equivalent Privacy All of us (on a laptop) have tried to find a wireless network at one time or another. Wired Equivalent Privacy (WEP) is a wireless encryption that was originally defined in 802.11. WEP helps to prevent unauthorized wireless users from accessing your wireless network by the use of a shared secret key: ■ If your wireless network is using the infrastructure mode, the WEP key must be configured on the wireless AP and all of the wireless clients. ■ If your wireless network is using the ad hoc mode, the WEP key must be config- ured on all of the wireless clients.
The WEP key can be either 40-bit or 104-bit, depending on what your hardware can accommodate. Wi-Fi Protected Access An organization of wireless equipment vendors called the Wi-Fi Alliance created an interim standard called Wi-Fi Protected Access (WPA) while the IEEE 802.11i wireless LAN security standard was still being completed. WPA uses a strong encryption method called the Temporal Key Integrity Protocol (TKIP) to replace the weaker WEP standard. You have the ability to use the Advanced Encryption Standard (AES) for encryption that is provided by WPA. WPA can be used in two different mode types: WPA-Personal This is used for a home office or small company. In the WPA-Personal model, you would use a preshared or passphrase code to gain authorization onto the network. WPA-Enterprise This was designed for a midsize to large organization. WPA-Enterprise has all of the same features as WPA-Personal, but it also includes the ability to use a 802.1X RADIUS server.
Wi-Fi Protected Access 2 Wi-Fi Protected Access 2 (WPA2) was officially designed to replace the WEP standard. WPA2 certifies that equipment used in a wireless network is compatible with the IEEE 802.11i standard. This certification is used to help standardize the use of the additional security features of the IEEE 802.11i standard that are not already included in WPA. WPA2 can be used in two different mode types: WPA2-Personal This is used for a home office or small company. In the WPA-Personal model, you would use a preshared or passphrase code to gain authorization onto the network. WPA2-Enterprise This was designed for a midsize to large organization. WPA-Enter- prise has all of the same features as WPA-Personal, but it also includes the ability to use a 802.1X RADIUS server. Service Set Identifier To specify a wireless network by name, you specify the service set identifier (SSID), also known as the wireless network name: Infrastructure Mode The SSID is configured on the wireless access point. Ad Hoc Mode The SSID is configured on the initial wireless client. To help wireless clients discover and join the wireless network, the wireless AP or the initial wireless client periodically advertises the SSID. (This can be disabled for security.) Group Policies for Wireless You have the ability to use Group Policy settings for Vista, Windows 7, Windows 8, Windows 2008/2008 R2, and Windows Server 2012/2012 R2 for WPA2. Group Policy settings allow you to configure WPA2 options at the server for all wireless clients.
Remote Access Security
In the past, remote access was seldom part of most companies’ networks. It was too hard to implement, too hard to manage, and too hard to secure. It’s reasonably easy to secure your networks from unauthorized physical access, but it was perceived to be much harder to do so for remote access. Recently, a number of security policies, protocols, and technologies have been developed to ease this problem. First I’ll discuss the user authentication protocols.
User Authentication One of the first steps in establishing a secure remote access connection involves allowing the user to present some credentials to the server. You can use any or all of the following authentication protocols that Windows Server 2012 R2 supports: Password Authentication Protocol The Password Authentication Protocol (PAP) is the simplest authentication protocol. It transmits all authentication information in cleartext with no encryption, which makes it vulnerable to snooping if attackers can put themselves between the modem bank and the remote access server. However, this type of attack is unlikely in most networks. The security risk with PAP is largely overemphasized considering the difficulty of setting up a sniffer in between the modems and the remote access server. If an attacker has the ability to install a sniffer this deep in the network, you have larger problems to address. PAP is the most widely supported authentication protocol, and therefore you may find that you need to leave it enabled. Microsoft CHAPv2 Microsoft created Microsoft CHAPv2 (MS-CHAPv2) as an extension of the CHAP protocol to allow the use of Windows authentication information. Version 2 is more secure than version 1, and version 1 is not supported by Windows Server 2008 and newer. Some other operating systems (besides Microsoft) support MS-CHAP version 1. Extensible Authentication Protocol The Extensible Authentication Protocol (EAP) doesn’t provide any authentication itself. Instead, it relies on external third-party authentication methods that you can retrofit to your existing servers. Instead of hardwiring any one authentication protocol, a client-server pair that understands EAP can negotiate an authentication method. The computer that asks for authentication (the authenticator) is free to ask for several pieces of information, making a separate query for each one. This allows the use of almost any authentication method, including smart cards, secure access tokens such as SecurID, one-time password systems such as S/Key, or ordinary username/ password systems. Each authentication scheme supported in EAP is called an EAP type. Each EAP type is implemented as a plug-in module. Windows Server 2012 R2 can support any number of EAP types at once; the Routing and Remote Access Services (RRAS) server can use any EAP type to authenticate if you’ve allowed that module to be used and the client has the module in question. Windows Server 2012 R2 comes with EAP-Transport Level Security (EAP-TLS). This EAP type allows you to use public key certificates as an authenticator. TLS is similar to the familiar Secure Sockets Layer (SSL) protocol used for web browsers. When EAP-TLS is turned on, the client and server send TLS-encrypted messages back and forth. EAP-TLS is the strongest authentication method you can use; as a bonus, it supports smart cards. However, EAP-TLS requires your RRAS server to be part of a Windows 2000, Windows Server 2003, Windows Server 2008/2008 R2, or Windows Server 2012 R2 domain. EAP-RADIUS is another authentication method included with Windows Server 2012 R2. EAP-RADIUS is a fake EAP type that passes any incoming message to a Remote Authentication Dial-In User Service (RADIUS) server for authentication. PEAP-MS-CHAP v2 This protocol is founded on the authenticated wireless access design, and it’s based on Protected Extensible Authentication Protocol Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2). This authentication protocol utilizes the user account credentials (username and password) stored in Active Directory Domain Services to authenticate wireless access clients instead of using smart cards or user and computer certificates for client authentication
PEAP-MS-CHAP v2 is an EAP-type protocol that is easier to deploy than Extensible Authentication Protocol with Transport Level Security (EAP-TLS). It is easier because user authentication is accomplished by using password-based credentials (username and password) instead of digital certificates or smart cards. Only servers running Network Policy Server or PEAP-MS-CHAP v2 are required to have a certificate. The server certificate used by NPS can be issued by your organization’s private trusted root CA deployed on your network or by a public CA that is already trusted by the client computer.
Just in case you missed the very important line above, I will say it again: Servers that are running Network Policy Server or PEAP-MS-CHAP v2 are required to have a certificate.
TLS/SSL (Schannel) TLS/SSL (Schannel) implements both the Secure Sockets Layer and Transport Layer Security Internet standard authentication protocols. Administrators can use TLS/SSL to authenticate servers and client computers. Administrators also have the ability to use the protocol to encrypt messages between the authenticated parties (client and server). The Transport Layer Security protocol, Secure Sockets Layer protocol, Datagram Transport Layer Security (DTLS), and Private Communications Transport (PCT) protocol are all based on the public key cryptography. The Security Channel authentication protocol suite provides these protocols, and this protocol is based on the client-server model. NTLMv2 NTLMv2 (Windows NT LAN Manager) helps the authentication process for Windows NT 4 systems or earlier, and it allows for transactions between any two computers running these older systems. Networks that use NTLMv2 are referred to as mixed mode. Kerberos The Kerberos authentication protocol is used to perform Active Directory domain authentication. By default, all computers joined to a Windows Server 2012 R2 domain use the Kerberos authentication protocol. Kerberos allows for single sign-on to network resources on a domain or on a trusted domain. Administrators have the ability to control certain parameters through the Kerberos security settings of the account policies. 802.1X The IEEE has a standard for wireless authentication called 802.1X. 802.1X allows wireless networks to authenticate onto wired Ethernet networks or wireless 802.11 networks. The IEEE 802.1X standard uses EAP for exchanging messages during the authentication process.
Connection Security You can use some additional features to provide connection-level security for your remote access clients: ■ The Callback Control Protocol (CBCP) allows your RRAS servers or clients to negotiate a callback with the other end. When CBCP is enabled, either the client or the
server can ask the server at the other end to call the client back at a number supplied by the client or a prearranged number stored on the server. ■ You can program the RRAS server to accept or reject calls based on the caller ID or automatic number identification (ANI) information transmitted by the phone company. For example, you can instruct your primary RRAS server to accept calls from only your home analog line. This means you can’t call the server when you’re on the road, and it also keeps the server from talking to strangers. ■ You can specify various types and levels of encryption to protect your connection from interception or tampering.
The limits of Caller Id
It’s risky to rely on ANI information for any type of authentication or caller verification. First, caller ID information can be forged. Therefore, if an attacker knows the telephone numbers from which your network accepted calls, they could make their ANI report as one of those numbers and be authenticated onto the network.
Another problem with relying on ANI for authentication is that not all telephone compa- nies pass ANI information with the call. Therefore, if your users are in remote locations (which is why they’d be dialing in anyway), they might not be able to authenticate. Even when ANI information is sent, some telephone companies pass different pieces of the information, which can also result in authentication failures.
Finally, not all incoming line types support ANI. If your site uses a network access server or modem bank that doesn’t receive this information based on the type of T1 connection used for incoming calls, the ANI information might not be there at all.
Access Control Apart from the connection-level measures that you can use to prohibit outside callers from talking to your servers, you can restrict which users can make remote connections in a number of ways: ■ You can allow or disallow remote access from individual user accounts. This is the same limited control you have in Windows NT, but it’s just the start for Windows Server 2012 R2. ■ You can use network access policies to control whether users can get access. Like group policies, network access policies give you an easy way to apply a consistent set of policies to groups of users. However, the policy mechanism is a little different: You create rules that include or exclude the users whom you want in the policy.
Unlike group policies, network access policies are available only in Windows 2000 native, Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2 domain functional level (that is, in domains in which there are no Windows NT domain controllers present). This means you may not have the option to use network access policies until your Windows 2000, Windows Server 2003, Windows Server 2008/2008 R2, and Windows Server 2012 R2 deployment is further along. In the next sections, you will learn how to configure user access control.
Configuring User Access
Now it’s time to determine who can actually use the remote access services. You do this in two ways: ■ By setting up remote access profiles on individual accounts ■ By creating and managing network access policies that apply to groups of users This distinction is subtle but important because you manage and apply profiles and policies in different places.
Setting Up User Profiles Windows Server 2012 R2 stores a lot of information for each user account. Collectively, this information is known as the account’s profile, and it’s normally stored in Active Directory. Some settings in the user’s profile are available through one of the two user- management snap-ins: ■ If your RRAS server is part of an Active Directory domain, the user profile settings are in the Active Directory Users and Computers snap-in. ■ If your RRAS server is not part of an Active Directory domain, the user profile settings are in the Local Users and Groups snap-in. In either case, the interesting part of the profile is the Dial-In tab of the user’s Properties dialog box (see Figure 5.1). This tab has a number of controls that regulate how the user account can be used for dial-in access. These controls include the following: Network Access Permission Control Group The first, and probably most familiar, controls on this tab are in the Network Access Permission control group. These options control whether the user has dial-in permission. Windows Server 2012 R2 has a feature that, in addition to explicitly allowing or denying access, lets you control access through Network Access Protection. Verify Caller-ID Check Box RRAS can verify a user’s caller ID information and use the results to allow or deny access. When you check the Verify Caller-ID check box and enter
a phone number in the field, you’re telling RRAS to reject a call from anyone who provides that username and password but whose caller ID information doesn’t match what you enter. This means the user can call in only from a single phone number. Callback Options Control Group The Callback Options control group gives you three choices for regulating callback: No Callback This is the default setting. It means that the server will never honor call- back requests from this account. Set By Caller This setting allows the calling system to specify a number at which it wants to be called back. The RRAS server will call the client back at that number. Always Callback To This setting allows you to enter a number that the server will call back no matter from where the client is actually calling. This option is less flexible but more secure than the Set By Caller option. Assign Static IP Addresses Check Box If you want this user always to get the same static IP address, you can arrange to do so by selecting the Assign Static IP Addresses check box and then entering the desired IP address. This allows you to set up nondynamic DNS records for individual users, guaranteeing that their machines will always have a valid DNS entry. On the other hand, this can be more prone to typographical errors on setup than the dynamic DNS-DHCP combination you could use instead. Apply Static Routes Check Box In an ordinary LAN, you don’t have to do anything special to clients to enable them to route packets—just configure them with a default gateway, and the gateway handles the rest. For dial-up connections, though, you may want
to define a list of static routes that will enable the remote client to reach hosts on your network, or elsewhere, without requiring that packets be sent to a gateway in between. Depending on the remote access server, though, the client may be able to use Address Resolution Protocol (ARP) for local devices too. If you want to define a set of static routes on the client, you’ll have to do it manually. If you want to assign static routes on the server, select the Apply Static Routes check box and then use the Static Routes button to add and remove routes as necessary.
Remember that these settings apply to individual users, so you can assign different routes, caller ID, or callback settings to each user.
Using Network Access Policies Windows Server 2012 R2 includes support for additional configuration systems: ■ Network access policies (which used to be called remote access policy). ■ Remote access profiles. ■ Network Policy Server (NPS) is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy in Windows Server 2012. NPS is the replacement for Internet Authentication Service (IAS) in Windows Server 2003. Policies determine who can and cannot connect; you define rules with conditions that the system evaluates to see whether a particular user can connect. You can have any number of policies in a native Windows Server 2012 R2 domain; each policy must have exactly one profile associated with it.
Settings in an individual user’s profile override settings in a network access policy.
You manage network access policies through the Remote Access Logging & Policies folder in the RRAS snap-in. Policies contain conditions that you pick from a list. When a caller connects, the policy’s conditions are evaluated, one by one, to see whether the caller gets in. All of the conditions in the policy must match for the user to gain access. If there are multiple policies, they’re evaluated according to an order you specify. In the following sections, you will see how to create and configure network access policies.
Network Policy Attributes To create a policy, right-click the Remote Access Logging & Policies folder and select Launch NPS (see Figure 5.2). Then right-click Network Policies and choose New.
This command starts the New Network Policy Wizard, which uses a series of steps to help you define the policy. The Select Condition dialog box (see Figure 5.3) is part of the New Network Policy Wizard. It lists the attributes you can evaluate in a policy. Table 5.1 describes the attributes that you can set. These attributes are drawn from the RADIUS standards, so you can (and in some cases, should) intermix your Windows Server 2012 R2 RRAS servers with RADIUS servers.
When setting up any policies, you must base your policy on company rules and standards. Remember, policies can allow or restrict users from remotely accessing your network. The needs of the organization determine the policy and when to use it.
Once you choose an attribute and click the Add button, its corresponding editor appears. You use the editor to set the value of the attribute. For example, if you select the Day And Time Restrictions attribute, you’ll see the Time Of Day Constraints dialog box, which offers a calendar grid that lets you select which days and times are available for logging on.
Table 5.1 Network access policy attributes
Attribute name What it specifies
Authentication Type Specifies the authentication methods required to match this policy.
Allowed EAP Types Specifies the EAP types required for the client computer authentication method configuration to match this policy.
Called Station Id Specifies the phone number of the remote access port called by the caller.
Calling Station Id Specifies the caller’s phone number.
Client Friendly Name Specifies the name of the RADIUS server that’s attempting to validate the connection.
Client IP Address (IPv4 and IPv6)
Specifies the IP address of the RADIUS server that’s attempting to validate the connection.
Client Vendor Specifies the vendor of the remote access server that originally accepted the connection. This is used to set different policies for different hardware.
Day And Time Restrictions Specifies the weekdays and times when connection attempts are accepted or rejected.
Framed Protocol Specifies the protocol to be used for framing incoming packets (for example, PPP, SLIP, and so on)
HCAP (Host Credential Authorization Protocol) User Groups
Used for communications between NPS and some third- party network access servers (NASs).
Location Groups Specifies the HCAP location groups required to match this policy. This is used for communications between HCAP and some third-party network access servers (NASs).
MS RAS Vendor Specifies the vendor identification number of the network access server (NAS) that is requesting authentication.
NAS Identifier Specifies the friendly name of the remote access server that originally accepted the connection.
NAS IP Address (IPv4 and IPv6) Specifies the IP address of the remote access server that originally accepted the connection.
NAS Port Type Specifies the physical connection (for example, ISDN, POTS) used by the caller.
Service Type Specifies Framed or Async (for PPP) or login (Telnet).
Tunnel Type Specifies which tunneling protocol should be used (L2TP or PPTP).
Windows Groups Specifies which Windows groups are allowed access.
After you select an attribute and give it a value, you can add more attributes or move to the next page by clicking the Next button on the Select Condition page. Once you’re finished setting attributes, you arrive at the Specify Access Permission page of the wizard. This page has only two radio buttons: Grant Remote Access Permissions and Deny Remote Access Permissions. These buttons specify whether the policy you create allows users to connect or prevents users from connecting. The page also includes an Access Is Determined By User Dial-In Properties check box. If this box is checked and there is a conflict between the network policy and user dial-in properties, the user dial-in properties take precedence.
Creating a Network Access Policy In Exercise 5.1, you’ll create an adjunct policy that adds time and day restrictions to the default policy. (An adjunct policy is one used in conjunction with another policy.) This exercise requires that you have completed the previous exercises in this chapter Creating a Network access Policy 1. Open the RRAS MMC snap-in by pressing the Windows key and selecting Administrative Tools ➢ Routing And Remote Access. 2. Expand the server you want to configure in the left pane of the MMC. 3. Right-click the Remote Access Logging And Policies folder. 4. Right-click and then select Launch NPS. 5. Once the Network Policy Server page appears, right-click Network Policies and then choose New.
On the Specify Conditions page, click the Add button. 8. In the Select Condition dialog box, scroll down and click Day And Time Restrictions. Click Add.
The Configure Constraints page appears. Under Constraints, click Session Timeout. On the right side, click the Disconnect After The Following Maximum Session Time box, and type 60 in the field (the value represents minutes). Click Next.
- The Configure Settings page appears. This page allows you to configure any additional settings for this network policy. Click Next. 15. On the Completing New Network Policy page, click Finish.
NPS as a RADIUS Proxy Server When a user tries to log into a domain through the use of a RADIUS server, the RADIUS server processes the connection request and helps the user log into the network. RADIUS proxy servers work in a different way. When a connection request comes into a RADIUS proxy server, the RADIUS proxy server forwards the request to another RADIUS server for authentication onto the network. Servers that are running Network Policy Server can act both as a RADIUS server and as a RADIUS proxy. When an administrator sets up NPS as a RADIUS server, NPS provides some of the following actions to help the RADIUS server work properly: ■ RADIUS clients send an access request to the central authentication and authorization service. NPS uses Active Directory to authenticate the user’s credentials. NPS accesses the Active Directories user’s dial-in properties and policies to authorize the connection. ■ When using NPS, the RADIUS server also records all accounting information on how much the RADIUS server is used. This is helpful when you have to bill other
departments for the RADIUS use. Many organizations require that each department pay for its RADIUS use for its users, and using NPS allows an administrator to do this. When you set up NPS as a RADIUS proxy, NPS provides all of the routing between all of the RADIUS servers and RADIUS clients. NPS is the main switching and routing service when you use RADIUS as a proxy server.
NPS Configuration Now that you know that NPS can be set up as a RADIUS server, let’s take a look at some of those details of how to do it. When an administrator sets up NPS as a RADIUS proxy, network access servers are then configured as the RADIUS clients. The RADIUS proxy server receives requests from the RADIUS clients, and then the RADIUS server forwards those requests to the appropriate servers. Using NPS to set up a RADIUS proxy should be done when the following conditions are needed: ■ If you are the administrator of an organization that offers VPN or wireless network access to multiple clients, the RADIUS server can authenticate and authorize the user through their authentication server. ■ If you are an administrator of a domain and you want users who are not members of your domain to authenticate into your domain, you can use an NPS server with a RADIUS proxy. To make this situation work, you must set up a two-way trust (two one-way trusts in opposite directions). ■ Another great example of when to set up a RADIUS proxy server is when you are using a non-Microsoft-based database. RADIUS servers have the ability to communicate with different types of databases, allowing users still to be authenticated even when it’s not a Microsoft authentication database; an example is a Novell Directory Services (NDS) database. Another configuration that you may need to set when configuring NPS and RADIUS is the priority. The higher the RADIUS priority number, the less that the RADIUS server gets used. For example, if I have two RADIUS servers named Server1 and Server2 and I want Server2 used only when Server1 is unavailable, I would set the RADIUS priority from 1 to 10. This way it will get used only when Server1 is having issues or is unresponsive.
RADIUS Clients Network access servers that are RADIUS RFC compliant (2865 and 2866) are considered RADIUS clients when used with NPS and a RADIUS server or proxy. NPS allows an administrator to enable the use of wireless, switches, remote access, or VPN equipment as long as they are heterogeneous or homogenous sets. Network administrators can allow authentication and authorization through the use of NPS network connection requests as long as administrators deploy the following types of network access servers and technologies: ■ Wired access with 802.1X-secured and RADIUS-compliant authenticating switches ■ Wireless access with 802.1X-secured and RADIUS-compliant wireless access points
NPS Templates Templates can be a valuable tool when used properly. Templates allow you to create something once and then use that template to create the same thing over and over again. You can use templates when creating Active Directory users, when setting up GPOs, and now even when setting up NPS. NPS templates allow an administrator to save time and thus also save the cost required to manage and configure NPS on multiple servers. Multiple NPS templates are available in the Templates Management MMC for an administrator to configure: ■ Shared Secrets ■ RADIUS Clients ■ Remote RADIUS Servers ■ IP Filters ■ Health Policies ■ Remediation Server Groups One advantage of creating a template is that once the template is created, there is no interference with the actual NPS server’s performance. Creating templates does not affect an operational NPS server in any way. Once you load the template to the appropriate location, the template becomes active.
Creating Templates To create a template in the Template Management MMC, right-click the template type you want to create (such as Health Policies) and click New. The New Template dialog box appears, and you just fill in all of your configuration information.
Importing and Exporting NPS Policies Importing/exporting NPS is a pretty easy thing. It just happens to depend on which version of Windows you are exporting from. In the following examples, I will explain how to export from Windows Server 2008 R2 using the Windows MMC and how to import into Windows Server 2012 R2.
Exporting from Windows Server 2008 R2 To export NPS from Windows Server 2008 R2, follow these steps: 1. On the source server, open Server Manager. 2. In the Server Manager console tree, open Roles\Network Policy and Access Services\ NPS. 3. Right-click NPS and then click Export Configuration. 4. In the dialog box that appears, select the check box I Am Aware That I Am Exporting All Shared Secrets and then click OK.
- For File Name, type file.xml, navigate to the migration store file location, and then click Save. 6. In the console tree, right-click Templates Management and then click Export Templates To A File. 7. For File Name, type iastemplates.xml, navigate to the migration store file location, and then click Save. 8. If you have configured SQL logging, you must manually record detailed SQL configuration settings. To record these settings, follow these steps: a. In the NPS console tree, click Accounting and then click Change SQL Server Logging Properties. b. Record the configuration settings on the Settings tab and then click Configure. c. Manually record all configuration settings from the Connection and Advanced tabs by copying them into the sql.txt file. Alternatively, you can click the All tab and enter Name and Value settings displayed on each line into the sql.txt file. 9. Copy the file.xml, iastemplates.xml, and sql.txt files to the migration store file location. This information will be required to configure the destination server.
Importing to Windows Server 2012 R2 To import NPS from Windows Server 2012 R2, follow these steps 1. Copy the configuration files file.xml, iastemplates.xml, and sql.txt that were exported to the migration store file location to the destination NPS server. Alternatively, you can import configuration settings directly from the migration store file location by supplying the appropriate path to the file in the import command. If you have custom settings that were recorded using the NPS Server Migration: Appendix A—Data Collection Worksheet, they must be configured manually on the destination server. 2. On the destination server, open Server Manager. 3. In the Server Manager console tree, click All Servers; then, from the list of servers in the right pane, right-click the relevant server and select Network Policy Server. 4. To import template configuration settings, complete the remaining steps in this list. If you do not have template settings, skip to step 7. 5. In the console tree, right-click Templates Management and then click Import Templates from a file. 6. Select the template configuration file iastemplates.xml that you copied from the source server and then click Open. 7. In the console tree, right-click NPS and then click Import Configuration
- Select the configuration file file.xml or ias.txt that you copied from the source server and then click Open. 9. Verify that a message appears indicating the import was successful. 10. Configure SQL accounting if required using the sql.txt file and the data collection worksheet. To configure SQL accounting, complete the remaining steps in this list. 11. In the NPS console tree, click Accounting and then click Change SQL Server Logging Properties in the details pane. 12. Modify the properties on the Settings tab if required and then click Configure to enter detailed settings. 13. Using information recorded in the sql.txt file, enter the required settings on the Connection and Advanced tabs and then click OK.
Using Remote Access Profiles Remote access profiles are an integral part of network access policies. Profiles determine what happens during call setup and completion. Each policy has a profile associated with it; the profile determines what settings will be applied to connections that meet the conditions stated in the policy. For security reasons, it’s usually a good idea to limit access to the administrative accounts on your network. In particular, as a consultant, I usually tell clients to restrict remote access for the administrator account; that way, the potential exposure from a dial-up compromise is reduced. In Exercise 5.2, you will learn how to configure the administrator account’s user profile to restrict dial-up access.
exerCISe 5.2 restricting a user Profile for dial-In access 1. Log on to your computer using an account that has administrative privileges. 2. If you’re using an RRAS server that’s part of an Active Directory domain, open the Active Directory Users and Computers snap-in by pressing the Windows key and select- ing Administrative Tools ➢ Active Directory Users And Computers. If not, open the Local Users and Groups snap-in by pressing the Windows key and selecting Administra- tive Tools ➢ Computer Management ➢ Local Users And Groups. 3. Expand the tree to the Users folder. Right-click the Administrator account in the right pane and choose Properties. The Administrator Properties dialog box appears. 4. Switch to the Dial-In tab. On machines that participate in Active Directory, make sure the Control Access Through NPS Network Policy option (in the Permissions group) is selected.
- Click the Deny Access radio button to prevent the use of this account over a dial-in con- nection. 6. Click the OK button.
You can create one profile for each policy. The profile contains settings that fit into specific areas. Each area has its own link in the profile’s Properties dialog box.
The Constraints Tab The Constraints tab has most of the settings that you think of when you consider dial-in access controls. The controls here allow you to adjust how long the connection can be idle before it gets dropped, how long it can be up, the dates and times for establishing the connection, and what dial-in port and medium can be used to connect.
Authentication Link In the Authentication Methods pane (see Figure 5.4), you can specify which authentication methods are allowed on this specific policy. Note that these settings, like the other policy settings, will be useful only if the server’s settings match. For example, if you turn EAP authentication off in the server’s Properties dialog box, turning it on in the Authentication Methods pane of the profile’s Properties dialog box will have no effect.
You’ll notice that each authentication method has a check box. Check the appropriate boxes to control the protocols that you want this profile to use. If you enable EAP, you can also choose which specific EAP type you want the profile to support. You can also choose to allow totally unauthenticated access (which is unchecked by default).
Settings Tab The Settings tab of the policy’s Properties dialog box has several useful sections, which are described in the following list: IP Settings Pane The IP Settings pane (see Figure 5.5) gives you control over the IP-related settings associated with an incoming call. If you think back to the server-specific settings covered earlier, you’ll remember that the server preferences include settings for protocols other than IP; this is not so in the network access profile. In this pane, you can specify where the client gets its IP address.
fIgure 5.5 IP Settings pane of the Settings tab
Multilink And Bandwidth Allocation Protocol (BAP) Pane The profile mechanism gives you a degree of control over how the server handles multilink calls. You exert this control
through the Multilink And Bandwidth Allocation Protocol (BAP) pane of the profile Properties dialog box. Your first choice is to decide whether to allow multilink calls at all and, if so, how many ports you want to let a single client use at once. Normally, this setting is configured so that the server-specific settings take precedence, but you can override them. Bandwidth Allocation Protocol Group The Bandwidth Allocation Protocol control group gives you a way to control what happens during a multilink call when the bandwidth usage drops below a certain threshold. For example, why tie up three analog lines to provide 168Kbps of bandwidth when the connection is using only 56Kbps? You can tweak the capacity and time thresholds. By default, a multilink call will drop one line every time the bandwidth usage falls to less than 50 percent of the available bandwidth and stays there for two minutes. The Require BAP For Dynamic Multilink Requests check box allows you to refuse calls from clients that don’t support BAP. This is an easy way to make sure that no client can hog your multilink bandwidth. Encryption Pane The Encryption pane of the Settings tab (see Figure 5.6) controls which type of encryption you want your remote users to be able to access.
fIgure 5.6 Encryption pane of the Settings tab of the policy’s Properties dialog box
The following radio buttons are on the Encryption pane: ■ Basic Encryption (MPPE 40-Bit) means single Data Encryption Standard (DES) for IPsec or 40-bit Microsoft Point-to-Point Encryption (MPPE) for Point-to-Point Tunneling Protocol (PPTP). ■ Strong Encryption (MPPE 56-Bit) means 56-bit encryption (single DES for IPsec; 56-bit MPPE for PPTP). ■ Strongest Encryption (MPPE 128-Bit) means triple DES for IPsec or 128-bit MPPE for PPTP connections. ■ No Encryption allows users to connect using no encryption at all. Unless this but- ton is selected, a remote connection must be encrypted, or it’ll be rejected. In Exercise 5.3, you’ll force all connections to your server to use encryption. Any client that can’t use encryption will be dropped. You must complete Exercise 5.1 before you do this exercise.
Don’t do this exercise on your production RRAS server unless you’re sure that all of your clients are encryption-capable.
exerCISe 5.3 Configuring encryption 1. Open the RRAS MMC snap-in by pressing the Windows key and selecting Administra- tive Tools ➢ Routing And Remote Access. 2. Expand the server you want to configure in the left pane of the MMC. 3. Right-click the Remote Access Logging & Policies folder. 4. Select Launch NPS. 5. Once the Network Policy Server page appears, click the hours policy you created in Exercise 5.3. (I named mine Test Policy.) 6. Select Action ➢ Properties. The policy’s Properties dialog box appears. 7. Click the Settings tab. Select Encryption in the left pane. 8. In the right pane, uncheck the No Encryption check box. Make sure that the Basic, Strong, and Strongest check boxes are all selected. 9. Click the OK button. When the policy Properties dialog box reappears, click the OK button.
Setting Up a VPN Network Access Policy Earlier in this chapter, you learned how to use the Network Access Policy mechanism on a Windows Server 2012 R2 domain. Now it’s time to apply what you’ve learned to a virtual private network (VPN). Recall that you have two ways to control which specific users can access a remote access server: ■ You can grant and deny dial-up permission to individual users in each user’s Properties dialog box. ■ You can create a network access policy that embodies whatever restrictions you want to impose. It turns out that you can do the same thing for VPN connections, but there are a few additional things to consider.
Granting and Denying Per-User Access To grant or deny VPN access to individual users, all you have to do is make the appropriate change on the Dial-In tab of each user’s Properties dialog box. Although this is the easiest method to understand, it gets tedious quickly if you need to change VPN permissions for more than a few users. Furthermore, this method offers you no way to distinguish between dial-in and VPN permissions.
Creating a Network Access Policy for VPNs You may find it helpful to create network access policies that enforce the permissions that you want end users to have. You can accomplish this result in a number of ways; which one you use will depend on your overall use of network access policies. The simplest way is to create a policy that allows all of your users to use a VPN. Earlier in this chapter, you learned how to create network access policies and specify settings for them; one thing you may have noticed was that there’s a NAS-Port-Type attribute that you can use in the policy’s conditions. That attribute is the cornerstone of building a policy that allows or denies remote access via VPN because you use it to accept or reject connections arriving over a particular type of VPN connection. For best results, you’ll use the Tunnel-Type attribute in conjunction with the NAS-Port-Type attribute, as described in Exercise 5.4.
Creating a vPN Network access Policy 1. Open the RRAS MMC snap-in by pressing the Windows key and selecting Administra- tive Tools ➢ Routing And Remote Access. 2. Expand the server you want to configure in the left pane of the MMC. 3. Right-click the Remote Access Logging & Policies folder. 4. Select Launch NPS.
exerCISe 5.4 (continued)
- Once the Network Policy Server page appears, right-click Network Policies and choose New. 6. The New Network Policy Wizard starts. In the Policy Name box, enter VPN Network Policy and click Next (leave the other settings as they are). 7. On the Specify Conditions page, click the Add button. 8. On the Select Condition page, scroll down, click NAS-Port-Type Attribute, and click Add. When the NAS Port Type page appears, click Virtual VPN in the Common Dial-Up And VPN Tunnel Types box. Click OK and then click the Next button. 9. The Specify Conditions page reappears, this time with the new condition listed. Click the Next button. 10. The Specify Access Permission page appears. Select the Access Granted radio button and click Next to continue. 11. Next the Configure Authentication Methods page will appear. This page is where you choose which authentication methods will be used for this connection. Make sure that MS-CHAP and MS-CHAPv2 are both checked along with their associated check boxes. Click Next. 12. The Configure Constraints page appears. Under Constraints, click Session Timeout. On the right side, click the Disconnect After The Following Maximum Session Time box and type 60 in the box (the value specifies minutes). Click Next. 13. The Configure Settings page appears. This page allows you to configure any additional settings for this network policy. Click Next. 14. At the Completing New Network Policy page, click Finish.
If you don’t want to grant VPN access to everyone, you can make some changes to the process in Exercise 5.6 to fine-tune it. First you’ll probably want to move the VPN policy to the top of the list. (When you first add the policy described in the exercise, it is placed at the end of the policy list. Unless you move it, the default policies will take effect before the VPN-specific policy does.) Next you can create an Active Directory group and put your VPN users in it. You can then create a policy using the two conditions outlined in Exercise 5.6 plus a condition that uses the Windows-Groups attribute to specify the new group. You can also use this process to allow everyone dial-up access and reserve VPN capability for a smaller group.
Connection Manager To help administrators create and manage remote access connections, Microsoft includes a suite of components called Connection Manager within Windows Server 2012 R2. Connection Manager is not installed by default. You can install the Connection Manager using Server Manager ➢ Add Roles ➢ Network Access Services.
Connection Manager allows an administrator to create remote access connections called service profiles. These profiles then appear on client machines as network connections. You can use these network connections to connect client machines to VPNs or remote networks.
When configuring remote access security, you must consider several aspects, the most fundamental of which involves configuring the types of authentication and encryption that the server will use when accepting client requests. You will look at each of these in the following sections.
Controlling Server Security The Security tab of the server’s Properties dialog box (see Figure 5.7) allows you to specify which authentication and accounting methods RRAS uses. You can choose one of two authentication providers by using the Authentication Provider drop-down list.
fIgure 5.7 The Security tab of the RRAS server’s Properties dialog box
Your choices include the following: Windows Authentication This is a built-in authentication suite included with Windows Server 2012 R2. RADIUS Authentication This authentication allows you to send all authentication requests heard by your server to a RADIUS server for approval or denial. You can also use the Accounting Provider drop-down list on the Security tab to choose between the following: Microsoft-Developed Accounting With this type of accounting, connection requests are maintained in the event log. RADIUS Accounting In this type of accounting, all accounting events, such as call start and call stop, are sent to a RADIUS server for action.
RADIUS Authentication Settings When you select the RADIUS Authentication option from the Authentication Provider drop-down menu, you are enabling a RADIUS client that passes authentication duties to a RADIUS server. This communication is sent via UDP on port 1645 or 1812, depending on the version of RADIUS being used. Click the Configure button to open the RADIUS Authentication dialog box. From here, you can set the following options: ■ Click the Add button to add the name or address of a RADIUS server to which the RAS server will pass authentication duties. ■ You must also enter the correct secret, which is initially set by the RADIUS server. ■ The Time-Out option determines how long the RRAS server will attempt to authenticate the remote user before giving up. ■ The Initial Score option is similar to the cost value used by routers. The RAS server will attempt to authenticate users on the RADIUS server with the highest score first. If that attempt fails, the RAS server will use the RADIUS server with the next highest score, and so on. ■ Although the Port option can be changed, the default setting is part of RFC 2866, “RADIUS Accounting,” and it should not be altered unless extraordinary circumstances call for it.
The Internet Assigned Numbers Authority (IANA) is the official source for port number assignment. You can view current port number assign- ments and other valuable information at www.iana.org/assignments/ port-numbers.
Windows Authentication Settings Select the Windows Authentication option from the Authentication Provider drop- down menu if you want the local machine to authenticate your remote access users. To configure the server by telling it which authentication methods you want it to use, click the Authentication Methods button, which displays the Authentication Methods dialog box. If you look at the list of authentication protocols earlier in the chapter, you’ll find that each one has a corresponding check box here: EAP, MS-CHAPv2, CHAP, and PAP. You can also turn on unauthenticated access by checking the Allow Remote Systems To Connect Without Authentication box, but that is not recommended because it allows anyone to connect to, and use, your server (and thus by extension your network). There’s actually a special set of requirements for using CHAP because it requires access to each user’s encrypted password. Windows Server 2012 R2 normally doesn’t store user passwords in a format that CHAP can use, so you have to take some additional steps if you want to use CHAP: 1. Enable CHAP at the server and policy levels. 2. Edit the default domain GPO’s Password Policy object to turn on the Store Password Using Reversible Encryption policy setting. 3. Change or reset each user’s password, which forces Windows Server 2012 R2 to store the password using reversible encryption. After these steps are completed for an account, that account can be used with CHAP.
These steps aren’t required for MS-CHAPv2; for that protocol, you just enable MS-CHAPv2 at the server and policy levels.
Configuring Network Access Protection Another way that you can have security is to allow users to access resources based on the identity of the client computer. This new security solution is called Network Access Protection. Determined by the client needs, network administrators now have the ability to define granular levels of network access using NAP. NAP also allows administrators to determine client access based on compliancy with corporate governance policies. The following are some of the NAP features: Network Layer Protection Network layer protection is the ability to secure communications at the Network layer of the OSI model. All communications travel through the seven layers of the OSI model. Starting at the top (layer 7), the seven layers are the Application, Presentation, Session, Transport, Network, Data-Link, and Physical layers.DHCP Enforcement If a computer wants to receive unlimited IPv4 network access, the computer must be compliant with corporate governance policies. DHCP enforcement verifies that a computer is compliant before granting unlimited access. If a computer is noncompliant, the computer receives an IPv4 address that has limited network access and a default user profile. One advantage of using DHCP is that you can set up user classes so that specific machines (for example, noncompliant DHCP systems) can get specific rules or limited access to the network. When a client computer attempts to receive an IP address from DHCP, the DHCP enforcement checks the health policy requirements of the system to make sure they meet the compliancy. VPN Enforcement VPN enforcement works a lot like DHCP enforcement, except that VPN enforcement verifies the compliancy of the system before the VPN connection is given full access to the network. IPsec Enforcement IPsec enforcement will allow a computer to communicate with other computers as long as the computers are IPsec compliant. You have the ability to configure the requirements for secure communications between the two compliant computer systems. You can configure the IPsec communications based on IP address or TCP/UDP port numbers. 802.1X Enforcement For a computer system to have 802.1X unlimited access to network connections (Ethernet 802.11 or wireless access point), the computer system must be 802.1X compliant. 802.1X enforcement verifies that the connecting system is 802.1X connection compliant. Noncompliant computers will obtain only limited access to network connections. Flexible Host Isolation Flexible host isolation allows a server and domain to isolate computers to help make it possible to design a layer of security between computers or networks. Even if a hacker gains access to your network using an authorized username and password, the server and domain isolation can stop the attack because the computer is not an authorized domain computer. Multiconfiguration System Health Validator This feature allows you to specify multiple configurations of a system health validator (SHV). When an administrator configures a network policy for health evaluation, the administrator will select a specific health policy. Using this feature allows you to specify different network policies for different sets of health requirements based on a specific configuration of the SHV. For example, an administrator can create a network policy that specifies that all internal computers must have antivirus software enabled and a different network policy that specifies that VPN-connected computers must have their antivirus software enabled and signature files up-to-date.
NAP Monitoring There may be many times when you will need to monitor how NAP is running and what NAP policies are being enforced. There are multiple ways that you can monitor NAP. You can use the Network Access Protection MMC snap-in to look at how things are running. But there is another tool that you can use called Logman. Logman creates and manages Event Trace Session and Performance logs and allows an administrator to monitor many different applications through the use of the command line. Table 5.2 shows some of the different Logman switches you can use.
Table 5.2 Logman switches
Logman create Creates a counter, trace, configuration data collector, or API
Logman query Queries data collector properties
Logman start | stop Starts or stops data collection
Logman delete Deletes an existing data collector
Logman update Updates the properties of an existing data collector
Logman import | export Imports a data collector set from an XML file or exports a data collector set to an XML file
In this chapter, I talked about the different ways that you can secure your remote access connections. You learned how to configure appropriate security settings so that communication between the client and server is secure because of NAP and NPS settings. I talked about how to verify that client machines meet the minimum requirements in order to gain either full or limited access to your network. I also discussed wireless networking and what types of security encryption you can use to help support your wireless network. You learned about the different components of wireless access and using group policies to configure wireless clients.
Published @ September 27, 2021 7:32 am