Configuring an External Server for VPN Concentrator User Authorization
The VPN Concentrator supports user authorization on an external LDAP or RADIUS server. Before you configure the VPN Concentrator to use an external server, you must configure the server with the correct VPN Concentrator authorization attributes and, from a subset of these attributes, assign specific permissions to individual users. Follow the instructions given here to configure your external server.
Note For more information on the LDAP protocol, refer to RFCs 1777, 2251, and 2849.
An LDAP server stores information as entries in a directory. An LDAP schema defines what types of information can be stored in those entries. The schema lists classes and the set of (required and optional) attributes that objects of each class may contain.
To configure your LDAP server to interoperate with the VPN Concentrator, define a VPN Concentrator authorization schema. A VPN Concentrator authorization schema defines the class and attributes of that class that the VPN Concentrator supports. Specifically, it comprises the object class (cVPN3000-User-Authorization) and all its possible attributes that may be used to authorize a VPN Concentrator user (such as access hours, primary DNS, and so on). Each attribute comprises the attribute name, its number (called an object identifier or OID), its type, and its possible values.
Once you have defined the VPN Concentrator authorization schema and loaded it on your server, define the VPN Concentrator attributes and permissions and their respective values for each user who will be authorizing to the server.
In summary, to set up your LDAP server:
Design your VPN Concentrator LDAP authorization schema based on the hierarchal set-up of your organization
Define the VPN Concentrator authorization schema
Load the schema on the LDAP server
Define each user's permissions on the LDAP server
The specific steps of these processes vary, depending on which type of LDAP server you are using.
Designing the VPN Concentrator LDAP Schema
Before you actually create your schema, think about how your organization is structured. Your LDAP schema should reflect the logical hierarchy of your organization.
For example, suppose an employee at your company XYZ Corporation is named Joe. Joe works in the Engineering group. Your LDAP hierarchy could have one or many levels. You might decide to set up a shallow, single-level hierarchy in which Joe is considered a member of XYZ corporation. Or, you could set up a multi-level hierarchy in which Joe is considered to be a member of the department Engineering, which is a member of an organizational unit called People, which is itself a member of XYZ Corporation. See Figure A-1 for an example of this multi-level hierarchy.
A multi-level hierarchy has more granularity, but a single level hierarchy is quicker to search.
Figure A-1 A Multi-Level LDAP Hierarchy
Searching the Hierarchy
The VPN Concentrator allows you to tailor the search within the LDAP hierarchy. You configure the following three fields on the VPN Concentrator to define where in the LDAP hierarchy your search begins, its extent, and the type of information it is looking for. Together these fields allow you to limit the search of the hierarchy to the just part of the tree that contain the user permissions.
LDAP Base DN = This field defines where in the LDAP hierarchy the server should begin searching for user information when it receives an authorization request from the VPN Concentrator.
Search Scope = This field defines the extent of the search in the LDAP hierarchy.The search proceeds this many levels in the hierarchy below the LDAP Base DN. You can choose to have the server search only the level immediately below, or it can search the entire subtree. A single level search is quicker, but a subtree search is more extensive.
Naming Attribute(s) = This field defines the Relative Distinguished Name (RDN) that uniquely identifies an entry in the LDAP server. Common naming attributes are: cn (Common Name) and ui (user identification).
Figure A-1 shows a possible LDAP hierarchy for XYZ Corporation. Given this hierarchy, you could define your search in different ways. Table A-1 shows two possible search configurations.
In the first example configuration, when Joe establishes his IPSec tunnel with LDAP authorization required, the VPN Concentrator sends a search request to the LDAP server indicating it should search for Joe in the Engineering group. This search will be quick.
In the second example configuration, the VPN Concentrator sends a search request indicating the server should search for Joe within XYZ Corporation. This search will take longer.
Once you have decided how to structure your user information in the LDAP hierarchy, define this organization in a schema. To define the schema, begin by defining the object class name. The class name for the VPN Concentrator directory is: cVPN3000-User-Authorization. The class has the object identifier (OID): 1.2.840.113556.1.8000.795.1.1. Every entry or user in the directory is an object of this class.
Some LDAP servers (for example, the Microsoft Active Directory LDAP server) do not allow you to reuse the class OID, once you have defined it. Use the next incremental OID. For example, if you incorrectly defined the class name as "cVPN3000-Usr-Authrizaton" with OID "1.2.840.113556.1.8000.795.1.1," you can enter the correct class name "cVPN3000-User-Authorization" with the next OID, for example: 1.2.840.113556.1.8000.795.1.2.
For the Microsoft Active Directory LDAP server, define the schema in text form in a file using the LDAP Data Interchange Format (LDIF). This file has an extension of .ldif, for example: schema.ldif. Other LDAP servers use graphical user interfaces or script files to define the object class and its attributes.
All schema attributes that the VPN Concentrator supports begin with the letters "cVPN3000"; for example: cVPN3000-Access-Hours. For a complete list of attributes, see Table A-2.
An unique identifier for the AV pair. For example: ip:inacl#1=. This field only appears when the filter has been sent as an AV pair.
Action
Action to perform if rule matches: deny, permit.
Protocol
Number or name of an IP protocol. Either an integer in the range 0-255 or one of the following keywords: icmp, igmp, ip, tcp, udp.
Source
Network or host from which the packet is sent, specified as an IP address, a hostname, or the keyword "any". If specified as an IP address, the source wildcard mask must follow.
Source Wildcard Mask
The wildcard mask to be applied to the source address.
Destination
Network or host to which the packet is sent, specified as an IP address, a hostname, or the keyword "any". If specified as an IP address, the source wildcard mask must follow.
Destination Wildcard Mask
The wildcard mask to be applied to the destination address.
Log
Generates a FILTER log message. You must use this keyword to generate events of severity level 9.
Operator
Logic operators: greater than, less than, equal to, not equal to.
Port
The number of a TCP or UDP port: in the range 0-65535.
For example:
ip:inacl#1=deny ip 10.155.10.0 0.0.0.255 10.159.2.0 0.0.0.255 log
ip:inacl#2=permit TCP any host 10.160.0.1 eq 80 log
The following chart lists the tokens for the Cisco-AV-Pair attribute:
Table 0-3 VPN Concentrator-Supported Tokens
Token
Syntax Field
Description
ip:inacl#Num=
N/A (Identifier)
(Where Num is a unique integer.) Starts all AV pair access control lists.
deny
Action
Denies action. (Default.)
permit
Action
Allows action.
icmp
Protocol
Internet Control Message Protocol (ICMP)
1
Protocol
Internet Control Message Protocol (ICMP)
IP
Protocol
Internet Protocol (IP)
0
Protocol
Internet Protocol (IP)
TCP
Protocol
Transmission Control Protocol (TCP)
6
Protocol
Transmission Control Protocol (TCP)
UDP
Protocol
User Datagram Protocol (UDP)
17
Protocol
User Datagram Protocol (UDP)
any
Hostname
Rule applies to any host.
host
Hostname
Any alpha-numeric string that denotes a hostname.
log
Log
When the event is hit, a filter log message appears. (Same as permit and log or deny and log.)
lt
Operator
Less than value
gt
Operator
Greater than value
eq
Operator
Equal to value
neq
Operator
Not equal to value
range
Operator
Inclusive range. Should be followed by two values.
Example VPN Concentrator Authorization Schema
This section provides a sample of an LDAP schema. This schema supports the VPN Concentrator class and attributes. It is specific to the Microsoft Active Directory LDAP server. Use it as a model, in conjunction with Table A-2, to define your own schema for your own LDAP server.
Note For more information on LDIF, refer to RFC-2849.
Note The directions in this section are specific to the Microsoft Active Directory LDAP server. If you have a
different type of server, refer to your server documentation for information on loading a schema.
To load the schema on the LDAP server, enter the following command from the directory where the schema file resides: ldifde -i -f Schema Name. For example: ldifde -i -f 3k_schema.ldif
Defining User Permissions
Note The directions in this section are specific to the Microsoft Active Directory LDAP server. If you have a
different type of server, refer to your server documentation for information on defining and loading user
attributes.
For each user authorizing to your LDAP server, define a user file. A user file defines all the VPN Concentrator attributes and values associated with a particular user. Each user is an object of the class cVPN3000-User-Authorization. To define the user file, use any text editor. The file must have the extension .ldif. (For an example user file, see "ann_smith.ldif.")
To load the user file on the LDAP server, enter the following command on the directory where your version of the ldap_user.ldif file resides: ldifde -i -f ldap_user.ldif. For example: ldifde -i -f ann_smith.ldif
Once you have created and loaded both the schema and the user file, your LDAP server is ready to process VPN Concentrator authorization requests.
Example User File
This section provides a sample of a user file for the user Ann Smith.
Follow the steps below to set up the RADIUS server to inter operate with the VPN Concentrator.
Step 1 Load the VPN Concentrator attributes into the RADIUS server. The method you use to load the attributes depends on which type of RADIUS server you are using:
If you are using Cisco ACS: the server already has these attributes integrated. You can skip this step.
If you are using a FUNK RADIUS server: Cisco supplies a dictionary file that contains all the VPN Concentrator attributes. Obtain this dictionary file, cisco3k.dct, from Software Center on CCO or from the VPN Concentrator CD-ROM. Load the dictionary file on your server.
For other vendors' RADIUS servers (for example, Microsoft Internet Authentication Service): you must manually define each VPN Concentrator attribute. To define an attribute, use the attribute name or number, type, value, and vendor code (3076). For a list of VPN Concentrator RADIUS authorization attributes and values, see
Step 2 Set up the users or groups with the permissions and attributes to send during IPSec tunnel establishment. The permissions or attributes might include access hours, primary DNS, banner, and so on.
VPN Concentrator RADIUS Authorization Attributes
Table A-4 lists all the possible VPN Concentrator supported attributes that can be used for user authorization.
Table A-4 VPN Concentrator Supported RADIUS Attributes and Values
