Authentication on Cisco VPN 3000 Concentrator

Unanswered Question
Apr 1st, 2008

I have a single 3000-series concentrator. Due to various forces at work in my organization, I must authenticate some users on an RSA server, and some users on a seperate server running RADIUS. In short, I need to authenticate people in "group-A" on authentication server-A, and people in "group-B" on authentication server-B.

I'm dictating VPN group-membership by a profile file I send to the user that has the group-name and password pre-specified. That's how I get the person into the group, then once they're in group-A, they will be authenticated on "auth-server-A". Clear as mud?


Question: Has this been done before, and if so how?

NOTE: I'm not trying to authenticate entry into the VPN group on the authentication server, I'm trying to authenticate the *user* himself on the auth-server. Entry into the VPN-group is determined by the group-name and PW stored in the client Profile.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Richard Burts Tue, 04/01/2008 - 14:51


I have not done what you describe to authenticate one group with one server and authenticate another group with a different server. so I can not say with certainty that it works. But I would think that it would work. Since there is an option to specify an authentication server at the group level (and since any server configured at the group level over-rides the global server) I would believe that you could successfully authenticate one group via RSA and another group via Radius.



abatson Tue, 04/01/2008 - 16:47

Thanks for the reply, but be careful, I'm not trying to authenticate users' admission into the groups, I'm trying to authenticate the users themselves. Admission into the groups is via credentials stored in the client's profile.

What I was afraid of, is that the Authentication Servers listed at the group-level, might be for authenticating admission into the group, and not authenticating users themselves. I had a CCIE repond to this issue on another forum on another website; I'll post the solution here if it works. He seemed to think it was a common configuration.

cisco24x7 Tue, 04/01/2008 - 17:51


That is exactly what I have setup at my current work place.

I have a pair of VPN concentrator 3030 running in load-sharing mode.

Both the External and Internal interfaces are connected to the

Firewall for extra protection. IPSec traffics are allowed through

the firewall to terminate at the cluster IP address of the VPN

concentrator. Once IPsec is decrypted by the Concentrator, it goes

back into the firewall for inspection and access for maximum

security and access-control

We have two different groups of remote access users, both use

the same pre-share key. One group is "admin", the other group

is "normal" users. The "admin" group uses RSA SecurID for remote access

authentication. The "normal" group uses Steelbelt Radius

for remote access authentication. We use profile on the radius to

control IP pool that will be assign to "admin" and "normal" group.

In other words, if a user belong to "admin", he will get ip address

from pool_A and the firewall will allow unlimited access to pool_A.

A user belong to "normal" group will get ip address from pool_B.

Firewall will restrict access from pool_B to certain resources.

This is done by the Radius server returning the attributes back

to the user such as IP address and other things.

It is a very simple to setup. I will post the link tomorrow.

We decided to go with RSA SecurID and Juniper Steelbelted radius

because both of these run on Linux and not windows.

"I'm not trying to authenticate users' admission into the groups, I'm trying to authenticate the users themselves"

This is what Cisco referred to as "extended"

authentication. I think that what you meant

as "Admission into the groups is via credentials stored in the client's profile".

This is referred to vpngroup and pre-share


CCIE Security

Richard Burts Tue, 04/01/2008 - 18:42


I AM careful. My suggestion was not about how to authenticate admission into the group. My suggestion was how to authenticate the individual user. The authentication server configured at the group level does not authenticate admission into the group but authenticates the individual user - which is what you want to do.



abatson Wed, 04/02/2008 - 06:41

I just successfully tested authentication for two different users; one on an RSA server, and one on a RADIUS server. This meets my immediate requirements.

Cavaet: In Configuration | System | Servers | Authentication Servers, the concentrator only allows creation of one server of each type, (SDI, RADIUS, NT Domain....) So, if I had two different RSA (SDI) Servers to authenticate to, I'd be out of luck with one of them. Luckily, I only need to authenticate to one single RSA and one single RADIUS server (for now)..

Do I need to buy another concentrator when the next RSA server comes along, that I need to auth to? (I think I'll try an ASA this time..)

Richard Burts Wed, 04/02/2008 - 11:47


It sort of depends on how you want to use the RSA/SDI authentication servers. The normal method is that multiple servers work together in a group and share the processing load. You need to configure only a single server on the concentrator. And when the concentrator establishes its session with RSA it dynamically learns the other members of the group.

And if you are thinking about getting any more concentrators you would certainly be better off to get an ASA next time.



abatson Thu, 04/03/2008 - 06:06


Normally, you're right; you'd specify seperate servers for redundancy sake. --However what I'm up against, is that the "two different" RSA servers are actually in two different realms meaning that they're autonomously different & don't back each other up. This meshes with the idea of group-A authenticating against server-A, and group-B authenticating against server-B. Another CCIE reccomended Document-ID 71942 and said it showed how to specify multiple servers at the group-level, versus on a global level. I'd not checked it out yet, but I'll post results when I do.


This Discussion