In computer security, authentication is the process of verifying (or not) the digital identity of the sender of a digital communication, such as a login attempt. The sender may be a person, computer, or computer program. In computer terms, authentication is distinct from authorization. Authentication is the verification of user credentials, as opposed to authorization, which is the privilege granted upon successful authentication.

ScreenOS provides a portion of all three services in AAA (Authentication, Authorization, and Accounting) security schemes, but it is not designed to offer fully featured capabilities beyond simple password authentication and simple authorization which is provided with RADIUS, or other types of external AAA systems.

Profiles are created to provide username and password matches as well as to grant access rights for a login attempt. You can store profiles locally within the ScreenOS internal database. In addition to the internal database, ScreenOS supports the following external authentication server types:

You can use external servers with ScreenOS; the most widely used external authentication server in use is RADIUS. ScreenOS also has native support for LDAP and RSA Security’s SecurID. The default authentication server for all user types is the local database. However, you can specify that an external auth server be used for any of the user types except IKE users. For example, you can specify that administrators be authenticated via RADIUS, while policy authentication uses SecurID.

LDAP

LDAP is a protocol used for conducting searches through a directory. LDAP is based on the X.500 specifications, but it is significantly simpler. It allows users to query directories of information such as email addresses or public keys. Because LDAP is an open standard and it supports the Transmission Control Protocol/Internet Protocol (TCP/IP), it is well suited for centralized storage of information that a variety of host computers or applications may access. Microsoft uses a very common LDAP system, called Active Directory. Active Directory stores information about organizations, groups, and users within a Windows domain structure, including the user logon credentials for the domain. You can find more information on LDAP in RFC 1777, at http://www.ietf.org/rfc/rfc1777.txt.

LDAP directories are designed in a hierarchical fashion and you can think of them as branches of a tree, starting at the root. In its basic form, LDAP branches from country to organization to organizational units to individuals (where individuals can be people, files, devices, etc.). Figure 13-1 illustrates a typical LDAP structure.

Figure 13-1. A typical LDAP structure

ScreenOS can use the LDAP protocol for authentication of user passwords for any user type except IKE users.

Warning

You can use LDAP for authentication only; it does not support admin privilege assignment, remote settings for L2TP users or user groups, or remote settings for Xauth users or user groups.

Support is available for the various user types within ScreenOS:

Auth user

Full support for auth users.

L2TP user

Authentication only. User will receive the default remote settings from the security device.

Xauth user

Authentication only. User will receive the remote settings from the Xauth server configured within the security device.

Admin user

Authentication only. User will receive the default read-only privilege level.

User groups

Not supported with LDAP external authentication server.

In addition to the generic auth-server properties, LDAP configuration requires the default setting for the LDAP server port to be 389. You can find examples of configuring LDAP external authentication servers in Recipe 13.8.

SecurID

Instead of relying on a fixed password, SecurID provides two-factor authentication. The two factors are “something you know” in the form of a PIN, and “something you have” in the form of a one-time token generated by an RSA SecurID authenticator. An authenticator is available in several formats, from a credit-card-size device with an LCD window, to keychain fobs, to software that runs on your computer. The authenticator displays a new pseudorandom number every 60 seconds and is synchronized to the RSA Ace server. When a user attempts a logon using SecurID, he enters his username followed by his PIN and the pseudorandom number currently displayed by the authenticator, as shown in Figure 13-2. In essence, it is a password that is valid for only 60 seconds.

Figure 13-2. An RSA SecurID authenticator

If that isn’t enough, a duress mode will send an alarm if the user enters a predetermined PIN code that signifies that the user is being forced to enter her login credentials, perhaps with a gun to her head. The login will succeed for that one time only and will trigger an event on the Ace server. All future login attempts will fail until the user contacts the Ace server administrator. This feature is available only on Ace servers that support this feature.

The ScreenOS security device performs the same basic function when communicating with an RSA Ace server as it does with a RADIUS server. That is, the security device acts as a proxy between the user and the authentication server, prompting the user for the login credentials and then forwarding them for verification to the Ace server. The Ace server will respond with a success or failure message allowing ScreenOS to accept or deny the login attempt.

Warning

You can use SecurID for authentication only; it does not support admin privilege assignment, remote settings for L2TP users or user groups, or remote settings for Xauth users or user groups.

You can use SecurID with any user type except IKE users. Support for the individual user types is the same as for LDAP:

Auth user

Full support for auth users.

L2TP user

Authentication only. User will receive the default remote settings from the security device.

Xauth user

Authentication only. User will receive the remote settings from the Xauth server configured within the security device.

Admin user

Authentication only. User will receive the default read-only privilege level.

User groups

Not supported with the LDAP external authentication server.

In addition to the generic authentication properties, you can configure SecurID external servers with the following options:

Authentication port

The port number on the SecurID Ace server to which the security device sends authentication requests. The default port number is 5500.

Encryption type

The algorithm used for encrypting communication between the security device and the SecurID Ace server—either SDI or Data Encryption Standard (DES).

