Setting Up RADIUS Authentication

This chapter discusses how to configure the RADIUS server to authenticate MAX clients. This chapter contains:

Overview of RADIUS authentication

Overview of RADIUS authentication attributes

Specifying a user name

Specifying a password

Specifying the MAX unit's IP address

Setting up the MAX for callback

Specifying an access protocol for incoming calls

Requesting an access protocol for outgoing calls

Setting up security-card authentication

Setting up CLID authentication

Setting up called-number authentication

Putting it all together

This chapter discusses authentication only. It does not discuss how to configure RADIUS attributes to restrict user access to MAX features and services. For information on specifying the MAX features users can access, see Chapter 4, Setting Up WAN Connections in RADIUS.

Overview of RADIUS authentication

By default, when you require a profile for authentication, the MAX always checks for a Connection profile. If it cannot find one, it checks for a Password profile. If neither a Connection profile nor a Password profile exists, the MAX checks for a remote RADIUS, TACACS, or TACACS+ profile.

However, you can change this default by setting Local Profile First=No in the Ethernet > Mod Config > Auth menu. When Local Profile First=No, the MAX first looks for a remote profile. If it cannot find one, the MAX looks for a local Connection profile. If none exists, the MAX looks for a Password profile.

This section assumes that the MAX looks for a local profile first. For an incoming call, the MAX carries out these steps:

1. Before the MAX answers a call, it checks its Answer profile to see whether either CLID authentication or called-number authentication is required.

   When CLID authentication is required, the caller's phone number must match a phone number specified in a local Connection profile or RADIUS user profile.When called-
   number authentication is required, the number called must match a phone number is a local Connection profile or RADIUS user profile. Called-Number authentication is also known as Dialed Number Information Service (DNIS) authentication.

2. If CLID authentication is required (Id Auth=Require in the Answer profile) or if called- number authentication is required (Id Auth=Called Require in the Answer profile), the MAX first looks for a matching phone number in a local Connection profile.

   If one does not exist, it then looks for a matching phone number in a RADIUS user profile. If it cannot find the correct phone number, the MAX hangs up.

3. If CLID or called-number authentication is not required (Id Auth=Prefer, Fallback, Ignore, or Called Prefer in the Answer profile), or if the MAX finds a matching phone number in a local Connection profile or RADIUS user profile, it answers the call.

4. The MAX checks its other Answer profile settings.

5. If the Answer profile specifies the type of link encapsulation the call uses, the MAX continues checking Answer profile parameters.

   If the Answer profile does not enable the type of link encapsulation the call uses, the MAX drops the call.

6. The MAX checks the value of the Profile Reqd parameter in the Answer profile.

   If Profile Reqd=Yes, the MAX must find a Connection profile, Password profile, RADIUS user profile, TACACS profile, or TACACS+ profile to authenticate the call.

7. If a profile is required, the MAX checks to see whether the profile must contain a matching user name and password.

   These Answer profile settings require a matching name and password as a condition of authentication:

   • Recv Auth=PAP, CHAP, MS-CHAP, or Either (for PPP, MP, and MP+ calls)

   • Password Reqd=Yes (for Combinet calls)

8. If name and password authentication is required, the MAX attempts to match the caller's name and password to a local Connection profile.

   If authentication succeeds using a local Connection profile, the MAX uses the parameters specified in the profile to build the connection.

9. If it cannot find a matching Connection profile, the MAX looks for a Password profile.

   If the MAX finds a Password profile, it uses the name and password in the Password profile and builds the connection using the settings in the Answer profile. The Password profile applies only to ARA, PPP, MP, MP+, and terminal server calls.

10. If it cannot find a matching Password profile, the MAX looks for a RADIUS, TACACS, or TACACS+ profile containing a matching name and password.

    If authentication succeeds using a RADIUS user profile, the MAX uses the specified RADIUS attributes to build the connection. The MAX can then forward the call to its bridge/router or other destination. For example, the MAX might forward a terminal server call to a Telnet or TCP host.

    If authentication succeeds using a TACACS or TACACS+ profile, the MAX must make a request to the server for information on the resources and services the user can access.

11. If name and password authentication is not required (Recv Auth=None or Password Reqd=No in the Answer profile), the MAX can match IP-routed PPP calls using the IP address specified by the Connection profile.

12. If the Answer profile does not require a profile (Profile Reqd=No), the MAX uses Answer profile parameters to build the connection.

Overview of RADIUS authentication attributes

Table 3-1. RADIUS authentication attributes

service line channel

Specifying a user name

Table 3-2. User name attributes

Because the MAX uses the first matching name for an incoming caller, you must not specify a duplicate user name in any RADIUS user profile.

Setting the User-Name attribute

Using the caller's name

Emma Password="pwd", Ascend-PW-Expiration="Jan 30 1997"

Using the caller's MAC address (for Combinet calls)

Consider this first line in a user profile:

000145CFCF01 Password="m2dan", User-Service=Framed-User

The user name is the MAC address 000145CFCF01.

Note that Combinet bridging cannot use PAP, CHAP, or MS-CHAP authentication. The MAX must use the caller's MAC address and password to authenticate calls.

Using the keyword Default

For example, this first line in a profile enables a terminal server user to log in using his or her UNIX account name or password:

Default Password="UNIX"

Using the incoming phone number (for CLID authentication)

For complete information on configuring CLID authentication, see Setting up CLID authentication.

Using the called number (for called-number authentication)

For complete information on called-number authentication, see Setting up called-number authentication.

Using a keyword representing a pseudo-user profile

Table 3-3. Pseudo-user references

Setting the Ascend-Authen-Alias attribute

This example uses the Ascend-Authen-Alias attribute in an outgoing profile:

Homer-Out Password="Ascend", User-Service=Dialout-Framed-User

        User-Name="Homer",

        Ascend-Authen-Alias="myMAXcallingU",

        Ascend-Send-Auth=Send-Auth-PAP,

        Ascend-Send-Secret="passwrd1",

        Ascend-Dial-Number="31",

        Framed-Protocol=PPP,

        Framed-Address=10.0.100.1,

        Framed-Netmask=255.255.255.0,

        Ascend-Metric=2,

        Framed-Routing=None,

        Framed-Route="10.5.0.0/24 10.0.100.1 1",

        Ascend-Idle-Limit=30

Specifying a password

Table 3-4. Password attributes

Setting the Password attribute

Table 3-5. Password specifications

Setting the Ascend-Send-Passwd and Ascend-Send-Secret attributes

This example uses the Ascend-Send-Secret attribute:

