Inside Windows Server 1002003 [Electronic resources] نسخه متنی

Configuring a Remote Access Server

With the preliminaries and theory out of the way, it's time to prepare a server for dial-in access. The Routing and Remote Access Services (RRAS) service is installed by default but it is kept in a disabled state until needed.

The RRAS service is managed via the Routing and Remote Access Services console, Rrasmgmt.msc. You can manage all servers running RRAS from a single console as long as you have administrator rights on the servers themselves. You cannot manage desktop connections from the RRAS console. You can also manage NT4 RRAS servers but several of the router options are not available. Your best option is to copy the classic NT4 RAS management utility, Rasadmin.exe, to your desktop. When you add the legacy server to the RRAS console and click the icon, the console automatically launches Rasadmin.

Initial RRAS Service Setup

Figure 20.28 shows a relatively simple remote access configuration. The remote access server has been placed outside the firewall in a De-Militarized Zone (DMZ) to improve security. The server routes dial-in client traffic onto the main network through the DMZ interface, which is trusted but provides a higher level of control than simply dialing into the server behind the firewall. Because a standalone RRAS server can only authenticate users in its local SAM, it has been configured to use RADIUS and paired with an IAS server inside the firewall.

Here are the general steps involved in building this configuration:

dial-in access. If the domain is in Native, use the remote access policies in RRAS to control dial-in permissions.




• Add the remote access server to the RAS and IAS Servers group in other domains in the forest, if there are any.

There is no need for special configuration at the dial-in clients. The clients use their default authentication method, which is MS-CHAPv2 for Windows clients.

Like most setup operations in Windows Server 2003, the RRAS setup uses a wizard. The configuration options you select in the wizard are not quite as simple as they appear. Let's use the wizard to initialize the service then walk through some details on the settings. Follow Procedure 20.9.

Procedure 20.9 Initializing the RRAS Service to Support Remote Access

1. Open the Routing and Remote Access console using S

   TART | P

   ROGRAMS | A

   DMINISTRATIVE T

   OOLS | R

   OUTING AND R

   EMOTE A

   CCESS . The icon representing the local server has a red down-arrow, indicating that the serviceConfiguring Internet Authentication Services (IAS)" section for details.

2. Click Next. A summary window opens. Click Finish to start the service.

3. If the domain is in Mixed, make sure the user accounts have dial-in permission in Active Directory. If the domain is in Native, use the RRAS console to change the setting of the Allow Access If Dial-in Permission Is Enabled policy under Remote Access Policies to Grant Access. This gives access to authorized users.

Checking Dial-In Connections Using Remote Access Logging

The server is now ready to accept dial-in users. Test by making a connection from a client desktop using credentials from an Active Directory account. If you encounter problems that are related to remote access, not the modem connection, you may want to enable one of the Logging options in RRAS.

The first logging option is enabled for the server itself via the RRAS server Properties window (see Figure 20.31).

This option places information about the server operation in the Event log. The second logging option is available in the Remote Access Logging icon in the RRAS management console. This option tracks activity at each dial-in interface. It is a valuable analytical tool, but it takes a little patience to interpret.

The log is a comma-delimited file with each line representing one record. The first line is a header that contains information about the dial-in user who accessed the server:

10.4.1.1  IP address
testuser  logon name
02/15/2002  access date
22:24:5  access time
RAS  access method
DC-01  target domain controller

The next fields are number pairs. The first number is the attribute designator and the second number is the value for the attribute. Here is a brief example for a user who was denied access:

4121,0x00453D36343920523D3020563D33  CHAP error
4127,4  authentication type
4130,SUBSIDIARY\testuser  Fully qualified user name
4136,3  packet type (accept-reject)
4142,48  rejection reason (incomplete accounting-request packet received.)

If you want more information about the attributes and constraints that are listed in the log entries, search the online help for "Interpreting IAS-Formatted Log Files." This contains an exhaustive list of the attribute types and meanings. Also check out RFC 2138, "Remote Authentication Dial In User Service (RADIUS)" with Microsoft extensions documented in RFC 2548, "Microsoft Vendor-Specific RADIUS Attributes."

