Configuring an External Server for Authorization and Authentication

This appendix describes how to configure an external LDAP, RADIUS, or TACACS+ server to support AAA on the security appliance. Before you configure the security appliance to use an external server, you must configure the server with the correct security appliance authorization attributes and, from a subset of these attributes, assign specific permissions to individual users.

Understanding Policy Enforcement of Permissions and Attributes

The security appliance supports several methods of applying user authorization attributes (also called user entitlements or permissions) to VPN connections. You can configure the security appliance to obtain user attributes from a Dynamic Access Policy (DAP) on the security appliance, from an external authentication and/or authorization AAA server (RADIUS or LDAP), from a group policy on the security appliance, or from all three.

If the security appliance receives attributes from all sources, the attributes are evaluated, merged, and applied to the user policy. If there are conflicts between attributes coming from the DAP, the AAA server, or the group policy, those attributes obtained from the DAP always take precedence.

The security appliance applies attributes in the following order (also illustrated in Figure E-1:

1. DAP attributes on the security appliance—Introduced in Version 8.0, take precedence over all others. If you set a bookmark/URL list in DAP, it overrides a bookmark/URL list set in the group policy.

2. User attributes on the AAA server—The server returns these after successful user authentication and/or authorization. Do not confuse these with attributes that are set for individual users in the local AAA database on the security appliance (User Accounts in ASDM).

3. Group policy configured on the security appliance—If a RADIUS server returns the value of the RADIUS CLASS attribute IETF-Class-25 (OU=<group-policy>) for the user, the security appliance places the user in the group policy of the same name and enforces any attributes in the group policy that are not returned by the server. For LDAP servers, any attribute name can be used to set the group policy for the session. The LDAP attribute map you configure on the security appliance maps the LDAP attribute to the Cisco attribute IETF-Radius-Class.

4. Group policy assigned by the Connection Profile (called tunnel-group in CLI)—The Connection Profile has the preliminary settings for the connection, and includes a default group policy applied to the user before authentication. All users connecting to the security appliance initially belong to this group which provides any attributes that are missing from the DAP, user attributes returned by the server, or the group policy assigned to the user.

5. Default group policy assigned by the security appliance (DfltGrpPolicy)—System default attributes provide any values that are missing from the DAP, user attributes, group policy, or connection profile.

Figure E-1 Policy Enforcement Flow

Configuring an External LDAP Server

The VPN 3000 Concentrator and the ASA/PIX 7.0 required a Cisco LDAP schema for authorization operations. Beginning with Version 7.1.x, the security appliance performs authentication and authorization, using the native LDAP schema, and the Cisco schema is no longer needed.

Your LDAP configuration should reflect the logical hierarchy of your organization. For example, suppose an employee at your company, Example Corporation, is named Terry. Terry 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 Terry is considered a member of Example Corporation. Or, you could set up a multi-level hierarchy in which Terry 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 Example Corporation. See Figure E-2 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 E-2 A Multi-Level LDAP Hierarchy

Searching the Hierarchy

The security appliance lets you tailor the search within the LDAP hierarchy. You configure the following three fields on the security appliance to define where in the LDAP hierarchy your search begins, the extent, and the type of information it is looking for. Together these fields allow you to limit the search of the hierarchy to only the part of the tree that contains the user permissions.

•LDAP Base DN defines where in the LDAP hierarchy the server should begin searching for user information when it receives an authorization request from the security appliance.

•Search Scope 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) defines the RDN that uniquely identifies an entry in the LDAP server. Common naming attributes can include cn (Common Name), sAMAccountName, and userPrincipalName.

Figure E-2 shows a possible LDAP hierarchy for Example Corporation. Given this hierarchy, you could define your search in different ways. Table E-1 shows two possible search configurations.

In the first example configuration, when Terry establishes the IPSec tunnel with LDAP authorization required, the security appliance sends a search request to the LDAP server indicating it should search for Terry in the Engineering group. This search is quick.