Homer-Out Password="Ascend", User-Service=Dialout-Framed-User

        User-Name="Homer",

        Ascend-Authen-Alias="myMAXcallingU",

        Ascend-Send-Auth=Send-Auth-PAP,

        Ascend-Send-Secret="passwrd1",

        Ascend-Dial-Number="31",

        Framed-Protocol=PPP,

        Framed-Address=10.0.100.1,

        Framed-Netmask=255.255.255.0,

        Ascend-Metric=2,

        Framed-Routing=None,

        Framed-Route="10.5.0.0/24 10.0.100.1 1",

        Ascend-Idle-Limit=30

For more information on configuring an ARA link, see Setting up an ARA connection.

Configuring password expiration

• A RADIUS server authenticates the expired password.

• The expired password is not a reserved RADIUS password.

  ACE, SAFEWORD, and UNIX are reserved RADIUS passwords. Although a programmer with access to the daemon source code can change these passwords, they are the default reserved passwords, and typically remain so.

• The password belongs to a user in a terminal server session.

  Users who dial in as an IP router, IP bridge, host-to-bridge, or bridge cannot replace an expired password.

Table 3-6. Password expiration attributes

To set up password expiration, follow these steps:

1. On the first line of a RADIUS user profile, specify the Ascend-PW-Expiration attribute.

   Ascend-PW-Expiration specifies an expiration date for a user's password in a user profile. Specify a date in the format month day year.

   • For the month specification, enter the first three letters of the month in which you want the password to expire. Or, you can specify the entire name of the month. The month must begin with a capital letter.

   • For the day specification, enter one or more digits indicating a valid day of the month. The values 2, 02, 002, and 0021 are all valid, but 32 is not.

   • For the year specification, enter a four-digit year. The year must start with the
     number 19.

   • Separate each part of the date specification using one or more spaces, tabs, or
     commas.

   You must specify Ascend-PW-Expiration when you first create a user and it must appear on the first line of the user profile. If it appears after the first line, RADIUS does not check the expiration date and could accept an expired password. Your specification might look like this one:

   Emma Password="pwd", Ascend-PW-Expiration="Jan 1, 1997"
   

   When the MAX makes an authentication request, the RADIUS server checks the current date against the value of Ascend-PW-Expiration. If the date of the authentication request is the same date or a later date than the value of Ascend-PW-Expiration, the user receives a message saying that the password has expired.

2. On any line other than the first line of the user profile, set the Ascend-PW-Lifetime attribute.

   Ascend-PW-Lifetime specifies the number of days that a password is valid. Your specification might look like this one:

   Emma Password="pwd", Ascend-PW-Expiration="Jan 1, 1997"
   

             Ascend-PW-Lifetime=30.
   

             ...
   

   Ascend-PW-Lifetime applies only to the process of renewing an expired password. When the user wants to renew the password, the MAX adds the value you specify for Ascend-PW-Lifetime to the current date and updates the user profile.

For example, suppose that today's date is March 1, 1997 and these lines appear in a user profile:

Emma Password="pwd", Ascend-PW-Expiration="Jan 1, 1997"

          Ascend-PW-Lifetime=30,

          ...

If the password has not expired, the value of Ascend-PW-Lifetime is irrelevant. For example, suppose that today's date is January 1, 1997 and these lines appear in a user profile:

Emma Password="pwd", Ascend-PW-Expiration="Jan 15, 1997"

          Ascend-PW-Lifetime=30

          ...

If Ascend-PW-Lifetime is absent, the value of Lifetime-In-Days determines the password duration. The Lifetime-In-Days value in the RADIUS dictionary is the default value for
Ascend-PW-Lifetime. By default, Lifetime-In-Days is 0 (zero). This value means that passwords do not expire.

Changing a non-expired password

1. Enable password expiration in the user profile.

   When you change a non-expired password, the MAX uses the same mechanism that enables you to enter a new password when an older one has expired. To enable password expiration, follow the instructions in Configuring password expiration.

2. At the terminal server prompt, enter this command:

   ascend% password
   

   This text displays:

   ascend% password 
   Enter old password: 
   Enter new password: 
   Re-type new password:
   

3. At the Enter old password prompt, specify the current password.

4. At the Enter new password and Re-type new password prompts, enter the new password.

Password Updated

Password NOT Changed

Changing an expired password

1. The MAX informs the user that the authentication failed because the password has expired.

2. The MAX prompts the user for a new password.

   If the new password is null or matches the old password, the MAX prompts the user again for a new password.

   If the new password is valid, the MAX asks the user to re-enter it for confirmation. If the two entries do not match, the MAX prompts again for a new password.

3. After receiving a valid confirmation of the new password, the MAX contacts the RADIUS server for acceptance of the new password.

   If the RADIUS server accepts the new password, it reports the successful change.

   If the RADIUS server rejects the new password, it informs the user and prompts again for a new password. The RADIUS server can reject the password change for any of these reasons:

   • You did not start the RADIUS daemon with the -p option.

   • The file system containing the RADIUS users file is full and the system cannot update the entry.

   • The RADIUS users file is locked against writing.

   • The RADIUS daemon is running in DBM mode.
     When the daemon is running in DBM mode, a user can successfully change an expired password, but cannot gain access to the network immediately. Access using the new password can take place only after you rebuild the RADIUS database with the modified users file containing the new password.

Specifying the MAX unit's IP address

Table 3-7. NAS-Identifier attribute

NAS-Identifier example

However, you might want to specify it if multiple MAX units use a single RADIUS server, and you want to specify the MAX to which a particular user can connect. In this case, the NAS-Identifier value in the Access-Request packet and the NAS-Identifier value in the user profile must match for the RADIUS server to authenticate the connection. The NAS-Identifier value must appear in the first line of the user profile.

Suppose that the user Emma is allowed to dial into the MAX at IP address 200.65.212.46. The first line of the user profile might look like this one:

Emma Password="pwd", NAS-Identifier=200.65.212.46

Setting up the MAX for callback

Ascend callback security

To set up the MAX for callback, use the attributes listed in Table 3-8.

Table 3-8. Callback attributes

Attribute	Possible values
Ascend-Callback (246)	Callback-No (0) Callback-Yes (1) The default value is Callback-No.
Ascend-Dial-Number (227)	A telephone number containing up to 21 characters, limited to the following: 1234567890()[]!z-*#| The MAX sends only the numeric characters to place a call. The default value is null.
Ascend-Send-Passwd (232)	Text string containing up to 20 characters. The default value is null.
Ascend-Send-Secret (214)	Text string containing up to 20 characters. The default value is null.

To set up the MAX for callback, follow these steps:

1. Set Ascend-Callback=Callback-Yes.

2. Set Ascend-Dial-Number to the phone number of the remote device.

   The MAX can also use the CLID in order to reach the remote end of the connection, if the CLID is available.

3. Set Ascend-Send-Secret or Ascend-Send-Passwd.

   Both of these attributes specify the password that the MAX sends to the remote end of a connection on outgoing calls. If the value you specify for Ascend-Send-Secret or Ascend-Send-Password does not match the remote end's value for Ascend-Receive-Secret (in a RADIUS user profile) or Recv PW (in a Connection profile), the remote system rejects the call.

   Use Ascend-Send-Passwd only if your version of the MAX does not support Ascend-Send-Secret.

