LTLnetworker | IT hálózatok, biztonság, Cisco

               IT networks, security, Cisco

Using Cisco ISE as a generic RADIUS server

Posted by ltlnetworker on August 31, 2014


Cisco ISE is an identity-based policy server featuring a wide range of functions from RADIUS CLI authentication to workstation posturing. With just a base license it includes a full-featured RADIUS server and it is capable of performing trivial RADIUS tasks which would not require such a sophisticated product themselves. For the functions described in this article Cisco Secure ACS could have been commonly chosen some years earlier. ISE’s policy logic and web interface is quite different.

The following use cases are described:

  • Cisco device access (admin login)
  • IOS switch, IOS router
  • Nexus switch (NX-OS)
  • ASA firewall
  • wireless controller
  • ACE
  • remote access VPN (RAVPN) with Cisco ASA
  • Cisco VPN Client
  • AnyConnect
  • wireless 802.1X

For simplicity’s sake all kinds of access are authenticated in Active Directory. Authorization is based on AD group memberships.

These requests can be differentiated by incoming RADIUS attributes. A Cisco VPN Client authentication request contains Service-Type[6] = Framed[2] .

ASA# debug radius
...
Radius: Type = 6 (0x06) Service-Type
Radius: Length = 6 (0x06)
Radius: Value (Hex) = 0x2
...

An AnyConnect authentication request contains no Service-Type attributes unfortunately. IOS switches and routers are able to put Service-Type[6] = Login[1] in the request with the
radius-server attribute 6 on-for-login-auth
command.

switch2960(config)#radius-server attribute 6 on-for-login-auth
switch2960(config)#
002685: Aug 25 10:16:53.812 CET-DST: %PARSER-5-CFGLOG_LOGGEDCMD: User:user1  logged command:radius-server attribute 6 on-for-login-auth
switch2960(config)#debug radius
002686: Aug 25 10:17:09 CET-DST: RADIUS/ENCODE(000003B9): ask "Password: "
002687: Aug 25 10:17:09 CET-DST: RADIUS/ENCODE(000003B9): send packet; GET_PASSWORD
002688: Aug 25 10:17:14 CET-DST: RADIUS/ENCODE(000003B9):Orig. component type = Exec
002689: Aug 25 10:17:14 CET-DST: RADIUS(000003B9): Config NAS IP: 0.0.0.0
002690: Aug 25 10:17:14 CET-DST: RADIUS(000003B9): Config NAS IPv6: ::
002691: Aug 25 10:17:14 CET-DST: RADIUS/ENCODE(000003B9): acct_session_id: 943
002692: Aug 25 10:17:14 CET-DST: RADIUS(000003B9): sending
002693: Aug 25 10:17:14 CET-DST: RADIUS/ENCODE: Best Local IP-Address 10.1.1.11 for Radius-Server 10.1.1.22
002694: Aug 25 10:17:14 CET-DST: RADIUS(000003B9): Send Access-Request to 10.1.1.22:1812 id 1645/23, len 76
002695: Aug 25 10:17:14 CET-DST: RADIUS:  authenticator 0C CD 8D 7D B8 71 1E 6B - 71 F0 D7 BE 52 E6 8F A6
002696: Aug 25 10:17:14 CET-DST: RADIUS:  User-Name           [1]   8   "user1"
002697: Aug 25 10:17:14 CET-DST: RADIUS:  User-Password       [2]   18  *
002698: Aug 25 10:17:14 CET-DST: RADIUS:  NAS-Port            [5]   6   3                        
002699: Aug 25 10:17:14 CET-DST: RADIUS:  NAS-Port-Id         [87]  6   "tty3"
002700: Aug 25 10:17:14 CET-DST: RADIUS:  NAS-Port-Type       [61]  6   Virtual                   [5]
002701: Aug 25 10:17:14 CET-DST: RADIUS:  Service-Type        [6]   6   Login                     [1]
002702: Aug 25 10:17:14 CET-DST: RADIUS:  NAS-IP-Address      [4]   6   10.1.1.11              
002703: Aug 25 10:17:14 CET-DST: RADIUS(000003B9): Sending a IPv4 Radius Packet