Client retries

The number of times the SecurID client (i.e., the security device) tries to establish communication with the SecurID Ace server before aborting the attempt.

Client timeout

The length of time in seconds that the security device waits between authentication retry attempts.

You can find examples of configuring SecurID external authentication servers in Recipe 13.9.

You can create multiple types of user accounts on the ScreenOS device. Each has a different purpose. Table 13-1 compares user types with the server type.

Table 13-1. ScreenOS authentication types and capabilities

You can assign only a few types of administrative privileges to an administrative user:

Figure 13-3 shows the process for authenticating administrative users.

Figure 13-3. Example of admin authentication process

You must store the root admin account locally on the firewall. You can store all other admin accounts for the root level, or VSYS level, on an external authentication server. If you’re using RADIUS, you can load the NetScreen dictionary file to provide VSAs that can be returned to the ScreenOS device assigning a privilege level. Optionally, you can assign a global privilege level of read/write or read-only for all admin users. If you’re using SecurID, LDAP, or RADIUS without the dictionary file, you must configure the privilege level for the user in the local database.

Here is an excerpt from the NetScreen dictionary file:

	# For Admin Privileges
	# READ_WRITE (ALL): 2, VSYS_ADMIN: 3, READ_ONLY: 4, VSYS_READ_ONLY: 5
	ATTRIBUTE NS-Admin-Privilege 26 [vid=3224 type1=1 len1=+2 data=int4] r
	VALUE NS-Admin-Privilege        READ_WRITE      2
	VALUE NS-Admin-Privilege        VSYS_ADMIN      3
	VALUE NS-Admin-Privilege        READ_ONLY       4
	VALUE NS-Admin-Privilege        VSYS_READ_ONLY  5

	ATTRIBUTE NS-Admin-Vsys-Name 26 [vid=3224 type1=2 len1=+2 data=string] r

You can find examples of creating both local and external administrative user accounts in Recipe 13.1, Recipe 13.2, and Recipe 13.7.

You create auth users to be used in firewall policies. You can use one of two schemes.

In the first scheme, as shown in Figure 13-4, you use a standard auth policy to authenticate users attempting an HTTP, FTP, or Telnet connection across the firewall. In this form, ScreenOS intercepts the connection request and prompts the user for his username and password, meanwhile buffering the packets associated with the connection attempt. If successfully authenticated, the packets are forwarded to the target host and the connection proceeds.

In the optional scheme, the user authenticates to the firewall first, before attempting any connections through the firewall. This is known as WebAuth. Using WebAuth, users are authenticated and then can forward any type of traffic (not just Telnet, FTP, or HTTP) that may be permitted by the policy.

You can create authentication users within the local database on the firewall or on external authentication servers. Figure 13-5 shows the authentication process. You can find examples for configuring authentication policies in Recipe 13.4, Recipe 13.5, and Recipe 13.8.

For the second scheme that uses WebAuth, ScreenOS is configured with an additional IP address that will be bound to an internal web server process. This IP address should be in the same subnet as one of the interface IP addresses of the fire-wall. In this scheme, the authentication user will initially connect to the firewall WebAuth IP address where she will be prompted for her username and password prior to any firewall policy checks. Once authenticated to the firewall, the user will be added to the authentication table within ScreenOS and all traffic permitted by an authentication policy for that user or group will be forwarded. You can find examples for configuring WebAuth in Recipe 13.5.

Figure 13-4. Example of user-based firewall authentication process

Figure 13-5. Example of prepolicy WebAuth authentication process

ScreenOS supports both IP Security (IPSec) and L2TP. You can configure IKE, Xauth, and L2TP users and user groups for establishing these tunneled connections:

For Xauth and L2TP, only the local security device or a RADIUS server can assign the IP, DNS, and WINS. LDAP and SecurID do not support this functionality; however, you can use a combination of servers for this purpose. For example, you could authenticate your Xauth users, via SecurID, and then assign the additional information from the local security device.

You can find examples of IKE users in Recipe 13.6.

You can combine IKE, Auth, L2TP, and Xauth users in the following combinations to store within the local database:

You should consider the following points when creating accounts with multiple types of use:

Although it is more convenient to create a single multiple-type user account, separating the user types into two single accounts allows you to increase security. For example, you can store an auth user account on an external auth server and an Xauth user account on the local database. You can then assign different login usernames and passwords to each account and reference the Xauth user in the IKE gateway configuration and the auth user in the policy configuration. The dial-up VPN user must authenticate twice, potentially with two completely different usernames and passwords.

You use a group expression within a policy to set conditions for authentication. Group expressions allow you to use users, groups, or other group expressions to create alternatives for authentication, such as matching a or b. In addition, you can use group expressions as requirements for authentication, such as a and b. You also can use group expressions to exclude users, user groups, or other group expressions such as not a.

Group expressions use three different operators: AND, OR, and NOT. The operators can relate to an auth user, auth user group, or previously defined group expression, as detailed in Table 13-2.

