RE: SAP PASSWORD

[sreekanth_sunkara]

Hi All,

we are unlocking an SAP System user in PRD and it is locking automatically.

Only thing i know is we can set password parameters for a instance in RZ10 or RZ11

is there any other way to automatically lock particular user according to user id or user group.

Thanks,

SS

[Former Member]

Mass locking of users can be done in SU10, look at the trx to see what search options there are to collect the users (i know that usergroup is one of them)

[sreekanth_sunkara]

Hi ,

Is there any way to check all the users locked in su10

[Former Member]

you can use S_BCE_68001402 to see locked passwords.

USR02 with UFLAG > 0 will also tell you users who are locked.

[Former Member]

to be able to answer on the other question:

what kind of user is automatically locked again, a dialog or interface user?

[sreekanth_sunkara]

Dialong User

[Former Member]

Why is a SAP System users set as Dialog?

[sreekanth_sunkara]

It was set up by some else 2 years back

[Former Member]

>

> It was set up by some else 2 years back

so........

It shouldn't be dialog. Just because someone else did it badly doesn't mean it's right.

Your user will be constantly at risk of being locked by attempts at misuse which brings me on to your next question

>

> My question is, there is any way to set user settings for a particular user according to user id or group

You can get creative by using logon groups (speak to your basis team about this) to force a user to log onto an app server with different profile parameters, however do you really want a different app server for a handful of users.

Set your user to a system user and this won't happen

[sreekanth_sunkara]

My question is, there is any way to set user settings for a particular user according to user id or group

[sreekanth_sunkara]

??

[sreekanth_sunkara]

I tried changing user group, but still not working.

[Former Member]

>

> ??

huh? answer to your Q is in the thread.

[sreekanth_sunkara]

Ok i will see all the parameters and will reply you back

[Former Member]

Hi Sreekanth,

Only way to do this is either switch the user to System (which is recommended) or to get it to log onto an app server with the system params changed. Obviously the latter is a big load of effort to go to for one user......point is that all Dialog users should be subject to login controls.

Service users don't adhere to some password params, but from memory they can still be locked by incorrect logins (you might want to check that though)

[sreekanth_sunkara]

Ok thank you.

[WolfgangJanzen]

> Service users don't adhere to some password params, but from memory they can still be locked by incorrect logins (you might want to check that though)

Of course, there are no exceptions from the rule to limit the number of permissible failed password logon attempts - otherwise you'd allow to perform an unlimited number of password hack attempts (which finally will definitely succeed).

Have a kind look on [SAP Note 622464|https://service.sap.com/sap/support/notes/622464] regarding the impacts of the user type on the security policy. Whenever two systems are communicating with each other, I'd strongly recommend to use a SYSTEM user rather than a COMMUNICATION user.

[Former Member]

>

>

>

> > Service users don't adhere to some password params, but from memory they can still be locked by incorrect logins (you might want to check that though)

>

> Of course, there are no exceptions from the rule to limit the number of permissible failed password logon attempts - otherwise you'd allow to perform an unlimited number of password hack attempts (which finally will definitely succeed).

Thanks for clarifying that, I didn't have SAP to hand to check. I know there has been unexpected behaviour with non-dialog user types (fixed) and the Service User principle is d=fundamentally an easy one to abuse in the first place

[WolfgangJanzen]

Well, there are alternatives to using passwords ...

Especially for those inter-system communication: e.g. you could use the RFC Trusted System concept (for ABAP-to-ABAP RFC calls) or you could use the Java Destination Service with "Assertion Tickets" (for Java-to-ABAP communication, and vice versa). Or you can use SNC and associate the SNC identity of the caller to a SYSTEM user on the target system side (for an RFC connection). Using http(s) you could consider to use X.509 client certificates (which identity the calling system, mapped to a SYSTEM user on the target system side).

[sreekanth_sunkara]

Thank you all, basis team is reviewing this issue now and i will hear back from them soon