Chapter 7 - RAS Security

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Windows NT user accounts and domains provide security with encrypted authentication. RAS provides additional security features such as callback and data encryption. You can also install 3rd-party security hosts to prevent unauthorized access to your LAN.

This chapter covers the following RAS security features:

• Setting RAS up in a domain 

• Granting RAS permission to user accounts 

• Setting RAS security on user accounts 

• Data encryption 

• Callback security 

• Support for security hosts 

• Auditing 

Setting RAS up in a Domain

Applying RAS security to clients involves three steps: Setting RAS up in a Windows NT domain, granting RAS permission to Windows NT user accounts, and then setting RAS security on these accounts.

This section explains Windows NT user accounts and approaches for implementing domain-based security for RAS. This section assumes you have a domain structure established and provides information about integrating RAS into your existing domain scheme. Remote Access servers using Windows NT Server domain-based security can be centralized in a single domain or distributed among several domains that might have trust relationships.

Centralized Servers

If your goal is to simplify administration, centralize all Remote Access servers in a single domain: Only one user account database will need to be maintained, and the system administrator will be able to monitor all RAS servers and users at one time. (Use trust relationships if departments maintain their own user accounts.)

Note Because the domain is logical rather than physical, centralized servers can be in different locations and still be part of the same domain.

In a trusted domain model, it is best to set up a user account on only one domain for each user, especially for users dialing in through RAS version 1.1 or earlier. If the Remote Access server cannot find the user's account in the server's domain, it simultaneously checks the trusted domains and accepts the first response. If the first response comes from a domain where the user has a different password or does not have Remote Access permission, authentication fails even though a second response from another domain might have the same user account with Remote Access permission.

Distributed Servers

Smaller organizations that value flexibility and local control, or organizations that have no clear need for centralized security, might prefer a distributed server system, in which individual departments or workgroups set up and maintain their own Remote Access domains. Trust relationships can be used to permit access across domains.

Note For additional information about Windows NT Server user accounts and domains, see the Windows NT Server Concepts and Planning Guide.

Granting RAS Access and Permissions

After a RAS server is installed, you must specify who can dial in to it. Use the Remote Access Admin utility or User Manager to select a computer's or domain's user accounts. Then grant RAS permission to the user accounts, as shown in the following sections. After passing Remote Access authentication and connecting to the LAN, remote users can access resources on the application server for which they have permission. Remember: You grant or revoke remote access privileges on a user-by-user basis. So although RAS is running on a Windows NT Server computer, access to the network must be explicitly granted to each user who needs it.

Note Remote users are subject to Windows NT Server security, just as they are at the office. In other words, they cannot do anything for which they lack sufficient privilege, nor can they access resources for which they do not have permission.

You do not need to create user accounts just for RAS users. RAS servers use the user accounts of any trusted domain or computer on the Windows NT network.

For information about adding a remote client to a domain, see Remote Access online Help or Control Panel Help.

Setting up RAS Security on Accounts

Remote users must be authenticated by a Remote Access server before they can access or generate traffic on the network. This authentication is a separate step from logging on to Windows NT. User passwords and the authentication procedure are encrypted when transmitted over phone lines.

You can restrict remote users' access to the network and to the Remote Access server. This allows an administrator to tightly control what information is available to remote users, and to limit their exposure in the event of a security breach.

For more information about granting RAS permission to users, see the Remote Access Admin online Help.

Granting and Preventing Network Access

By enabling and disabling sets of protocols and adapters called bindings, you dictate network access by remote users:

• Enable bindings to grant user access to resources. 

• Disable bindings to prevent user access to resources.

Figure 0.1 shows a configuration with two bindings that allow remote users to see and access all connections in the Remote Access gateway:

• TCP/IP and Adapter 1 

• NetBEUI and Adapter 2 

 

Figure 7.1 Remote Users Allowed Access to the Network 

For more information about bindings, see the Network icon in Control Panel and Control Panel online Help.

Restricting Remote Users to the Dial-In Server

Even if the Remote Access server is connected to a network, you can restrict remote users to the server they dial in to, as shown in Figure 7.2

For more information, see "Network Configuration" in online Help.

 

Figure 7.2 Remote Users Restricted to the Dial-In Server 

How Security Works at Connection

The following steps show what happens during a call from a client to a RAS server:

1. Through Dial-Up Networking, a client dials a Remote Access server. 

2. The server sends a challenge to the client. 

3. The client sends an encrypted response to the server. 

4. The server checks the response against the user database. 

5. If the account is valid, the server checks for Remote Access permission. 

6. If Remote Access permission has been granted, the server connects the client. 

If callback is enabled, the server calls the client back and repeats steps 2–6.

