Choosing Security Features | Microsoft Corporation Microsoft Windows Server 2003 Deployment Kit(c) Deploying Network Services 2003

As described in "Choosing the Remote Site Connection Type" earlier in this chapter, security is one of the factors that you weigh when you choose a connection type. For all connection types, securing site-to-site communications requires making decisions about several additional security features. The flowchart in Figure 10.6 shows the tasks required when choosing these additional security features.

click to expand
Figure 10.6: Choosing Security Features

Integrate the VPN Server into a Perimeter Network

Windows Server 2003 supports VPN functionality without the use of a firewall. However, many organizations use firewalls to implement a perimeter network (also known as a DMZ, demilitarized zone, and screened subnet) to increase security by protecting their internal network from intrusion through the Internet.

Only servers that provide resources to users over the Internet, such as Proxy, Web, and FTP servers, are located in the perimeter network. Traffic between dial-up routers does not cross the Internet. Therefore, you do not need to locate dial-up routers in a perimeter network. However, placing VPN routers in a perimeter network helps ensure that communications between sites are protected.

VPN Router Placement in Relation to Firewall

If your organization already uses a perimeter network, you can add your VPN router to the existing set of servers on the perimeter network. If not, consider adding a perimeter network to your infrastructure when you deploy a VPN site-to-site connection.

How you configure firewall filters and the filters on the VPN router depends on the position of the VPN router relative to the firewall. Although it is possible to place the VPN router in front of the firewall (with the VPN router attached to the Internet), the more common — and recommended — configuration for a site-to-site connection is to place the VPN router behind the firewall (attaching the firewall to the Internet). When you place the VPN router behind the firewall, you configure the firewall with input and output filters on the firewall's Internet and perimeter network interfaces to restrict traffic to the VPN server. These filters are configured the same for a site-to-site VPN server as for a remote access VPN server. For a description of these filters and how they function, see the instructions for configuring packet filters for a VPN server in "Deploying Dial-up and VPN Remote Access Servers" in this book.

For more information about VPN servers and firewalls, including configuration of PPTP and L2TP/IPSec packet filters both for VPN servers behind the firewall and for VPN servers in front of the firewall, see "VPN servers and firewall configuration" in Help and Support Center for Windows Server 2003.

Match IP Packet Filters to Demand-Dial Filters

At the same time that you plan where to place your VPN router in relation to a firewall and how to configure PPTP and L2TP/IPSec IP packet filters on the firewall, also plan how to configure demand-dial filters in conjunction with the IP packet filters configured on the demand-dial interfaces. Although IP packet filters and demand-dial filters serve different purposes, Microsoft recommends that you configure them together.

You use demand-dial filters, which are applied before a connection is made, to specify which types of traffic are allowed to create a connection in the first place. You use IP packet filters, which are applied after a connection is made, to specify what traffic is allowed into and out of an interface after a connection is established. To prevent the demand-dial connection for traffic that will be discarded by the IP packet filters, you need to match your demand-dial and IP packet filters.

For more information about configuring IP packet filters to match your demand-dial filters, see "Demand-dial routing design considerations" in Help and Support Center for Windows Server 2003.

Choosing the Authentication Provider

Site-to-site connections between remote offices require an authentication and accounting provider for:

Authentication of calling router credentials and authorization of the site-to-site connection.
Accounting services that record the creation and termination of each site-to-site connection.

When a connection is attempted, the answering router authenticates the credentials of the calling router by using one of two authentication providers: Windows or RADIUS. Your choice of authentication provider is determined by whether your solution involves a site-to-site only connection or a combined site-to-site and remote access connection:

For a site-to-site only connection, choose Windows. When you choose Windows as the authentication, authorization, and accounting provider, the same Windows authentication process that validates user credentials when a user logs on also validates the calling router.
For a combined site-to-site and remote access connection, choose either Windows or RADIUS. If the same answering router will support both a site-to-site connection and remote access users (such as home or mobile users), you can use either Windows or Remote Authentication Dial-in User Service (RADIUS) as your authentication provider. Servers running the Internet Authentication Service (IAS) component of Windows Server 2003 provide an Internet standards-compliant RADIUS server and proxy.

