Chapter 10 - Logging On To Remote Computers Using RAS Terminal And Scripts

Article
02/20/2014

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.

The exact logon process for remote computers varies as widely as the remote computers themselves. Remote computers you might log on to include a Windows Remote Access Service (RAS) server giving you access to your corporate network or the Internet, a UNIX computer in a commercial network that gives you an Internet connection, or a proprietary security computer that protects your corporate network from intruders.

Most remote logons require you to provide a username (frequently called login) and a password. This chapter covers how you provide the username, password, and any other information required by remote computers before you log on.

This chapter also describes how to connect to Microsoft, Point-to-Point Protocol (PPP), and Serial Line Internet Protocol (SLIP) servers, when and how to use RAS Terminal, how to create and activate scripts that automate remote logons, and how to debug your scripts. Most of the information regarding Terminal screens, scripts, and Device.log also applies to RAS for Windows for Workgroups version 3.11. However, the PPP, SLIP, and <username> and <password> macro information does not apply.

Connecting to Remote Servers

The three most common remote connections are to

Microsoft RAS servers( including LAN Manager 2.1, Windows for Workgroups 3.11 with server extension, Windows NT 3.1 or later, and Windows 95)
Non-Microsoft PPP servers
SLIP servers

Microsoft RAS Servers

Connecting to a Microsoft RAS server is a simple process that uses the credentials specified when you logged on to Windows NT. If you use Windows NT RAS to connect to computers that are not running Windows NT RAS, the remote computer might require a specific sequence of commands and responses through a terminal window to successfully log you on to the remote system.

If the client is a Windows NT computer and the remote server is any Microsoft RAS server, logon is completely automated using Windows NT security.

PPP Servers

Point-to-point protocol (PPP) is a newer protocol used to negotiate connections between remote computers. Remote server and client software that supports PPP authentication protocols automatically negotiate network and authentication settings. The following steps are necessary to connect to a PPP server:

In Dial-Up Networking application, edit an entry and choose the Server tab. In the Dial-up server type box, select PPP. This is the default selection.
If the server you are calling requires a text-based logon exchange, choose the Script tab and select the Pop up a terminal window option. Now, during the connect sequence, you will see a terminal dialog that allows you to perform the text-based logon exchange.

The PPP standard provides for fully automated authentication using encrypted or clear-text authentication protocols. Some PPP providers do not implement the PPP authentication protocols; instead they require a text-based exchange prior to starting PPP.

To automate the text-based exchange, use a Switch.inf script instead of the clear-text logon dialog. For more information see "Automating Remote Logons Using Switch.inf Scripts," "Activating Switch.inf Scripts," and "Troubleshooting Scripts Using Device.log" later in this chapter.

SLIP Servers

Serial Line Internet Protocol (SLIP) is an older protocol that does not support authentation as part of the protocol. SLIP connections typically rely on text-based logon sessions. Encryption and automatic network parameter negotiations are not supported. The following steps are important when you are connecting to a SLIP server:

In Dial-Up Networking, edit a Phonebook entry and choose the Server tab. In the Dial-up server type box, select SLIP.
If the server you are calling requires a text-based logon exchange, choose the Script tab and select the Pop up a terminal window option. Now, during the connect sequence, you will see a terminal dialog that allows you to perform the text-based logon exchange.

Note Although Windows NT RAS is not a SLIP server, Windows NT RAS clients can connect to SLIP servers.

Using RAS Terminal for Remote Logons

For a PPP or SLIP server, if the remote computer you dial in to requires that you log on with a terminal screen, you must configure the Script settings for that RAS entry to use a RAS Terminal logon. With such a logon, after RAS connects to the remote system, a character-based window displays the logon sequence from the remote computer. You use this window to interact with the remote computer for logging on. Alternatively, you can automate this manual logon as described in the section, "Automating Remote Logons Using Switch.inf Scripts."

Some commercial networks will present a large menu of available services before you log on. On old, established SLIP servers, you might go through an extensive sequence of commands that updates files, collects data about you, or configures your SLIP connection during your logon process. On a new PPP server, you might be prompted for only your username and password before you are given a connection.

Note If the remote computer is a Microsoft RAS server, you do not need to use a terminal logon. Instead, logon is completely automated for you.

To configure a Windows NT RAS entry to use RAS Terminal after dialing

