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: 

"new password " option to change password disable for specific SAP ID

Former Member
0 Kudos

Dear Experts,

Specific SAP ID shouldn't able to use "new password " option for  change password,

1) Service user type not possible since license violation

2) Implement of login/password_logon_usergroup + login/disable_password_logon also not feasible because it will allow user to logon directly which is IT security violation.

Please advice. Do we have any Parameter/ Functional module so that we can write a code on it.

Thanks

Sumit

9 REPLIES 9

Colleen
Advisor
Advisor
0 Kudos

Hi Sumit

it is concerning that you are trying to prevent users from changing their password. If they choose the "new password" button on login, they will have to enter their existing password to change it

The new password button allows the user to change their password daily so long as they know their current. This provides adequate security to prevent another user accessing password.

1). Service Users - I take it you mean you cannot see these accounts as Service user type due to license violation - correct

2) Parameters - have you the correct understanding of these? They work with SSO to prevent user from entering password to login (if user attempts, they get error message on log-on screen preventing them - ie. password deactivation login not allowed). It will not allow them to access the system directly so I do not see IT security violation.

What is a practical example of a user who you do not want to change their own password? Preventing them from changing a password is more of a concern/breach than allowing them to change it when they choose?

If you find a way to prevent them changing their password, what happens if they ask for a password reset? They will not be able to change initial password OR you have a security risk in the Administrator knowing everyone's passwords

If you want to change rules and password strengths, then you could look at SECPOL - Security Policy if you are on a recent EhP

mvoros
Active Contributor
0 Kudos

What is a practical example of a user who you do not want to change their own password?

My guess is that they are sharing one SAP account by multiple users. If one user changes the password then others can't use it anymore. I might be wrong and I understand that my comment is not really helpful. What I want to say is that usually, these weird requirements come from weird practices that are not very secure or aligned with licensing policy.

Cheers

0 Kudos

Martin

I suspect the same. However, language barriers can cause some confusion so I keep an open-mind

If you are correct, it is concerning that some IT risk-based policies and License agreements are considered but not the basics!

Former Member
0 Kudos

Dear Colleen,

Thanks for reply.....

Actually, We have SAP ID (Read access) used by multiple users, At times, someone from them change the password (using new password) without BASIS core team knowledge. We can't able  to figure out what is  the new password & who changed it It's create a problem for CORE team to communicate all users every other day.

We want prevent them to do so  by their choice anytime. Please suggest....

Thanks

sumit

0 Kudos

wouldn't this be a major breach/violation of SAP User Agreement

Generally - each user has their own account even if display only

I am surprised that you do not consider sharing accounts a breach  yet setting the account as a Service User is a license breach?

My suggestion (and I suspect most experts on this blog) - change your approach and issue each user their own login.

Message was edited by: Colleen Lee - really bad, unintelligible sentence

Former Member
0 Kudos

Hi Colleen,

You are right - sharing accounts is not allowed according to the SAP license agreement independent of what authorizations the user has.

Sumit,

I'm not sure why you chose for this solution. It might seem more efficient from maintenance point of view, but I think that in practice it is not. In practice you are constantly communicating the passwords to the various users:

- mandatory password reset every x months

- forgotten password

- someone changed the password on own initiative.

I really think it's better practice to give each user his/her own user ID; that will save you effort and worries and you are also working according the SAP license agreement.

Hope this helps.

Kind regards

Maaike

Former Member
0 Kudos

   Dear Maaike/Colleen,

   So, there is no solution for problem.....

Regards

Sumit

Former Member
0 Kudos

Hi Sumit,

No, I don't think so not taking into consideration the option to create custom ABAP code (which is also not advisable). I know it is possible to block passwords in Java systems, but I'm aware of this possibility in ABAP systems.

Kind regards
Maaike

mvoros
Active Contributor
0 Kudos

Hi,

you could try to build a custom solution that would mitigate some issues. Let's ignore licensing issue for now. You could maintain a list of email addresses that are allowed to use this account. You would provide a web based app (e.g. web dynpro or BSP app) that would be accessible to any user (predefined user used for running this app). A user would need to enter only her email address. If the entered email address is on the list then the system would generate a new password for a shared account and set the validity period of this account only for today. It would also send a generated password to entered email address. Basically, if a user wants to use this account she needs to request a password. The system could also log every request which would give you a bit of accountability. The problem is that if 2 users request new password on same day. In that case you can't say who did what. Another issue is that there is a lag between requesting access and ability to log on to system (lag depends on how fast an email can be sent to user's account).

Cheers