If you have more than one answering router or other types of access servers (such as wireless access servers), you can use a single RADIUS server to provide centralized authentication, authorization, and accounting for all answering routers and access servers instead of administering each answering router and access server separately. To simplify administration for a combined site-to-site and remote access connection, you can use IAS to store both site-to-site and remote access information.

In an Active Directory domain, it is recommended that you use the Windows Server 2003 version of IAS as your RADIUS server. The IAS RADIUS server is tightly integrated with Windows Server 2003, Active Directory, and the Routing and Remote Access service. When you use RADIUS authentication, you configure each of participating answering router as a RADIUS client. After you configure both the answering router and the IAS server, the answering router uses remote access policies stored on the IAS server instead of those on the answering router.

Although it is possible to use RADIUS as the authentication provider for a site-to-site only connection, you do not need RADIUS. Deploying an IAS server is unnecessary administrative overhead for a demand-dial connection that connects two sites but does not support remote access users.

The credentials that the calling router passes to the answering router for verification are those of a user account, either in Active Directory or on the local computer. Authorization is granted based on the dial-in properties that you specify in the user account and on remote access policies configured on the answering router (or on the RADIUS server). For more information, see "Choosing Router User Accounts and Groups" and "Choosing a Remote Access Policy Type" later in this chapter.

The authentication provider that you choose also functions as the authorization provider. However, the Routing and Remote Access service does not require that you use the same provider for authentication and authorization that you use for accounting. You can use Windows for authentication and RADIUS for accounting, or vice versa. However, if you have multiple answering routers that support remote access users, consider using RADIUS for integrated authentication, authorization, and accounting, and, if you use IAS, to manage remote access policies.

For more information about RADIUS authentication, see "Checklist: Configuring IAS for dial-up and VPN access" in Help and Support Center for Windows Server 2003. For more information about deploying IAS to perform centralized authentication, authorization, and accounting, see "Deploying IAS" in this book.

Choosing an Authentication Method

For site-to-site connections, you must implement user-level authentication, and, for greater security, you might decide to implement computer-level authentication as well:

User-level authentication — for all site-to-site connection types.
Computer-level authentication — for L2TP/IPSec connections only.

Choosing EAP-TLS or MS-CHAP v2 for User-Level Authentication

All site-to-site connection technologies require user-level authentication. The "user" to be authenticated is the calling router. To prevent a nonauthorized router from making a connection, the Routing and Remote Access service requires that the calling router requesting the connection be authenticated by the answering router.

The Routing and Remote Access service can use any of several PPP authentication methods to provide user-level authentication. For optimal security, choose one of the two strongest recommended PPP user authentication methods — EAP-TLS or MS-CHAP v2.

For more information about the other PPP authentication protocols (in addition to EAP-TLS and MS-CHAP v2) supported by Windows Server 2003, Windows 2000 Server, and Windows NT Server 4.0, see "Authentication methods" in Help and Support Center for Windows Server 2003.

Certificate-based EAP-TLS

EAP-TLS is a more secure protocol than MS-CHAP v2 for user-level authentication on a dial-up, PPTP VPN, or L2TP/IPSec VPN connection. EAP-TLS requires a certificate infrastructure, because it uses a user certificate for the calling router and a computer certificate for the authenticating server of the answering router. The identity of the authenticating server depends on the authentication provider:

If Windows provides authentication, as is the case for a site-to-site only connection, the computer certificate is installed on the answering router. The answering router must be joined to the Active Directory domain.
If RADIUS provides authentication, as might be the case if your answering router also supports remote access users, the computer certificate is installed on the RADIUS server. If the RADIUS server is an IAS server, it must be joined to the Active Directory domain. In this case, the answering router does not need to belong to the domain.

EAP-TLS is recommended for all connection types both because it is the strongest method for user authentication and because it provides mutual user authentication between calling and answering routers. The calling router submits a user certificate for authentication, and the answering router (or RADIUS server) submits a computer certificate for authentication. With EAP-TLS, the user account that the answering router uses to authenticate and authorize the calling router must be an Active Directory user account.

