Thanks a lot for your information.

My idea is implement the same functionality that ACS 4.2, in other words I would like that password expires based on date, not as result of failed attempts.

Kind regards.

Gotcha.

Concept in ACS 5 is to not implement such authorization decisions as part of the user definition. Rather as part of policy. There are Date/Time conditions that can be used as part of an authentication policy to deny a user access after a particular date

1) Create date/time condition (Policy Elements > Session Conditions >Date and Time). To disable user after a specific date select

"End By" option and then date/time to be disabled

2) Create conditions in policies to deny access to the user. Add the "Date/Time" and "User Name" conditions to the policy and select the date/time condition from step 1) and enter the user name to be denied access after condition expired.

I assume these conditions are temporary:to expire accounts for a small number of users. As such, a good place can be the Authorization Exception policy which is designed to administratively separate temporary changes to policy. However, could also be in the iidentity policy or others

The steps are very much clear but where should i apply these conditions, like in earlier versions it was in the user profile but here i dont find any option to apply the step 1) and 2).

FAIL. This is not what we want. We want to be able to automatically disable a User Account in ACS based on a date. This functionality was commonly used in ACS versions prior to 5.X. I have not heard a valid reason why Cisco took this feature out.

Cisco, it doesn't seem like you're listening to your customers. Why throw the baby out with the bath water?

Please add this functionality back into ACS 5.X in the next patch.

(Screenshot below is from ACS v3.3)

I am attaching an example of how to create both temporary and permanent accounts within the internal user database. It achieves the requirements above although maybe with a different approach. It uses two new capabilities in ACS 5.3

- Attribute to attribute comparison in the authorization policy

- Leverages a new System attributed called "NumberOfHoursSinceUserCreation"

I am also including a summary of the steps below

- Create two identity attributes for internal users

  -Define an identity attribute for the user type. Can use an integer where 1 indicates a permanent account and 2 a temporary one

- Define an identity attribute for user lifetime. Use an integer. Defines the user lifetime in hours

- Create a rule in a compound condition in the the authorization policy to deny access to users where Number Of Hours Since User Creation exceeds the lifetime. Eg (Internal Users:User Type = 2 And System:NumberOfHoursSinceUserCreation > Internal Users:UserLifetime) then DenyAccess

Note, I used an integer attribute type for the user type. This is because of issues displaying the enumerated values of an attribute in a compound condition. However, if install patch 1 for ACS 5.3 it may be possible to use an enumerated attribute instead of an integer one (which will be clearer) since the following CDETS is resolved in patch 1

CSCtg51846 Enum values are not shown in compound conditions in rule

I have not tested with patch 1

Hello,

I do see on the user account page, that there are three timestamps - User Creation, modification and enablement.

Is there any way to access the difference from now and any of those timestamps, not only the creation?

The use case is that for guests (new users) Creation is enough, but often you may have recurrent users that are disabled and are enabled just temporarily. For that, the other timestamps would be interesting to assess...

Is there any way to do so?

Thanks

Gustavo

Hi,

After so much of time cisco re-introduced this option in 5.3, One more problem am facing like:

1: We have normal VPN users on whom i want to enforce this policy of 90 days and 5 failed attempts.

2: We have some VIP users on whom i don't want to enforce any of the policy.

What i see in 5.3 is global setting effecting all users or am i missing any configuration related to this....because in previous versions till 4.x this option was under user settings itself which make us easier to choose based on user.