Note When using RAS in a domain environment, changes in Remote Access permission do not take effect immediately on all servers. It can take up to 15 minutes for replication of the change to other servers in the domain. If necessary, you can resynchronize the domain to ensure that a user with revoked permissions cannot gain access to the network before the change is automatically replicated.

Security Features

RAS security features include password encryption using different forms of authentication protocols, data encryption to maintain security in case of unauthorized interception of remote access transmissions, and callback security to predetermine a client's number before allowing access to the network.

Authentication

Authentication is an important concern for many corporations. This section shows how RAS helps ensure password privacy.

Authentication Protocols

RAS uses the Challenge Handshake Authentication Protocol (CHAP) to negotiate the most secure form of encrypted authentication supported by both server and client. CHAP uses a challenge-response mechanism with one-way encryption on the response. CHAP allows the RAS server to negotiate downward from the most-secure to the least-secure encryption mechanism, and it protects passwords transmitted in the process.

Level of security	Type of encryption	RAS encryption protocol
High	One-way	CHAP, MD5
Medium	Two-way	SPAP
Low	Clear-text	PAP

CHAP allows different types of encryption algorithms to be used. Specifically, RAS uses DES and RSA Security Inc.'s MD5. Microsoft RAS uses DES encryption when both the client and the server are using RAS. DES encryption— the U.S. government standard—was designed to protect against password discovery and playback. Windows NT 3.5 or later, Windows for Workgroups, and Windows 95 always negotiate DES-encrypted authentication when communicating with each other. When connecting to third-party remote access servers or client software, RAS can negotiate SPAP or clear-text authentication if the third party product does not support encrypted authentication.

MD5, an encryption scheme used by various PPP vendors for encrypted authentication, can be negotiated by the Microsoft RAS client when connecting to other vendors' remote access servers. MD5 is not available in the RAS server.

The Shiva Password Authentication Protocol (SPAP) is a two-way (reversible) encryption mechanism employed by Shiva. Windows NT Workstation, when connecting to a Shiva LAN Rover, uses SPAP, as does a Shiva client connecting to a Windows NT Server. This form of authentication is more secure than clear text but less secure than CHAP.

Password Authentication Protocol (PAP) uses clear-text passwords and is the least sophisticated authentication protocol. It is typically negotiated if the remote workstation and server cannot negotiate a more secure form of validation.

The Microsoft RAS server has an option that prevents clear-text passwords from being negotiated. This option enables system administrators to enforce a high level of security.

Data Encryption

Data encryption protects data and ensures secure dial-up communications. This is especially important for financial institutions, law-enforcement and government agencies, and corporations that require secure data transfer. For installations where total security is required, the RAS administrator can set the RAS server to force encrypted communications. Users connecting to that server automatically encrypt all data sent.

RAS provides data encryption in addition to password encryption as described in the "Authentication" section. To maintain security in case of unauthorized interception of remote access transmissions, clients configure each Phonebook entry to use data encryption. Windows NT RAS provides data encryption using the RSA™ Data Security Incorporated RC4 algorithm.

Callback

As an additional measure of security, RAS offers a Callback feature, which ensures that only users from specific locations can access the RAS server. It also saves toll charges for the user.

When using call back, the user initiates a call and connects with the RAS server. The RAS server then drops the call and calls back a moment later to the pre-assigned call-back number. This security method thwarts most impersonators.

You configure each user's callback privilege when granting Remote Access permission. For information about granting permission, see Chapter 6, "Installing and Configuring Remote Access Service" and online help for Remote Access Admin.

In Remote Access Admin, the Remote Access Permissions dialog box contains three callback options to choose from:

• Preset To 

• Set By Caller 

• No Callback (the default)

Note Until the user has been authenticated and called back (if Callback is set), no data from the remote client or the Remote Access server is transferred.

Preset To

For maximum security, select Preset To and type the number of the phone to which the user's modem is connected. When the user's call reaches the Remote Access server, the server takes the following steps:

1. Determines whether the user name and password are correct. 

2. If they are, responds with a message announcing that the user will be called back. 

3. Disconnects and calls the user back at the preset number.

Set this option for stationary remote computers, such as those in home offices.

Set By Caller

Although Set By Caller is not really a security feature, it is useful for clients who call from various locations and phone numbers. It also minimizes telephone charges for these users. When the user's call reaches the Remote Access server, the following events occur:

1. The server first determines if the user name and password are correct. 

2. If they are, the Callback dialog box appears on the user's computer. 

3. The user types the current callback number in the dialog box and waits for the server to return the call.

No Callback

If the user account has not been configured for callback, RAS establishes a connection as soon as the user's name and password is authenticated.

Support for Security Hosts and Switches

RAS supports various kinds of intermediary devices (security hosts and switches) between the Remote Access client and the Remote Access server. These devices include

• Modem-pool switch 

• Security host 

• X.25 network

Figure 7.2 shows a sample configuration incorporating a modem pool and a security host.

 

