RZ parameter ( login/password_max_idle_productive ) on selective users?

[Former Member]

Hi all,

I have an inquiry with regards to the rz10 parameter login/password_max_idle_productive .

Currently, I have setup this parameter such that users that is idle for 30days will be automatically locked.

My inquiry is that could I setup SAP system such that certain users will be omitted from the parameter above?

Example, users with admin privileges will not have the need to sign in at least once every 30days just to ensure that his/her id is not idle.

Thank you.

Regards.

[Former Member]

I am pretty sure that is not intended to be possible...

Perhaps you want to consider re-interpreting the meaning of the parameter to be "Number of days of idle productive password after it should have been changed" and then set the value to be 30 days greater than the validity parameter.

This is also mentioned in the documentation in RZ11 if I remember correctly.

Cheers,

Julius

[Former Member]

I see.

The security setting that I have impose is abit out of norm with the following setting:

1. We accept that an user only need to change his/her password once (there is no time frame in which SAP will prompt him/her to change password again).

2. We will block an user if he/she does not sign into SAP within 7 days after admin reset his/her password, or we detected that that user did not sign into SAP for a period of 30days.

With this conditions, I set the system with only login/password_max_idle_productive and not with

login/password_expiration_time

If the system is configured in such a way that I cannot perform a selective enforcement, then I would have to see out other alternatives.

Thank you.

[Former Member]

Forgive me for not seeing the logic behind this... but the reason for locking an inactive password or a failed password is to prevent misuse of it.

Now if someone is misusing a password unbeknown to the user, then why should it ever become idle if it will never expire anyway?

If I have your DDIC password then I will make sure that I use it once a week, or, once you have found another alternative to excempt it... then perhaps also go on a longer vacation without worrying about missing the idle period (only!).

That would be your problem, not mine. But I wanted to point it out to you.

Perhaps a better way would be to monitor who has not logged on at all (regardless of how they logon) and then lock their user accounts or restrict the validity of it as and when they appear.

You can do this manually with report RSUSR200 to try it out first. There you can also exclude a "super user" group in the selection, and not have to weaken your overall security because of them.

Cheers,

Julius

[Former Member]

I understand.

The initial reasoning is purely because there is lack of communcation between my company's HR and IT dept, which resulted in situations where IT will not know whom have resigned and whom has joined. This setup that I have done is an attempt to lock any users that does not use their ID (such as those resigned but was not announced).

I will have a check at the report that you mention and see if I can come out with another solution.

Thank you.

Regards.

[Former Member]

In that case, there is something else which might interest you...

Take a look at the discussions here about report HRPROFL0, and PFCG_TIME_DEPENDENCY and possible also the IDM forum (there is a sticky thread at the top of the forum which points to it).

As you also indicate, HR are typically the first folks to have this information and to tap into their data for automation can be usefull.

But changing the passwords (if used) still makes sense and deactivating password based logons (if idle for too long beyond the user responsibility) makes sense to me.

Good luck and feel free to continue with the thread if you need opinions on the available options and insights into what worked for others who have faced similar challenges.

Cheers,

Julius

[WolfgangJanzen]

>

> The initial reasoning is purely because there is lack of communcation between my company's HR and IT dept, which resulted in situations where IT will not know whom have resigned and whom has joined.

Well, that's the typical use-case for an Identity Management (IdM) solution: to ensure that accounts are created (and supplied with the proper roles) in various systems (of different type and from different vendors) - and deleted when no longer required. All that should happen automatically / tool-supported (e.g. with workflow support).

I assume that your system landscape does not only exist of one single system. Typically an employee requires an email account, a Windows domain account, etc.

[Former Member]

Ya, We are running on mutliple platform, naming Oracle email system and Windows active directory.

However, for these platforms, it is generally controlled by AD inwhich there is group policies to assist.

As such, I was trying to follow the concept (locks if no actions is detected after predefine period) enforced from AD as even our AD and other applications receives delay (sometime missing) updates from our HR dept.

[WolfgangJanzen]

>

> Ya, We are running on mutliple platform, naming Oracle email system and Windows active directory. 
> However, for these platforms, it is generally controlled by AD inwhich there is group policies to assist. 
> 
> As such, I was trying to follow the concept (locks if no actions is detected after predefine period) enforced from AD as even our AD and other applications receives delay (sometime missing) updates from our HR dept.

Well, as I wrote: that's the task of an Identity Management system.

The NWAS ABAP does (currently) not support multiple security policies - only one. So, it's not possible to implement what you are looking for (w/o using an IdM).