In the second example configuration, the security appliance sends a search request indicating the server should search for Terry within Example Corporation. This search takes longer.

Table E-1 Example Search Configurations

#

LDAP Base DN

Search Scope

Naming Attribute

Result

1

group= Engineering,ou=People,dc=ExampleCorporation, dc=com

One Level

cn=Terry

Quicker search

2

dc=ExampleCorporation,dc=com

Subtree

cn=Terry

Longer search

Binding the Security Appliance to the LDAP Server

Some LDAP servers (including the Microsoft Active Directory server) require the security appliance to establish a handshake via authenticated binding before they accept requests for any other LDAP operations. The security appliance identifies itself for authenticated binding by attaching a Login DN field to the user authentication request. The Login DN field defines the authentication characteristics of the security appliance; these characteristics should correspond to those of a user with administrative privileges. An example Login DN field could be: cn=Administrator, cn=users, ou=people, dc=example, dc=com.

Note As an LDAP client, the security appliance does not support sending anonymous binds or requests.

Login DN Example for Active Directory

The Login DN is a username on the LDAP server that the security appliance uses to establish a trust between itself (the LDAP client) and the LDAP server during the Bind exchange, before a user search can take place.

For VPN authentication/authorization operations, and beginning with version 8.0.4 for retrieval of AD Groups, (which are read operations only when password-management changes are not required), the you can use the Login DN with fewer privileges. For example, the Login DN can be a user who is a memberOf the Domain Users group.

For VPN password-management changes, the Login DN must have Account Operators privileges.

In either of these cases, Super-user level privileges are not required for the Login/Bind DN. Refer to your LDAP Administrator guide for specific Login DN requirements.

Defining the Security Appliance LDAP Configuration

This section describes how to define the LDAP AV-pair attribute syntax. It includes the following topics:

Note The security appliance enforces the LDAP attributes based on attribute name, not numeric ID. RADIUS attributes, on the other hand, are enforced by numeric ID, not by name.

Authorization refers to the process of enforcing permissions or attributes. An LDAP server defined as an authentication or authorization server will enforce permissions or attributes if they are configured.

For software Version 7.0, LDAP attributes include the cVPN3000 prefix. For Version 7.1 and later, this prefix was removed.

Supported Cisco Attributes for LDAP Authorization

This section provides a complete list of attributes (Table E-2) for the ASA 5500, VPN 3000, and PIX 500 series security appliances. The table includes attribute support information for the VPN 3000 and PIX 500 series to assist you configure networks with a mixture of these security appliances.

A unique identifier for the AV pair. For example: ip:inacl#1= (for standard access lists) or webvpn:inacl# (for clientless SSL VPN access lists). 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 that sends the packet. Specify it as an IP address, a hostname, or the keyword "any." If using an IP address, the source wildcard mask must follow.

Source Wildcard Mask

The wildcard mask that applies to the source address.

Destination

Network or host that receives the packet. Specify as an IP address, a hostname, or the keyword "any." If using an IP address, the source wildcard mask must follow.

Destination Wildcard Mask

The wildcard mask that applies to the destination address.

Log

Generates a FILTER log message. You must use this keyword to generate events of severity level 9.

User-Based Attributes Policy Enforcement

Any standard LDAP attribute can be mapped to a well-known Vendor Specific Attribute (VSA) Likewise, one or more LDAP attribute(s) can be mapped to one or more Cisco LDAP attributes.

In this use case we configure the security appliance to enforce a simple banner for a user configured on an AD LDAP server. For this case, on the server, we use the Office field in the General tab to enter the banner text. This field uses the attribute named physicalDeliveryOfficeName. On the security appliance, we create an attribute map that maps physicalDeliveryOfficeName to the Cisco attribute Banner1. During authentication, the security appliance retrieves the value of physicalDeliveryOfficeName from the server, maps the value to the Cisco attribute Banner1, and displays the banner to the user.