You use login banners to display the terms of use for the security device or protected resources behind the security device. Default messages are present for most banners, but you can customize them to meet the needs of the organization.

Here is an example banner that may be displayed upon login to a host system to inform the user of the terms of use:

ScreenOS supports multiple banners. Telnet, FTP, and HTTP protocols have three banners presented when used in authentication policies. A login banner is displayed with the login prompt and additional banners for successful and failed login attempts. WebAuth allows for a single banner for successful authentications.

One additional banner is available for administrative login. You can configure this login banner via the CLI or load it onto the security device as a file via the Secure Copy (SCP) protocol. You can find examples of creating an administrative login banner in Recipe 13.1. You can find examples of other authentication banners in Recipe 13.4 and Recipe 13.5.

The remainder of this chapter provides configuration recipes for various combinations of users, types, and authentication services.

You want to secure the ScreenOS device with your chosen usernames and passwords.

Use the set admin context for this operation:

	mydevice-> set admin name fwadmin
	mydevice-> set admin password !secret$PW
	mydevice-> set admin user "super" password "super$pw1" privilege all
	mydevice-> set admin user "ro-admin" password "pwF0rRO" privilege
	     "read-only"
	mydevice->set admin auth server local

Set a login banner for administrative access if desired:

	mydevice-> set admin auth banner telnet login
	"This security device may only be accessed by authorized firewall
	administrators of my-company. All access is logged."

A critical security task is to secure your firewall from unauthorized access to the configuration interfaces as well as add any additional user accounts for managing the firewall. ScreenOS devices ship with the default username netscreen and the default password netscreen for the “root” level account. You should change this immediately using this recipe’s solution. Here, we have changed the existing root user account name to fwadmin, and set the password for that account to !secret$PW.

We have also created two additional users. One user, super, has full privileges, and another user, ro-admin, has read-only privileges. Lastly, we have specified that ScreenOS uses the local authentication server for firewall admins.

To show the configuration of users that have been created on the firewall, use the get admin user command:

	mydevice-> get admin user
	Name                             Privilege
	-------------------------------- ---------------
	fwadmin                          Root
	super                            Read-Write
	ro-admin                         Read-Only

Set a login banner for administrative access if desired:

	mydevice-> set admin auth banner telnet login "This security device
	may only be accessed by authorized firewall administrators of my-company.
	All access is logged."

You can find additional information about preparing your device for initial operation in Chapter 2.

You want to create VSYS administrator accounts.

To create VSYS-level accounts, you must “enter” the vsys. Here we will enter vsys1:

	mydevice-> enter vsys vsys1
	mydevice(vsys1)-> set admin vsys name vadmin
	mydevice(vsys1)-> set admin vsys password !secret$PW
	mydevice(vsys1)->set admin vsys user "vadminr-o" password "St1ng3r"
	    privilege"read-only"

ScreenOS supports VSYS on the higher-end devices. You can create user accounts to authenticate administrators of specific VSYS. A VSYS administrator will have read-only or read/write access only, within the VSYS in which the user account resides. A VSYS administrator cannot see any configuration information within the root level of the firewall or any other VSYS devices that have been created.

Here, vsys1 was created previously. By using the enter vsys command, we can access the VSYS named vsys1. A simple variation on the preceding recipe provides the ability to create our VSYS admin accounts. From the following output, you can see the two accounts within the virtual system:

	mydevice(vsys1)-> get admin user
	Name                             Privilege
	-------------------------------- ---------------
	vadmin                           VSYS Read-Write
	vadminr-o                        VSYS Read-Only

You can find more information on VSYS in Chapter 21.

You want to create user groups instead of managing users individually.

Rather than manage each user individually, you can gather users into a group so that any changes made to the group propagate to each group member:

	mydevice->set user jim password mypass06
	mydevice->set user kim password mypass07
	mydevice->set user bill password mypass08
	mydevice->set user bill type ike xauth
	mydevice->set user pearl password mypass09
	mydevice->set user pearl type ike xauth
	mydevice->set admin user bill password billpass99 type ike
	mydevice->set user-group auth_grp1 location local
	mydevice->set user-group auth_grp1 user jim
	mydevice->set user-group auth_grp1 user kim
	mydevice->set user-group vpn location local
	mydevice->set user-group vpn user bill
	mydevice->set user-group vpn user pearl

By default, creating a user with a password creates a user account type of “auth”. When you create a user group in ScreenOS, the type remains undefined until you add a user to the group, at which point the group inherits the type(s) of accounts from the user definitions. You can create groups with multiple types by adding such users as Xauth, IKE, and L2TP to the group. However, you cannot combine the admin user with any other type of account. Any user account can be a member of up to four user groups.