In Dial-Up Networking, select the entry to which you want to connect.
Click More and choose Edit entry and modem settings.
In the Script tab, choose the Pop up a terminal window option.
Click OK and then click Dial.

After you dial and connect to this entry, the After Dial Terminal window appears, and you will see prompts from the remote computer. You then log on to the remote computer using the After Dial Terminal window. After you have completed all interactions with the remote computer, click Done.

If the logon sequence does not vary, you can write a script that automatically passes information to the remote computer during the logon sequence, enabling completely automatic connections.

For more information see "Automating Remote Logons Using Switch.inf Scripts," "Activating Switch.inf Scripts," and "Troubleshooting Scripts Using Device.log" later in this chapter.

Automating Remote Logons Using Switch.inf Scripts

To automate the logon process, you can use the Switch.inf file (or Pad.inf on X.25 networks) instead of the manual RAS Terminal window described in the "Using RAS Terminal for Remote Logons" section.

Automated scripts are especially useful when a constant connection to a remote computer is needed. If the RAS entry is configured to use a script, and if a remote connection fails, RAS automatically redials the number and reestablishes the connection. Scripts also save time if you frequently log on to a remote system and do not want to manually log on each time.

The Switch.inf file provides a generic script that will probably work with little or no modification. Try it first and if it does not work, copy and modify the generic script to match the logon sequence of the remote computer you want to connect to.

Note The script language described in this chapter was also designed to communicate with other devices, including modems. If you are unfamiliar with modem scripts, scripting can be difficult to understand. The following section explains how to create scripts, although you will probably find it easiest to copy, then modify, one of the generic sample scripts.

Creating Scripts for RAS

The Switch.inf file, located in the systemroot\SYSTEM32\RAS folder, is like a set of small batch files (scripts) contained in one file. The Switch.inf file contains a different script for each intermediary device or online service that the RAS user will call.

A Switch.inf script has six elements: a section header, comments, commands, responses, response keywords, and macros.

Section Headers

Section headers divide the Switch.inf file into individual scripts. A section header marks the beginning of a script for a certain remote computer and must not exceed 31 characters. The text of a section header will appear in RAS when you activate the script. The section header is enclosed in square brackets. For example:

[Route 66 Logon]

Comment Lines

Comment lines must have a semicolon (;) in column one and can appear anywhere in the file. Comment lines contain information for those who maintain the Switch.inf file. For example:

; This script was created by MariaG on September 29, 1996

Commands

Each line in a script is a command from your local computer to the remote computer or a response from the remote computer to your local computer. Each command or response is a stream of data or text. For example, the following command sends a username (MariaG) and a carriage return (the macro <cr>) to the remote computer.

COMMAND=MariaG<cr>

The commands and responses must be in the exact order the remote device expects them. Branching statements, such as GOTO or IF, are not supported.

The required sequence of commands and responses for a specific remote device should be in the documentation for the device or, if you are connecting to a commercial service, from the support staff of that service. If the exact sequence is not available, activate the generic script provided with RAS and modify it to match the logon sequence of the remote computer as described in the "Troubleshooting Scripts Using Device.log" section.

The COMMAND= statement can be used in two additional ways:

COMMAND= 
NoResponse

This is the default behavior and causes an approximate two-second delay. This can be useful when the intermediate device requires a delay.

COMMAND= string

Note string is not followed by a carriage return (<cr>). This is useful when a device requires slow input. Instead of receiving the whole command string, the device requires characters to be sent one-by-one.

The following is an example in which the intermediary device is so slow that it is able to receive and process only one character of the command PPP at a time:

COMMAND=P
NoResponse

COMMAND=P
NoResponse

COMMAND=P
NoResponse

Response

A response is sent from the remote device or computer. To write an automatic script, you must know the responses you will receive from the remote device. If a gap of two or more seconds occurs between characters, the received text is sent as a response. This gap is the only cue that a response is over. For more information, see the following section, "Getting Through Large Blocks of Text and Two-Second Gaps."

Response Keywords

The keyword in a response line specifies what to do with the responses you receive from the remote computer:

