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.
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.
All authorization is currently done via LDAP to AD.
This is since it seams rare in Radius-servers to support only radius authorization requests without first doing authentication, think use case certificates.
(Would love to see the ISE support that as well, might already do with proper configuration?)
Today both OTP-services are address direct from the ASA and being run on the same server but with different profiles(behavior) being distinguished by incoming UDP port. That is since as far as I know the ASA does not send any useful attributes I can look at in the Access-Request.
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 authentications 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.
The ISE does not, as far as I have been told, support listening on multiple ports or IP-addresses(which could be one way of differentiating the requests). Ideally the ASA would give me information about the Connection Profile/Tunnel Group being used in one of the available attributes in the Access-Request, but currently that is not the case as far as I know.
So, this gives me for the moment a problem which I hope you could be able to help me solve.
One solution that has been suggested is to have user login using username such as user@domain or domain\user and use username strip options to extract the username before submitting to a external Token server using RADIUS proxy. The prefix/suffix cold be used to make proxy selection.
Domain would i this case be something bogus to indicate diffrent tunnel-groups.
From a technical perspectiv that will probalbly work, but from a administrativ perspective I will have a hard time instructing my users to change the behaviour. Could this in any way be done without having the users actually type domain info, i.e. have it automatically inserted?
I also heard roumors, not committed in roadmap, that there should be investigations in options to send specific ASA attributes in RADIUS request based on criteria such as Tunnel Group. That would be wonderfull.
The documentation you are refeering to am I familiar with, we are actually using just that software.
What the documentation sugests is pretty much what we do today, just that we are using multiple variations of diffrent OTP-methods/Connection Profiles(Tunnel Groups).
The problem as I see it arises when I try to proxy all those authentication methods via a single ISE installation. I then have no way to know to which OTP backend to proxy/forward the request to since there is no attribute to distinguish one methods requests from the other.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...