The vendor attributes associated with each interface are stored in Active Directory in an object called Identity-Dictionary. This object is located in cn=RRAS, cn=Services,cn=Configuration,dc=

<domain> ,dc=

<root> . You can view the contents of this attribute using with the ADSI Editor from the Support Tools.

Configuring Dial-In IP Settings

From the perspective of NDIS, the network interface represented by a modem or ISDN terminal adapter is no different than that of an Ethernet adapter. You'll see terms in the interface such as

PPP adapter and

virtual

WAN interface assigned to these connections. In actuality, NDIS sees all network interfaces as virtual adapters, not just remote access connections. One of the functions of the NDIS wrapper is to hide underlying physical hardware behind a virtual shroud of access logic.

If you were to run ipconfig /all on any of the machines shown in the figure, you'd see a PPP adapter listed along with the network adapter. Here's an example listing:

Windows IP Configuration
Host Name . . . . . . . . . . . . : pro1
Primary Dns Suffix  . . . . . . . :
Node Type . . . . . . . . . . . . : Mixed
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . . : No
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : 3Com XL 10/100 PCI NIC (3C905C-TX)
Physical Address. . . . . . . . . : 00-14-39-3C-6B-2D
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.0.3
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.254
DNS Servers . . . . . . . . . . .  : 192.168.0.15
PPP adapter Company VPN:
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-13-25-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.10.23
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 192.168.10.23
DNS Servers . . . . . . . . . . . : 192.168.10.100

The default gateway for the PPP adapter is the same as the IP address assigned to the interface by the RRAS server. This is an old routing trick that says, in essence, "If you want an exit path off this machine, I'm your guy." You can confirm this by running route print. Here's an example with the dial-in connection shown in bold:

===========================================================================
Interface List
0x1 ............................... MS TCP Loopback interface
0x2 ... 00 14 39 3C 6B 2D ......... 3Com 10/100 PCI NIC (3C905C-TX)
0x20006 ...00 13 25 00 00 00 ...... WAN (PPP/SLIP) Interface
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
0.0.0.0          0.0.0.0      192.168.0.1   192.168.0.253       21
0.0.0.0          0.0.0.0    192.168.10.23   192.168.10.23       1 
127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
192.168.0.0    255.255.255.0    192.168.0.253   192.168.0.253       20
192.168.0.2  255.255.255.255        127.0.0.1       127.0.0.1       20
192.168.0.255  255.255.255.255    192.168.0.253   192.168.0.253       20
192.168.10.3  255.255.255.255        127.0.0.1       127.0.0.1       50
192.168.10.255  255.255.255.255    192.168.10.23   192.168.10.23       50
224.0.0.0        240.0.0.0    192.168.0.253   192.168.0.253       20
224.0.0.0        240.0.0.0    192.168.10.23   192.168.10.23       1
255.255.255.255  255.255.255.255    192.168.0.253     192.168.0.2       1
Default Gateway:      192.168.10.23 
===========================================================================
Persistent Routes:
None

The end result of this maneuvering is to route non-local IP traffic from the client to the RRAS server and from there onto the network. A single virtual WAN adapter at the RRAS server handles all incoming traffic. The interface appears in the Network Connections as an Incoming Connections icon.

The IP settings assigned to the PPP adapters come from the RRAS server unless the system has been configured to permit dial-in clients to use static addresses assigned at the client. The IP options for RRAS are located on the IP tab of the Properties window for the server in the RRAS console. Figure 20.32 shows an example.

Assigning Client IP Addresses

The IP Address Assignment window has two options for assigning addresses to dial-in clients and to the PPP interface on the RRAS server.

One option specifies a static range of IP addresses. This option is for use if you do not have a DHCP server or you do not want to obtain dial-in addresses from DHCP. When you specify the address range, select a range in a different subnet than the main interface on the RRAS server. The server will route traffic between the two subnets. See the sidebar, "Routing Protocols."

The other option is to use DHCP. When you make this selection, the RRAS server locates the DHCP server for its subnet and leases IP addresses for its dial-up interfaces from that DHCP server. The key word here is

interfaces , not

