Экспорт (0) Печать
Развернуть все

Configuring Router User Accounts

Обновлено: Март 2003 г.

Назначение: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

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 "Создание новой учетной записи пользователя" 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 "Создание новой учетной записи пользователя" 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.

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв

Добавления сообщества

ДОБАВИТЬ
Корпорация Майкрософт проводит интернет-опрос, чтобы выяснить ваше мнение о веб-сайте MSDN. Если вы желаете принять участие в этом интернет-опросе, он будет отображен при закрытии веб-сайта MSDN.

Вы хотите принять участие?
Показ:
© 2014 Microsoft