SSL VPN Authorization to AD via ACS 5.2

[Fredric Nilsson]

Hi!

We have a setup with an ASA terminating SSL VPN users authentication with smart-cards. The authentication is done between the client and the ASA via its certificate and crl check. This works fine.

But, we would like to make sure that the user that connect with its smart card is approved to use the SSL VPN service. This is controlled via a Windows AD group membership. Therefore we can in the ASA setup a AAA-server-group going through LDAP to the Windows AD servers. Set the connection profile to authenticate using certificates and authorize through LDAP AAA-server-group. This also works fine.

Now to the issue.

Instead of setting the authorization to the LDAP server directly we would like the ASA to send this authorization request to an ACS 5.2 to get loggstatement of which users who are logging in and when. Therefore we have another AAA-server-group with the ACS 5.2 servers in it.

The ACS have a AD integration and this works fine with other connection profile for authentication.

But when we change the authorization aaa-server-group from LDAP to RADIUS via the ACS 5.2 we get the errormessage in the ASA:

6          Jul 01 2011          10:16:46          113005                                                  AAA user authorization Rejected : reason = AAA failure : server = x.x.x.x : user = XXXXX

And the following message in the ACS:

24430  Authenticating user against Active Directory

24408  User authentication against Active Directory failed since user has entered the wrong password

22057  The advanced option that is configured for a failed authentication request is used.

22061  The 'Reject' advanced option is configured in case of a failed authentication request.

11003  Returned RADIUS Access-Reject

It seems like the ACS is sending the request as an authentication and not as an authorization-only to get the attributes (for example group-membership) back from the AD and match an ACS-authorization-rule.

I have tried 2 different identity store sequence setup and both gives the same result.

1. authenticate to AD

2. authenticate to X and retrieve additional attributes from AD.

Any idea?

Regards

Fredric

[Herbert Baerten]

Hi Fredric,

sorry for the late response, I don't follow this forum that frequently - for VPN related questions you can always (also) try the VPN forum BTW.

The problem is that there is no such thing as "authorization only" in Radius - so the ASA needs to do a Radius Access-Request to ACS. To do that it needs to supply a password - but since the user does not log in it doesn't have one.

To solve this, we send the username in the password field, the idea being that you create a user on ACS (locally) with the username as password, and assign the necessary attributes for authorization.

Alternatively you can configure a common password on the ASA, so it will send each Access-Request with the same password (instead of the username). But I guess that won't help you either.

I don't really see a solution for this that meets your requirements.

Obviously you can do LDAP authorization directly to AD - but you won't have your logs on ACS.

Or you could implement 2-factor authentication, i.e. require the user to have a cert AND enter his username&password on the login screen (actually you can pre-fill the username field so they only have to enter the password). In that case you can use Radius authentication to ACS (with AD back end).

hth

Herbert

[njlaw@xyrodian.com]

Hello Fredric,

I know that your question is fairly old; however, since there hasn't been a solution posted, I thought I'd reply.  We were in a similar situation: a VPN authenticated with certificates to simplify the user experience.  However, we still want to be able to push different AnyConnect profiles and other settings by AD group.

The following setup works for us:

• The ASA connection profile is set to certificate authentication with additional authorization.  The authorization server group points to our ACS 5.3 installation.
• On the ACS, we have a loopback network access policy setup that always replies with Access-Accept.  (Identity store: internal, advanced: continue, continue, continue, default authorization rule: permit access)
• On the ACS, we have a RADIUS identity server configured that points back to itself.
• The identity store sequence used for the VPN connection has the authentication identity store set to the loopback RADIUS service, so it always gets an Access-Accept.  Then we have our AD server listed in the additional attribute retrieval search list.
• Since the authentication always succeeds, ACS will proceed to retrieve the group membership from our Active Directory server.
• The authorization policy for the VPN service then grants access based on AD group membership and denies access by default.
• Please note that you should be careful to use prior authentication (e.g., certificates) before accessing this service; otherwise, you risk granting access to unauthorized individuals.

このメッセージは次により編集されています: Nathanael Law