Watch the password any of the user

[Former Member]

Hi Friends

I am new in the SDN and for SAP also. We have recently implemented SAP. I am a administrator and having the Basis password with me. How I can see the password of other users.

[martin_nooteboom]

Wrong forum to ask the question, but the answer is you can't.

[andreas_mann3]

What's your intention Rajesh, <b>honestly</b>?

regards

Andreas

[Former Member]

Hi Andreas,

Honestly to smooth my organization working because many of my end user changing it intentionally to create the problem their colleagues and at that time somehow I am responsible to manage it. Nothing else.

Regds

Rajesh Gupta

[martin_nooteboom]

Hi Rajesh,

I am confused do users change passwords of other users? And if so how did the know the other users password in the first place? Maybe you should tell the users their passwords should only be known by them and they couldn't give them to other users.

Regards,

Martin

[Former Member]

It sounds as if the users (persons) are sharing the same user (ID)...

or

the unique users (persons and IDs) have access to an application which is running under a common dialog user ID, and are being prompted to change the password.

The latter problem can be solved by changing the user type from 'dialog' to 'service'.

Cheers,

Julius

[Former Member]

I agree with Julius that it looks like users share accounts and thus passwords. Looks like a violation of SAP license to me, so I see no reason why this is a problem, just give everyone its own account and password. As always if you go the the bottom of a problem, the solution is simple

[WolfgangJanzen]

> It sounds as if the users (persons) are sharing the same user (ID)...

Yes, this came also into my mind when I read Rajesh's last statement.

PS: account sharing is not only relevant regarding licenses but also has a <b>severe impact on auditibility</b> - if multiple persons share one account it will be hard to impossible to tell which action was performed by which person. Consequently it will be impossible to hold anyone accountable. That becomes important when "someone" did cause some damage (intentionally or unintentionally).

[Former Member]

Hi all,

Personally, I try to give people the benefit of the doubt for a while.

Ragesh has marked the thread as answered now...

So I took the liberty of <i>guessing</i> why...

Have a nice weekend,

Julius

Regarding the PS: I am currently trying to solve some WAPI problems

[Former Member]

Hi Julius,

Thanks for reply, I think changing the user type will solve my problem. Please suggest changing the user type 'dialog' to 'service' will not effect any other operation accept password.

Please suggest one more solution for 'Increase the password failure attempts' to save the problem of again and again locking of password.

Thanks & Regards

Rajesh Gupta

[Former Member]

Hello Rajesh,

Sorry, the thread had the status "answered" yesterday, so I assumed that you had returned to it and found what you wanted.

Changing the user type, much like any change, can potentially change unexpected things as well. If I were you, I would keep an eye on ST22 (ABAP dump analysis) after changing the user type. This should ideally be a normal procedure anyway. Any surprises (for example new authority-checks introduced) will in most cases end up there. Note that there are both good and bad types of dumps.

A popular way to solve the <i>"Increase the password failure attempts' to save the problem of again and again locking of password"</i> is to implement some form of Single-Sign-On (SSO), or, establish a trusted / trusting relationship between the unique user application and the common one => irrespective of how high- or low-tech the password attack is, it is useless even if successfull

There are a number of threads, blogs and articles on it here. If you use the search, then you will find yourself in good company here at SDN

If you describe the scenario in more detail, then a more "use case" answer on the "locking of password" problem would be possible for us; because there are some special case exceptions for special settings, user activities, types, names, etc. One example, the "Trust" mentioned above, does not work for user DDIC.

Kind regards,

Julius

[WolfgangJanzen]

Please notice: setting the usertype to SERVICE has <u>not only</u> implications on the ability / requirement to change passwords but also on the <b>lifetime of idle / unused passwords</b> and on the <b>ability to obtain SAP Logon Tickets</b> - see <a href="https://service.sap.com/sap/support/notes/622464">SAP Note 622464</a>

[Former Member]

Hello Rajesh,

I have moved this for you from the Test & Playground forum to the Security forum...

Take a look at .

Basically, what you are trying to do is typically considered an illegal activity and in "hacker" communities it is even frowned upon as so called "cracking".

Kind regards,

Julius

[WolfgangJanzen]

Yes, in most countries the usage of tools to retrieve access data (of other users) is subject of legal prosecution. Whether this is done by cracking (e.g. using password rainbow tables) or simply by spying (e.g. wire-tapping) does not matter.

Since passwords are always personal data you might also get into trouble regarding data protection / privacy laws. I can tell you that this is the case in Germany: even if you are performing a security assessment you are not allowed to violate data protection laws; e.g. you are not allowed to get access to any plaintext password (after using a password crack program) - you are only allowed to state that it has been possible (for the machine) to crack someone's password; but even this is critical; it's much better to anonymize the result (providing only statistics).

Regards, Wolfgang

[Former Member]

Hi everybody,

I think changing the user type is not the solution for what Rajesh is looking for. he probably needs to restrict access on the users who were able to manipulate with passwords.

As far I remember, Service user type is not counted in User license administration and allows multi login without any limit or warning messages and many other things. So changing user type of dialog users to service is not a good thing in any perspective unless you are using it for RFC or services for special functionalities.

basically you are breaking the basic rule from SAP with user types.

upto what I know, no audit company would be ok with this.

[Former Member]

Hi Keerti,

Reading the original question again, I would tend to agree with you.

Though we still do not know the exact "use case" of this user.

Cheers,

Julius

[WolfgangJanzen]

SERVICE users are intended to be used only when a user should be given the ability to use (web-based) applications / services anonymously - that is achieved by storing the required credentials (of that SERVICE user) in the service configuration (e.g. using an external ITS: in the ITS service file, or when storing credentials in an ICF service configuration).

-> SERVICE users and SYSTEM users are <u>technical</u> accounts

-> DIALOG users and COMMUNICATION users are assigned to individual <u>human</u> users

Only DIALOG and SERVICE users are able to use SAPGUI to logon to an ABAP system. SYSTEM and COMMUNICATION users cannot logon using SAPGUI.

-> DIALOG user = <i>interactive</i> COMMUNICATION user

-> SERVICE user = <i>interactive</i> SYSTEM user

(<i>interactive</i> refers to the ability to use SAPGUI)

[Former Member]

Somehow I got the solution. Thanks everyone who has supported and guided in this issue.

Regds

Rajesh GUpta

[WolfgangJanzen]

Kindly notice the implications on auditibility and license issues (see above).

Not everything that is technical feasible is appropriete. You might think over.