OK= remote computer response<macro> The script continues to the next line if the response or macro is encountered. LOOP=remote computer response<macro> The script returns to the previous line if the response or macro is encountered. CONNECT=remote computer response <macro> Used at the end of a successful modem script. Not generally useful for the Switch.inf file. ERROR= remote computer response <macro> Causes RAS to display a generic error message if the response is encountered. Useful for notifying the RAS user when the remote computer reports a specific error. ERROR_DIAGNOSTICS= remote computer response <diagnostics> Causes RAS to display the specific cause for an error returned by the device. Not all devices report specific errors. Use ERROR= if your device does not return specific errors that can be identified with Microsoft RAS diagnostics. NoResponse Used when no response will come from the remote device.

RAS on the local computer always expects a response from the remote device and will wait until a response is received unless a NoResponse statement follows the COMMAND= line. If there is no statement for a response following a COMMAND= line, the COMMAND= line will execute and stop the script at that point.

Macros

Macros are enclosed in angle brackets (<>) and perform a variety of special functions:

<cr> Inserts a carriage return. <lf> Inserts a line feed. <match> "string" Reports a match if the string enclosed in quotation marks is found in the device response. Each character in the string is matched according to upper and lower case. For example, <match> "Smith" matches Jane Smith and John Smith III, but not SMITH. <?> Inserts a wildcard character, for example, CO<?><?>2 matches COOL2 or COAT2, but not COOL3. <hXX> (XX are hexadecimal digits) Allows any hexadecimal character to appear in a string—including the zero byte, <h00>. <ignore> Ignores the rest of a response from the macro on. <diagnostics> Passes specific error information from a device to RAS. This enables RAS to display the specific error to RAS users. Otherwise, a nonspecific error message appears.

Authentication Macros

The following macros enable your username and password logon credentials to be automatically passed to the remote computer.

<username> The username entered in the RAS Authentication window is sent to the remote computer. This is not supported with SLIP connections. <password> The password entered in the RAS Authentication window is sent to the remote computer. This is not supported with SLIP connections.

Your logon creditials will fail (and the Retry Authentication dialog box will appear) if both of the following occur

You call into a system that has an intermediary security device. (This situation would generally not apply if you are using RAS to call an Internet provider.)
After the security device has logged you on successfully, you try to log on to a Windows NT RAS server.

The dialog box appears because the RAS Authentication dialog box username and password boxes are used by the two new username and password macros as well as by Windows NT RAS servers.

For example, if the logon information for an intermediary security device that is plugged in between the Windows NT RAS server and its modem is username: "BB318" and password: "34554377", but on the Windows NT RAS server it is username: "BB318" and password: "treehouse", then your logon to the intermediary device will succeed, but your logon to the Windows NT RAS server will fail.

Logon will fail because the security device password of "34554377" is different from the Windows NT domain password. Windows NT will prompt you with the Retry Authentication dialog box to obtain your proper Windows NT logon credentials, in this case the password.

To eliminate the Retry Authentication dialog box

Ask your administrator to make your username and password identical on both systems. (Because this solution defeats the purpose of the security device, it is not recommended.)
Do not use the shared dialog box for the intermediary device logon credentials: Enter the username and password in clear text into the Switch.inf file according to the [Generic login for YourLoginHere] script provided in Switch.inf. To keep your clear-text password confidential you must use Windows NT file system (NTFS) file permissions to prevent other users from accessing this file.

Stepping Through an Example Script

This section describes each part of the generic script provided in the Switch.inf file included with RAS.

Every script must start with a command to the remote computer, followed by one or more response lines. This initial command might be simply to wait for the remote computer to initialize and send its logon banner. The default initial command is to wait two seconds for the logon banner. It would look like this in the Switch.inf file:

COMMAND=

If the response, (the logon banner from the remote computer) is the following:

Welcome to Gibraltar Net. Please enter your login:

then the corresponding response line in the Switch.inf file should be:

OK=<match>"Please enter your login:"

This line indicates that everything is correct if the remote computer sends the string "Please enter your login:". You respond by sending a command with the characters in your username and the carriage return.

COMMAND=MariaG<cr>

If the response from the remote computer is the following:

Please enter your password:

then the corresponding response line in the Switch.inf file should be:

OK=<match>"Please enter your password:"

To send your password, you would send the command:

COMMAND=mUs3naB<cr>

On many PPP computers, this script would automatically log you on.

Automating Log On to SLIP Computers

If your SLIP provider assigns you the same IP address every time you call, you can fully automate your SLIP connection by entering that address in the SLIP TCP/IP Settings dialog box.

