Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Remove "New Password" option in Initial SAP GUI screen

cyanna_chung2
Explorer
0 Kudos

Hi all,

In order to avoid changing the standard program SAPMSYST (Initial SAP GUI logon screen), I am writing to seek possible "NO core mod.changes" solution/suggestion. We would like to disable the "new password" option for users to change their passwords in the initial screen of the backend (SAP GUI ABAP), have anyone done that before?

Any feedback in regards to this is greatly appreciated!

Thanks much and regards,

Cyanna

3 REPLIES 3

Former Member
0 Kudos

> In order to avoid changing the standard program SAPMSYST (Initial SAP GUI logon screen), I am writing to seek possible "NO core mod.changes" solution/suggestion.

Yep, I would not do that. It is more than just a "core mod."... the program intentionally protects itself against being changed by preventing logons to the system from using it in a modified state (lock-out). The same also applies to DDIC attributes of tables it uses during the logon process.

> We would like to disable the "new password" option for users to change their passwords in the initial screen of the backend (SAP GUI ABAP), have anyone done that before?

This can be done easily, but there are potential license consequences and well as security considerations.

The user type SERVICE (see logon data tab in SU01) does not have the ability to change it's own password at logon. If it can administrate itself (S_USER_GRP object) then it can reset an initial password for itself, but that is different to changing it's own password. The same applies to SYSTEM type users, as both of these are not subject to some of the password rules (most notably, the requirement to change the password periodically).

I am sure that someone is going to comment on this, so it might as well be me: Preventing a human person from changing the password of their own UID account is very often traced back to sharing accounts... and attempting to avoid license costs. These are generally frowned upon here in the forum...

Perhaps the easiest solution is to obtain an enterprise license from SAP and then you can create as many users as you wish.

Cheers,

Julius

0 Kudos

Hi Julius,

Thanks much for your prompt response. Perhpas I should have been more clear about my intention on disabling the "function". So here's the story - what I am looking at was to disable the "change password" function in the backend (via SAP GUI) for all dialog users. What we are trying to achieve here is to only let users change their password via an external security system (SSO is setup already) since if the "change password" option exists in SAP GUI, once the user changes his/her password, SSO will be messed up. Thus we would like to disable the "change password" function in the logon screen of SAP GUI. Currently, the user can change their password via 3 ways in the SAP logon screen (right mouse click, "new password" push button, and top menu navigation).

Any help on this is greatly appreciated!!

Thanks much,

Cyanna

0 Kudos

Hi Cyanna,

Why does it mess up the SSO if the user changes his password? If you permit passwords, and the user is changing it as per the password rules, then they should be able to do so and also change it.

If you prevent them from complying with password rules, then perhaps what you are looking for is to delete the user's password when they logon via SSO without giving them the option of keeping or changing the password? See the options for parameter login/password_change_for_SSO in RZ11 and SAP note 379081 & 869218.

Cheers,

Julius

ps: My answers above still assume that you have a "real" SSO (which is without passwords --> hence deleting the password in the system for which secure SSO is activated). If you are infact refering to a password synchronization mechanism as being a "SSO", then your terminology is not correct (to use the term SSO).

Edited by: Julius Bussche on Feb 22, 2009 8:51 PM