1. The MAX hangs up after receiving an incoming call that matches the one specified in the RADIUS user profile.

2. The MAX then calls back the device at the remote end of the link using these values:

   • The number specified by the Ascend-Dial-Number attribute or the CLID

   • The password specified by Ascend-Send-Passwd or Ascend-Send-Secret

Callback example

Emma Password="pwd"

          Ascend-Callback=Callback-Yes,

          Ascend-Dial-Number=555-1213,

     Ascend-Send-Secret="mysecret",

          ...

Microsoft's Callback Control Protocol (CBCP)

CBCP also offers features not available with the standard callback defined in RFC 1570. The client side supports a configurable time delay to allow users to initialize modems or enable supportive software before the MAX calls the client. You can configure the MAX with a phone number to use for the callback, or you can configure it to allow the client to specify the phone number used for the callback.

Currently, Microsoft's Windows NT 4.0 and Windows 95 software support client-side authentication using CBCP. The MAX now supports a CBCP central-site solution.

Ascend's implementation of CBCP

The MAX employs the user name and password to link a caller with a specific RADIUS User profile. Configured CBCP parameters in that User profile specify variables for the callback. If, at any point, the client and the MAX disagree about any CBCP variables, the MAX drops the connection.

Both sides of the connection must agree on whether the callback phone number is supplied by the client or by the MAX. The trunk group parameter Ascend-CBCP-Trunk-Group, configured on the MAX, supplies a trunk group that is prepended to phone numbers supplied by the client.

Table 3-9

Table 3-9. Microsoft's CBCP parameters for RADIUS

Attribute	Possible values
Ascend-CBCP-Enable (112)	CBCP-Enabled (0) CBCP-Not-Enabled (1)
Ascend-CBCP-Mode (113)
Ascend-CBCP-Trunk-Group (115)

lists Microsoft's callback parameters on the MAX.

Negotiation of CBCP

1. Caller connects to MAX.

2. LCP negotiations begin.

   Caller and MAX must agree to use CBCP. Otherwise, the MAX terminates the connection.

3. After successful LCP negotiation, both sides have acknowledged that CBCP will be used.

4. Caller authenticates itself to the MAX. If authentication fails, the MAX terminates the connection.

5. CBCP begins if the MAX verifies that the profile has Ascend-CBCP-Mode set.

6. The MAX sends a request to determine if a callback is to occur. The caller's configuration must match the Ascend-CBCP-Mode value on the MAX.

   The client also supplies to the MAX the number of seconds it should delay before initiating the callback, and, if applicable, the phone number.

7. If both sides agree on which phone number the MAX will dial, the client clears the connection.

8. The MAX delays the callback on the basis of the previous negotiation.

9. The MAX dials the client, by applying information from the same profile used in previous negotiation.

1. Open the Ethernet > Answer > PPP Options menu.

2. Set CBCP Enable = Yes.

3. Find the user profile you want to add callback.

4. Set Ascend-CBCP-Mode to the callback mode to be offered the caller.

5. If the caller is supplying the phone number, set Ascend-CBCP-Trunk Group to the value (4 through 9) that the MAX prepends to the number when calling back.

6. Save your changes.

Specifying an access protocol for incoming calls

Requiring PAP, CHAP, or MS-CHAP for PPP, MP, and MP+ calls

Table 3-10. Recv Auth values

If the incoming PPP call does not include a source IP address, the MAX requires PAP, CHAP, or MS-CHAP authentication. PAP, CHAP, and MS-CHAP authentication is not available for Combinet, ARA, modem, V.110, V.120 calls, or X.75 calls.

For PAP, CHAP, and MS-CHAP authentication, the calling unit and the MAX share a different secret with the RADIUS server:

• The calling unit's secret is called the remote secret. The MAX does not know the value of this secret.

• The MAX unit's secret is called the NAS secret (because the MAX is an NAS). The calling unit does not know the value of this secret.

1. The calling unit sends the remote secret in the clear to the MAX.

2. The MAX encrypts the remote secret using the NAS secret.

3. The RADIUS server decrypts the remote secret using the NAS secret.

4. The RADIUS server validates the remote secret, or passes the clear copy of the remote secret to a UNIX or other password validation system.

1. The MAX sends a random, 128-bit challenge to the calling unit.

2. The calling unit calculates an MD5 digest using the remote secret, the challenge, and the PPP packet ID.

3. The calling unit sends the MD5 digest, the challenge, and the PPP packet ID (but not the remote secret) to the MAX.

   The MAX never has the remote secret.

4. The MAX forwards the digest, along with the original challenge and PPP packet ID to RADIUS.

   No encryption is necessary, because MD5 creates a one-way code that cannot be decoded. In addition, RADIUS cannot extract the remote secret. Therefore, it cannot provide a password to a UNIX password system. For this reason, CHAP and UNIX authentication cannot work together.

5. The RADIUS server looks up the remote secret from a local database, and calculates an MD5 digest using the local version of the remote secret, along with the challenge and the PPP packet ID it received from the MAX.

6. The RADIUS server compares the calculated MD5 digest with the digest it received from the MAX.

   If the digests are the same, the remote secrets used by the calling unit and the RADIUS server are the same, and the MAX authenticates the call.

How PAP-TOKEN works

For information on setting up PAP-TOKEN authentication, see Configuring PAP-TOKEN authentication.

How CACHE-TOKEN works

For information on setting up CACHE-TOKEN authentication, see Configuring CACHE-TOKEN authentication.

How PAP-TOKEN-CHAP works

Using different access methods with local authentication

Table 3-11. Access methods and local authentication

Requesting an access protocol for outgoing calls

Table 3-12. Authentication protocol attributes

To specify an authentication protocol for an outgoing PPP or MP+ call, follow these steps:

1. Set the Ascend-Send-Auth attribute.

   The Ascend-Send-Auth attribute specifies the authentication protocol that the MAX requests when initiating a connection using PPP or MP+ encapsulation. The answering side of the connection determines which authentication protocol, if any, the connection uses. You can set Ascend-Send-Auth to one of these values:

   • Send-Auth-None (0) specifies that the MAX does not request an authentication
     protocol for outgoing calls. This setting is the default.

   • Send-Auth-PAP (1) specifies that the MAX requests Password Authentication
     Protocol (PAP). If you choose this setting, the MAX requests PAP authentication, but uses CHAP authentication if the called unit requires CHAP. Choose this setting for non-token card authentication if you want to send your password unencrypted.
     For details on how PAP operates, see How PAP works

     Send-Auth-CHAP (2) specifies that the MAX requests Challenge Handshake Authentication Protocol (CHAP). If you choose this setting, the MAX does not bring up the connection using PAP. Choose this setting for non-token card authentication if you do not wish to send your password unencrypted-that is, if you do not wish to use PAP authentication.

     For details on how CHAP operates, see How CHAP and MS-CHAP work.