If you are assigned a different IP address every time you call, then even though you can automate much of the logon sequence, you must manually enter your IP address in the SLIP terminal window.

Getting Through Large Blocks of Text and Two Second Gaps

If the remote computer has a two-second gap in the data stream reponse to your computer, RAS assumes that the gap is the end of the response. These gaps can occur anywhere—even between words—and can only be detected using Device.log. For more information, see the "Troubleshooting Scripts Using Device.log" section later in this chapter.

If you write a script that seems to fail for no reason, consult Device.log to see if a response ends in the middle of a word. If it does, your script must account for the two- second gap. A simple way to do this is to include the following command:

COMMAND=<cr>

You can skip to the end of large blocks of text that contain multiple gaps by using the LOOP= keyword and by matching text at the end of a block. For example,

COMMAND=<cr>OK=<match>"Enter the service to start:"LOOP=<ignore>

In this example, RAS sends a null command (waits two seconds). RAS then waits for the message "Enter the service to start:". If this is a long block of text, RAS does not find the string, so RAS then moves to the LOOP command. The LOOP command causes RAS to return to the line above, and RAS waits for the words "Enter the service to start:" in the second response. In this manner, you can loop though long blocks of text until you reach the text of the desired prompt.

Commands and Carriage Returns

Usually, you must include <cr>, which indicates a carriage return, at the end of a command. The carriage return causes the remote computer to process the command immediately. If you do not include <cr>, the remote computer might not recognize the command.

In other situations, <cr> cannot be used because the remote computer accepts the command without a carriage return and requires time to process the command. This situation mainly applies when you are sending a series of commands without expecting a response.

Activating Switch.inf Scripts

After you have created a script in Switch.inf, you can configure a RAS entry to execute the script.

To activate a script in Windows NT

In Dial-Up Networking, select the entry to which you want to connect.
Click More and choose Edit entry and modem settings.
In the Script tab, select the Run this script option and select the name of the script. The section header in Switch.inf appears as the name of the script.

You can also edit your script by clicking Edit scripts.
Click OK and then click Dial.

When you dial this entry, the selected script will execute and complete all comunication with the remote device before or after RAS dials the remote host.

Troubleshooting Scripts Using Device.log

Windows NT enables you to log all information passed between RAS, the modem, and the remote device, including errors reported by the remote device. This allows you to find errors that prevent your scripts from working.

The Device.log file is created by enabling logging in the registry. After you enable logging, the Device.log file is in the systemroot\SYSTEM32\RAS folder.

To create the Device.log file

Hang up any connections, and then exit from Dial-Up Networking.
Start the Registry Editor by running the REGEDT32.EXE program.
Go to HKEY_LOCAL_MACHINE, and then access the following key:\SYSTEM\CurrentControlSet\Services\RasMan\Parameters
Change the value of the Logging parameter to 1. When changed, the parameter should look like this:

Logging:REG_DWORD:0x1
Close the Registry Editor.

Logging begins when you restart Remote Access or start the Remote Access Server service (if your computer is receiving calls). You do not need to shutdown and restart Windows NT.

After you dial a number and connect, a script will start. If an error is encountered during script execution, execution halts. You should exit RAS, and then determine the problem by using any text editor to view Device.log. The following topic is an example of an incomplete script that failed when a connection was attempted and the Device.log file that was created.

Note The traces from all calls will be appended to Device.log as long as RAS or the Remote Access Server service are not stopped and restarted. So, if you need to save a Device.log file with useful information for later review or troubleshooting, make a copy of the file, giving the file another name before you restart RAS or the Remote Access Server service.

Example of an Incomplete Switch.inf Script

The following script is incomplete for the service to which the user tried to connect. This script was used with Device.log to discover that the remote computer expected additional commands from the script. See the sample Device.log for the complete output that was generated.

[Gibraltar Net Login for MariaG]; FIRST COMMAND TO INITIALIZE REMOTE COMPUTERCOMMAND=; Skip to login prompt. That is, loop through blocks of text ; separated by 2-second gaps until the login prompt is encountered.OK=<match>"Login:"LOOP=<ignore>; Provide username to remote computerCOMMAND=MariaG<cr>; Since no 2-second gap is present, immediately match "Password:"OK=<match>"Password:"; Provide password to remote computerCOMMAND=mUs3naB