If you plan to use certificate-based EAP-TLS, you can use a third-party CA if the conditions in Table 10.5 are met.

Table 10.5: Requirements for Using a Third-Party CA
Certificates Installed on Authenticating Server (Answering Router or RADIUS Server)	Certificates Installed on Calling Router
Computer certificates must be installed in the Local Computer certificate store. Computer certificates must have a corresponding private key. The cryptographic service provider for the certificates must support secure channel (Schannel). (If not, the authenticating server cannot use the certificate and the certificate cannot be selected from the properties of the Smart Card or Other Certificate EAP type on the Authentication tab in the properties of a profile for a remote access policy.) Computer certificates must contain the Server Authentication certificate purpose (also known as an enhanced key usage [EKU]). An EKU is identified using an object identifier (also known as an OID). The object identifier 1.3.6.1.5.5.7.3.1 represents Server Authentication. Computer certificates must contain the fully qualified domain name (FQDN) of the computer account of the authenticating server computer in the Subject Alternative Name property. The root CA certificates of the CAs that issued the calling router user certificates must be installed in the Trusted Root Certification Authorities certificate store.	User certificates must have a corresponding private key. User certificates must contain the Client Authentication EKU (the 1.3.6.1.5.5.7.3.2 object identifier). User certificates must be installed in the Current User certificate store. User certificates must contain the universal principal name (UPN) of the user account in the Subject Alternative Name property. The root CA certificates of the CAs that issued the authenticating server computer certificates must be installed in the Trusted Root Certification Authorities store.

For examples of how to deploy EAP-TLS certificate-based user authentication for site-to-site connections, see "Deploying certificate-based authentication for demand-dial routing" in Help and Support Center for Windows Server 2003. For more information about certificate types and requirements, see "Certificate Services" in Help and Support Center for Windows Server 2003, and see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit.

Password-based MS-CHAP v2

Like EAP-TLS, MS-CHAP v2 also provides mutual authentication between the calling router and the answering router. MS-CHAP v2 is a password-based authentication method in which the answering router uses either an Active Directory user account or a local user account to authenticate the calling router. MS-CHAP v2 is the recommended method for user authentication if a certificate infrastructure is not available.

If you use a local user account for MS-CHAP v2 authentication, the demand-dial routers do not need to join the Active Directory domain. Be sure to use strong passwords with MS-CHAP v2. In an Active Directory domain, you can use Group Policy settings to enforce the use of strong passwords.

Advantages of EAP-TLS and MS-CHAP v2

Although several weaker PPP authentication protocols are also available for user authentication, EAP-TLS and MS-CHAP v2 are the preferred methods because both provide the following benefits:

Mutual authentication. With mutual authentication, the calling router is authenticated by the answering router, and the answering router is then authenticated by the calling router. This mutual authentication prevents an attacker from masquerading as the answering router, whereas other types of authentication verify only the identity of the calling router.
Encryption features. In addition, for a dial-up or PPTP connection, EAP-TLS and MS-CHAP v2 provide the following encryption features. (L2TP/IPSec generates its encryption keys using IPSec and therefore does not need EAP-TLS or MS-CHAP v2 for encryption keys.)
- Stronger initial encryption keys. MS-CHAP v2 uses both a unique session identifier and user credentials to generate encryption keys. EAP-TLS uses user certificates to verify user identity. (In contrast, MS-CHAP uses only the user name and password to create these keys, making it easier for attackers to determine the keys in use.)
- Different keys for sending and receiving data. The calling router and answering router use separate keys to encrypt data and to send data. Using different keys makes it more difficult for attackers to determine which key is used for encryption.
- MPPE for encryption. MPPE uses Rivest-Shamir-Adleman (RSA) RC4 stream ciphering with 40-bit, 56-bit, and 128-bit encryption keys. (RC4, developed by RSA Data Security, is a secret key cryptographic method that uses a variable-length key.) Encryption key strength is negotiated during connection establishment (as is authentication method). The client (calling router) and server (answering router) negotiate the strongest mutually allowable key size. If the answering router requires a larger key than that supported on the calling router, the answering router rejects the connection.