2. If you request PAP or CHAP authentication, you must also specify a password using Ascend-Send-Secret or Ascend-Send-Passwd.

   Both of these attributes specify the password that the MAX sends to the remote end of a connection on outgoing calls. If the value you specify for Ascend-Send-Secret or Ascend-Send-Password does not match the remote end's value for Ascend-Receive-Secret (in a RADIUS user profile) or Recv PW (in a Connection profile), the remote system rejects the call.

   Use Ascend-Send-Passwd only if your version of the MAX does not support Ascend-Send-Secret.

CHAP example

Homer-Out Password="Ascend", User-Service=Dialout-Framed-User

        User-Name="Homer",

        Ascend-Send-Auth=Send-Auth-CHAP,

        Ascend-Send-Secret="passwrd1",

        Ascend-Dial-Number="31",

        Framed-Protocol=PPP,

        Framed-Address=10.0.100.1,

        Framed-Netmask=255.255.255.0,

        Ascend-Metric=2,

        Framed-Routing=None,

        Framed-Route="10.5.0.0/24 10.0.100.1 1",

        Ascend-Idle-Limit=30

Setting up security-card authentication

• Introducing security-card authentication

• Configuring the MAX to recognize the authentication server

• Configuring the MAX to recognize the APP Server utility on each workstation

• Configuring PAP-TOKEN authentication

• Configuring CACHE-TOKEN authentication

• Configuring PAP-TOKEN-CHAP authentication

Introducing security-card authentication

Figure 3-1 illustrates an environment that includes an Ascend Pipeline as the calling unit, an NAS (the MAX), a RADIUS server, and an external authentication server.

Figure 3-1. Using an external authentication server

When you use security-card authentication, these events take place:

1. A user attempts to open a connection to the MAX, sending his or her user name.

   This user is a client of the MAX. The user can be in terminal server mode or use the APP Server utility during the authentication phase. When authentication is complete, the user can switch to PPP mode.

2. The MAX determines that it must use a RADIUS user profile to authenticate the user.

3. The MAX sends the user connection request to the RADIUS server in an Access-Request packet.

   The MAX is a client of the RADIUS server.

4. The RADIUS server forwards the connection request to the ACE or SafeWord client residing on the same system as RADIUS.

5. The ACE client forwards the information to the ACE/Server authentication server, and the SafeWord client forwards the information to the SafeWord authentication server.

   In these cases, the RADIUS server is a client of the authentication server.

6. The authentication server sends an Access-Challenge packet back through the RADIUS server and the MAX to the user dialing in.

7. The user sees the challenge message and obtains the current password from his or her security card.

   If the authentication server is an ACE/Server, the user has a SecurID token card that displays a randomly generated access code. This code changes every 60 seconds.

   If the authentication server is a SafeWord server, the user can have one of these types of token cards:

   • ActivCard

   • CryptoCard

   • DES Gold

   • DES Silver

   • SafeWord SofToken

   • SafeWord MultiSync

   • DigiPass

   • SecureNet Key

   • WatchWord

8. The user enters the current password he or she obtained from the security card in response to the challenge message.

   This password travels back through the NAS and the RADIUS server to the authentication server.

9. The authentication server sends a response to the RADIUS server, specifying whether the user has entered the proper user name and password.

   Note: If the caller is using AppleTalk Remote Access (ARA) there must be no password, and the username must be "SecurID." Once the user makes the initial connection, SecurID authentication begins with a pop-up screen on the Macintosh. At this point, the user must enter the "User ID" and "Passcode". If the user enters incorrect values, he or she gets two more tries to authenticate before the connection fails.

   If the user enters an incorrect password, the ACE/Server or SafeWord server returns another challenge and the user can again attempt to enter the correct password. The server sends up to three challenges. After three incorrect entries, the MAX terminates the call.

10. The RADIUS server sends an authentication response to the MAX.

    If authentication is unsuccessful, the MAX receives an Access-Reject packet. If authentication is successful, the MAX receives an Access-Accept packet containing a list of attributes from the user profile in the RADIUS server's database. The MAX then establishes network access for the caller.

Table 3-13. Authentication server parameters

All of the parameters apply only to outgoing calls using security-card authentication. For the parameters to work, you must meet these conditions:

• The MAX must request PAP-TOKEN authentication. For details, see Configuring PAP-TOKEN authentication.

• You must have the APP Server utility running on a UNIX or Windows workstation on the local network.

  Ascend Password Protocol (APP) is a UDP protocol from Ascend. For details on installing the APP Server utility, see the MAX Security Supplement.

1. Open the Ethernet menu.

2. Open the Mod Config menu.

3. Open the DNS menu.

4. For the Password Host parameter, specify the IP address of the authentication server on the remote network.

5. Return to the Mod Config menu and open the Auth menu.

6. For the Password Port parameter, specify the User Datagram Protocol (UDP) port number that the server indicated by Password Host is monitoring.

   Valid port numbers range from 0 to 65535. The default value is 0 (zero). This setting indicates that the authentication server is not monitoring a UDP port.

7. Set Password Server=Yes.

   This setting specifies that callers use security-card authentication rather than terminal server authentication.

8. Save your changes.

Table 3-14. APP Server parameters

Ascend Password Protocol (APP) is a UDP protocol whose default port is 7001. The communication between the MAX and the host running the APP Server may be unicast (when both the MAX and the host have an IP address) or broadcast (when the host may not have an IP address)

To setup the MAX to communicate with the APP Server utility, follow these steps:

1. Open the Ethernet menu.

2. Open the Mod Config menu.

3. Open the Auth menu.

4. Set APP Server=Yes.

   This setting enables the MAX to communicate password challenges to the host running the APP Server utility.

5. Specify the IP address of the host running the APP Server utility.

   For example, you must enter this setting:

   APP Host=10.65.212.1
   

   If the host obtains its address at boot time from a BOOTP or DHCP server, or if it has no IP address, you can specify the IP broadcast address (255.255.255.255).

6. Specify the UDP port to use for communicating with the host running the APP Server.

   7001 is the default UDP port for the APP Server. If you change this number, you must specify the new UDP port number in the APP Server utility (DOS), the WIN.INI file (Windows), or the /etc/services file (UNIX). The MAX and the host running the APP Server utility must agree about the UDP port number.

7. Save your changes.

Table 3-15. PAP-TOKEN attributes

To set up PAP-TOKEN authentication, follow these steps:

1. Set the User-Name attribute to the remote bridge/router's system name.

