Auto Lock the User not logged on for specific period

[Former Member]

Hi,

Is there any way to auto lock users who have not logged on in SAP R/3 System for certain number period or certain number of days ?

Thanks,

Vignesh P.

[Former Member]

What you can do is auto-lock their passwords if they remain unused (idle) for a period after having been (re)set by an admin or remained unchanged by the user themselves, even although they would normally have been required to change it.

This means that logon methods which do not involve the ABAP password are still possible (SSO, background jobs, etc).

Search for "idle"...

Cheers,

Julius

[Former Member]

Hi Julius,

Thanks for your reply,but can you pls give me the exact details?!Like SAP standard program if it is available/custom program or any note number related to this?!

Regards,

Vignesh P

[Former Member]

Did you search for "idle"?

You will also find discussions around report "RSUSR200" and why the "idle" parameters were introdoced => to reject the logon at logon time if the admin would have locked the account... manually.

There is also a thread about this and release dependencies in the FAQ thread at the top of the forum.

Please explain exactly what you want to achieve (without negative side-affects) and which release you are on?`

Cheers,

Julius

[Former Member]

Hi Julius,

Actually we wants to lock the user / bar the user from login if he / she is not logging in to the production client for past 10 days.

Our Kernel release is 700 SP Level is 185.

I think we can use parameters

login/password_max_idle_productive &

login/password_max_idle_initial

but it applies to SUPER users and other client users (000 , 001 ...etc ) as well right?!

Thanks,

Vignesh P

[Former Member]

It applies to password based logons (both DIAG and RFC), not other types of logons => SSO, Trusted RFC, jobsteps...

10 days can be set (or less) for a password in initial state - as the admin might know it until the user changes it,

10 days for a productive password is pretty harsh...

What is the validity time of passwords? (the time before the user would be requested by the system to change the password at logon).

If named dialog users are only logging in via RFC (e.g. current user setting) then a different approach is needed.

Please explain your scenario?

Cheers,

Julius

[Former Member]

> but it applies to SUPER users and other client users (000 , 001 ...etc ) as well right?!

Yes, but those users are more critical (typically) than others, and are more likely to be targets of attacks (if that is your concern).

Are passwords saved in shortcuts or hardcoded into scripts? Rejecting expired passwords is a good way to find them - even if the user does appear to be logging on often...

Via the "user type" you can then excemp some (and ensure correct user type usage), but not via the group nor the client.

Cheers,

Julius

Edited by: Julius Bussche on Jun 13, 2009 10:51 PM

[WolfgangJanzen]

>

> Our Kernel release is 700 SP Level is 185.
> I think we can use parameters 
> 
> login/password_max_idle_productive &
> login/password_max_idle_initial
> 
> but it applies to SUPER users and other client users (000 , 001 ...etc ) as well right?!

Yes, those profile parameters are intended to be used for that purpose - and you are using a NetWeaver version which supports them.

Unfortenately, you are also right assuming that it effects all (DIALOG) users, including the "super" users.

Currently (using profile parameters to specify the security policy) it's not possible to use different policies for different (groups of) users. But that will change: with one of the next Enhancement Packs (for NW 7.0) multiple security policies per logical system (i.e. ABAP client) will be supported.

Regards, Wolfgang

[Former Member]

> Currently (using profile parameters to specify the security policy) it's not possible to use different policies for different (groups of) users. But that will change: with one of the next Enhancement Packs (for NW 7.0) multiple security policies per logical system (i.e. ABAP client) will be supported.

Ahh, so "basis" can use "init1234" again, or "C11ADMPW"?

Or does this only apply to the idle aspect, to discourage synchronizing the otherwise idle password?

I am curious to see how this will work and how it will be lived in the wild. Instance parameters are tricky enough, but now with logical system parameters this must be very tricky...

I am not logged on, but if I remember correctly then T000 is buffered and has foreign keys as well for the logical system name.

Are there any notes or infos related to this? Sorry to be a pessimist

Cheers,

Julius

[WolfgangJanzen]

>

> I am curious to see how this will work and how it will be lived in the wild. Instance parameters are tricky enough, but now with logical system parameters this must be very tricky...
>  Sorry to be a pessimist 
> 
> Cheers,
> Julius

Hi Julius,

there is no reason to be pessimistic. Actually I find it more natural to use standard customizing mechanisms rather than profile parameters (which should be used only for technical stuff, such as location of executables / libraries, etc.).

Security Policies will be transportable (like other customizing data), changes will be recorded, and everything is deterministic: one user could be assigned to none or exactly one Security Policy. If he is assigned to none, then the old profile parameter concept will be used to determine the policy. Otherwise the Security Policy specifies the policy. A policy is a set of attributes; each security policy attribute (key value pair) specifies a specific behavior (e.g. "minimal length of passwords", "frequency of periodic password changes", "max. idle time for initial passwords", etc.). So, this is pretty much the same as the profile parameters. And, of course, the (hard-coded) default values of security policy attributes will be the same as of the corresponding profile parameter.

I hope that you are no longer scared / concerned, now.

Instead you should be looking forward.

Cheers, Wolfgang

[WolfgangJanzen]

>

> Ahh, so "basis" can use "init1234" again, or "C11ADMPW"? 

Well, all users of group "BASIS" could be assigned to a Security Policy "BASIS" which contains a Security Policy Attribute "PASSWORD_HISTORY_SIZE" being set to value "1" - while other users will be assigned to other Security Policies which specify other PASSWORD_HISTORY_SIZE values. That's all.

Don't worry, the boundary / value range remains unchanged: login/password_history_size has a valid value range of 1 - 100 and so does PASSWORD_HISTORY_SIZE. And that's the same for all the other parameters / attributes - there's always a correspondence.

[Former Member]

This is interesting news. Thanks Wolfgang!

> there's always a correspondence.

Would the parameters still provide the "minimum global policy requirements"?

What would also be usefull would be a client specified view to the policies of other clients (e.g. 000, 066, etc) as I assume these will be connected to the client logical system as well, together with the user and their group. Actually, I have been using "dirty tricks" to look into other clients for sometime now and SAP is closing the door on these, so a general information system would come in handy sometime.

Cheers and thanks again for the insight

Julius

[WolfgangJanzen]

> Would the parameters still provide the "minimum global policy requirements"?

No - there's no mix between both concepts. That would make things too complicated.

The fact that users could be assigned to no Security Policy is the tribute to downwards-compatibility.

Future feature extensions (regarding security policies) will only result in new Security Policy Attributes - but no additional profile parameters.

> What would also be useful would be a client specified view to the policies of other clients (e.g. 000, 066, etc) as I assume these will be connected to the client logical system as well, together with the user and their group. Actually, I have been using "dirty tricks" to look into other clients for sometime now and SAP is closing the door on these, so a general information system would come in handy sometime.

Same as SU01 (users, user groups) and PFCG (roles) works client-specific, the new Security Policy will respect the "client isolation" principle. There will be no cross-client operations. Security Policies are client-specific customizing data.

[Former Member]

Please forgive my curiosity and hijacking this (albeit related) thread with it, but this is interesting...

How will the "feature" of dynamicly changeable profile parameters which have been increasingly used in the recent past be implemented in client dependent customizing tables then? Current settings for views which can be configured by the customer as well?

More often than not I observe that different systems in a landscape (e.g. DEV vs PROD) have different settings even although the company "minimum baseline policy" might be respected by both. So how can this be achieved using transportable customzing changes which tend to force the opposite by keeping the settings in sync? Transport requests marked as "Do not trransport!!!" are not a good idea in my opinion, as someone might oneday transport a new change through...

The same goes for the user group within the client (SUGR): There are valid reasons to maintain these differently between the systems and for the same reason probably they don't have a transport option of their own. But if their policies are being transported, then it would make sense to me to keep the groups in sync as well.

Cheers,

Julius

[WolfgangJanzen]

> How will the "feature" of dynamicly changeable profile parameters which have been increasingly used in the recent past be implemented in client dependent customizing tables then? Current settings for views which can be configured by the customer as well?

The policy is always defined by the customer - in both cases (profile parameters, Security Policy).

> More often than not I observe that different systems in a landscape (e.g. DEV vs PROD) have different settings even although the company "minimum baseline policy" might be respected by both. So how can this be achieved using transportable customzing changes which tend to force the opposite by keeping the settings in sync? Transport requests marked as "Do not trransport!!!" are not a good idea in my opinion, as someone might oneday transport a new change through...

>

> The same goes for the user group within the client (SUGR): There are valid reasons to maintain these differently between the systems and for the same reason probably they don't have a transport option of their own. But if their policies are being transported, then it would make sense to me to keep the groups in sync as well.

Notice: "transportable" does not mean "will have to be transported".

But especially for Security Policies it might make sense to keep them identical in multiple systems.

[Former Member]

To return to the original question:

> Is there any way to auto lock users who have not logged on in SAP R/3 System for certain number period or certain number of days ?

I recommend that you do this manually via report RSUSR200 until you have your user groups, user types and logon methods clear - then flick the "idle" switches and possibly consider rejecting expired RFC and ICF passwords.

Is that clear? Do you agree?

Cheers,

Julius

[Former Member]

Vignesh,

From what I understand about your requirement, I would say same as Julius.

There is no such standard program. Go for a customized one.

Use the report RSUSR200. I would recommend, go to an ABAPer and ask him to modify this standard report as per your clientu2019s requirements. Eg. Include an input field for Creation Date, etc

Now, in the modified report, there will be two parts. First is executing the report and fetching the results. In this you might just

u2022 Exclude all privileged users. (you can input basis team lead ids here, so that they will never get locked even if they donu2019t use the system)

u2022 Exclude any privileged groups. (like SUPER)

u2022 Last logon date: 10 Days as per your requirement

u2022 Last Password Change: use it if u wanna

u2022 Creation date of user (if included in modified report): 10 days - because you donu2019t want to lock any user which was created within past 10 days and not yet used.

u2022 Other check boxes (to be selected or deselected wisely) (user type, password status, etc help you a lot)

Please wisely opt for the selection criteria and fetch for the required output. Once you have all the user ids which are to be locked, then the second part of the program comes into the picture, which is executing a BDC on this result.

The BDC would be to lock the users. (or to change user group or to delete or any other activity using transaction SU01 or SU10, etc.)

So, this way you have a completely customizable program which will help you a lot, even if there are any changes in the selection criteria in future.

Run this report in the system with the selected variant as a background job on a periodic basis.

Limitation of this program is it is client dependant.

Lemme know if you have more queries.

Regards,

Aslam Javid

[Former Member]

We developed a Z program to meet this requirement based on RSUSR200 report.

Thanks,

Vingesh P

Edited by: Vignesh Palaniswamy on Jul 16, 2009 7:10 PM