So sometimes the differentiation by Service-Type is possible but neither an ASA ssh login nor an ASA AnyConnect connection has a Service-Type attribute in the Access-Request. AnyConnect and Cisco VPN client connections can be identified by Client-Type attribute 150 which was introduced in ASA version 8.4(3). This attribute belongs to Cisco VPN 3000/ASA/PIX 7.x+ RADIUS VSAs. The vendor ID for this Cisco RADIUS implementation is 3076. Its values are:

1 = Cisco VPN Client (IKEv1)
2 = AnyConnect Client SSL VPN
3 = Clientless SSL VPN
4 = Cut-Through-Proxy
5 = L2TP/IPsec SSL VPN
6 = AnyConnect Client IPsec VPN (IKEv2)

ASA RADIUS debug:
ASA#debug radius
...
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 150 (0x96) Client-Type
Radius: Length = 6 (0x06)
Radius: Value (Integer) = 2 (0x0002)
...

Received and sent attributes can be seen on ISE authentication detail page. This screenshot shows the AnyConnect client type among the received attributes:
 
i08-ISE-authc-det-AnyConnect

If the authentication source is always AD we don’t need to create very granular authentication rules. This example still shows how to restrict the allowed protocols used in the RADIUS requests. The authentication rule conditions are capable of differentiating between a wired MAB request from a switch and a CLI login request from the same switch. You may want to lock down the allowed protocol list just to the necessary items. We have four rules in the authentication policy:

Rule name

Condition

Protocols

Identity Source

Remark

MAB If Wired_MAB OR Wireless_MAB Default Network Access Internal  Endpoints factory rule, not used
Wireless dot1x Wireless_802.1X Default Network Access ADinfra
ASA Device  Type EQUALS All Device  Types#ASA RAVPN-ASAadmin AD_intuser ASA RAVPN and admin access
Device access Device  Type NOT  EQUALS All Device  Types#ASA Default Network Access AD_intuser Network device access

In this example we use a dedicated rule for the ASA firewall and another rule for the rest of the devices. This ASA rule covers RAVPN as well as ssh/ASDM login authentication though we might as well split it into two rules. SSH/ASDM admin access generates PAP request inside the RADIUS request. RAVPN authentication uses PAP by default but we set it to MS-CHAPv2 to support password change on VPN clients. It is set by this command on ASA:

tunnel-group partner type remote-access
tunnel-group partner general-attributes
 authentication-server-group ISE
 default-group-policy GP-partner
 password-management password-expire-in-days 3
tunnel-group partner ipsec-attributes
 ikev1 pre-shared-key xxxx

i01-password-management-ASDM

AD_intuser is an identity source sequence: ADinfra + Internal Users. If AD is inaccessible, a fallback admin user (ISE internal user) can log in via VPN and log in to the devices.

Defaul network access is a factory-default protocol list allowing a bunch of protocols:

i07-ISE-Allowed-Protocols-Default

You may want to define your own Allowed Protocols set and enable just what is needed. RAVPN-ASAadmin contains only PAP/ASCII and MSCHAPv2 for the above reasons.

The granular access control is defined in the authorization policy:

Rule name

Identity group and Conditions

Permissions

Remark

Wireless Black List Default

Blacklist AND Wireless_Access

Blackhole_Wireless_Access

factory rule, not used

Profiled Cisco IP Phones

Cisco-IP-Phone

Cisco_IP_Phones

factory rule, not used

Profiled Non Cisco IP Phones

Non_Cisco_Profiled_Phones

Non_Cisco_IP_Phones

factory rule, not used

AnyConnect AD admin

PIX7x-Client-Type EQUALS AnyConnect-Client-SSL-VPN AND
ADinfra:ExternalGroups EQUALS corp.local/corp/SecGroups/VPN/RAVPN-admin