2. Set the Password attribute to SAFEWORD or ACE.

   You can request validation from the Enigma Logic SafeWord dynamic password library by setting the Password attribute to SAFEWORD, as shown in this first line of a user profile:

   Mike Password="SAFEWORD"
   

   You can request validation from the Security Dynamics ACE dynamic password library by setting the Password attribute to ACE, as shown in this first line of a user profile:

   Connor Password="ACE"
   

Figure 3-2. ACE/Server configuration

At the remote end, the Appserv process constantly monitors for authentication requests. When it receives one from the Pipeline 50, it sends the request to the MAX. The MAX tries to match the caller's Name to the value of the Station parameter in a Connection profile. If the MAX does not find a match, it forwards the request to RADIUS. RADIUS then checks its profiles. If it finds one whose password is set to ACE, it requests that Appserv prompt the Pipeline 50 for a passcode.

To modify an existing profile for ACE/Server authentication, simply change the password to ACE, as in this example:

Connor Password="ACE"

       User-Service=Framed-User,

       Framed-Protocol=MPP,

       Framed-Address=200.72.138.1,

       Framed-Netmask=255.255.255.0,

       Ascend-Idle-Limit=300,

       Framed-Routing=None

Table 3-16. CACHE-TOKEN attributes

To set up CACHE-TOKEN authentication, follow these steps:

1. Set the User-Name attribute to the remote bridge/router's system name.

2. Set the Password attribute to SAFEWORD or ACE.

   You can request validation from the Enigma Logic SafeWord dynamic password library by setting the Password attribute to SAFEWORD, as shown in this first line of a user profile:

   Mike Password="SAFEWORD"
   

   You can request validation from the Security Dynamics ACE dynamic password library by setting the Password attribute to ACE, as shown in this first line of a user profile:

   Connor Password="ACE"
   

3. On the first line of the user profile, set the Ascend-Token-Expiry attribute to a nonzero value.

   The Ascend-Token-Expiry attribute specifies the lifetime in minutes of a cached token. When the cached token is still alive, CHAP authenticates subsequent CACHE-TOKEN access requests from the same user without the use of a hand-held security card. When the cached token has expired, the ACE or SAFEWORD server authenticates CACHE-TOKEN access requests.

   If the Ascend-Token-Expiry is not specified in the user profile or is set to 0 (zero), the MAX rejects subsequent calls.

4. On the first line of the user profile, set the Ascend-Token-Idle attribute (optional).

   The Ascend-Token-Idle attribute specifies the maximum length of time in minutes a cached token can remain alive between authentications. This attribute is useful for enforcing authentication when a connection comes up again after an idle period. If you do not specify this attribute, the cached token remains alive until the value of the Ascend-Token-Expiry attribute causes it to expire. Typically, the value of Ascend-Token-Idle is lower than the value of Ascend-Token-Expiry.

5. On the first line of the user profile, set the Ascend-Token-Immediate attribute.

   The Ascend-Token-Immediate attribute establishes how RADIUS treats the password it receives from a login user when the user profile specifies a hand-held security card server. Use this attribute in an ACE or SAFEWORD user profile that contains the setting User-Service=Login-User.

   Ascend-Token-Immediate can have one of the following values:

   • Tok-Imm-No (0) indicates that RADIUS ignores the password. Choose this value for a security server that requires that a user enter a challenge using a security card before the security server derives a password.

   • Tok-Imm-Yes (1) specifies that RADIUS sends the password to the security server for authentication.

6. On any line of the profile after the first one, set the Ascend-Receive-Secret attribute to the same password as the Send PW parameter in the Connection profile that places the incoming call.

   The RADIUS server uses this value to authenticate incoming calls from a user while his or her token is cached and alive. The cached token resides on the MAX during the initial security-card authentication process.

7. When you start the radius daemon, specify the -c option to enable cache-token
   authentication.

John    Password="SAFEWORD", Ascend-Token-Expiry=90, Ascend-
Token-Idle=80, Ascend-Token-Immediate=Tok-Imm-Yes

            Ascend-Receive-Secret="shared-secret",

            User-Service=Framed-User,

            Framed-Protocol=MPP, 

            Framed-Address=200.0.5.1,

            Framed-Netmask=255.255.255.0

Table 3-17. PAP-TOKEN-CHAP attributes

To set up PAP-TOKEN-CHAP authentication, follow these steps:

1. Set the User-Name attribute to the remote bridge/router's system name.

2. Set the Password attribute to SAFEWORD or ACE.

   You can request validation from the Enigma Logic SafeWord dynamic password library by setting the Password attribute to SAFEWORD, as shown in this first line of a user profile:

   Mike Password="SAFEWORD"
   

   You can request validation from the Security Dynamics ACE dynamic password library by setting the Password attribute to ACE, as shown in this first line of a user profile:

   Connor Password="ACE"
   

3. Set Ascend-Receive-Secret to the value of the Aux Send PW parameter in the Connection profile the remote end uses to dial the call.

   The RADIUS server sends this value to your MAX in order to verify an encrypted password.

   In PAP-TOKEN-CHAP authentication, you need to verify only the initial connection using a hand-held security card. CHAP verifies any additional channels. That is, whenever the MAX adds channels to a PPP or MP+ call using PAP-TOKEN-CHAP, the calling unit sends the encrypted value of Aux Send PW, and the answering unit checks this password against Ascend-Receive-Secret. The answering unit receives Ascend-Receive-Secret from the RADIUS server when the first channel of the call connects.

Emma    Password="SAFEWORD"

            User-Service=Framed-User,

            Framed-Protocol=MPP, 

            Framed-Address=200.0.5.1,

            Framed-Netmask=255.255.255.0,

            Ascend-Receive-Secret="b5XSAM"

Table 3-18. ACE authentication attributes for remote users

To specify that the RADIUS server use an ACE profile to authenticate multiple users behind a single remote bridge/router (such as an Ascend Pipeline unit), follow these steps:

1. Set the User-Name attribute to the remote router's system name.

2. Set the Password attribute to ACE.

password.realname 

Setting up CLID authentication

This section describes how to set up a RADIUS user profile for CLID authentication. You can choose from these configurations:

• Authenticate all callers using name, password, and caller ID. For details, see Scenario 1: Authentication using name, password, and caller ID.

• Authenticate all callers using a caller ID only. For details, see Scenario 2: Authentication using a caller ID only.

• Use an external authentication server, such as a token-card authentication server, to authenticate users after CLID authentication. For details, see Scenario 3: External authentication after CLID authentication.

• Request PAP, CHAP, or MS-CHAP after CLID authentication. For details, see Scenario 4: PAP, CHAP, or MS-CHAP after CLID authentication.

1. Open the Ethernet menu.

2. Open the Answer menu.