In the solution to this recipe, four users and two user groups are defined. Users jim and kim are members of the auth_grp1 user group and users bill and pearl are members of the vpn group. User jim is also a member of the local group. We can view the group memberships with the get user-group command:

	mydevice-> get user-group auth_grp1
	GroupId:   3              Group Name    : auth_grp1
	Type   : auth             Total members :   2
	Location      : local
	Use cnt: Gateway 0, Firewall 0, L2TP 0, XAuth 0
	Users:
	Id    User name   Enable   Type  ID-type Identity   Belongs to groups
	----- ----------- ------ ------- ------- ---------- -----------------
	  101 jim        Yes     auth                           local auth_gr. 
	    6 kim        Yes     auth                           auth_grp1

	mydevice-> get user-group vpn
	GroupId:   2                  Group Name    : vpn
	Type   : ike xauth            Total members :   2
	Location      : local
	Use cnt: Gateway 0, Firewall  0, L2TP 0, XAuth 0
	Users:
	Id    User name  Enable   Type  ID-type Identity   Belongs to groups
	----- ---------- ------ ------- ------- ---------- -----------------
	    4 bill       Yes     ike xauth      NONE               vpn
	    5 pearl      Yes     ike xauth      NONE               vpn

You can also view individual users and group memberships with the get user command:

	mydevice-> get user all
	Total users: 6
	Id    User name  Enable      Type ID-type Identity Belongs to groups
	----- ---------- ------- --------- ------- -------- -----------------
	    4 bill      Yes     ike xauth NONE             vpn
	  100 dude      Yes     auth                       local
	  101 jim       Yes     auth                       local auth_gr..
	    6 kim       Yes     auth                       auth_grp1
	    3 louis     Yes     auth
	    5 pearl     Yes     ike xauth NONE             vpn
	user with ASN1_DN type ID sort list:

User groups can now be used in VPN or authentication policies, as shown in the following recipes.

You can find more information on setting up VPN scenarios in Chapter 10.

You want to require user authentication before permitting an FTP connection across the firewall.

This solution touches on a few areas of ScreenOS configuration, users, objects, policies, and banners.

User and group:

	mydevice->set user "jim" uid 100
	mydevice->set user "jim" type auth
	mydevice->set user "jim" password $somePw671
	mydevice->set user "jim" "enable"
	mydevice->set user-group "local" id 100
	mydevice->set user-group "local" user "jim"

Objects:

	mydevice->set address trust user-a 10.1.1.1/32
	mydevice->set address dmz server-a 10.2.2.2/32

Policy:

	mydevice->set policy id 11 top from trust to dmz user-a server-a ftp
	permit auth user-group local log

Banners:

	mydevice-> set auth banner ftp login "Please enter your username and
	password to be authenticated by this security device"

	mydevice-> set auth banner ftp success "You are now authenticated.
	You may proceed with your ftp session"

	mydevice->set auth banner ftp fail "The username and password
	presented is not authorized for this ftp session"

In this section, we will provide an example of simple user authentication within a firewall policy for FTP. ScreenOS permits this type of authentication for FTP and Telnet. These protocols can support an interactive style of communication that allows for prompting of user credentials.

ScreenOS will cache these credentials and offer them to the FTP server. This means that if the user credentials configured on the firewall match the FTP login credentials, the user will be automatically logged into the FTP server, having to provide credentials only once. If the username and password do not match the FTP server login process, the user will have to log in to the FTP server again and provide the correct credentials.

Upon successfully authenticating to the firewall, ScreenOS will create an entry in the authentication table for the user’s IP address. You can view this authentication table with the get auth table command:

	mydevice-> get auth table
	Total users in table:     1
	  Successful:     1, Failed:     0
	  Pending   :     0, Others:     0
	  Infranet users :     0
	Col T: D = Default, W= WebAuth, I= Infranet, A= Auth server in policy
	id src          user  group    age status   server T srczone  dstzone
	 1 10.1.1.1     jim   local      0 Success  Local  D Untrust  Trust

Additional commands are available for the get auth context. An example is the get auth statistics command:

	mydevice-> get auth statistics
	Values of the following:
	  Current entries in Auth Queue: 0
	  Maximum entries ever in Auth Queue: 0

	Number of times the following have happened:
	  Auth Queue was full: 0
	  LDAP connect failed: 0
	  Out of Auth Msg Bufs: 0
	  Auth table entry unavailable: 0
	  Could not send mail to Auth task: 0
	  Auth callback func called: 0 times
	  Select() has data: 0 times
	  Select() has data on socket: 0 times 
	  Authq entry allocated: 0, freed: 0
	Radius counters:
	  Authentication:
	    L2TP/XAuth Access Requests sent: 0
	    Admin/FW Access Requests sent: 0
	    Total Access Accepts Received 0
	    Total Access Rejects Received 0
	    Total Access Challenges Received 0
	    Authenticator in Accept/Reject/Challenge: Valid: 0, Invalid: 0

	  Accounting:
	    Accounting Start Requests sent: 0
	    Accounting Start Response recd: 0 (Valid: 0, Invalid: 0)
	    
	    Accounting Stop Requests sent: 0
	    Accounting Stop Response recd: 0 (Valid: 0, Invalid: 0)
	    Accounting Stop Retry attempts: 0

	    Total Accounting Responses recd: 0
	    Authenticator in Accounting Response: Valid: 0, Invalid: 0

	  Total Radius Packets sent: 0
	  Total Radius Packets recd: 0
	  Total Radius Retry attempts: 0

