cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8296
Views
15
Helpful
21
Replies

ACS 5.x with either AD or RSA Authentication depending on user

timsilverline
Level 4
Level 4

I am trying to implement RSA two-factor authentication for our company for access to secure resources.

Our current setup before we had RSA, due to PCI restrictions, was based on AD group membership but was still extremely restrictive on even our admin users to ensure that no secure resources could be accessed without two-factor authentication.

I do not want to have to enable RSA tokens for our entire company - but I would like to be able to allow admins the ability to connect from the outside with two-factor authentication and have access to secure resources in an emergency.

We have less than ten people that require elevated access privileges so my hope is to enable RSA only for those ten users, and leave the rest of the accounts authenticating normally against AD.

I cannot figure out how to configure this.  With ACS 4.x such a policy would be simple - just create the user on ACS and point to the Identity Store that I want to authenticate against.  Not as easy with 5.x

I tried creating an rules based selection for Identity policy, making RSA the first one, configuring it to drop if no users is found, and configuring the RSA to treat user rejects as user not found.  This broke VPN completely.

From what I can tell it seems like ACS really wants me to choose an Identity store based on the NDG - but in this case it will always be our same ASA VPN device.

Anyone know how to accomplish this?

I am running 5.4 with the latest patches.

3 Accepted Solutions

Accepted Solutions

Each of the results in your identity policy are only selecting a single store; either RSA or AD1

You need to:

1) Create an identity sequence: Users and Identity Stores > Identity Store Sequences

2) select Password based and then add both RSA and AD1 in the selected list in teh order you desire

3) Ocne this is created; select as as the "Identity Source" in the identity policy

View solution in original post

One other thing that may be useful as an additional data point

If you look at the definition of the RSA object on ACS it has a timeout setting. By default this is 30 seconds.

It may be worth reducing this and see whether it reduces the round trip time for the case of the user not found while still being short enough for users that are found

May not solve anything but can be an additional datapoint to see if the timeout on ACS side is the thing that is terminating the interaction

View solution in original post

I am not sure I haev all the details of the issue but I think there is an additional attribute that defines the name of the external store that was authenticated against. Variable is called "AuthenticationIdentityStore" and is in system dictionary. In fact this is last database that was used to check authentication. In case authentication passed it will in fact be the database against which authentication passed

Therefore, best conditon to use is ("System:AuthenticationIdentityStore" equals "RSA" ) and ("System:AuthenticationStatus" equlas "AuthenticationPassed" )

This will check if authentication was done against RSA

View solution in original post

21 Replies 21

Tarik Admani
VIP Alumni
VIP Alumni

Hi,

I assume you created an identity store sequence and set the RSA at the top of the sequence followed by AD? If so, then setting the process to continue if user not found should have fixed your issue. Please post a screenshot of your settings.

Thanks,

Tarik Admani
*Please rate helpful posts*

I created an Identity store sequence which has RSA at the top of the sequence and then I was just using the Default Rule for AD to match all users that aren't in RSA but I have also tried creating an explicit rule to match All Devices and am having the same result. 

I have done some additional analysis on what is happening today.

Here is a log from my session:

11001  Received RADIUS Access-Request

11017  RADIUS created a new session

Evaluating Service Selection Policy

15004  Matched rule

15012  Selected Access Service - Default Network Access

Evaluating Identity Policy

15004  Matched rule

15013  Selected Identity Store -

24500  Authenticating user against the RSA SecurID Server.

24501  A session is established with the RSA SecurID Server.

24552  Reject response from the RSA server is considered as User not found.

24502  The session with RSA SecurID Server is closed

22056  Subject not found in the applicable identity store(s).

22058  The advanced option that is configured for an unknown user is used.

22060  The 'Continue' advanced option is configured in case of a failed authentication request.

Evaluating Group Mapping Policy

Evaluating Exception Authorization Policy

15042  No rule was matched

Evaluating Authorization Policy

15006  Matched Default Rule

15016  Selected Authorization Profile - DenyAccess

15039  Selected Authorization Profile is DenyAccess

11003  Returned RADIUS Access-Reject

From this it seems that my policy is working for RSA and it is continuing to evaluate afterwards, but is no longer using the Authorization Policies that are configured to evaluate the AD user and somehow defaulting to the DenyAll policy.  If I switch back to single result for Identity evaluation, everything goes back to working - so I know that the Authorization Profiles are configured correctly if they are properly evaluated.  What is the "Exception Authorization Policy"?

Here is what I have configured on the Identity pages:

Each of the results in your identity policy are only selecting a single store; either RSA or AD1

You need to:

1) Create an identity sequence: Users and Identity Stores > Identity Store Sequences

2) select Password based and then add both RSA and AD1 in the selected list in teh order you desire

3) Ocne this is created; select as as the "Identity Source" in the identity policy

Okay this was very helpful and seems to have gotten me past where I was stuck at but something is still not working right....

The ACS Server is evaluating the rules in order, matching the right authorization policy, and sending a success response back, but I am getting a login failed message from AnyConnect.

Need to try doing some active debugs on the firewall while this is happening to see maybe what is going on.

11001  Received RADIUS Access-Request

11017  RADIUS created a new session

Evaluating Service Selection Policy

15004  Matched rule

15012  Selected Access Service - Default Network Access

Evaluating Identity Policy

15006  Matched Default Rule

