01-23-2013 03:27 PM - edited 03-10-2019 08:00 PM
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.
Solved! Go to Solution.
01-24-2013 09:22 AM
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
01-29-2013 09:53 PM
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
02-07-2013 06:40 AM
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
01-23-2013 10:17 PM
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*
01-24-2013 08:41 AM
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:
01-24-2013 09:22 AM
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
01-24-2013 09:47 AM
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.
01-24-2013 07:29 PM
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*
01-25-2013 01:51 PM
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.
01-25-2013 10:24 PM
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
access-list acs permit ip any host
capture capin match access-list acs interface inside
Tarik Admani
*Please rate helpful posts*
01-28-2013 02:01 PM
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.
01-28-2013 03:08 PM
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
01-29-2013 10:03 AM
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.
01-29-2013 09:39 PM
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!
01-29-2013 09:51 PM
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*
01-29-2013 09:53 PM
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
01-29-2013 10:02 PM
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...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide