Way to differentiate Services using a single group of Radius servers on an ASA

[derek.small]

Here is the setup.  I have a single ASA, and single Microsoft NPS server acting as the Radius server.  I would like to have two VPN group profiles on my NPS server, one for each of my two user groups. In the past, I have resorted to using two NPS/Radius servers.  On the ASA, I define two Radius server groups and use a different Radius group for each of my two VPN group profiles.  Then each NPS/Radius server has different parameters for my two groups.  I would like to be able to do this with one NPS/Radius server, but have never found a way to do that.  I need to be able to send the Radius login attempts to the Radius server so that I can identify the two different groups on the NPS/Radius server.  On a router, I have used two different loopback interfaces, and used a different one for the source of each Radius group, then I can used the client-IP to determine which Network policy to apply, but that isn't an option on an ASA as far as I can tell.

Is there someway on an ASA, to create two Radius server groups, each using the same Radius server, but pass a parameter to the Radius server so it can differentiate between the two different requests? Something like this:

!
aaa-server RADIUS-1 protocol radius
aaa-server RADIUS-1 (inside) host 10.1.1.32
key h8ha789sdf
aaa-server RADIUS-1 VSA 26 string Group1
!
aaa-server RADIUS-2 protocol radius
aaa-server RADIUS-2 (inside) host 10.1.1.32
key h8ha789sdf
aaa-server RADIUS-2 VSA 26 string Group2
!

[Rob Ingram]

Hi, can you clarify your requirement please.

What value/parameter are you expecting to see?
Why can't the RADIUS server already distinguish the different requests?

[derek.small]

I need to have two different VPN group profiles, and I need each group profile to be treated differently by the NPS server.  The only response I can give to your question about why Radius can't distinguish between the different requests is, that is what I'm asking, how can I present the requests to the Radius server so it CAN distinguish between the two different requests. I need a way to let the NPS server distinguish between an authentication request to one VPN group versus the other VPN group.

[Rob Ingram · Accepted solution]

I assume you are referring to Tunnel Groups?
On the RADIUS server you can determine the Tunnel Group using "Cisco-VPN3000=CVPN3000/ASA/PIX7x-Tunnel-Group-Name" and write a rule to match against the Tunnel Group the user is connecting from.

[derek.small]

I think I can make that work.  Thank you!

[derek.small]

I spoke too soon.  It looks like this is passing the VPN group (or tunnel group) name back to the ASA from the NPS server.  I need to have two different Network Policies on the NPS server, and have one of them used when a user logs into one VPN group on the ASA, and the other NPS Network policy used when a user logs into the other VPN group on the ASA.

So to back up a step...

I want to have two AD groups for remote access.  One we'll call "Internal-Users", and a second AD group, we'll call "Vendor-Users".  The first group should connect using a VPN-group called "Internal-Users", and the second group should connect using a VPN-group called "Vendor-Users".  The "Internal-Users" group would be allowed to access a certain list of resources on the network, and the "Vendor-Users" would be allowed to access a different list of resources.

In the past I've done this by using two different Radius servers, and each Radius server has an NPS policy which matches a different AD group, but I shouldn't have to have a different set of Radius servers for each VPN group.  Why can't I just include something so the Radius/NPS server can distinguish between the two different logins and match one of two different Network Policies on the same Radius/NPS server.  

[Rob Ingram]

Does creating 2 policies combining the different AD Group + TunnelGroup not give you the desired result? If the user is not connected to the "Internal-Users" AD Group and connected to the "Interal-Users" Tunnel Group then it would not match that rule and move to the next.

[derek.small]

Sorry found out test user was in a nested AD group which was matching the first NPS Network Policy.  Once we got the test accounts set up correctly, this worked.

Thanks again.