I'm using Cisco doc #13831, by the name, "Locking Users into a VPN 3000 Concentrator Group usin ga RADIUS Server"
I've followed the directions therein, but I log into the "Everyone" group, and stay there; I'm never assigned to the proper group that is dictated by my RADIUS server. I've verified by verbose-logging on RADIUS, that the class attribute #25 is being returned in the 'authentication-accept' packet & is in the proper syntax as described in that doc. The doc doesn't explain whether the "Group Lock" feature must be used in the Everyone Group, or in the 'real' groups specified on the Concentrator.
Is anyone else using RADIUS to assign people to groups in the 3000-Series Concentrator?
In order to configure group lock, send the group policy name in the class attribute 25 on the Remote Authentication Dial-In User Service (RADIUS) server and choose the group to lock the user into within the policy. For example, in order to lock the Cisco 123 user into the RemoteGroup group, define the Internet Engineering Task Force (IETF) attribute 25 class OU=RemotePolicy; for this user on the RADIUS server.
Thanks for the reply. However, I tried this, and it didn't work. The concentrator disregards the RADIUS attribute. There's nothing reflecting anything about attributes in the server-side log, or the client side log. I know the RADIUS accept-packet contains the proper string, because the verbose RADIUS logging tells me so.
The paper I read says to create a dummy-group that's totally locked down, and have the user authenticate into that group. Then magically I guess, the concentrator will move the user out of this dummy-group, into the group specified by the RADIUS attribute.
Make sure your base group does not have "Group Lock" checked (that is on the IPSec tab). Also make sure your attribute 25 has OU=Classname; The OU has to be in CAPS, the classname has to match exactly the VPN group name, capitalization counts, and it has to be terminated with a semicolon.
Once you've got that it should work.
If you're using ACS, I've had problems on ACS 3.3 doing this when using a RADIUS type other than the RADIUS (VPN 3000...), but I have had this working with other RADIUS servers without any issue.
The RADIUS attribute is configured as you suggest. I was not able to log into the concentrator at all, until I gave an IP pool to the "Everyone" group. When I log in, I get an IP from that pool, which shows me that I'm always entering the Everyone group, instead of being moved to the proper group.
The document doesn't say to assign an IP pool to the Everyone group, yet I can't log in at all, without it present.
Lastly, Question: The username I'm loging in under, does it NEED to be a locally-authenticated user, or can it be a RADIUS-authenticated user? What I'm driving towards, is a RADIUS-authenticated user who receives group-assignment info from RADIUS as well.
Regarding the IP pool, what you are seeing is how the box works. When the user first logs in they will be initially in the Base Group, and then the Class attribute will switch them to the appropriate VPN group. In order to prevent anyone from doing anything in the base group, apply a deny all filter to it.
If you cannot successfully login to the Base Group it won't work, so make sure that works before trying to setup the group switching. If you set your logging level on the VPN concentrator high enough you will see this take place, you will also see the switch to the new group. I'd also recommend using the IPSec client to test the other group directly to make sure that you can successfully sign into that group. The problem may end up being a problem with the group configuration on the VPN box, and not the RADIUS configuration.
If you're still having trouble with it try to get some debug logs from the VPN Concentrator.
I am assuming by locally-authenticated you mean local to the VPN box. In this case, no, you can use a RADIUS authenticated user, and you do not need to have any trace of the user in the VPN concentrator.
If you mean locally-authenticated as in local to an ACS box, the answer is still no, you can use an external user database, as long as you have configured the appropriate ACS group mapping.
Use the IPSec client and verify the group you are switching to is working correctly, and if it still doesn't work, please send some additional information:
What RADIUS server are you using?
Can you send the configuration of the reply attributes, or even better, the authentication conversation between your RADIUS and VPN box (be sure to wash it first!)?
This is actually working now. I was trying so many different things, I stopped recording what I was doing. I do believe that there's more to making this work than is described in article 13831. I think it involves inheritance from the Base Group, into the subordinate groups that prevented it from working.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...