For more information about encryption for site-to-site connections, see "Choosing MPPE or IPSec Encryption" later in this chapter.

Choosing Computer Certificates or Preshared Keys for Computer-Level Authentication

The only site-to-site connection technology that provides computer-level authentication is an L2TP/IPSec VPN connection. Computer-level authentication occurs in one of two ways:

Computer certificates: the exchange of computer certificates by the calling and answering routers. Computer-level authentication requires that you deploy a public key infrastructure (PKI). Although computer certificate authentication requires more administrative overhead for initial setup than does the use of preshared keys, it is the recommended method because it provides stronger computer authentication than the preshared keys method. Windows Server 2003 supports the automatic enrollment of certificates, which makes certificate deployment and management easier than using preshared keys over the long term.
Preshared keys: the exchange of preshared keys during the establishment of the IPSec security association (SA). Support for preshared keys is new with Windows Server 2003, and it requires running Windows Server 2003 on both VPN routers. A preshared key is a text string that is configured on both the calling and the answering router. Because a preshared key is a weaker computer authentication method than certificate authentication, Microsoft recommends that you use preshared key authentication only during the time you are deploying a PKI to enable the use of certificates. Using preshared key authentication is not as secure as using computer certificates, but it requires less administrative overhead.

The IPSec Internet Key Exchange (IKE) protocol can use either certificate-based or preshared key authentication to negotiate security for the L2TP traffic.

For more information about creating a certificate infrastructure, see "Certificate Services" in Help and Support Center for Windows Server 2003, and see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit. For more information about key exchange, see "Internet Key Exchange" in Help and Support Center for Windows Server 2003.

Choosing MPPE or IPSec Encryption

For site-to-site connections, the connection type and the user authentication protocol that you choose to deploy determine the data encryption method. Table 10.6 shows the available options.

Table 10.6: Choosing a Data Encryption Method
Connection Type	Recommended User Authentication Protocol	Encryption Method
Dial-up connection	EAP-TLS or MS-CHAP v2	MPPE
PPTP connection	EAP-TLS or MS-CHAP v2	MPPE
L2TP connection	EAP-TLS or MS-CHAP v2	IPSec

Understanding the following features can help you decide how you want to manage encryption:

Link encryption versus end-to-end encryption. MPPE provides link encryption. Link encryption encrypts data as it passes between the calling and answering routers. In addition to providing computer-level authentication, IPSec provides end-to-end encryption for data that passes between the sending and receiving nodes.
Encryption method used if VPN connection type is Automatic. If you configure a VPN connection for an Automatic server type (the default), the connection first tries to use PPTP and its associated MPPE encryption, and then it tries to use L2TP and its associated IPSec encryption. If you configure the VPN connection to connect to a PPTP server, only MPPE encryption is used. If you configure the VPN connection to connect to an L2TP server, only IPSec encryption is used.
No encryption needed for link to ISP. For VPN connections, you do not need to use encryption for the link between your site and the ISP, because no data is transmitted during the process that establishes this connection. After the connection to the ISP is made, the data that passes between the calling and answering routers is encrypted as it passes through the VPN tunnel.

You configure MPPE and IPSec encryption strengths on the Encryption tab for the properties of a remote access policy. For information about how to configure encryption in a remote access policy for a site-to-site connection, see "Configure a Remote Access Policy" later in this chapter. For general information about configuring encryption, see "Add a remote access policy" and "Remote access policy examples" in Help and Support Center for Windows Server 2003.

Configure either MPPE or IPSec to use one of the encryption keys as shown in Table 10.7.

Table 10.7: Encryption Strength by Connection Type
Encryption Strength	Dial-up or PPTP	L2TP/IPSec
Basic	40-bit MPPE	56-bit DES
Strong	56-bit MPPE	56-bit DES
Strongest	128-bit MPPE	3DES (three 56-bit keys)

Note

Windows NT 4.0 with the 128-bit version of Service Pack 4 (SP4) can support 128-bit MPPE, but it does not support 56-bit MPPE. Therefore, any Windows operating system earlier than Windows NT 4.0 SP4 is not recommended, because security enhancements for MS-CHAP and MPPE are not included.

