Configure Router User Accounts
Updated: April 30, 2010
Applies To: Windows Server 2008, Windows Server 2008 R2
Successfully configuring the user account of the router includes the following tasks:
Configure the router user account name to match the demand-dial interface name.
Configure the authentication provider for the router.
Select an Active Directory user account or a local user account.
Select 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. 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.
However, for a one-way initiated connection, do not create a demand-dial interface on the answering router; instead, configure static routes in the user account of the calling router.
Warning
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.
The following table shows an example configuration of the demand-dial interfaces and user accounts for a two-way initiated VPN connection. The example in this table uses Active Directory user accounts for the routers. In some cases, you can alternatively use a local user account.
| 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 above, 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 IP 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.
The following table 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.
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 Network Policy Server (NPS) can use to authenticate and authorize site-to-site dial-up or VPN connection attempts are those available in Windows Server 2008, Windows Server 2003, or Windows 2000 native-mode or mixed-mode Active Directory domains.
Select 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, 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 NPS 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 an NPS server running Windows Server 2008 as your RADIUS server, Microsoft recommends that you use Active Directory accounts.
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.
Instead of creating the local user account for the calling router manually, use the Demand-Dial Interface Wizard. 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.
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 an NPS server as your RADIUS server, however, using Active Directory accounts is recommended.
Select dial-in options for the router user account
Use the Dial-in tab of the calling router’s user account to specify the network access permission as follows:
Allow access. Allows access when a connection is attempted. (When you use the Demand-Dial Interface Wizard to create a local account, the network access permission is set to Allow access by default.)
Deny access. Denies access when a connection is attempted.
Control access through NPS Network Policy. With this option selected, the grant or deny access permission setting specified on the Overview page of any associated network policy is used. Thus, for example, if you select Control access through NPS Network Policy on the router user account, and if you select Deny access on the network policy, the connection attempt is blocked.
Note
If the user account is in a Windows 2000 or later mixed-mode domain, the Control access through NPS Network Policy setting is not available, and you must set the network access permission in each calling router’s user account to Allow access.
Even when network 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.
Configure the following settings on the user account Dial-in tab:
- Verify Caller ID. 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 specify. Windows Server 2008 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 2000 or later 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 Static IP Addresses. Use this option to cause the answering router to assign a static IP address to the calling router when a connection is made. For more information about assigning IP addresses, see IP Address Assignment for the Virtual Interface. You can increase security by specifying which IP address the router must use. This option is not available in a mixed-mode Active Directory 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. This option is designed for one-way initiated site-to-site connections. You select Apply Static Routes to add static IP routes to the routing table of the answering router about the calling router’s site 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 mixed-mode Active Directory 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 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.
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 network 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 “Network Policy Conditions Properties” in Windows Server 2008 Help.