Sample Device.log

This is the Device.log file created by using the sample generic script. Note that Device.log comment lines in all uppercase letters are writer comments added after the file was created to help you understand the contents of the file.

Remote Access Service Device Log 08/23/1996 13:52:21---------------------------------------------------------------; THIS SECTION IS THE COMMUNICATION BETWEEN RAS AND THE MODEMPort:COM1 Command to Device:AT&F&C1&D2 W2\G0\J0\V1 S0=0 S2=128 S7=55
Port:COM1 Echo from Device :AT&F&C1&D2 W2\G0\J0\V1 S0=0 S2=128 S7=55
Port:COM1 Response from Device:OKPort:COM1 Command to Device:AT\3\N7%C0M1
Port:COM1 Echo from Device :AT\Q3\N7%C0M1
Port:COM1 Response from Device:OK

; COMMAND TO DIAL REMOTE COMPUTER AND SUCCESSFUL CONNECTION
Port:COM1 Command to Device:ATDT1 206 555 5500
Port:COM1 Echo from Device :ATDT1 206 555 5500
Port:COM1 Response from Device:CONNECT 14400/RELPort:COM1 Connect BPS:19200Port:COM1 Carrier BPS:14400
; INITIAL NULL COMMAND SENT TO DEVICE
Port:COM1 Command to Device:Port:COM1 Response from Device:_[2J_[HWelcome to Gibraltar Net, a service of: Trey Computing, Inc.Problems logging in? Call us at 555-5500 between 8:00am and 8:00pm Mon-Sat.NOTE: Your software must support VT100 (or higher) terminal emulation! Port:COM1 Response from Device:P
; THE LINE ABOVE INDICATES A TWO-SECOND GAP IN THE MIDDLE ; OF THE WORD "PLEASE" IF YOUR SCRIPT FAILED AND DEVICE.LOG ENDED ; AFTER THE RESPONSE ABOVE, YOU WOULD ACCOUNT FOR THIS ; TWO-SECOND GAP IN YOUR SCRIPT BY USING A NULL COMMAND= LINE OR THE ; OK=response AND LOOP=<match> COMBINATION.
Port:COM1 Response from Device:lease turn OFF your Caps Lock if it is on now.Please enter your login name and password at the prompts below. - Log in as "guest" to take a look around the system. - Log in as "new" to create an account for yourself.Login: 
; SEND YOUR USERNAME AS A COMMAND
Port:COM1 Command to Device:MariaG
Port:COM1 Echo from Device :MariaG
Port:COM1 Response from Device:Password:
; SEND YOUR PASSWORD AS A COMMAND
Port:COM1 Command to Device: mUs3naB
Port:COM1 Echo from Device : mUs3naB

; THE LOGIN SEQUENCE CONTINUES ON THE REMOTE COMPUTER
; BUT THE SCRIPT DOES NOT CONTINUE FROM HERE. 
; THE AUTOMATED LOG IN WOULD FAIL AT THIS POINT.
Port:COM1 Response from Device:

This script would be complete for many remote computers, but the remote computer sent more responses and expected a command to start a service. To complete the script you must know the remainder of the responses from the remote computer. If you logged on manually using RAS Terminal and found the remainder of the logon sequence looked like this:

Gibraltar Net offers you several network services:Service
----------------------------------------------------------------------
SHellUPloadDOwnloadPAsswordPPPSLIPPlease enter a service:

you would complete the script with these lines:

COMMAND=<cr>
OK=<match>"Please enter a service:"
LOOP=<ignore>

If you added the lines above to your script, restarted RAS and redialed, you would successfully connect.

If the generic script in RAS does not work, these guidelines should help you modify the generic script to work for your connections. First copy the generic script to the end of Switch.ing, then modify the copy to work with your connections.

Using Scripts with Other Microsoft RAS Clients

Microsoft RAS version 1.0 (which runs on LAN Manager) cannot invoke RAS Terminal or use scripts in .inf files.

Microsoft RAS version 1.1a (which runs on LAN Manager) supports Pad.inf only. Note that the syntax used in the Pad.inf file differs slightly from subsequent versions of Microsoft RAS.

Microsoft RAS for Windows for Workgroups version 3.11 and Windows NT version 3.1 or later support RAS Terminal and scripts in Switch.inf and Pad.inf.