Choosing Router User Accounts and Groups

After a calling router is authenticated by using either Windows or RADIUS as the authentication provider, it must be authorized: that is, it must be given permission to establish a connection with the answering router. You use two interrelated sets of components to authorize access by the calling router: user accounts and (optionally) groups, and remote access policies.

Before you can successfully configure either the router user accounts or remote access policies (both described later in this chapter), you need to understand the relationship between the two. Configuring the router user account includes the option of choosing whether to use remote access policies to grant the calling router access to the answering router. You can grant or deny permission for the calling router to access the answering router either at the user account level or at the remote access policies level. The permission specified in the user account overrides the permission specified in a remote access policy. However, if you choose the Control access through Remote Access Policy option in the user account that the answering router uses to authenticate the calling router, the remote access policy permission specified on Properties page for the remote access policy governs whether the user account of the calling router is granted or denied access. This option is available only for accounts on stand-alone routers or members of a native mode Active Directory domain. For more information about remote access policies, see "Choosing a Remote Access Policy Type" later in this chapter.

To allow or reject connection attempts according to a variety of criteria, you can specify several remote access options in the user account of the calling router and multiple additional options by using remote access policies. This granularity enhances the security of your site-to-site connection by providing great flexibility in how you can control access to the answering router and its network resources.

You can configure router user accounts individually for each router or by adding router accounts to an Active Directory group.

Configuring Router User Accounts

Successfully configuring the router's user account includes the following tasks:

Configure the router user account name to match the demand-dial interface name.
Configure the authentication provider for the router.
Choose an Active Directory user account or a local user account.
Choose dial-in options for the router user account.
Ensure that the calling router can establish a connection.

Configure the Router User Account Name to Match the Demand-Dial Interface Name