This case applies to any connection type, including the IPSec VPN client, AnyConnect SSL VPN client, or clientless SSL VPN. For the purposes of this case, User1 is connecting through a clientless SSL VPN connection.

Step 1 Configure the attributes for a user on the AD/LDAP Server.

Right-click a user. The properties window displays (Figure E-3). Click the General tab and enter some banner text in the Office field. The Office field uses the AD/LDAP attribute physicalDeliveryOfficeName.

Figure E-3 Figure 3 LDAP User configuration

Step 2 Create an LDAP attribute map on the security appliance:

The following example creates the map Banner, and maps the AD/LDAP attribute physicalDeliveryOfficeName to the Cisco attribute Banner1:

The following example enters the aaa server host configuration more for the host 3.3.3.4, in the AAA server group MS_LDAP, and associates the attribute map Banner that you created in step 2:

hostname(config)# aaa-server MS_LDAP host 3.3.3.4

hostname(config-aaa-server-host)# ldap-attribute-map Banner

Step 4 Test the banner enforcement.

This example shows a clientless SSL connection and the banner enforced through the attribute map after the user authenticates (Figure E-4).

Figure E-4 Banner Displayed

Placing LDAP users in a specific Group-Policy

In this case we authenticate User1 on the AD LDAP server to a specific group policy on the security appliance. On the server, we use the Department field of the Organization tab to enter the name of the group policy. Then we create an attribute map and map Department to the Cisco attribute IETF-Radius-Class. During authentication, the security appliance retrieves the value of Department from the server, maps the value to the IETF-Radius-Class, and places User1 in the group policy.

This case applies to any connection type, including the IPSec VPN client, AnyConnect SSL VPN client, or clientless SSL VPN. For the purposes of this case, user1 is connecting through a clientless SSL VPN connection.

Step 1 Configure the attributes for the user on the AD LDAP Server.

Right-click the user. The Properties window displays (Figure E-5). Click the Organization tab and enter Group-Policy-1 in the Department field.

The following example enters the aaa server host configuration mode for the host 3.3.3.4, in the AAA server group MS_LDAP, and associates the attribute map group_policy that you created in step 2:

hostname(config)# aaa-server MS_LDAP host 3.3.3.4

hostname(config-aaa-server-host)# ldap-attribute-map group_policy

Step 4 Add the new group-policy on the security appliance and configure the required policy attributes that will be assigned to the user. For this case, we created the Group-policy-1, the name entered in the Department field on the server:

Step 5 Establish the VPN connection as the user would, and verify that the session inherits the attributes from Group-Policy1 (and any other applicable attributes from the default group-policy)

You can monitor the communication between the security appliance and the server by enabling the debug ldap 255 command from privileged EXEC mode. Below is sample output of this command. The output has been edited to provide the key messages:

[29] Authentication successful for user1 to 3.3.3.4

[29] Retrieving user attributes from server 3.3.3.4

[29] Retrieved Attributes:

[29] department: value = Group-Policy-1

[29] mapped to IETF-Radius-Class: value = Group-Policy-1

Enforcing Static IP Address Assignment for AnyConnect Tunnels

In this case we configure the AnyConnect client user Web1 to receive a static IP Address. We enter the address in the Assign Static IP Address field of the Dialin tab on the AD LDAP server. This field uses the msRADIUSFramedIPAddress attribute. We create an attribute map that maps it to the Cisco attribute IETF-Radius-Framed-IP-Address.

During authentication, the security appliance retrieves the value of msRADIUSFramedIPAddress from the server, maps the value to the Cisco attribute IETF-Radius-Framed-IP-Address, and provides the static address to User1 .

This case applies to full-tunnel clients, including the IPSec client and the SSL VPN clients (AnyConnect client 2.x and the legacy SSL VPN client).

Step 1 Configure the user attributes on the AD LDAP server.

Right-click on the user name. The Properties window displays (Figure E-6). Click the Dialin tab, check Assign Static IP Address, and enter an IP address. For this case we use 3.3.3.233.

