ACS 3.3 account caching when using external databases

[koksm]

Hello,

We are using ACS in a 802.1x enviromnent, where 802.1x clients authenticate via Cisco switches to an ACS server, and the ACS server has an external database; Windows AD.

This all works fine. The only weird thing is the account caching that ACS does. After a succesful authentication the ACS stores a dynamic user locally in de the ACS user database. We do not want this, because when a user is removed from the AD, he is still able to authenticate because of the cached account.

Is it possible to set this to off? Of at least let is time out quickly? (BTW, we are using an LDAP connection between ACS and AD because we need multiple group mappings to be able to dynamically assign multiple VLAN's.)

[umedryk]

As far as I know, there is no way to deal with the cached entries.

[raymond.santana]

If you have ACS set to authenticate the user to the externat database (AD) as you say then the username caching is not a problem.

The ACS still requires authentication against the AD Username and password.

The only effect that the cached name has is to tell ACS to always authenticate against the same External Database that is did last time. This helps speed up the porcess.

Also you might want to try mapping the users to different ACS groups by reading the AD group the user belongs to.

In this way you can restrict access as needed, set ACL's etc.

Hope this helps.

[koksm]

This is not exactly true. After a succesful authentication, ACS caches the username and password in such a way, that you can disable the account in AD, and the user can still succesfully logon to the network. We have tested this several times and are able to reproduce.

So when a user leaves the company and his account is disabled or removed from AD, the only way to make sure that he is no longer able to logon to the network, is to delete the 'dynamic' user from the ACS database.

So still, it would be nice to have a choice to use pasword caching (it also has some advantages) of to be able to al least set a time to live.

[cliffordpa]

Hi Koksm,

I was wondering if you had a solution to this issue? I have a similar problem where a user got married and the name change in AD took 72 hours to be updated in the ACS. Anyway please advise if you have a solution.

Thanks.

[darpotter]

Hi

ACS does *NOT* cache passwords for external users. It has never done this.

However, if you used a protocol such as PEAP or FAST to authenticate a user, then nuke them from AD. Re-authentication (using SSL fast session resume) may continue to work for a period of time. ie until the session-timeout forces a full re-authentication.

Darran

once again... passwords are NEVER cached by ACS. I wrote a lot of that code and it doesnt do it ;)

[cliffordpa]

Hi Darran,

Thanks for the reply, i understand that the passwords are not cached but was under the impression that the username was cached?

We had an issue where a user got married and when the name was changed in the AD she couldn't login for three days? We are using ACS V3.1 and i can not find any settings to remove or decrease the cache time, if as you say it caches at all. Any suggestions?

Oh yes the clients are using cisco software and we are using Peap.

Thanks,

Paul

[darpotter]

Hi

Acs v4.0 has a feature to purge external user records. I think it may be configurable based on record age.

Alternatively, you can use csutil -d to dump the db then remove the external users based on knowing their userids - not very nice!

The delay in being able to authenticate a user who (I assume) changed userid doesnt sound like an ACS issue. It sounds more like a very bad case of propogation delay in the AD network. For all unknown users ACS will simply fire the authentication at AD (if the unknown user policy is configured). If that says no... nothing ACS can do.

I could write a utility to strip out external users from the dump file. If interested use the contact page on extraxi.com

Regards

Darran