The name of a demand-dial interface configured on the answering router must match the name of the user account that the answering router uses to authenticate the calling router (unless, for a one-way initiated connection, you do not create a demand-dial interface on the answering router, instead configuring static routes in the calling router's user account). For example, if you have one headquarters site and multiple branch offices, on the headquarters answering router configure a separate demand-dial interface for the calling router at each branch-office site. This creates a one-to-one relationship between each calling router's user account name and the name of its corresponding demand-dial interface on the answering router.

Caution

If the user account name does not match the name of the demand-dial interface, the answering router identifies the calling router as a remote access client rather than as a demand-dial router. In this case, the connection might not work correctly. For this reason, do not change the user account name without also changing the corresponding demand-dial interface name.

Table 10.8 shows an example configuration of the demand-dial interfaces and user accounts for a two-way initiated VPN connection. The example in Table 10.8 uses Active Directory user accounts for the routers. In some cases, you can alternatively use a local user account.

Table 10.8: Example Configuration of Demand-Dial Interfaces and User Accounts for a Two-Way Initiated VPN Connection
Router	Demand-Dial Interface	User Account for Calling Router
Router located in Seattle (Functions as both a calling and an answering router)	Interface Name: VPN_NewYork Destination IP Address: 131.107.0.1 Credentials: VPN_Seattle Password: PasswordOne	VPN_NewYork PasswordTwo
Router located in New York (Functions as both a calling and an answering router)	Interface Name: VPN_Seattle Destination IP Address: 157.54.0.1 Credentials: VPN_NewYork Password: PasswordTwo	VPN_Seattle PasswordOne

For a two-way initiated VPN connection, such as the example in Table 10.8, the name of the demand-dial interface for each router must match the user name in the remote router's user credentials so that each router knows that a requested connection is for a site-to-site connection rather than for a remote access connection. The destination address of the remote router is configured on the demand-dial interface so that each router knows what address to connect to for the site-to-site connection. Each router uses the user account (the credentials and password of the remote router) to authenticate the remote router when it attempts to establish a connection.

Table 10.9 shows an example configuration of the demand-dial interfaces and user accounts for a one-way initiated dial-up connection in which two branch offices — Portland and Olympia — call the headquarters office in Seattle. In this case, because the connection is a one-way initiated connection, no demand-dial interface is required on the answering router. Therefore, the "rule" that the calling router's user account name must match the name of a demand-dial interface on the answering router does not apply. If you do not create a demand-dial interface on the answering router, you use the calling router's local or Active Directory user account to configure static routes that identify the network IDs of the calling router's site.

Table 10.9: Example Configuration for a Dial-up One-Way Initiated Connection
Router	Demand-Dial Interface	Calling Router User Accounts
Answering router in Seattle	No demand-dial interface needed. If you do not configure a demand-dial interface on the answering router, you must configure static routes specifying the network IDs of the calling router's site on the Dial-in tab of the calling router's user account.	DD_Olympia PasswordOne -and- DD_Portland PasswordTwo
Calling router in Olympia	Interface Name: DD_Seattle Modem or adapter: Modem on COM1 Phone number: 555-0111 Credentials: DD_Olympia/ PasswordOne	No user accounts needed, because the Seattle router does not call the routers in Olympia or Portland.
Calling router in Portland	Interface Name: DD_Seattle Modem or adapter: Modem on COM2 Phone number: 555-0111 Credentials: DD_Portland / PasswordTwo	No user accounts needed, because the Seattle router does not call the routers in Olympia or Portland.

Configure the Authentication Provider for the Router

The answering router uses the calling router's credentials to authenticate and authorize the calling router. As described earlier, if the answering router is configured for Windows authentication, as is the case for a site-to-site only connection, Windows security is used to authenticate the credentials of the calling router. If the answering router is configured for RADIUS authentication, as might be the case if the same answering router is used to support both a site-to-site connection and remote access users, the RADIUS server verifies the credentials of the calling router.

The user accounts and groups that Windows and IAS can use to authenticate and authorize site-to-site dial-up or VPN connection attempts are those available in Windows Server 2003 or Windows 2000 native-mode or mixed-mode Active Directory domains and Windows NT 4.0 domains.

Choose an Active Directory User Account or a Local User Account

The answering router must be able to access an Active Directory user account or a local user account to verify the calling router's credentials. In either case, because demand-dial routers make connections automatically, the user account that the answering router uses to authenticate and authorize the calling router must not prompt for human intervention.

Active Directory user account

If your demand-dial routers belong to an Active Directory domain, you use the Active Directory Users and Computers snap-in (rather than the Demand-Dial Interface Wizard) to create a user account for each calling router before you deploy a dial-up or VPN connection. When you create the router account, be sure to clear the User must change password at next logon check box and select the Password never expires check box.

If you use EAP-TLS user authentication with Windows as the authentication provider, the answering router must belong to the Active Directory domain, and you must create an Active Directory user account for the calling router. (If you use EAP-TLS user authentication with RADIUS as the authentication provider, you must join the IAS server to the Active Directory domain.)

If you use RADIUS authentication, the RADIUS server can use either an Active Directory user account or a local user account to authenticate the calling router. If you use a Windows Server 2003 IAS server as your RADIUS server, Microsoft recommends that you use Active Directory accounts.

For information about how to create an Active Directory user account, see "Create a new user account" in Help and Support Center for Windows Server 2003.

Local user account

If you use Windows authentication and your demand-dial routers do not belong to an Active Directory domain, the answering router uses a local user account to authenticate the calling router. This user account is created locally on the answering router.

Instead of creating the user account for the calling router manually, you use the Demand-Dial Interface Wizard to create the account. When you run the Demand-Dial Interface Wizard on an answering router that is not joined to an Active Directory domain, the wizard adds a local account for the calling router when you select Add a user account so a remote router can dial in on the Protocols and Security page. The wizard clears the User must change password at next logon check box and selects the Password never expires check box on the user account object.

For information about using the Demand-Dial Interface Wizard, see "Configure the Routing and Remote Access Service and Demand-Dial Interfaces" later in this chapter, and see "Add a demand-dial interface" in Help and Support Center for Windows Server 2003.

If you use a local account and password, you must use MS-CHAP v2 rather than EAP-TLS for user authentication.

If you use RADIUS authentication, the RADIUS server can use a local user account to authenticate the calling router. If you use a Windows Server 2003 IAS server as your RADIUS server, however, using Active Directory accounts is recommended.

Choose Dial-in Options for the Router User Account

You use the Dial-in tab of the calling router's user account to specify the remote access permission as follows:

Allow access (for native-mode or mixed-mode domains). Allows access when a connection is attempted. (When you use the Demand-Dial Interface Wizard to create a local account, the remote access permission is set to Allow access by default.) This option overrides the grant or deny remote access permission setting specified on the Properties page of any associated remote access policy. The remote access permission on the associated remote access policy is either Deny remote access permission or Grant remote access permission. Thus, for example, if you select Allow access on the router user account, and if you select Deny remote access permission on the remote access policy, the connection attempt succeeds.
Deny access. Denies access when a connection is attempted. This option also overrides the remote access permission configured on the remote access policy.

Control access through Remote Access Policy (available only for native-mode domains). With this option selected, the grant or deny remote access permission setting specified on the Properties page of any associated remote access policy is used. Thus, for example, if you select Control access through Remote Access Policy on the router user account, and if you select Deny remote access permission on the remote access policy, the connection attempt is blocked.

Note

If the user account is in a Windows Server 2003 or Windows 2000 mixed-mode domain, the Control access through Remote Access Policy setting is not available, and you must set the remote access permission in each calling router's user account to Allow access.

Even when remote access permission is allowed, the connection attempt still can be denied on the basis of other user account properties, such as callback options configured on the Dial-in tab, or it can be denied on the basis of remote access policy conditions or profile settings. Authorization of the site-to-site connection is controlled by a combination of the account dial-in properties (which includes the account remote access permission), the policy remote access permission, and the profile constraints configured on the remote access policy.

You can configure the following settings on the user account Dial-in tab:

Verify Caller ID (for dial-up router only). Typically, you use this option to increase security when accepting dial-in connections from telecommuters, but you can also use it for a calling router. Selecting this option requires that the calling router always call from the phone number that you type. Windows Server 2003 uses the caller ID functionality of the modem and the phone connection to verify that the dial-up router is in fact using the correct number; if the number matches, the connection is allowed. This option is not available if the answering router is in a Windows NT 4.0 domain or a Windows Server 2003 or Windows 2000 mixed-mode domain.

Note

For caller ID verification to work, the calling router, the answering router, and the phone system that connects them must all support caller ID. In addition to supporting the caller ID feature, the calling and answering routers must have the appropriate drivers to support the transmission of caller ID information to the Routing and Remote Access service.

Callback Options. Typically, these options are used for managing individual dial-up remote access users rather than demand-dial calling router user accounts. However, you can also configure callback options for a dial-up demand-dial connection. For example, you can specify that the main office router call the branch office router back if the main office has fixed or low-cost long-distance rates and the branch office has higher long-distance rates.
Assign a static IP address (for dial-up or VPN routers). Use this option to cause the remote router to assign a static IP address to this router when a connection is made. For more information about assigning IP addresses, see "IP Address Assignment for the Logical Interface" later in this chapter. You can increase security by specifying which IP address the router must use. This option is not available in a Windows NT 4.0 domain or a Windows Server 2003 or Windows 2000 mixed-mode domain.

If the static IP address that you specify is not valid or is already in use by another calling router or by a remote access user, the answering router assigns a dynamic IP address to the calling router.
Apply static routes (for dial-up or VPN routers). This option is designed for one-way initiated site-to-site connections. You select Apply static routes to add static IP routes (network IDs) for the calling router's site to the routing table of the answering router when a connection is made. This lets the answering router forward packets to all addresses on the calling router's intranet across the connection to the calling router. This option is not available if the answering router is in a Windows NT 4.0 domain or a Windows 2000 mixed-mode domain.

Ensure That the Calling Router Can Establish a Connection

To ensure that the router user account is not prevented from establishing a site-to-site connection, verify that the following options are configured as appropriate:

When you create the calling router user account, clear the option User must change password at next logon. If you select User must change password at next logon, the site-to-site connection attempt fails, because changing the password while attempting to make the connection is an interactive process. For information about how to create a user account, see "Create a new user account" in Help and Support Center for Windows Server 2003.
For a site-to-site connection, do not use the remote access account lockout feature. If the router user account is disabled (locked out by using the remote access account lockout feature), the connection attempt is rejected. For information about the remote access account lockout feature, see "Remote access account lockout" in Help and Support Center for Windows Server 2003.
If you block the calling router from establishing a connection during certain times, make sure that the times specified are appropriate for your organization. If the router user account is not permitted to log on during the time specified for the site-to-site connection, the connection attempt is rejected. For information about how to use remote access policies to configure dial-in hours on an answering router in order to block incoming connections from a calling router at specific times of the day or week (such as at night or on weekends), see "Configure dial-in constraints" in Help and Support Center for Windows Server 2003.

Configuring Router Groups

Adding demand-dial router user accounts to an Active Directory group reserved for demand-dial routers simplifies administration by letting you centrally manage the list of demand-dial routers on your network. If you decide to manage authorization by group rather than by each router's individual user account, you must set the remote access permission on each calling router's user account to either Control access through Remote Access Policy or Allow access and then create a remote access policy based on connection type and group membership.

For example, if multiple calling routers will use a VPN connection, you can create an Active Directory global group called VPN-Routers and add the user account of each calling router to that group.

Then, create a remote access policy with two conditions:

Set NAS-Port-Type to Virtual (VPN). A network access server (NAS) is a server that accepts point-to-point connections from a calling router, or other remote client, and then acts as a gateway to the network for the calling router; the NAS-Port-Type is the media type that a calling router uses to access the site of the answering router).
Set Windows-Group to VPN-Routers.