Entries within the auth table have a timeout to remove entries with idle connections. This inactivity timer is set to 10 minutes by default, but you can change it to any value between 0 and 255 minutes:

	mydevice-> set auth-server Local timeout ?
	<number> timeout in minutes. Valid range 0 - 255 (1000 for
	admin timeout)

You can find additional information on policy configuration in Chapter 7.

You want to use WebAuth to authenticate a user prior to policy-checking other traffic, similar to the scenario shown in Figure 13-6.

Figure 13-6. WebAuth process

WebAuth authenticates the user credentials and then creates an entry in the auth table for the IP address of the user host machine.

User and group:

	mydevice->set user "jim" uid 100
	mydevice->set user "jim" type auth
	mydevice->set user "jim" password $somePw671
	mydevice->set user "jim" "enable"
	mydevice->set user-group "local" id 100
	mydevice->set user-group "local" user "jim"

WebAuth:

	mydevice-> set webauth server Local
	mydevice-> set interf e0/0 webauth-ip 10.1.1.2
	mydevice-> set interf e0/0 webauth
	mydevice->set auth-server Local timeout 30

Policy:

	mydevice-> set pol id 12 from trust to dmz user-a server-a ftp permit
	webauth user-group local log
	mydevice->set pol move 12 after 11

Banner:

	mydevice-> set webauth banner success "You have successfully
	authenticated to the firewall. You may now use your other applications."

WebAuth allows user authentication prior to policy checking. Upon successful authentication, an entry is created within the auth table for the IP address of the user’s workstation. This entry in the auth table is checked for each session that matches a rule with the WebAuth option enabled. You can choose whether to use clear text HTTP or HTTPS (SSL) for this authentication. For example:

	mydevice-> set interf e0/0 webauth ssl-only

You can use WebAuth with the local database or an external authentication server. The main requirement is that WebAuth be used with the user account type of “auth”.

You can configure the WebAuth server on any physical interface, subinterface, or Virtual Security Interface (VSI), but it must be an address in the same subnet as the chosen interface. You also can configure WebAuth on multiple interfaces. If you have multiple interfaces bound to the same security zone, you can put a WebAuth IP address on one interface, and traffic from other interfaces within the same zone can still reach it.

You also can use WebAuth in transparent mode with a WebAuth IP address chosen in the same subnet as the vlan1 interface.

You can view entries within the auth table with the get auth table command:

	mydevice-> get auth table
	Total users in table:     1
	  Successful:     1, Failed:     0
	  Pending   :     0, Others:     0
	  Infranet users :     0
	Col T: D= Default, W= WebAuth, I= Infranet, A= Auth server in policy
	  id src       user  group    age status   server T srczone  dstzone
	   1 10.1.1.1  jim   local      0 Success  Local  D Untrust  Trust

The ScreenOS event log also has entries associated with WebAuth authentication events. Event type 518 displays authentication failures for WebAuth, and type 519 displays successful WebAuth authentications:

	mydevice-> get event type 518
	Date       Time     Module Level  Type Description
	2006-03-14 12:27:51 system warn  00518 Local authentication for
	WebAuth user jeff at 10.1.1.210 was denied
	2006-03-14 12:27:42 system warn 00518 Local authentication for
	WebAuth user jeff at 10.1.1.210 was denied
	2006-03-14 12:27:31 system warn 00518 Local authentication for
	WebAuth user jeff at 10.1.1.210 was denied
	2006-03-11 16:13:19 system warn 00518 ADM: Local admin authentication
	failed for login name 'fwadmin': invalid password
	2006-03-11 16:10:28 system warn 00518 Local authentication for WebAuth
	user joe at 10.1.1.210 was denied
	Total entries matched = 5

	mydevice-> get event type 519
	Date       Time     Module Level Type Description
	2006-03-14 12:25:19 system warn 00519 Local authentication for WebAuth
	user kim at 10.1.1.210 was successful
	2006-03-14 12:24:38 system warn 00519 Local authentication for WebAuth
	user jim at 10.1.1.210 was successful
	2006-03-14 12:23:06 system warn 00519 Local authentication for WebAuth
	user dude at 10.1.1.210 was successful
	2006-03-11 16:20:32 system warn 00519 Local authentication for user
	dude at 10.1.1.210 was successful
	2006-03-11 16:19:27 system warn 00519 Local authentication for user
	dude at 10.1.1.210 was successful
	2006-03-11 16:17:42 system warn 00519 Local authentication for WebAuth
	user dude at 10.1.1.210 was successful
	2006-03-11 16:12:09 system warn 00519 Local authentication for WebAuth
	user dude at 10.1.1.210 was successful
	Total entries matched = 7