clients . The RRAS server does not wait for the client to connect to lease the address. It grabs the addresses immediately.

In NT4, this could cause problems if you had a rack with 20 or 30 modems or you configured a few dozen Point-to-Point Tunneling Protocol (PPTP) interfaces. The RRAS server would reach out and nab addresses for all the interfaces plus one for itself. This could exhaust the supply of addresses in the DHCP address pool.

Starting with Windows 2000, RRAS was modified to lease only 10 addresses at a time. If you have 10 modems and 30 VPN interfaces but normally only have 18 concurrent logons, you would lose only 20 addresses from the DHCP address pool.

Configuring Name Resolution

A dial-in client needs to resolve names to IP addresses just like every other PC on the network. Getting the DNS and WINS settings to the client, though, is not as straightforward as you might think.

PPP clients obtain their configuration settings during the IPCP phase of the connection transaction. The remote access server determines where to obtain the values for these settings based on the IP addressing options discussed in the previous section.

Static IP Addressing

If the remote access server is configured to use a static range of addresses, the DNS and WINS settings are obtained from the LAN adapter settings.

If the LAN adapter is configured to use DHCP, the settings given to the dial-in clients are taken from the dynamic settings on the LAN adapter.

If the LAN adapter uses DHCP but also has static configurations for DNS and WINS, the static configurations take precedence and are the only settings delivered to the dial-in clients.

If the remote access server has more than one LAN adapter, you can select which one will be used to obtain IP configuration settings. The option is located in the IP tab of the RRAS server Properties window.

If you leave the selection in the default setting of Allow RAS to Select Adapter, the server will select the first adapter listed under the Routing Interfaces icon of the main RRAS console. This is typically the first interface installed on the server. If this adapter is not available, the second one on the list is used.

DHCP-Based IP Addressing

If the remote access server is configured to use DHCP to lease addresses for the dial-in client, the situation gets a little more complex.

As discussed in the last section, the IP addresses assigned to the dial-in clients come from a set of addresses leased from DHCP and cached locally by the remote access server. However, the IP configuration settings delivered to the dial-in clients during IPCP come from the LAN interface, not from DHCP. There is not enough time during IPCP to stop and get current configurations from DHCP.

You can effectively deliver current DHCP configuration settings, though, by enabling DHCP on the LAN interface of the remote access server. The DNS and WINS settings obtained from DHCP become the settings that will be delivered to the dial-in clients. If you statically assign different DNS or WINS settings to the LAN adapter, those take precedence.

DHCPINFORM

Many IT shops prefer to statically assign IP settings to servers. If the statically assigned DNS and WINS settings on the LAN adapter are suitable for the dial-in clients, this is not a problem. In cases where those settings are not appropriate, a modern Windows client can take over and obtain different settings from DHCP.

This trick depends on a relatively new DHCP feature called DHCPINFORM. One of the functions of DHCPINFORM is to permit a non-DHCP client to obtain configuration settings from a DHCP server.

Windows Server 2003, XP, and Windows 2000 clients take advantage of this feature by broadcasting a DHCPINFORM packet after the PPP transaction has been completed. The DHCP Relay Agent service on the remote access server passes the DHCPINFORM packet to a DHCP server, which responds with a configuration packet. The client assigns the settings in the configuration packet to its dial-up interface in addition to those it obtained during IPCP.

You do not need a packet sniffer to follow this transaction. At a dial-in client, disable the Ethernet interface then run ipconfig /all at a command prompt. You will get no listings. Now, initiate a dial-in connection to the remote access server. As soon as the modem finishes squealing, start repeating the ipconfig /all entry. You'll first see a single set of configuration settings that match the LAN interface at the remote access server. Then, in a few seconds, the listing changes to include the configuration settings from the DHCP server.

You'll end up with at least two entries for DNS and WINS. This is your indication that the DHCPINFORM process completed successfully. Here's a sample listing. The bold entries were obtained via DHCPINFORM. The secondary entries came from the LAN interface:

