03-04-2013 2:28 AM
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
03-04-2013 4:06 AM
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
03-04-2013 4:28 AM
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
03-04-2013 4:38 AM
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!
03-04-2013 4:40 AM
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
03-04-2013 4:45 AM
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
03-04-2013 6:45 AM
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
03-04-2013 9:29 AM
Dear Maaike/Colleen,
So, there is no solution for problem.....
Regards
Sumit
03-04-2013 9:49 AM
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
03-04-2013 10:22 AM
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