AAA with fallback user

[Florian Pressler]

Hi,

it is common practice to configure a kind of "fallback-user" in case the "normal" way of AAA-checking is not working. For example, on the device you configure LOCAL fallback (with a locally configured fallbackuser), which is only used when the primary AAA-method (RADIUS or TACACS) is not reachable, for whatever reason. We have that in place, and it works fine.

In our case the TACACS-Server (ACS 5.3) is checking against a external database (AD). Now we also want to achieve a kind of "fallback"-mechanism in case this external database is not reachable. We want to cover the case that the TACACS-Server itself (ACS 5.3) is still reachable, but the external database is not. In this case the switch would be able to contact the TACACS-Server (and wouldn't fallback to LOCAL), but you wouldn't be able authenticating with your user stored in the external database.

For this case I wanted to configure the fallback-user locally on the ACS 5.3 also. This, combined with the use of "identity sequence stores" on the ACS should do it - I thought. In reality, the ACS in this configuration checks the external database first, if it doesn't find it there, it searches the locally configured users and authenticates normally. This leads to the unwanted situation that the fallback-user *always* works. Is there a way to configure it that local fallback (on the ACS) only works when the external database is not working?

Thanks,

Florian

[Tarik Admani]

Florian,

This feature should work, there is a setting in the identity sequence store to continue if the external store is unavailable or to leave it as "process error".

In the identity seqence option, click the carrot button for the Advanced Options, you should see this:

	Advanced Options
	If access to the current identity store failed Break Sequence Continue to next identity store in the sequence

Select the 2nd option.

Thanks,

Tarik Admani
*Please rate helpful posts*

[Florian Pressler]

Tarik,

thanks for your answer, I tried that out. Unfortunately, it did not yield the expected result.

The Access-Service I'm using has "Single result selection" selected for Identity Policy. There, I selected an Identity Store Sequence called ONG-AD as the identity store (which itself has two identity stores configured - AD1 & Internal Users in this sequence). The Identity Store Sequence "ONG-AD" has "Continue to next identity store in the sequence" configured in the advanced options as you described.

When I test the setup now, there is no difference - the Internal User may authenticate, although the AD1 is perfectly reachable and you can also authenticate with external users there.

The detailed log in ACS 5.3 shows:

Evaluating Identity Policy

Matched Default Rule

Selected Identity Store - Internal  Users

Authenticating user against Active  Directory

User not found in Active Directory

Looking up User in Internal Users IDStore -  ong

Found User in Internal Users  IDStore

Authentication Passed

I assume that this has to be solved rather with rule-based result selection (in the Identity Store configuration of the access service) instead of Identity Store Sequences. I'll try that and let you know.

Regards,

Florian

[ghuey]

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.

[Florian Pressler]

In my case, we want to have one common fallback-user. This user+pass is "well-known" to the internal IT-staff and should be used (only) if there is a servere malfunction in the AAA-system, preventing IT-staff to login into devices. I think configuring separate fallback-users for everyone is a little bit cumbersome, because of the administrative overhead. On the other hand, it's better for security, because there is no "general" password. Why should you be doomed when you do it like that? I think it should be possible too.

The point is: fallback-user should work *only* when there is a AAA-malfunction - not always. Otherwise this fallback-user would be too much a security-threat of its own. I think I solved it now by *not* using Identity Store Sequences any more, as they do not seem to provide the functionality. Instead, I re-configured the Identity Policy on ACS to a rule-based one. First line points to AD (external database). Second line points to Internal Users. As long as there is no "process failure" (external database not reachable), ACS should never proceed to line 2. So, the fallback-user can't be used in this case - as expected. This has to be configured in the "Advanced Options" of the first rule in the Identity Policy.

Regarding testing: Good question. I don't have a solution!

[ghuey]

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.