Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

ASA VPN with ISE and diffrent OTP backends for authentication

Hi,

I have an AAA-problem I hope to get some help solving.

The problem in short is: How to make the ASA via ISE send Radius Access Requests to diffrent given OTP backends given a connection to a certain Tunnel Group.

BACKGROUND:

I will try to give you a brief picture of the scenario this is what I currently have.

A VPN system ( ASA 8.4(4) ) where I allow my users to choose from 3 different authentication methods being

1) Certificate (on smart-card)

2) Pledge - OTP token (One-Time-Password delivered via application in smartphone: using pledge from Nordic Edge OTP-Server)

3) SMS - OTP token (OTP via SMS from Nordic Edge OTP-Server)

The choice corresponds to different Connection Profiles/Tunnel Groups.

Today all authentication requests go directly to the OTP-servers and authorization goes directly to AD via LDAP.

THE PROBLEM:

The problem arises when I try to put in the ISE into the mix.

What I obviously(?) would like to do is to have all network authentication/autorization go thru my ISE platform to take advantage of centralized administration, monitoring etc.

Still I would need to use the different backend databases such as AD and Nordic Edge OTP-Server, but then proxied via ISE.

For me to be able to know to which backend AAA system to proxy I must somehow be able to distinguish the incoming Radius Access-Requests.

                 

WHAT IS KNOWN:

As of ASA 8.4.3 the Radius Access-Request contains 2 new attributes, Tunnel Group Name and Client Type, when a VPN user connects.

http://www.cisco.com/en/US/docs/security/asa/asa84/configuration/guide/ref_extserver.html#wp1802187

QUESTION:

So, in theory is seams I can achive what I want looking at the Radius Access-Request attribute "Tunnel Group Name" and forward my request to diffrent OTP backends for the Autentication part. But, how do I actually go ahead and configure that in ISE?

I do not see this attribute when I look at the Radius Authentication details for a AAA autentication from the ASA to the ISE.

Best regards

/Mattias

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

ASA VPN with ISE and diffrent OTP backends for authentication

I think you may be hitting the following issue:

CSCtz49846: ISE does not match condition with VPN attribute 146 Tunnel-Group-Name

This issue is not specific to this attribute as can be seen from the workaround in the release note

Workaround

Ensure that attribute name does not include a '.' character. This also applies to some of the existing attributes in the Cisco-VPN300 dictionary. The attribute names should similarly be modified so that they do not include a '.' character.

3 REPLIES
New Member

ASA VPN with ISE and diffrent OTP backends for authentication

Hi,

I have an update for this quite broad question.

I have now came a bit further on the path.

Now the needed Radius Access Attribute are available in ISE after adding them in

"Policy Elements" -> "Dictionaris" -> "System" -> "Radius" -> "Cisco-VPN3000".

I added both the attribute 146 Tunnel-Group-Name which I realy need to achive what I want(select diffrent OTP-backends depending on Tunnel Group in ASA) and the other new attribute 150 Client-Type which could be intresting to look at as well.

Here the "Diagnostics Tools" -> "Generel tools" -> "TCP Dump" and Wireshare helped me understand how this worked.

With that I could really see the attributes in the radius access requests going in to the ASA.

Now looking at a request in "Radius Authentication details" I have

---

Other Attributes:

ConfigVersionId=29,Device Port=1025,DestinationPort=1812,RadiusPacketType=AccessRequest,Protocol=Radius,CVPN3000/ASA/PIX7.x-Tunnel-Group-Name=SMHI-TG-RA-ISESMS,CVPN3000/ASA/PIX7.x-Client-Type=,CPMSessionID=ac100865000006294FD60A7F,.....

----

Ok, the tunnel group name attribute seems to be understood correct, but Client-Type just say =, no value for that.

That is strange, I must have defined that wrong(?), but lets leave that for now, I do not really need it for the moment being.

So now when I have this Tunnel-Group-Name attribute available I want to use it in my Rule-Based Authentication Policy.

Problem now is that as soon as I in an expression add a criteria containing Cisco-VPN3000:CVPN3000/ASA/PIX7.x-Tunnel-Group-Name matches .* (just anything), then that row does not match any more. It still work matching against NAS-IP and other attributes.

What could it be I have missed?

Best regards

/Mattias

Cisco Employee

ASA VPN with ISE and diffrent OTP backends for authentication

I think you may be hitting the following issue:

CSCtz49846: ISE does not match condition with VPN attribute 146 Tunnel-Group-Name

This issue is not specific to this attribute as can be seen from the workaround in the release note

Workaround

Ensure that attribute name does not include a '.' character. This also applies to some of the existing attributes in the Cisco-VPN300 dictionary. The attribute names should similarly be modified so that they do not include a '.' character.

New Member

ASA VPN with ISE and diffrent OTP backends for authentication

Thanks alot, that was it!

It also solved the problem that I did not see any values for the Client-Type attribute.

I renamed both thoose attributes to not include a . in the name.

After changing the attribute name in the dictonary the authentication policy changed to reflect that.

I hoped it would now directly work, but that was not the case. Looking at the "Authentication Details" the name for the attribute was still the old name. I figured some component must be restarted to fetch the new attribute name. Don't knowing exacly which one I restarted the whole primary ISE-box and the it just worked.

I have been spending a lot of hours on this one and thought I have missunderstood the whole concept. I'm really glad to hear it was a bug and not me...

2185
Views
0
Helpful
3
Replies