Question:
Hi, all:
This was posted in the basis forum and was directed to be posted here instead.
Today my boss asked about a way to prevent users from changing his passwd. We only want to do this to some IDs, not to all SAP IDs. Is there a way to do this?
Thanks.
Answer:
Why would you want to do this?
A user has a right to protect themsleves and if they feel that their password may have become known to someone else then they should be allowed to change it.
or are you referring to an admin changing someone else's password and restricvting who the admin can update?
You can restrict that by putting people in user groups which are controlled by S_USER_GRP
_________________
Sandi
~~~~
Apparently Father Christmas, the Easter Bunny, the Tooth Fairy and Star Wars aren't real
Tuly kiwi.
Answer:
Why would you want to do this?
A user has a right to protect themsleves and if they feel that their password may have become known to someone else then they should be allowed to change it.
Honestly I am not sure why my boss want to do this. I guess the reason is that we keep the password of some ID public so everybody who needs to use those IDs can use them freely because the password is known to them. Thus we want to prevent the password of those IDs from being changed.
is there a way to accomplish this?
thanks.
Answer:
Hi, All:
I just find out if we change the user type from "dialogue" to "service". The ID will not be able to change his password anymore. Not sure this is the right way to solve the problem or not because in the "SAP R/3 System Admin" book, it says "only assigns such users with great caution for security reasons". Any opinion on this?
Thanks.
Answer:
...I guess the reason is that we keep the password of some ID public so everybody who needs to use those IDs can use them freely because the password is known to them. ...
thanks.
If you are talking gerneric UserIDs, or sharing or logons then you could be in breach of your licensing agreement. I thnk before you look at the how you look at the why (ie what is really gonig on in your boss's head).
_________________
Sandi
~~~~
Apparently Father Christmas, the Easter Bunny, the Tooth Fairy and Star Wars aren't real
Tuly kiwi.
Answer:
...I guess the reason is that we keep the password of some ID public so everybody who needs to use those IDs can use them freely because the password is known to them. ...
thanks.
If you are talking gerneric UserIDs, or sharing or logons then you could be in breach of your licensing agreement. I thnk before you look at the how you look at the why (ie what is really gonig on in your boss's head).
Oh, really!
Setting up service typr Ids is violating the licensing agreement? Sorry but I didn't know this before.
Answer:
Service type UserIDs do not in themsleves breach licence agreements. That's why I said 'you could be in breach of your licensing agreement', not 'you are in breach of your licensing agreement.
Such breaches occur when multiple users share a logon for their normal work (eg not a training logon in a training client). The licence type is assigned to the UserID and USMM counts these up. If you have 5 users using one account and another 5 sharing a second one you are paying for two user licences but really you have eight more users SAP doesn't know about. That's where things start to get dodgy.
Service account types are useful for users where a dialog logon is not required and maintaining a password is not so practical, eg a user system user set specifically to communicate with your exchange server.
_________________
Sandi
~~~~
Apparently Father Christmas, the Easter Bunny, the Tooth Fairy and Star Wars aren't real
Tuly kiwi.
Answer:
What your boss is asking for is not too bright. The service user idea is ok but if someone finds the password (because it is never changed) then you have a security issue. Service users can be individuals, but usually they are anonymous ids that have limited read access and/or some internal validation mechanism that justifies the lack of va forced password change.
Answer:
Thanks, guys!
Right now, it looks like changing the user type to "service" will prevent the user from changing password thus will sovle the problem, I am not sure about breaking the agreement or security issue(very good point, thank you!). Anybody has another solution other than "service" user? please let us know.
Thanks.
Answer:
Be careful with that my friend. I know we had some issues in testing workflow when we changed user types from dialog to service. If you're not using workflow, then not an issue, but if you are.... I know it caused me some major headaches. Just throwing a flag up for ya...
_________________
"SOX.. hmm .. Aren't they the baseball teams in Boston and Chicago?"
Kind Regards,
IamEvilHomer
(Wayne)
Answer:
Some of the bolt on tools like IXOS Viewer cannot be used by service users. They don't want to be ripped off of license fees.
Answer:
I got a crazy idea, what if we can set a background job running which in night mode reactivates the password once each day, we make sure the password is the same one. Now as sap password cannot be changed more than once a day. so other users will not be able to do so.
But practically it has two problems
1. i think sap doesnt take the same password on changing
2. I am not sure if there is a background job which can do this.
If somebody can throw some light on this then it will be really beneficial, and also if there is such a possibility then ur problem is solved.
Cheers,
Guest_1
Answer:
Your Service users should be used with minimal processing access. Most companies use this as an example as workstations on shop floors where the workers need to see(read access) where stock is. Any processing transactions should be assigned to dialog users for audit trails and to ensure you have appropriate SOD conflicts resolved and in place. Your system settings should force users to change their passwords after x days anyway. As other comments, not sure why boss wants this as it is and should be the right of users to change their password.