3. If you want to authenticate callers by name, password, and caller ID, set Id Auth=Prefer.

   This setting specifies that whenever CLID is available, the MAX checks the calling party's phone number against the value of the Caller-Id attribute in a RADIUS user profile. If it finds a match, and the profile does not require any further authentication, the MAX accepts the call. If the CLID is not available, or if the MAX cannot find a match to the calling party number, the MAX applies authentication using the Recv Auth parameter in the PPP Options menu.

4. If you want to authenticate callers by caller ID only, set Id Auth=Require or Fallback.

   The Require setting indicates that the calling party's phone number must match the value of the Caller-Id attribute before the MAX can answer the call. If CLID is not available, the MAX does not answer the call.

   The Fallback setting handles the case of RADIUS server timeouts. If the RADIUS server query times out so that the MAX cannot complete CLID authentication, the MAX does not drop the call. Instead it looks for a resident Connection profile to use for standard PAP, CHAP, MS-CHAP, or terminal server authentication. Therefore, if you set Id Auth=Fallback, you must also set up a Connection profile. For details, see the MAX Security Supplement.

5. Open the PPP Options menu.

6. If you plan to use PAP, CHAP, or MS-CHAP after CLID authentication, set the Recv Auth parameter to the appropriate value.

7. Open the Ethernet > Mod Config > Auth menu.

8. Specify the value of the Disconnect message the MAX returns when CLID authentication fails.

   When CLID authentication fails in an ISDN connection, the MAX sends a Disconnect message. The Cause element in the Disconnect message can indicate why CLID authentication failed. You can set two parameters that affect Disconnect messages:

   • The CLID Timeout Busy parameter specifies whether to return User Busy when CLID authentication fails due to a RADIUS timeout. You can specify Yes or No. The default value is No, which indicates Normal Call Clearing.

   • The CLID Fail Busy parameter specifies whether to return User Busy when CLID authentication fails for reasons other than a RADIUS timeout. You can specify Yes or No. The default value is No, which indicates Normal Call Clearing.

• In some installations, the WAN provider might not be able to deliver CLIDs, or a caller might choose to keep a CLID private.

• CLID authentication applies only where CLID is available end-to-end and Automatic Number Identification (ANI) applies to the call.

• T1 access lines and Switched-56 lines do not support CLID.

• When a user dials into the MAX using MP or MP+, the calling device may have more than phone number associated with it.

  In these types of cases, the CLID is the phone number associated with the channel in use.

Table 3-19. CLID authentication attributes: Scenario 1

Although you can configure local Connection profiles to authenticate using name, password, and caller ID, we recommend that you perform this function in RADIUS. To require all callers to authenticate using name, password and caller ID, follow these steps:

1. If you have not done so already, set Id Auth=Prefer in the Ethernet > Answer menu on the MAX.

2. Ensure that the first line of all dial-in RADIUS user profiles has the following format:

   username Password="password", Caller-Id="phonenum"
   

   • username is the user name.

   • password is the user's password.

   • phonenum is the caller ID.

Emma  Password="test", Caller-Id="123456789"

            User-Service=Framed-User,

            Framed-Protocol=PPP,

            Framed-Address=255.255.255.254,

            Framed-Netmask=255.255.255.255,

            Ascend-Assign-IP-Pool=1,

            Ascend-Route-IP=Route-IP-Yes,

            Ascend-Idle-Limit=30

Table 3-20. CLID authentication attributes: Scenario 2

Although you can configure local Connection profiles to authenticate using a caller ID only, we recommend that you perform this function in RADIUS. To require all callers to authenticate using a caller ID only, follow these steps:

1. If you have not done so already, set Id Auth=Require or Id Auth=Fallback in the Ethernet > Answer menu on the MAX.

2. Verify that the first line of all dial-in RADIUS user profiles has the following format:

   phonenum Password="Ascend-CLID"

   • phonenum represents the calling party's phone number.

   • The Password value specifies that RADIUS authenticates the caller by caller ID only.

3. Set the Ascend-Require-Auth attribute to Not-Require-Auth.

   This setting specifies that after CLID authentication, the MAX does not require any additional authentication. If you want to include name and password authentication in addition to CLID authentication, see Scenario 1: Authentication using name, password, and caller ID or Scenario 3: External authentication after CLID authentication.

5551212  Password="Ascend-CLID"

                  Ascend-Require-Auth=Not-Require-Auth,

                  User-Service=Framed-User,

                  Framed-Protocol=PPP,

                  Framed-Address=255.255.255.254,

                  Framed-Netmask=255.255.255.255,

                  Ascend-Assign-IP-Pool=1,

                  Ascend-Route-IP=Route-IP-Yes,

                  Ascend-Idle-Limit=30

To set up this two-tiered authentication, use the attributes listed in Table 3-21.

Table 3-21. CLID authentication attributes: Scenario 3

Attribute	Possible values
Ascend-Require-Auth (201)	Not-Require-Auth (0) Require-Auth (1) The default value is Not-Require-Auth. In this instance, specify Require-Auth in the first tier.
User-Name (1)	Text string containing up to 252 characters. The default value is null. In the first tier, the user name is the calling party's phone number. In the second tier, the user name is Default.
Password (2)	Text string containing up to 252 characters. The default value is null. In this instance, the password is Ascend-CLID in the first tier.

To perform external authentication after CLID authentication, follow these steps:

1. If you have not done so already, set Id Auth=Require in the Ethernet > Answer menu on the MAX.

2. Configure the first tier of a two-tiered dial-in setup.

   The first-tier dial-in user profile has the following two-line format:

   phonenum Password="Ascend-CLID"
               Ascend-Require-Auth=Require-Auth
   

   • phonenum represents the calling party's phone number.

   • The Password setting specifies that RADIUS authenticates the caller by caller ID.

   • The Ascend-Require-Auth setting specifies that after CLID authentication, the MAX requires additional authentication.
     When you set Ascend-Require-Auth=Require-Auth, you should not include any other attributes in the user profile. You must specify the characteristics of the call in the second-tier user profile.

3. Configure the second tier of the two-tiered dial-in setup.

   The second-tier user profile has the following format for the first line, with the characteristics of the call specified by the second and succeeding lines:

   Default Password="SAFEWORD"

5551212   Password="Ascend-CLID"

                   Ascend-Require-Auth=Require-Auth 

Default     Password="SAFEWORD"

                    User-Service=Login-User,

                    Login-Host=10.0.4.1,

                    ...

Scenario 4: PAP, CHAP, or MS-CHAP after CLID authentication

Table 3-22. Attributes for PAP, CHAP, or MS-CHAP after CLID authentication

To request PAP, CHAP, or MS-CHAP authentication after CLID authentication, you must set up two RADIUS user profiles. Follow these steps:

1. If you have not done so already, set Recv Auth to PAP, CHAP, MS-CHAP, or Either in the Ethernet > Answer > PPP Options menu.

