Solved: 3015 stops working with ACS, when upgrading to 3.1

mjakobsson · ‎02-28-2003

Hi,

We´ve been using the 3015 with 3.5.2 for a couple a months.

It´s been using a ACS 3.0 with Radius set up exactedly as described in "Using Cisco Secure ACS for Windows with the

VPN 3000 Concentrator - IPSec".

Now we upgraded the ACS to 3.1 and it stops working.

When trying to TEST the communication between the 3015 and ACS we get "Authentication Rejected: Group password is

not configured", and if looking in the logg one can see the following.

191 02/28/2003 09:01:43.990 SEV=8 AUTHDBG/58 RPT=2

AUTH_Callback(514afe4, 0, 0)

192 02/28/2003 09:01:43.990 SEV=6 AUTH/4 RPT=2

Authentication successful: handle = 12, server = 192.168.244.48, user = borta

193 02/28/2003 09:01:43.990 SEV=3 AUTH/5 RPT=10

Authentication rejected: Reason = Group password is not configured

handle = 12, server = 192.168.244.48, user = borta, domain = <not specified>

195 02/28/2003 09:01:43.990 SEV=8 AUTHDBG/2 RPT=2

AUTH_Close(12)

Any idees?

gfullage · ‎03-03-2003

ACS 3.1 was changed slightly in that it returns the Class attribute in its reply packets when a user authenticates, this was done for session tracking purposes. Normally this doesn't have any effect on whatever you're authenticating against, but the 3000 uses this Class attribute to force a VPn user into a specific group. For example, you can force VPN users into specific 3000 groups by returning the Class attribute for that user with a specific VPN3000 group name, so no matter what group they actually have configured in their VPN client, they'll end up in this other group and inherit all the parameters from that group.

The "group password is not configured" error stems from the fact that ACS3.1 returns some string in the format "dfhsdfjsdfshhhhghgkgekjfkjguwywe" (or something like that anyway :-) ) in the Class attribute. The 3000 then interprets that as you wanting to force this user into that group. Obviously that group name doesn't exist on the 3000, and you get rejected.

There's two ways around this:

- Upgrade the concentrator to anything higher than what you're currently running. Starting in v3.5.3 the 3000 ignored this attribute format and the logins will work fine even though ACS still sends the attribute back.

- Change the ACS group/user and actually return the proper Class attribute in the form:

OU=groupname;

where groupname is the VPN3000 group name you want this user to be placed in (may or may not be the same as the one they have configured in their client). Make sure OU is in capitals and don't forget the semi-colon. The Class attribute is Radius (IETF) attribute 25, so just check this and off you go, you may need to enable it under Interface Config - Radius (IETF) first so you can see it under the ACS User/Group.

View solution in original post

gfullage · ‎03-03-2003

ACS 3.1 was changed slightly in that it returns the Class attribute in its reply packets when a user authenticates, this was done for session tracking purposes. Normally this doesn't have any effect on whatever you're authenticating against, but the 3000 uses this Class attribute to force a VPn user into a specific group. For example, you can force VPN users into specific 3000 groups by returning the Class attribute for that user with a specific VPN3000 group name, so no matter what group they actually have configured in their VPN client, they'll end up in this other group and inherit all the parameters from that group.

The "group password is not configured" error stems from the fact that ACS3.1 returns some string in the format "dfhsdfjsdfshhhhghgkgekjfkjguwywe" (or something like that anyway :-) ) in the Class attribute. The 3000 then interprets that as you wanting to force this user into that group. Obviously that group name doesn't exist on the 3000, and you get rejected.

There's two ways around this:

- Upgrade the concentrator to anything higher than what you're currently running. Starting in v3.5.3 the 3000 ignored this attribute format and the logins will work fine even though ACS still sends the attribute back.

- Change the ACS group/user and actually return the proper Class attribute in the form:

OU=groupname;

where groupname is the VPN3000 group name you want this user to be placed in (may or may not be the same as the one they have configured in their client). Make sure OU is in capitals and don't forget the semi-colon. The Class attribute is Radius (IETF) attribute 25, so just check this and off you go, you may need to enable it under Interface Config - Radius (IETF) first so you can see it under the ACS User/Group.

mjakobsson · ‎03-04-2003

Thanks, that did the trick!

drmassaro · ‎03-23-2003

I had the same problem with the "group password is not configured" error and the work around you discussed regarding the Class attribute OU=groupname solved my problem also.

Thanks so much.