The following example enters the aaa server host configuration mode for the host 3.3.3.4, in the AAA server group MS_LDAP, and associates the attribute map static_address that you created in step 2:

hostname(config)# aaa-server MS_LDAP host 3.3.3.4

hostname(config-aaa-server-host)# ldap-attribute-map static_address

Step 4 Verify the vpn-address-assigment command is configured to specify aaa by viewing this part of the configuration with the show run all vpn-addr-assign command:

vpn-addr-assign aaa

hostname(config)# show run all vpn-addr-assign

vpn-addr-assign aaa <<<< ensure this configured.

no vpn-addr-assign dhcp

vpn-addr-assign local

hostname(config)#

Step 5 Establish a connection to the security appliance with the AnyConnect client. Observe the following:

•The banner is received in the same sequence as a clientless connection (Figure E-7).

•The user receives the IP address configured on the server and mapped to the security appliance (Figure E-8).

Figure E-7 Verify the Banner for the AnyConnect Session

Figure E-8 AnyConnect Session Established

You can use the show vpn-sessiondb svc command to view the session details and verify the address assigned:

hostname# show vpn-sessiondb svc

Session Type: SVC

Username : web1 Index : 31

Assigned IP : 3.3.3.233 Public IP : 10.86.181.70

Protocol : Clientless SSL-Tunnel DTLS-Tunnel

Encryption : RC4 AES128 Hashing : SHA1

Bytes Tx : 304140 Bytes Rx : 470506

Group Policy : VPN_User_Group Tunnel Group : UseCase3_TunnelGroup

Login Time : 11:13:05 UTC Tue Aug 28 2007

Duration : 0h:01m:48s

NAC Result : Unknown

VLAN Mapping : N/A VLAN : none

BXB-ASA5540#

Enforcing Dial-in Allow or Deny Access

In this case, we create an LDAP attribute map that specifies the tunneling protocols allowed by the user. We map the Allow Access and Deny Access settings on the Dialin tab to the Cisco attribute Tunneling-Protocols. The Cisco Tunneling-Protocols supports the bit-map values shown in Table E-5:

Using this attribute, we create an Allow Access (TRUE) or a Deny Access (FALSE) condition for the protocols and enforce what method the user is allowed access with.

For this simplified example, by mapping the tunnel-protocol IPSec (4), we can create an allow (true) condition for the IPSec Client. We also map WebVPN (16) and SVC/AC (32) which is mapped as value of 48 (16+32) and create a deny (false) condition. This allows the user to connect to the security appliance using IPSec, but any attempt to connect using clientless SSL or the AnyConnect client is denied.

Another example of enforcing Dial-in Allow Acess or Deny Access can be found in the Tech Note ASA/PIX: Mapping VPN Clients to VPN Group Policies Through LDAP Configuration Example, at this URL:

Note If you select the third option "Control access through the Remote Access Policy", then a value is not returned from the server, and the permissions that are enforced are based on the internal group policy settings of the security appliance.

Step 2 Create an attribute map to allow both an IPSec and AnyConnect connection, but deny a clientless SSL connection.

In this case we create the map tunneling_protocols, and map the AD attribute msNPAllowDialin used by the Allow Access setting to the Cisco attribute Tunneling-Protocols using the map-name command, and add map values with the map-value command,

The following example enters the aaa server host configuration mode for the host 3.3.3.4, in the AAA server group MS_LDAP, and associates the attribute map tunneling_protocols that you created in step 2:

Using a PC as a remote user would, attempt connections using clientless SSL, the AnyConnect client, and the IPSec client. The clientless and AnyConnect connections should fail and the user should be informed that an unauthorized connection mechanism was the reason for the failed connection. The IPSec client should connect because IPSec is an allowed tunneling protocol according to attribute map.

Figure E-10 Login Denied Message for Clientless User

Figure E-11 Login Denied Message for AnyConnect Client User.

Enforcing Logon Hours and Time-of-Day Rules