Permit-AnyConnect-admin

RAVPN

Cisco VPN Client AD admin

PIX7x-Client-Type EQUALS Cisco-VPN-Client AND
ADinfra:ExternalGroups EQUALS corp.local/corp/SecGroups/VPN/RAVPN-admin

Permit-VPNclient-admin

RAVPN

Cisco VPN Client AD admin2

PIX7x-Client-Type EQUALS Cisco-VPN-Client AND
ADinfra:ExternalGroups EQUALS corp.local/corp/SecGroups/VPN/RAVPN-admin2

Permit-VPNclient-admin

RAVPN

Cisco VPN Client AD partner

PIX7x-Client-Type EQUALS Cisco-VPN-Client AND
ADinfra:ExternalGroups EQUALS corp.local/corp/SecGroups/VPN/RAVPN-partner

Permit-VPNclient-partner

RAVPN

Wireless 802.1X AD

Wireless_Access AND
Device Type EQUALS All Device Types#WLC

Permit-WLAN

Wireless 802.1X

Device access ASA AD

Device Type EQUALS All Device Types#ASA AND
ADinfra:ExternalGroups EQUALS corp.local/corp/SecGroups/Network/FW-Admin

DevicePermit-priv15

ASA login (ssh, ASDM)

Device access AD

Device Type EQUALS All Device Types AND
ADinfra:ExternalGroups EQUALS corp.local/corp/SecGroups/Network/Network-Admin

DevicePermit-priv15

Login to network devices

Default

 

DenyAccess

if no matches

We have 3 unused factory rules on the top that we did not delete. We differentiate between AnyConnect and Cisco VPN Client users. AD membership determines which one can be used by who. RAVPN-admin members can connect both with AnyConnect and Cisco VPN Client. RAVPN-admin2 members are allowed to use only AnyConnect but they get the same all-access authorization profile.

Another VPN group is the partner group. Members of this AD group are provided with a different authorization profile resulting in a different ASA group-policy with another IP pool. Other (more restrictive) firewall rules can be created for this pool and the group-policy also contains different security settings.

The device access rules can be split by device types. In this example ASA devices have a dedicated rule and all the switch, WLC, router logins etc. are covered by another rule. The returned profile is the same but could be tailored by device type.

The DevicePermit-priv15 authorization profile content:

            (all profiles return ACCESS_ACCEPT except for DenyAccess)

Name

Returned attributes

Remark

DevicePermit-priv15

cisco-av-pair = priv-lvl=15 (appears as Web Authentication (Local Web Auth) on the GUI)

cisco-av-pair = shell:roles=”network-admin” (for NX-OS)

RADIUS:Service-Type[6] = Administrative [6] (for ASA and WLC)

enable mode CLI/admin access (IOS, NX-OS, ASA and WLC)

As you can see, IOS, NX-OS and WLC devices require various RADIUS attributes to place the user in the privileged mode/role. We can add all the necessary attributes to the same profile. All the devices will receive all the attributes but that’s no problem, the relevant will be considered and the others will be ignored by the device (though I have seen a case when ACE’s shell:Admin=Admin default-domain attribute sent by ACS confused an IOS device).

IOS devices and ASA firewalls require
    cisco-av-pair = priv-lvl=15

but they accept the oldschool format too:
    cisco-av-pair = shell:priv-lvl=15

The authorization profile page has predefined options for the most commonly used attributes. If you add an attribute manually matching a predefined item (e. g. because you don’t know that Local Web Auth actually adds cisco-av-pair = priv-lvl=15, explanation here) its appearance will change after submitting. The Attributes Details section always shows the resulting attributes in clear text. Illustration:

i02-ISE-Devicepermit-priv15-create

After submitting the appearance changes like this:

i03-ISE-Devicepermit-priv15-result

If you have Cisco ACE too, it requires an attribute which is VSA [type 26] with Vendor ID of Cisco [9] and sub-type of cisco-av-pair [1]. The value is

    shell:=
