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.