C:\>ipconfig/all
Windows IP Configuration
Host Name . . . . . . . . . . . . : xp-pro1
Primary Dns Suffix  . . . . . . . : subsidiary.com
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : Yes
DNS Suffix Search List. . . . . . :   subsidiary.com
PPP adapter server3:
Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : WAN (PPP/SLIP) Interface
Physical Address. . . . . . . . . : 00-53-45-00-00-00
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.10.19
Subnet Mask . . . . . . . . . . . : 255.255.255.255
Default Gateway . . . . . . . . . : 192.168.10.19
DNS Servers . . . . . . . . . . . : 192.168.10.200 
192.168.0.100
Primary WINS Server . . . . . . . : 192.168.10.200 
Secondary WINS Server . . . . . . :   192.168.0.100

As you can see from the listing, the DHCPINFORM settings become the primary settings for the client. This permits the client to use DNS and WINS servers that are appropriate for its IP subnet.

Remember to enable the DHCP Relay Agent service in the RRAS console. You'll need to specify an interface on which to listen for DHCPINFORM broadcasts and you'll need to enter the IP address of at least one DHCP server.

If you have NT4 and Windows 9x clients, you will need to configure a different workaround because those clients do not use DHCPINFORM. The most straightforward method is to statically configure DNS and WINS settings in the dial-up connection. These settings will take effect even though the client obtains an address from the remote access server.

Flat Name Resolution

The Enable Broadcast Name Resolution option in the IP tab of the remote access Property window is a new feature in Windows Server 2003 and one that is not enabled by default. Its purpose is to simplify name resolution on small networks where DNS and WINS services are not installed.

An example would be a small manufacturing firm where the computer names were assigned by the owner's teenage children when they installed the network. When a dial-up user at a laptop named Blink_182 attempts to connect to a server named DMX over a mapped drive, the laptop needs a way to resolve the name into an IP address. On the local network, this would be done with broadcasts. By enabling broadcasts through the dial-up connection, the name can still be resolved.

Broadcast name resolution is not a welcome feature in large networks, but for a few dozen nodes in a single subnet, it works well and should not be avoided simply because of the traffic. If you are going to install Windows Server 2003 in this office, though, you might as well install DNS and WINS and avoid the broadcasts.

Configuring Miscellaneous IP Options

The Enable IP Routing option in the IP tab of the remote access server Properties window is set by default. This option controls access to the main network. This is a handy way to block network access when you want to change settings but you do not want to bring down the server. You do not need to stop and restart the service if you change this option. It takes effect immediately.

The Allow IP-Based Remote Access and Demand-Dial Connections option acts as an on-off toggle for remote access. This is a useful option when you are troubleshooting a problem and you want to leave the RRAS service up but you want to block access. Unfortunately, the users get a Cannot connect to remote network error rather than an error such as Remote network temporarily unavailable.

RRAS Command-Line Management

Windows Server 2003 includes a general-purpose, text-based tool for managing network settings, including the settings in RRAS. The tool is called the

Network Shell , or Netsh.

The Netsh utility provides a text-based interface with a variety of options. If you run the utility on one of your servers, you may not see some of these options listed. They are only displayed if the associated service is enabled.

To go to a particular context in the namespace, enter the name of the context at the prompt. For example, enter ras to go to the netsh ras> context.

You can move from one context to another without navigating up and down the namespace. For example, from the netsh ras> context, you can enter interface to go directly to the netsh interface> context. You can navigate up to a parent context using a double dot (..), just like navigating in a directory tree. Type bye, exit, or quit to exit the shell.

To see the available commands at each level of the namespace, type ? at the netsh> prompt. Some commands have additional parameters. Enter the command followed by a question mark to see them. For example, the show ? command lists the parameters of the current context:

[View full width]
netsh ras>show ?
show tracing            - Shows whether extended tracing is enabled for components.
show user               - Displays RAS properties for a user(s).
show authmode           - Shows the authentication mode.
show authtype           - Displays the authentication types currently enabled.
show link               - Shows the link properties PPP will negotiate
show multilink          - Shows the multilink types PPP will negotiate
show registeredserver   - Displays whether a computer is registered as a RAS server in 
the Active Directory of the given domain.
show domainaccess       - Displays whether NT4 RAS servers or Windows Server 2003 RAS 
servers in trusted NT4 domains have been enabled in the Active Directory of the given 
domain.
show activeservers      - Listens for RAS server advertisements.
show client             - Shows RAS clients connected to this machine.
show alias              - Lists all defined aliases.
show mode               - Shows the current mode.