Finally, configure the profile for the remote access policy, selecting an authentication method and encryption strength.

Choosing a Remote Access Policy Type

You can use remote access policy settings to validate a variety of connection settings before a connection is authorized and to specify a variety of connection restrictions after the connection is authorized. For example, you can use remote access policies to allow or reject connection attempts based on membership in an Active Directory group or by time of day or day of week; to require a specific authentication method and encryption strength; or to limit the connection based on bandwidth.

The computer on which you create a remote access policy is determined by which authentication provider you use for site-to-site connections. If you use Windows authentication, you create and manage remote access policies on each answering router. If you use RADIUS authentication, as you might if your answering router supports both a site-to-site connection and home or mobile users, you can configure and manage all remote access policies centrally on the IAS server that provides RADIUS authentication for multiple answering routers.

If you use RADIUS as the authentication provider in Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; or Windows Server 2003, Datacenter Edition, you can configure a RADIUS attribute to ignore the dial-in properties of a user account in the profile properties of a remote access policy. To support the multiple types of connections for which IAS provides authentication and authorization, you might need to disable the processing of user account dial-in properties. For more information about dial-in properties, see "Dial-in properties of a user account" and "Add RADIUS attributes to a remote access policy" in Help and Support Center for Windows Server 2003.

You can use one of three types of remote access policies:

Common policy. You can create a common policy, which uses typical settings for a particular access method.
Custom policy. You can create a custom policy, which lets you specify a detailed configuration for a particular access method. If you want to manage authorization and connection parameters other than by group or by type of connection, you must configure custom remote access policies. For more information about each possible setting for remote access policy conditions and profiles for a custom policy, see "Elements of a remote access policy" in Help and Support Center for Windows Server 2003.
Default policy. If enforcing a high level of security is not important for your organization, you can use one of the existing default policies. Two default remote access policies are created when you enable and configure the Routing and Remote Access service on a demand-dial router or when you install IAS: The Connections to Microsoft Routing and Remote Access server policy and the Connections to other access servers policy. To use the Connections to Microsoft Routing and Remote Access server policy for a site-to-site connection, all you have to do is change the remote access permission on the policy's Properties page to Grant remote access permission.

For more information about using Windows Server 2003 remote access policies, see "Remote access policies" in Help and Support Center for Windows Server 2003. For more information about using remote access policies with an Internet Authentication Service (IAS) server, see "Deploying IAS" in this book and see the Networking Guide of the Microsoft Windows Server 2003 Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).