Ok, I think it finally clicked what you are trying to accomplish and it looks you found a solution. Regarding my doomed statement.  My issue was that my users (ie boss) wanted to have both AD and local accounts which would behave simliar to your fallback scenario.  They were used to the old ACS 3.2 method where a user account was created, THEN you sepcified to authenticate the account against the internal ACS database or AD. Long story short, if you create local accounts that use the same exact username as your AD then ACS will NEVER authenticate against the internal datastore if there is an active connection to AD.  So if the passwords are different, authentication fails because it is reading the AD password since it already found the name and will never check the password of the internal user.  I understand the limitation as my users are saying they want ACS to read their minds on whichever account they feel like using at the time, so I am not losing any sleep over the fact that I cannot exacly duplicated the functionality of the older version. As far as testing, ACS needs a simple Connect/Disconnect option for the AD section simply for this purpose.  Last time I checked it looks like you have wipe out your existing AD info and potentialy lose all your group settings if you want to replicate AD failure now.  Could be totally wrong on this conclusion. ... View more

You are fighting my same battle.  Just curious, are you creating the local user ACS accounts with the same username as their AD accounts?  If that is the case then you are doomed, but if not then it should work fine. Also, how are you testing AD connection failure within ACS? I have just gone through an almost identical issue so I am curious if you discover anything new. ... View more

I may be missing something in your post, but you have setup and verified your connection to your Active Directory in the ACS server?  Then have you setup TACACS to authenticate using AD store? I am running the newer 5.3 so some of these settings may not be one for one. ... View more

Found the answer and I almost hate to admit what it was. When I initally installed ACS I apparently neglected to set my ntp and timezone settings.  Just noticed this the other day and corrected the issue.  My guess is that the incorrect time caused the log entries to be timestamped in the incorrect future date/time.  These log entries then stayed at the top of the report since they occurred in the future.  Once the actual time matched and surpised these bogus entries, newer events were posting correctly at the top. ... View more

Update...appears that I have the basics working although I am not real comfortable with the process.  First I removed all "aaa authorization" commands hoping that I could just deal with authentication. Changed this line: aaa authentication enable default group tacacs+ enable to this: aaa authentication enable default group tacacs+ So aaa was only configured with the following lines: aaa new-model aaa authentication login default group tacacs+ local-case aaa authentication enable default group tacacs+ With this change everything worked as expected.  My non-admin level users were stuck at priv 1 and could not change to enable mode.  My admin level user could switch to enable mode and run all privileged commands.  Not really understanding why that worked I set the changed line back by adding "enable" on the end again and everything continued to work. So I am really at a loss as to what happened, and I am concerned that there is something else going on to give me these inconsistent results. ... View more

Thank you Carlos for the information, but I am still running into issues.  I have mainly been focusing on Profile Shells, but did attempt using Command Sets. Based on the screenshots in your example it appears that you are using Command Sets only and no Profile Shells as part of your Policy rules. When I only use Command Sets my two test users from each of the test groups can log in, but now my superadmin user cannot go into "enable" mode using this example.  Here is the error, but I am confused as I removed the Shell Profile as a condition all together. Failure Reason > Authentication Failure Code  Lookup Failure Reason : 13029  Requested privilege level too high Generated  on:January 20, 2012 10:20:52 PM UTC Description The TACACS+  user requested a higher privilege level than the Maximum Privilege Level  configured in the Shell Profile Resolution Steps Check the  SelectedShellProfile attribute to verify that the expected Shell Profile was  selected by the Authorization policy ... View more

Just to add more info, the ACS log appears to show that everything is fine: Authentication Details Status: Passed Failure Reason: Logged At: Jan 20, 2012 4:04 PM ACS Time: Jan 20, 2012 4:04 PM ACS Instance: sls-acs.testdomain.com Authentication Method: PAP_ASCII Authentication Type: ASCII Privilege Level: 15 User Username: jack Remote Address: 172.30.1.152 Network Device Network Device: SL-OPS-3524PWR Network Device IP Address: 172.30.1.57 Network Device Groups: Device Type:All Device Types, Location:All Locations Access Policy Access Service: Default Device Admin Identity Store: Internal Users Selected Shell Profile: Level 15 Active Directory Domain: Identity Group: All Groups:Engineers Access Service Selection Matched Rule : Rule-2 Identity Policy Matched Rule: Default Selected Identity Stores: Internal Users, Internal Users Query Identity Stores: Selected Query Identity Stores: Group Mapping Policy Matched Rule: Authorization Policy Matched Rule: Rule-1 Authorization Exception Policy Matched  Rule: Other ACS Session ID: sls-acs.slfiber.com/116213333/139 Service: Enable AV Pairs: Response Time: 10 Other Attributes: ACSVersion=acs-5.3.0.40-B.839 ConfigVersionId=66 Protocol=Tacacs Type=Authentication Action=Login Port=tty1 Action=Login Port=tty1 UserIdentityGroup=IdentityGroup:All  Groups:Engineers Authentication Result Type=Authentication Authen-Reply-Status=Pass Steps Received TACACS+ Authentication START  Request Evaluating Service Selection Policy Matched rule Selected Access Service - Default Device  Admin Evaluating Identity Policy Matched Default Rule Selected Identity Store - Internal  Users Looking up User in Internal Users IDStore -  jack Found User in Internal Users  IDStore TACACS+ will use the password prompt from global  TACACS+ configuration. Returned TACACS+ Authentication  Reply Received TACACS+ Authentication CONTINUE  Request Using previously selected Access  Service Evaluating Identity Policy Matched Default Rule Selected Identity Store - Internal  Users Looking up User in Internal Users IDStore -  jack Found User in Internal Users  IDStore Authentication Passed Evaluating Group Mapping Policy Evaluating Exception Authorization  Policy No rule was matched Evaluating Authorization Policy Matched rule Returned TACACS+ Authentication  Reply Additional Details Diagnostics ACS Configuration Changes ... View more

Wish I had seen this earlier.  Experienced same issue and lucked into solution when I happened to disable a second adapter.  Updating to latest drivers from Intel resolved the issue for me. ... View more