2. In RADIUS, set up a first-tier profile specifying CLID authentication.

   • Set the User-Name attribute to the calling party's phone number.

   • Set the Password attribute to Ascend-CLID.

   • Set the Ascend-Require-Auth attribute to Require-Auth. Calls that have been CLID authenticated undergo no further authentication unless the matching RADIUS profile has Ascend-Require-Auth=Require Auth. If Ascend-Require-Auth=Require Auth, the parameters of the call are initially set by CLID authentication, but are subject to change by any authentication that might follow.

   For example, the first-tier CLID authentication profile might look like this one:

   5551212   Password="Ascend-CLID"
   

                       Ascend-Require-Auth=Require-Auth
   

   Do not include any other attributes in this profile. You must specify the characteristics of the call in the second-tier user profile.

3. In the first line of the second-tier user profile, specify these attributes:

   • user name

   • Password

   • Caller-Id. The value you specify for the Caller-Id attribute must match the phone number you specified for User-Name in the first-tier user profile.

4. On any succeeding lines of the second-tier user profile, set these attributes:

   • User-Service=Framed-User

   • Framed-Protocol=PPP

5. Specify any additional attributes in the second-tier user profile.

   The characteristics of the call appear in this user profile.

5551212      Password="Ascend-CLID" 

                   Ascend-Require-Auth=Require-Auth

Emma      Password="pwd", Caller-Id="5551212"

              User-Service=Framed-User,

              Framed-Protocol=PPP,

              Framed-Address=200.11.12.10,

              Framed-Netmask=255.255.255.248,

       Ascend-Send-Secret="pwd",

              ...

Setting up called-number authentication

This section describes how to set up a RADIUS user profile for called-number authentication. You can choose from these configurations:

• Authenticate all callers using name, password, and the called number. For details, see Scenario 1: Authentication using name, password, and called number.

• Authenticate all callers using the called number only. For details, see Scenario 2: Authentication using the called number only.

• Use an external authentication server, such as a token-card authentication server, to authenticate users after called-number authentication. For details, see Scenario 3: External authentication after called-number authentication.

1. Open the Ethernet menu.

2. Open the Answer menu.

3. If you want to authenticate callers by name, password, and called number, set Id Auth=Called Prefer.

   This setting specifies that whenever the called number is available, the MAX checks the called number against the value of the Client-Port-DNIS attribute in a RADIUS user profile. If it finds a match, and the profile does not require any further authentication, the MAX accepts the call. If the called number is not available, or if the MAX cannot find a match to the called number, the MAX applies authentication using the Recv Auth parameter in the PPP Options menu.

4. If you want to authenticate callers by called number only, set Id Auth=Called Require

   This setting indicates that the called number must match the value of the Client-Port-DNIS attribute before the MAX can answer the call. If the called number is not available, the MAX does not answer the call.

1. Create the first line of a pseudo-user entry using the User-Name and Password attributes.

   You create a pseudo-user to store information that the Ascend unit can query-in this case, in order to store DNIS numbers. You can configure pseudo-users for both global and Ascend unit-specific configuration control of DNIS numbers The Ascend unit adds the unit-specific information in addition to the global information.

   For a unit-specific DNIS configuration, specify the first line of a pseudo-user entry in this format:

   dovbs-<unit_name>-<num> Password="ascend"
   

   For a global DNIS configuration, specify the first line of a pseudo-user entry in this format:

   dovbs-<num> Password="ascend"
   

   <unit_name> is the system name of the Ascend unit-that is, the name specified by the Name parameter in the System Profile. <num> is a number in a sequential series, starting at 1.

2. For each pseudo-user entry, specify one or more DNIS numbers using the Client-Port- DNIS attribute.

   Specify each DNIS number in this format:

   Client-Port-DNIS="<DNIS number>"

   Client-Port-DNIS specifies the called-party number, indicating the phone number dialed by the user to connect to the Ascend unit. You can specify up to 100 DNIS numbers; if you specify more than 100, the remaining numbers are ignored.

Five small ISPs connect to a larger ISP using DOVBS with the following numbers:

• 4165551111

• 4165552222

• 4165553333

• 4165554444

• 4165555555

dovbs-Toronto-1 Password = "ascend"

Client-Port-DNIS = "5105551111"

    Client-Port-DNIS = "5105552222"

    Client-Port-DNIS = "5105553333"

    Client-Port-DNIS = "5105554444"

    Client-Port-DNIS = "5105555555"

1. RADIUS looks for entries having the format dovbs-<unit_name>-1, where <unit_name> is the system name.

2. If at least one entry exists, RADIUS loads all existing entries with the format dovbs- <unit_name>-<num>.

   The variable <num> is a number in a sequential series, starting with 1.

3. The Ascend unit queries dovbs-<unit_name>-1, then dovbs-<unit_name>-2, and so on, until it receives an authentication reject from RADIUS.

4. Once the host-specific numbers are loaded, RADIUS loads the global configuration entries; these configurations have the format dovbs-<num>.

5. The Ascend unit queries dovbs-1, then dovbs-2, and so on, until it receives an authentication reject from RADIUS.

   The Ascend unit checks the DNIS number of each incoming call against the phone numbers it has loaded.

Table 3-23. Called-number authentication attributes: Scenario 1

Although you can configure local Connection profiles to authenticate using a name, password, and called number, we recommend that you perform this function in RADIUS. To require all callers to authenticate using name, password and called number, follow these steps:

1. If you have not done so already, set Id Auth=Called Prefer in the Ethernet > Answer menu on the MAX.

2. Ensure that the first line of all dial-in RADIUS user profiles has the following format:

   username Password="password", Client-Port-DNIS="phonenum"
   

   • username is the user name.

   • password is the user's password.

   • phonenum is the called number.

Emma  Password="test", Client-Port-DNIS="123456789"

            User-Service=Framed-User,

            Framed-Protocol=PPP,

            Framed-Address=255.255.255.254,

            Framed-Netmask=255.255.255.255,

            Ascend-Assign-IP-Pool=1,

            Ascend-Route-IP=Route-IP-Yes,

            Ascend-Idle-Limit=30

Table 3-24. Called-number authentication attributes: Scenario 2

Although you can configure local Connection profiles to authenticate using the called number only, we recommend that you perform this function in RADIUS. To require all callers to authenticate using the called number only, follow these steps:

1. If you have not done so already, set Id Auth=Called Require in the Ethernet > Answer menu on the MAX.

2. Verify that the first line of all dial-in RADIUS user profiles has the following format:

phonenum Password="Ascend-DNIS" 

• phonenum represents the called number.

• The Password value specifies that RADIUS authenticates the caller by called number only.

• Set the Ascend-Require-Auth attribute to Not-Require-Auth.

  This setting specifies that after called-number authentication, the MAX does not require any additional authentication. If you want to include name and password authentication in addition to called-number authentication, see Scenario 1: Authentication using name, password, and called number or Scenario 3: External authentication after called-number authentication.