In this use case we configure and enforce the hours that a clientless SSL user is allowed to access the network. A good example of this is when you want to allow a business partner access to the network only during normal business hours.

For this case, on the AD server, we use the Office field to enter the name of the partner. This field uses the physicalDeliveryOfficeName attribute. Then we create an attribute map on the security appliance to map that attribute to the Cisco attribute Access-Hours. During authentication, the security appliance retrieves the value of physicalDeliveryOfficeName (the Office field) and maps it to Access-Hours.

Step 1 Configure the user attributes on the AD LDAP server.

Select the user. Right click on Properties. The Properties window displays (Figure E-12). For this case, we use the Office field of the General tab:

Figure E-12 Active Directory - Time-range

Step 2 Create an attribute map.

In this case we create the attribute map access_hours and map the AD attribute physicalDeliveryOfficeName used by the Office field to the Cisco attribute Access-Hours.

The following example enters the aaa server host configuration mode for the host 3.3.3.4, in the AAA server group MS_LDAP, and associates the attribute map access_hours that you created in step 2:

hostname(config)# aaa-server MS_LDAP host 3.3.3.4

hostname(config-aaa-server-host)# ldap-attribute-map access_hours

Step 4 Configure time ranges for each value allowed on the server. In this case, we entered Partner in the Office field for User1. Therefore, there must be a time range configured for Partner. The following example configures Partner access hours from 9am to 5pm Monday through Friday:

hostname(config)# time-range Partner

hostname(config-time-range)# periodic weekdays 09:00 to 17:00

Configuring an External RADIUS Server

This section presents an overview of the RADIUS configuration procedure and defines the Cisco RADIUS attributes. It includes the following topics:

Reviewing the RADIUS Configuration Procedure

This section describes the RADIUS configuration steps required to support authentication and authorization of the security appliance users. Follow these steps to set up the RADIUS server to inter operate with the security appliance.

Step 1 Load the security appliance 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 security appliance attributes. Obtain this dictionary file, cisco3k.dct, from Software Center on CCO or from the security appliance 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 security appliance attribute. To define an attribute, use the attribute name or number, type, value, and vendor code (3076). For a list of security appliance RADIUS authorization attributes and values, see Table E-6.

Step 2 Set up the users or groups with the permissions and attributes to send during IPSec or SSL tunnel establishment.

Security Appliance RADIUS Authorization Attributes

Authorization refers to the process of enforcing permissions or attributes. A RADIUS server defined as an authentication server enforces permissions or attributes if they are configured.

Table E-6 lists all the possible security appliance supported RADIUS attributes that can be used for user authorization.

Note RADIUS attribute names do not contain the cVPN3000 prefix. Cisco Secure ACS 4.x supports this new nomenclature, but attribute names in pre-4.0 ACS releases still include the cVPN3000 prefix. The appliances enforce the RADIUS attributes based on attribute numeric ID, not attribute name. LDAP attributes are enforced by their name, not by the ID.

This text replaces the default string, "Application Access," on the clientless portal home page.

IE-Proxy-Server

Y

80

String

Single

IP address

IE-Proxy-Server-Policy

Y

81

Integer

Single

1 = No Modify

2 = No Proxy

3 = Auto detect

4 = Use Concentrator Setting

IE-Proxy-Exception-List

Y

82

String

Single

newline (\n) separated list of DNS domains

IE-Proxy-Bypass-Local

Y

83

Integer

Single

0 = None

1 = Local

IKE-Keepalive-Retry-Interval

Y

Y

Y

84

Integer

Single

2 - 10 seconds

Tunnel-Group-Lock

Y

Y

85

String

Single

Name of the tunnel group or "none"

Access-List-Inbound

Y

Y

86

String

Single

Access list ID

Access-List-Outbound

Y

Y

87

String

Single

Access list ID

Perfect-Forward-Secrecy-Enable

Y

Y

Y

88

Boolean

Single

0 = No

1 = Yes

NAC-Enable

Y

89

Integer