Figure 7.2 Sample Configuration with Modem Pool and Security Host 

Connecting Through Intermediary Devices

Before connecting to the Remote Access server, a client can have one of two possible dialogs (user input and computer response screens) with each intermediary device:

• Static (a dialog that's always the same and requires no input from the user) 

• Interactive (a dialog that always changes, requiring input from the user)

You must configure the client to work with each intermediary device.

If you require both static and interactive dialogs, you must take two steps:

1. Write a script for the static dialog. (See the next section, "Writing Scripts.") 

2. Activate terminal mode for the interactive dialogs. (See "Activating Terminal Mode on the Client," later in this chapter.)

If you require only one kind of dialog, take only one of the above steps. For example

• If your clients connect through only one intermediary with a static dialog (such as an X.25 network), skip step 2. 

• If your clients connect through a security host with an interactive dialog, skip step 1.

Writing Scripts

Figure 7.3 is an example of when two dialogs are required: Preconnect (a modem-pool switch) and postconnect (a security host). Although preconnect and postconnect dialogs can be either static or interactive, the preconnect dialog is normally static and the postconnect is normally interactive.

With static dialogs, the user selects from the Switch dialog box a user-written custom script. With interactive dialogs, the user selects Terminal from the Switch dialog box.

 

Figure 7.3 Sample Dialogs Between Client and Intermediary Devices 

The SWITCH.INF file included in Windows NT provides a generic script that will probably work with little or no modification when connecting to many PPP servers. Try to connect using the generic script. If that does not work, you can copy—then modify—the generic script to match the logon sequence of the remote computer you want to connect to.

For more information about how to write scripts, see Chapter 10 "Logging on to Remote Computers Using RAS Terminal and Scripts."

Security Hosts

A security host is a third-party authentication device that verifies whether a caller from a remote client is authorized to connect to the Remote Access server. This verification supplements security already supplied by RAS and by Windows NT Server.

The security host sits between the remote user and the RAS Server. The security host generally provides an extra layer of security by requiring a hardware key of some sort in order to provide authentication. Verification that the remote user is in physical possession of the key takes place before access to the RAS Server is granted. This open architecture allows customers to choose from a variety of security hosts to augment the security in RAS.

For example, one kind of security system consists of two hardware devices: the security host and the security card. The security host is installed between the Remote Access server and its modem. The security card is a small unit the size of a credit card, resembling a pocket calculator without keys. The security card displays a different access number every minute. This number is synchronized with the same number calculated in the security host every minute. When connecting, the remote user sends the number on the security card to the host. If the number is correct, the security host connects the remote user with the Remote Access server.

Another kind of security host prompts the remote user to type in a username (which may or may not be the same as the Remote Access username) and a password (which differs from the Remote Access password).

The security host must be configured to allow the RAS server to initialize the modem before the security functions take effect. The RAS server must also be able to directly initialize the modem connected to the security host without security checks from the security host. The security host might interpret the RAS server's attempt to initialize the modem as an attempt to dial out.

You should also set up the host for a fixed bits-per-second (bps) speed rather than autobaud. The fixed bps should equal the value of the MAXCONNECTBPS parameter for the entry you created for this device in the Modem.inf file.

To make third-party security devices work with the Remote Access Service 

1. If the Remote Access server's modem is different from the modem in the security host's section in Modem.inf, the Modem.inf file on the Remote Access server needs to be customized to link the security host to the server's modem. 

2. The remote user must activate Terminal mode to interact with the security host.

Note To use a Security Dynamics security host, you must order two connectors through your Security Dynamics provider to permit initialization of the RAS modem. When you order, specify that you want the dial-out option. The provider will then send you an AND gate and a jumper box. For the ACM/400 security host, you will also receive different software.

Customizing the Remote Access Server's Modem.inf

When you install a security host between the Remote Access server and its modem(s), the server's modem and the security host act together as a new type of modem. The Modem.inf file is shipped with a template for each supported security host paired with a particular modem. (For example, the ACM/400 is paired with an AT&T® Comsphere 3820 modem.)

To use the security host with a different modem, you must modify the Modem.inf file. For details about customizing Modem.inf, see the RAS online Help or see Appendix C, "Understanding Modem.inf."

Activating Terminal Mode on the Client

Remote Access Terminal lets the remote user send the correct access number to the security device. If the number is correct, the user is connected to the Remote Access server.

For information about how to prepare the client for Terminal mode or connect to the Remote Access server, see "Activating Terminal Mode on the Client" in online Help.

Auditing

RAS generates audit trails of remote connections. With this feature, you can audit all Remote Access activity using Windows NT Server Event Viewer to see whether network security is intact. You can also monitor servers and users with RAS Admin. For more information about audits and monitoring, see Chapter 8, "Maintenance and Troubleshooting."