5551212  Password="Ascend-DNIS"

                  Ascend-Require-Auth=Not-Require-Auth,

                  User-Service=Framed-User,

                  Framed-Protocol=PPP,

                  Framed-Address=255.255.255.254,

                  Framed-Netmask=255.255.255.255,

                  Ascend-Assign-IP-Pool=1,

                  Ascend-Route-IP=Route-IP-Yes,

                  Ascend-Idle-Limit=30

To set up this two-tiered authentication, use the attributes listed in Table 3-25.

Table 3-25. Called-number authentication attributes: Scenario 3

Attribute	Possible values
Ascend-Require-Auth (201)	Not-Require-Auth (0) Require-Auth (1) The default value is Not-Require-Auth. In this instance, specify Require-Auth in the first tier.
User-Name (1)	Text string containing up to 252 characters. The default value is null. In the first tier, the user name is the called number. In the second tier, the user name is Default.
Password (2)	Text string containing up to 252 characters. The default value is null. In this instance, the password is Ascend-DNIS in the first tier.

To perform external authentication after called-number authentication, follow these steps:

1. If you have not done so already, set Id Auth=Called Require in the Ethernet > Answer menu on the MAX.

2. Configure the first tier of a two-tiered dial-in setup.

   The first-tier dial-in user profile has the following two-line format:

   phonenum Password="Ascend-DNIS"
                           Ascend-Require-Auth=Require-Auth
   

   • phonenum represents the called number.

   • The Password setting specifies that RADIUS authenticates the caller by called number.

   • The Ascend-Require-Auth setting specifies that after called-number authentication, the MAX requires additional authentication. When you set Ascend-Require-Auth=Require-Auth, you should not include any other attributes in the user profile. You must specify the characteristics of the call in the second-tier user profile.

3. Configure the second tier of the two-tiered dial-in setup.

   The second-tier user profile has the following format for the first line, with the characteristics of the call specified by the second and succeeding lines:

   Default Password="SAFEWORD"

5551212   Password="Ascend-DNIS"

                   Ascend-Require-Auth=Require-Auth 

Default     Password="SAFEWORD"

                    User-Service=Login-User,

                    Login-Host=10.0.4.1,

                    ...

Putting it all together

Analog dial-in with terminal server authentication

1. Set the User-Service attribute in the customer's RADIUS user profile.

   If the user will make use of the terminal server interface and then use PPP, set
   User-Service=Login-User. If the user will bypass the terminal server interface and use PPP, set User-Service=Framed-User.

2. If User-Service=Login-User, set PPP=Yes in the Ethernet > Mod Config > TServ Options menu.

3. If User-Service=Login-User, make sure that your customer's PPP software has an expect- send script in this format:

   expect "Login:" 
   send $username 
   expect "Password:" 
   send $password:
   

   At the end of the script, the user starts sending PPP packets.

1. The client calls with an analog modem, and the MAX answers.

2. The MAX waits for PPP packets, while the client software expects the terminal server login prompt.

3. The MAX times out on PPP, and sends the login prompt.

4. The client software sees the login prompt, enters a user name, and waits, expecting the password prompt.

5. The MAX sends the password prompt, and the client sends a password.

6. The MAX authenticates the user name and password against a RADIUS profile or local Connection profile.

7. If User-Service=Framed-User in the RADIUS user profile, the MAX does not present the ascend% prompt, but sends PPP packets.

8. If User-Service=Login-User in the RADIUS user profile, the MAX presents the ascend% prompt and then sends PPP packets.

9. The client software and the MAX communicate using PPP over the asynchronous serial analog line.

1. Set the User-Service attribute in the customer's RADIUS user profile.

   If the user will make use of the terminal server interface and then use PPP, set
   User-Service=Login-User. If the user will bypass the terminal server interface and use PPP, set User-Service=Framed-User.

2. If User-Service=Login-User, set PPP=Yes in the Ethernet > Mod Config > TServ Options menu.

3. In the Answer profile, set V.120=Yes.

4. Make sure that your customer's TA is configured for V.120 encapsulation.

   You can set most TAs in automatic mode so that the TA looks for a PPP packet from the host. If it finds one, it starts PPP negotiations. If it does not find one, it tries V.120 authentication. Once the call connects, the TA uses asynch/PPP mode for the duration of the call.

1. The client calls using an ISDN TA and the MAX answers the call.

2. The MAX waits for PPP packets, while the client software expects the terminal server login prompt.

3. The MAX times out on PPP, and sends the login prompt.

4. The client software sees the login prompt, enters a user name, and waits, expecting the password prompt.

5. The MAX sends the password prompt, and the client sends a password.

6. The MAX authenticates the user name and password against a RADIUS profile or local Connection profile.

7. If User-Service=Framed-User in the RADIUS user profile, the MAX does not present the ascend% prompt, but sends PPP packets.

8. If User-Service=Login-User in the RADIUS user profile, the MAX presents the ascend% prompt and then sends PPP packets.

9. The client software and the MAX communicate using PPP over an asynchronous line- asynchronous from the workstation to the TA, and asynchronous over V.120 from the TA to the MAX.

Most ISDN TAs support either V.120 clear text or asynchronous-to-PPP conversion, but not both. Therefore, if you log into a PPP server in terminal and/or scripted (ASCII text) mode, the TA goes into V.120 mode and should not dial the second B channel. If for some reason the TA does dial the second channel, it will fail to bind the two channels together and will probably drop the first channel.

In order to get the second channel connected, you must use the Authentication area, fill out the Auth. ID: field and the Password: field, and choose the appropriate authentication method, usually PAP or CHAP. If you want a second channel, you cannot use a script or the terminal.

PPP login with PAP, CHAP, or MS-CHAP authentication

• Analog modems with no expect-send script.

  The customer's PPP software must support PAP, CHAP, or MS-CHAP. The software must start negotiating PPP once it registers that the modems have connected.

• ISDN TAs using asynchronous-to-synchronous conversion.

  In this scenario, the connection between the client and the TA is asynchronous, and the ISDN connection between the TA and the MAX is synchronous. You must ensure that the customer's TA is configured for asynchronous-to-synchronous conversion. You do not need V.120 support for clients using ISDN TAs with PAP, CHAP, or MS-CHAP authentication.

• True ISDN routers, such as the Pipeline 50.

1. The client calls and the MAX answers.

2. The MAX waits for PPP packets, based on the RADIUS user profile or a local Connection profile.

3. The client sends PPP packets.

4. The MAX responds with PPP, and LCP negotiation starts.

5. The MAX carries out PAP, CHAP, or MS-CHAP authentication.

6. After authentication, upper layer NCPs (IPCP, IPXCP, CCP) are negotiated.

7. The client device and the MAX communicate using PPP over the ISDN line.

Copyright © 1998, Ascend Communications, Inc. All rights reserved.