You can find additional information on policy configuration in Chapter 7.

You want to create VPN users and groups for both IKE and Xauth authentication.

For this recipe, you’ll need to create both IKE and Xauth user types. Passwords are assigned for Xauth authentication, and you must configure remote networking settings for the Xauth users. Note that you can store only IKE users and user groups on the local database.

First, create the users:

	mydevice-> set user alex ike-id u-fqdn [email protected]
	mydevice-> set user ben ike-id ip 24.1.1.1
	mydevice-> set user cal ike-id fqdn www.juniper.net
	mydevice->set used dan ike-id asn1-dn wildcard
	   CN=clark,OU=dan,O=mycompany,L=dallas,ST=tx,C=us,[email protected]

Then, set the account types for the users:

	mydevice-> set user alex type ike xauth
	mydevice-> set user ben type ike xauth
	mydevice-> set user cal type ike xauth
	mydevice->set user dan type ike xauth

Set passwords for each user:

	mydevice-> set user alex password pass1
	mydevice-> set user ben password pass2
	mydevice-> set user cal password pass3
	mydevice->set user dan password pass4

Create the IP address pool:

	mydevice-> set ippool vpn1pool 10.60.1.1 10.60.1.100

Assign remote networking settings for each user:

	mydevice-> set user alex remote ippool vpn1pool
	mydevice-> set user alex remote dns1 10.10.10.30
	mydevice-> set user alex remote wins1 10.10.10.30
	mydevice-> set user ben remote ippool vpn1pool
	mydevice-> set user ben remote dns1 10.10.10.30
	mydevice-> set user ben remote wins1 10.10.10.30
	mydevice-> set user cal remote ippool vpn1pool
	mydevice-> set user cal remote dns1 10.10.10.30
	mydevice-> set user cal remote wins1 10.10.10.30
	mydevice-> set user dan remote ippool vpn1pool
	mydevice-> set user dan remote dns1 10.10.10.30
	mydevice->set user dan remote wins1 10.10.10.30

And finally, create the group and add its users:

	mydevice-> set user-group vpnauth location local
	mydevice-> set user-group vpnauth user alex
	mydevice-> set user-group vpnauth user ben
	mydevice-> set user-group vpnauth user cal
	mydevice->set user-group vpnauth user dan

In ScreenOS, an IKE user is for VPN tunnel establishment typically when the end system will have a dynamically assigned IP address. In this case, you must use an IKE ID to establish the Phase-1 Security Association (SA). The IKE ID can be one of four types. In this example, there are four users, each with a different type of IKE ID, and they are placed in a group called vpnauth.

Each user is configured to be of type IKE and Xauth. You can view users and group configurations with the get user commands:

	mydevice-> get user all
	Total users: 11
	Id    User name Enable    Type    ID-type Identity   Belongs to groups
	----- --------- ----------------- ------- ---------- -----------------
	    7 alex      Yes   ike xauth   USER-DN [email protected] vpnauth
	    8 ben       Yes   ike xauth   IPV4    24.1.1.1   vpnauth
	    4 bill      Yes   ike xauth   NONE               vpn
	    9 cal       Yes   ike xauth   FQDN    www.juniper.net vpnauth
	   10 dan       Yes   ike xauth   ASN1-DN
	CN=clark,OU=dan,O=mycompany,L=dallas,ST=tx,C=us,Email=cal@mycompan
	.com,DC=, vpnauth
	  100 dude       Yes     auth                         local
	   11 eve        Yes     l2tp xauth
	  101 jim        Yes     auth                         local admin_gr..
	    6 kim        Yes     auth                            admin_grp1
	    3 louis      Yes     auth
	    5 pearl       Yes     ike xauth      NONE               vpn
	user with ASN1_DN type ID sort list:
	[0]=10u

Here, our users are created as IDs 7–10, are enabled, are of type IKE and Xauth, with the IKE ID type and identity, and are members of the vpnauth group.

A more detailed look at user alex will show the remote settings assigned to this user:

	mydevice-> get user alex
	Id  User name  Enable     Type  ID-type Identity   Belongs to groups
	--- ---------- ------ --------- ------- ---------- ------------------
	  7 alex       Yes    ike xauth USER-DN [email protected] vpnauth
	user type<00000034>.
	Number login with this user id is 1. gw_use_cnt<0>
	identity type<3>.
	identity <[email protected]>.
	Remote IP          : 0.0.0.0           IP Pool Name :vpn1pool
	Remote Primary DNS : 10.10.10.30       Remote Secondary DNS : 0.0.0.0
	Remote Primary WINS: 10.10.10.30       Remote Secondary WINS: 0.0.0.0
	Static IP          : 0.0.0.0
	User belongs to group(s): vpnauth

	mydevice-> set user alex type ike
	User alex is in use

In the preceding example, each user was assigned remote networking settings. A variation on this is to use the Xauth server to assign these values. Using the Xauth server to assign these values is recommended when a large number of users will be connecting to the security device. More detailed information on using Xauth, IKE, and VPN tunnels is available in Chapter 10.