that is, to access the Admin context:
    shell:Admin=Admin default-domain

Cisco AV-pairs are a bit hard to grasp for the first time. Standard RADIUS attributes have type, length and value. A RADIUS VSA attribute has type, length, Vendor ID, sub-type, sub-length and value. The ‘value’, in turn, is composed of a service, a Cisco attribute string, an equal sign (or * for optional attributes) and a string value.

Further authorization profile contents:

 

Name

Returned attributes

Remark

Permit-AnyConnect-admin

RADIUS:Class[25] = OU=GP-admin
appears as

ASA VPN   =    OU=GP-admin

AnyConnect users, enforcing group-policy based on AD group membership

Permit-VPNclient-admin

RADIUS:Class[25] = OU=GP-admin
appears as

ASA VPN   =    OU=GP-admin

Cisco VPN Client users, enforcing group-policy based on AD group membership

Permit-VPNclient-partner

RADIUS:Class[25] = OU=GP-partner
appears as

ASA VPN   =    OU=GP-partner

Cisco VPN Client users, enforcing group-policy based on AD group membership

Permit-WLAN

 

Wireless 802.1X

 

The Class[25] attribute that specifies the ASA group-policy can be typed in the ASA VPN field or added as a custom attribute. The result is the same. The “ASA VPN” field is a built-in placeholder for the Class attribute. This way we can override the group policy regardless of which VPN group (tunnel-group) the client connects with.

i45-ISE-Permit-VPNclient-partner-dual

Wireless 802.1X does not require any special attributes apart from the Access-Accept message but it can be customized in various ways exploiting ISE and BYOD functions. For example, a wireless ACL or a URL redirect ACL can be set in the authorization profile. Some useful guides and examples:

Central Web Authentication with FlexConnect APs on a WLC with ISE Configuration Example
Cisco TrustSec 2.0 Design and Implementation Guide
SBA: LAN and Wireless LAN 802.1X Authentication Deployment Guide
Wireless BYOD for FlexConnect Deployment Guide

To sum it up, ISE is full-featured RADIUS server. We can set up device access rules reaching almost the same functions as with Cisco Secure ACS and TACACS+ protocol. Command authorization is an exception as it is not available in RADIUS, only in TACACS+.

Another good article on this topic:
Cisco CLI access using Radius and ISE

Software versions used in the examples:

Cisco ISE 1.2.0.899 patch 7
c2960s-universalk9-mz.152-1.E2.bin
asa915-smp-k8.bin
Cisco VPN Client 5.0.07.0290
Cisco AnyConnect Secure Mobility Client 3.1.05160

Advertisements

9 Responses to “Using Cisco ISE as a generic RADIUS server”

  1. parag said

    Really Thanks… Very informative article…for dynamic group policy assigment …Even if you do not put OU= static text in ISE , still ASA can recognise group policy name,,I have tested and its working…

    Parag Mahajan

  2. Wild Cat said

    Hooray!! You skipped ACL’s.

  3. Nitin said

    which ISE node , we have to use for RADIUS authentication

  4. Nitin said

    Is it a Policy node or admin node?

  5. Nitin said

    Thanks for your reply.
    Is it necessary that we configure AAA services on the policy node.? Can we configure it on Admin Node. ?

    or it depend upon topology to topology.?

    may be is it upon us where to configure AAA either on Admin or policy node?

    Thanks

  6. lucky said

    how we can access a ISE Server if there is a Firewall in between Switch & ISE… & ISE ip is NATTED to let say 5.5.5.5… we are able to ping ISE from Switch… but when we configure it for dot1x & MAB… it say “radius server dead”… is it some NATTING issue…. i mean from Switch if we ping 5.5.5.5 it is successful…. but when we define radius-server host 5.5.5.5 auth-port 1812 acct-port 1813 key cisco… it gives error… it is not able to access ISE…

  7. Ram Katha said

    I really delighted to find this internet site on bing, just what I was searching for : D too saved to fav.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: