I was able to get RSA and AD authentication working fine with the timeout set to 5 seconds and all is working now.
I am confused on why thie timesout setting is required though.
Can anyone help to clarify why this is needed? Is it just a bug that I am working around by changing the timeout?
Thanks for your help guys. Much appreciated.
This is still a work around and means system is working in one of two ways
- valid user / password: positive response immediately
- invalid user/password: response from RSA appears to be received but does not seem to get flushed/processed until timeout occurs
In means in case of failures processing is taking longer than it should and not sure of can clearly distnguish all cases including a real timeout from server
Worth still digging some more to undelying causes and also debug from RSA side
When you say Not Surprised is that because this sort of timeout behavior is expected? I have sent logs to RSA and am waiting on their response.
In the meantime, during further testing I found a flaw in my current design....
Succesful Authentication works properly for users as intended.
However, I have found that when using the elevated privilege level account, if I enter the AD password for this account, after RSA authentication fails it still successfully authenticates the end users against AD afterwards and they end up being given the same network access.
The way I have it setup right now is Authorization Profiles are tied to AD group memberships. So even though I have users authenticating against RSA, RSA is still checking against AD for these user accounts, and ACS is still using their group membership from AD to determine which Authorization Profile to provide to the user.
I don't see how else I can set this up to get it working anymore. If I can't base the Authorization Profile on AD group, or NDG device, I can't figure out how to change their authorization profile to know that this user was authenticated against RSA and use the proper profile.
Any idea how I can accomplish this?
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
Thanks again jrabinow. That was the exact attribute I had been looking for. It doesn't show up as an option when you just click customize. You have to select Compound Condition when you customize and then select the System variable from that option, and then select its options to see this attribute. It is buried more than the others it seems.
In any event, all authentication is working successfully right now with the timeout set to 5.
Still waiting on feedback from RSA engineering
Hope you're well!
I am facing some access issue after completed the ACS (5.1) and AD (Windows 2003) integration, details underneath.
Enable password for (Router, Switches) is working fine if identify source is "Internal Users", unfortunately after completed the integration between ACS to MS AD, and change the Identity source to "AD1" I got the following result
1. able to access network device (cisco switch) using MS AD username and password via SSH/Telnet.
2. Enable password is not working (using the same user password configured in MS AD.
3. When I revert back and change the ACS identity source from "AD1" to "Internal Users" enable password is working fine.
Switch Tacacs Configuration
|aaa authentication login default none|
|aaa authentication login ACS group tacacs+ local|
|aaa authentication enable default group tacacs+ enable|
|aaa authorization exec ACS group tacacs+ local|
|aaa authorization commands 15 ACS group tacacs+ local|
|aaa accounting exec ACS start-stop group tacacs+|
|aaa accounting commands 15 ACS start-stop group tacacs+|
|aaa authorization console|
|aaa session-id common|
|tacacs-server host 10.X.Y.11|
|tacacs-server timeout 20|
|tacacs-server key gacakey|
|line vty 0 4|
|access-class 5 in|
|exec-timeout 5 0|
|login authentication ACS|
|authorization commands 15 ACS|
|authorization exec ACS|
|accounting commands 15 ACS|
|accounting exec ACS|
This is my first ACS - AD integration experience, hoping to fix this issue with your support, thanks in advance.
I am facing the same issue while using RSA as primary identity and Internal Users as secondary.
I have configured identity sequence and same I have used in default device admin profile with single rule instead of role based identity and in advance option I have used continue when user not found but its not working in that way....Plz suggest me what best coniguration I can do for using RSA as primary and Internal database as secondary or if possible gourp wise policy that this group should go to RSA and other group should go to internal users for authenication.....