You want to use Windows Active Directory accounts with the Microsoft Internet Authentication Service (IAS) as the RADIUS server for administrator authentication.

You can configure any user, other than the “root” user, for RADIUS authentication and privilege assignment from the RADIUS server.

First, define the auth-server properties:

	mydevice-> set auth-server "IAS" id 1
	mydevice-> set auth-server "IAS" server-name "10.1.1.66"
	mydevice-> set auth-server "IAS" account-type admin
	mydevice-> set auth-server "IAS" radius secret "netscreen"
	mydevice-> set auth-server "IAS" radius retries 3
	mydevice-> set auth-server "IAS" radius timeout 5
	mydevice->set auth-server "IAS" account-type admin

Then, specify what privilege should be assigned by the remote authentication server:

	mydevice-> set admin privilege get-external

And finally, choose the external server as the default for admin authentication:

	mydevice-> set admin auth server "IAS"

In this section, we will provide a ScreenOS configuration example for using Microsoft IAS, which is included with Windows 2003 Server. It is common to want to leverage the existing credentials present in the Active Directory of the domain controller. Therefore, here we have used a combination of RADIUS and LDAP to authenticate administrators of the security device, even though ScreenOS is only aware of the RADIUS server.

The first part of the configuration defines the external authentication server properties to be used. Next, ScreenOS is instructed to get the privilege, either read/write or read-only, from the external server. Finally, the new authentication server is set as the default for admin authentication.

You can view the configuration of this newly created authentication server with the get auth-server command:

	mydevice-> get auth-server IAS
	Id     :   1                 Auth Server   : IAS
	Type   : Radius              Server Name/IP: 10.1.1.66
	Backup1:                     Backup2       :
	Idle Timeout:   10           Account Type  : admin
	Forced Timeout: 0 (Disabled)
	Fail-over revert interval: Disabled
	Radius shared secret: 7VV93tUaNXoxWnsEeACurDXZWHndDAe4AQ==
	Radius server port : 1645
	Radius retry timeout: 5 second(s), Number of retries: 3

The root user account of the security device can only reside locally. It cannot reside on an external authentication server, and ScreenOS will always search for the user account within the local database first. If it cannot find the user account, it will consult the external server configured to serve the admin account type.

RADIUS is the preferred external authentication server type, as it supports the ability to assign the privilege level, whereas LDAP and SecurID do not have this ability. As shown in this example, you can combine RADIUS with LDAP.

You also can combine it with SecurID in the same fashion. Therefore, it is recommended that you use this approach for authenticating external administrator accounts.

For the Microsoft part of the configuration, you should consult the appropriate documentation for assistance, but here is a quick tutorial:

You can find additional information on setting up administrators or setting service options on the interface in Chapter 2.

You want to use an LDAP database for authentication within auth or WebAuth policies.

Configure an auth server with the LDAP properties that match your environment by first defining the auth-server properties:

	mydevice-> set auth-server "my-ldap" type ldap
	mydevice-> set auth-server "my-ldap" account-type auth
	mydevice-> set auth-server "my-ldap" server-name 10.1.1.66
	mydevice-> set auth-server "my-ldap" backup1 10.1.1.67
	mydevice-> set auth-server "my-ldap" backup2 10.1.1.68
	mydevice-> set auth-server "my-ldap" timeout 30
	mydevice-> set auth-server "my-ldap" ldap port 389
	mydevice->set auth-server "my-ldap" ldap cn cn

Then, set the base dn:

	mydevice-> set auth-server "my-ldap" ldap dn c=us;o=mycompany;ou=sales

Set the server as the default for the account-type auth:

	mydevice-> set auth default auth server my-ldap

And, use it within a policy:

	mydevice-> set pol top from untrust to dmz any server-a svc-grp1
	permit auth log

Sometimes you do not know the IP address from which authorized users may be accessing protected resources. Because of this, administrators have been known to use the any object in the source address field of the rule permitting such access. This is an example of why it is difficult to secure networks.

ScreenOS offers the auth and WebAuth features to help with security. With these authentication features, you can use the any identifier in the rule and still be assured that only authorized users can gain access to protected resources.

Here, we have defined the authentication server to use with policy authentication to be an LDAP server by defining a group of servers with a logical name of my-ldap and a server type of ldap, and we set these servers to serve the authentication requests for the auth account type. The server name could be a name resolvable via DNS, or as defined here, simply an IP address. The default timeout of 10 minutes was changed to 30 minutes, so after an idle time of 30 minutes on any given session, the authentication status will be removed, and the user will have to reauthenticate.

The server at 10.1.1.66 will be the primary LDAP server. If this server does not respond, the security device will try the backup1 server at 10.1.1.67. If neither responds, the backup2 server will be tried.

You can view the configuration of the newly defined authentication server with the get auth-server command:

	mydevice-> get auth-server my-ldap
	Id     :   2                 Auth Server   : my-ldap
	Type   : LDAP                Server Name/IP: 10.1.1.66
	Backup1: 10.1.1.67           Backup2       : 10.1.1.68
	Idle Timeout:   30           Account Type  : auth
	Forced Timeout: 0 (Disabled)
	Fail-over revert interval: Disabled
	LDAP server port            : 389
	LDAP distinguished name (dn): c=us;o=mycompany;ou=sales
	LDAP common name identifier : cn

The server was set to be the default server for account type “auth”; you can verify this by issuing the get auth settings command:

	mydevice-> get auth settings
	Id     :   2                 Auth Server   : my-ldap
	Type   : LDAP                Server Name/IP: 10.1.1.66
	Backup1: 10.1.1.67           Backup2       : 10.1.1.68
	Idle Timeout:   30           Account Type  : auth
	Forced Timeout: 0 (Disabled)
	Fail-over revert interval: Disabled
	LDAP server port            : 389
	LDAP distinguished name (dn): c=us;o=mycompany;ou=sales
	LDAP common name identifier : cn

The output of the get auth settings command shows that our newly defined server will be the default for policy-based authentication.

This authentication server is now ready to use with any auth or WebAuth rules within the security device. Recipe 13.4 and Recipe 13.5 are applicable here, as once you have defined the external authentication server, you can use it in the other user authentication schemes in this chapter.

For more information on using policies, please refer to Chapter 7.

You want to use your SecurID authentication server for authentication within auth or WebAuth policies.

Configure an authentication server with properties to match your environment.

First, define the auth-server properties:

	mydevice-> set auth-server "ace1" type securid
	mydevice-> set auth-server "ace1" server-name 10.1.1.88
	mydevice-> set auth-server "ace1" backup1 10.1.1.188
	mydevice-> set auth-server "ace1" timeout 40
	mydevice-> set auth-server "ace1" account-type auth
	mydevice-> set auth-server "ace1" securid retries 3
	mydevice-> set auth-server "ace1" securid timeout 10
	mydevice-> set auth-server "ace1" securid auth-port 5000
	mydevice-> set auth-server "ace1" securid encr 1
	mydevice->set auth-server "ace1" securid duress 0

Set this server as the default for account type “auth”:

	mydevice-> set auth default auth server ace1

Then, use it within a policy:

	mydevice-> set pol top from untrust to dmz any server-a svc-grp1
	permit auth log

SecurID is a product available from RSA that provides for strong, two-factor authentication. The product consists of server software and individual authenticators. The authenticators are available in a variety of forms, but the most common are keychain-style fobs that produce pseudorandom numbers as one-time passwords. A typical user would enter her username, followed by her PIN, and then enter the numbers currently displayed on her authenticator device. The server upon which the software is installed is referred to as the “Ace” server.

You can use SecurID authentication servers for policy-based authentication, admin authentication, and Xauth/L2TP authentication. However, because the SecurID server cannot send any configuration data back to the ScreenOS device, SecurID is best suited for policy-based authentication. The SecurID server is natively supported within ScreenOS.

In the following example, we will create the authentication server and accept the default ID assigned by ScreenOS. We set the primary server to be at address 10.1.1.88 and to have a backup server at 10.1.1.188. We set the timeout for inactivity within an authenticated session to 40. Lastly, we set specific SecurID properties for the number of retries for reaching the Ace server. We set a timeout of 10 seconds for awaiting a response from the Ace server; we set the port the server is listening on to 5,000; we set encryption to 1, which is DES; and we set the duress mode to disabled.

Use the get auth-server command to view the properties of the newly configured SecurID server object:

	mydevice-> get auth-server ace1
	Id     :   3                 Auth Server   : ace1
	Type   : SecurID             Server Name/IP: 10.1.1.88
	Backup1: 10.1.1.188          Backup2 :
	Idle Timeout:   40           Account Type : auth
	Forced Timeout: 0 (Disabled)
	Fail-over revert interval: Disabled
	SecurID Authentication Port: 5000
	SecurID Use Duress         : NO
	SecurID Encryption Type    : DES
	SecurID Timeout            : 10
	SecurID Max Number Retries : 3

Set the server to be the default for account type “auth”, which you can verify with the get auth settings command:

	mydevice-> get auth settings
	Id     :   3                 Auth Server   : ace1
	Type   : SecurID             Server Name/IP: 10.1.1.88
	Backup1: 10.1.1.188          Backup2 :
	Idle Timeout:   40           Account Type : auth
	Forced Timeout: 0 (Disabled)
	Fail-over revert interval: Disabled
	SecurID Authentication Port: 5000
	SecurID Use Duress         : NO
	SecurID Encryption Type    : DES
	SecurID Timeout            : 10
	SecurID Max Number Retries : 3

This authentication server is now ready to use with any auth or WebAuth rules within the security device. Recipe 13.4 and Recipe 13.5 are applicable here, as once you have defined the external authentication server, you can use it with other user authentication recipes in this chapter.