Single

0 = No

1 = Yes

NAC-Status-Query-Timer

Y

90

Integer

Single

30 - 1800 seconds

NAC-Revalidation-Timer

Y

91

Integer

Single

300 - 86400 seconds

NAC-Default-ACL

Y

92

String

Access list

WebVPN-URL-Entry-Enable

Y

Y

93

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-File-Access-Enable

Y

Y

94

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-File-Server-Entry-Enable

Y

Y

95

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-File-Server-Browsing-Enable

Y

Y

96

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-Port-Forwarding-Enable

Y

Y

97

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-Outlook-Exchange-Proxy-Enable

Y

Y

98

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-Port-Forwarding-HTTP-Proxy

Y

Y

99

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-Auto-Applet-Download-Enable

Y

Y

100

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-Citrix-Metaframe-Enable

Y

Y

101

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-Apply-ACL

Y

Y

102

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-SSL-VPN-Client-Enable

Y

Y

103

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-SSL-VPN-Client-Required

Y

Y

104

Integer

Single

0 = Disabled

1 = Enabled

WebVPN-SSL-VPN-Client-Keep- Installation

Y

Y

105

Integer

Single

0 = Disabled

1 = Enabled

SVC-Keepalive

Y

Y

107

Integer

Single

0 = Off

15 - 600 seconds

SVC-DPD-Interval-Client

Y

Y

108

Integer

Single

0 = Off

5 - 3600 seconds

SVC-DPD-Interval-Gateway

Y

Y

109

Integer

Single

0 = Off)

5 - 3600 seconds

SVC-Rekey-Time

Y

110

Integer

Single

0 = Disabled

1- 10080 minutes

WebVPN-Deny-Message

Y

116

String

Single

Valid string(up to 500 characters)

SVC-DTLS

Y

123

Integer

Single

0 = False

1 = True

SVC-MTU

Y

125

Integer

Single

MTU value

256 - 1406 in bytes

SVC-Modules

Y

127

String

Single

String (name of a module)

SVC-Profiles

Y

128

String

Single

String (name of a profile)

SVC-Ask

Y

131

String

Single

0 = Disabled

1 = Enabled

3 = Enable default service

5 = Enable default clientless

(2 and 4 not used)

SVC-Ask-Timeout

Y

132

Integer

Single

5 - 120 seconds

IE-Proxy-PAC-URL

Y

133

String

Single

PAC Address String

Strip-Realm

Y

Y

Y

135

Boolean

Single

0 = Disabled

1 = Enabled

Smart-Tunnel

Y

136

String

Single

Name of a Smart Tunnel

WebVPN-ActiveX-Relay

Y

137

Integer

Single

0 = Disabled

Otherwise = Enabled

Smart-Tunnel-Auto

Y

138

Integer

Single

0 = Disabled

1 = Enabled

2 = AutoStart

VLAN

Y

140

Integer

Single

0 - 4094

NAC-Settings

Y

141

String

Single

Name of NAC policy

Member-Of

Y

Y

145

String

Single

Comma delimited string, for example:

Engineering, Sales

Address-Pools

Y

Y

217

String

Single

Name of IP local pool

IPv6-Address-Pools

Y

218

String

Single

Name of IP local pool-IPv6

IPv6-VPN-Filter

Y

219

String

Single

ACL value

Privilege-Level

Y

Y

220

Integer

Single

An integer between 0 and 15.

WebVPN-Macro-Value1

Y

223

String

Single

Unbounded

WebVPN-Macro-Value2

Y

224

String

Single

Unbounded

Configuring an External TACACS+ Server

The security appliance provides support for TACACS+ attributes. TACACS+ separates the functions of authentication, authorization, and accounting. The protocol supports two types of attributes: mandatory and optional. Both the server and client must understand a mandatory attribute, and the mandatory attribute must be applied to the user. An optional attribute may or may not be understood or used.

Note To use TACACS+ attributes, make sure you have enabled AAA services on the NAS.