Enter the command with the correct syntax and the results are listed in the console:

ras>show registeredserver domain=company.com
The following RAS server is registered:
RAS Server:     DC-01
Domain:          company.com

To change a parameter, substitute the word set for show. The Network Shell has two modes: online and offline. You can shift back and forth between them by entering online or offline at the netsh> prompt. In the online mode, any changes you make are implemented immediately. In the offline mode, changes are saved but not implemented. Implement them using the commit command or discard them using the abort command.

One of the most useful Network Shell features is its capability to dump the current configuration to a script so you can replay the script and get back your original configuration. The command to show the running configuration is dump. You can type dump at the shell prompt to see the results on the screen, but to save the output to file, you must run it from a command prompt and redirect the output to a file. For example, enter c:\>netsh dump > netsh.scr.

If you want to limit the dump to a particular context, put the context on the command line. Here is an example:

c:\>netsh ras ip dump > netshrasip.scr
# -----------------------------------------
# RAS IP Configuration
# -----------------------------------------
pushd ras ip
set negotiation mode = allow
set access mode = all
set addrreq mode = deny
set pool addr = 10.1.2.0  mask = 255.255.255.240
set addrassign method = auto
popd
# End of RAS IP configuration.

To apply the settings you saved in the script, enter netsh f <

filename >. For example:

c:\>netsh f netshrasip.scr.

You can use Netsh to control other servers either by executing the script remotely using a remote shell or by putting the script in the Windows Scheduler at the remote server for execution at a later time.

Managing Client Remote Access Connections with Group Policies

There are a variety of group policies available for managing remote access connections at the client desktops. These policies are available in the Group Policy Editor under Administrative Templates | Network | Network Connections. There is a short set of policies for Computers and a longer set for Users.

The Computer-side policies permit you to disable the following services at the desktops:

• Internet Connection Sharing (ICS)




• Internet Connection Firewall (ICF)




• Network Bridge




• Certificate-based authentication of wireless connections

Of these, you may want to consider disabling ICS very soon after you begin deploying Windows 2000 and XP desktops. This prevents users with local admin rights from creating back doors out of your network.

The User-side policies restrict users from changing or even viewing the contents of their remote access connections. This is a handy set of policies to implement if you want to avoid constant calls to the Help Desk from users who think they know enough to change the connection settings. Because group policies remain in effect even when a machine is off the network, you may want to ease up on the restrictions for users who might need to change phone numbers for connecting to their ISPs as they travel.

Making Dial-In Connections from the Command Line

You do not need to use the graphical user interface to initiate a dial-up session. An executable to handle the connection, Rasdial.exe, can be called from the command line or a batch file.

Using Rasdial, you can configure an unattended workstation to use the Task Scheduler to make dial-up connections, transfer files, pick up email, or do other periodic chores. Do this by configuring the batch file to give Rasdial the name of a phonebook entry. The name of the entry is the same as the name assigned to the Connection icon in the Networking and Dial-up Connections window. For example, if you have a connection named Home Office, the syntax would be as follows:

rasdial "home office"

During the time that the system is making the connection, the console displays the same status information that you would see from the graphical interface. When you are ready to hang up, enter the following:

rasdial /disconnect

Unfortunately, you cannot use Rasdial in conjunction with a smart card. You must use passwords. If you do not cache your passwords when you use dial-up connections, or you want to provide a different set of credentials than those stored in the phonebook, you can provide this information on the command line. Here's the syntax: (The parameters are not case sensitive.)

rasdial "home office" 
username  * /DOMAIN:
domain  /PHONE:
phonenumber 
/CALLBACK:
callbacknumber  /PREFIXSUFFIX

The * causes Rasdial to prompt for a password. You can enter the password on the command line, if you prefer. The /prefixsuffix switch tells Rasdial to use the TAPI settings for the modem interface