15013  Selected Identity Store - AD1

24500  Authenticating user against the RSA SecurID Server.

24501  A session is established with the RSA SecurID Server.

24552  Reject response from the RSA server is considered as User not found.

24502  The session with RSA SecurID Server is closed

24430  Authenticating user against Active Director

24416  User's Groups retrieval from Active Directory succeeded

24402  User authentication against Active Directory succeeded

22037  Authentication Passed

Evaluating Group Mapping Policy

Evaluating Exception Authorization Policy

15042  No rule was matched

Evaluating Authorization Policy

15004  Matched rule

15016  Selected Authorization Profile -

22065  Max sessions policy passed

22064  New accounting session created in Session cache

11002  Returned RADIUS Access-Accept

But I am still getting a login failed from the firewall.

Will go get some logs from it to try to see what is happening.  Maybe a timeout because it is taking longer or something...

Thanks for your help so far.

Hi,

It should be pretty fast when ACS authenticates the session, typically the default timeout on the ASA is 5 if i am not mistaken. You can issue a show run all aaa-server to see what the value is.

Good luck great to know your almost there.

Tarik Admani
*Please rate helpful posts*

Yah something is going on with the firewall and I will probably have to open a TAC case for it..

The ACS log appears to return the Access-Accept, but the firewall just doesn't seem to be listening or something.  I even changed the timeout to 60 seconds, and this seems to cause the firewall to keep sending more requests as evidenced by the errors in ACS showing "11013 RADIUS packet already in the process"

I then tried changing on my firewall both the retry intervals to 10 (max).  No effect as well.

If anyone has any ideas let me know.  Otherwise I will try opening a case with TAC next week to see if they can help.

Hi,

Please use the "test aaa authentication...." command while running a capture to the ACS (assuming acs is on the inside).

access-list acs permit ip host any

access-list acs permit ip any host

capture capin match access-list acs interface inside

Tarik Admani
*Please rate helpful posts*

When I do a test aaa authentication from the ASA I receive an Authentication Successful message.

It showed that the timeout for this test is 62 seconds and I think this is where my issue is....

When I timed how long it took for the Authentication Successful message to be returned from the ASA during this test I got more than 25 seconds each time.

When I do it from the AnyConnect client, I think what is happening is that the response is not coming within the retry interval - and then it is asking me for my password again which is restarting the whole process before it can get a response from the device.

Why would it take so long for ACS to process the request this way?  I don't see any errors other than the "24552  Reject response from the RSA server is considered as User not found." message.  But the process continues on after this as normal until it sends back the RADIUS ACCess-Accept message.

Very interesting

There is a timeout interval on the RSA which by default is set at 30 seconds. Not clear that is coming into play here since does appear that a response has been received from the RSA server but may be worth a try to see if impacts things

If this is a test system (non production / load) I think can open policy diagnostics

System Administration > Configuration > Log Configuration > Logging Categories > Global

select policy diagnostics and set level to DEBUG. Same for

Identity Stores Diagnostics and Authentication Flow Diagnostics

Run test and then see AAA diagnostics

Monitoring & Reports > Reports > Catalog > AAA Protocol

Should see all the steps with the timings to see how long things took

Thank you for the guidance here.

Using these debugs I was able to find the following details in a test authentication in the logs....

Jan 29,13 5:38:12.126 PM A session is established with the RSA SecurID Server.

Jan 29,13 5:38:37.153 PM Reject response from the RSA server is considered as User not found.

So it is definitely the RSA server which is taking about 25 seconds to respond with the rejection message.

When I have the live activity monitor running on RSA it seems to show the message about the user cannot be found within 1 or 2 seconds, so I am not sure why it would take 25 seconds to respond back to ACS.

I will give RSA a call and see what I can find out.  If anyone else has any ideas in the mean time let me know.

Thanks for the help so far.

Okay so I was able to get on the phone with RSA support today and made a little progress with the issue before I got dragged into other priorities.  It is still not resolved though.

We installed wireshark to do some packet captures on the server and saw that after each packet by Cisco ACS, RSA responds with something.  Since it is encrypted we can't see what but there doesnt seem to be much.  In the RSA trace it appears to be seeing the user as invalid right away - matching the live monitor - but I don't see anywhere that specifies when it sends the response.

It just seems like there is some back and forth communication for 25 seconds at which point the ACS server recognizes a Reject response and proceeds with authenticating against AD.

Can anyone with a working setup like this do a wireshark capture to see what a regular transaction should look like?  Is it just one packet in each direction?

RSA has sent the wireshark capture, the ACS debug, and the RSA trace up to engineering for a closer look and I will see what they come back with.

This sure is frustrating! 

Please post a screenshot of the settings in your identity store sequence, I am curious to see what your settings are.

Thanks,

Tarik Admani
*Please rate helpful posts*

One other thing that may be useful as an additional data point

If you look at the definition of the RSA object on ACS it has a timeout setting. By default this is 30 seconds.

It may be worth reducing this and see whether it reduces the round trip time for the case of the user not found while still being short enough for users that are found

May not solve anything but can be an additional datapoint to see if the timeout on ACS side is the thing that is terminating the interaction

I just changed the timeout value to 5 seconds and I am able to login to VPN now!

This may have fixed it

I will have to verify now that RSA two-factor is actually working with this timeout...

I don't really understand why I need to specify a timeout but hey if it works...