Problem with Users sharing login credentials

[Former Member]

Hello Gurus,

We are having issues with users sharing their login credentials and I am wondering if you would have any suggestions to help track and/or prevent this kind of behaviour within our SAP system.

We know this is happening, our helpdesk gets the odd request from a user asking to reset another users password so they can do their job. The problem we run into with these requests is our higher ups will not proceed with actioning the respective users since we have no corroborating evidence to prove that this is indeed happening.

I am wondering if others have had this issue and what you have done to address this problem.

I should note that we already have the login/disable_multi_gui_login enabled, this violation tends to happen when the user is away for vacation etc.

Thanks for your help.

James.

[Former Member]

Weapon of prefered choice is Single-Sign-On in combination with a better solution for vacation substitutes and "deputies" than sharing passwords.

There are several ways of doing this. Workflows (for escalating items) are one of them.

How many users do you have?

Cheers,

Julius

[Former Member]

Thanks for the replies,

I should expand my explanation, our vacation coverage policy is pretty simple.

If you are a manager and you are going away on vacation all you have to do is ask another manager in your org unit to cover your employees. All managers within the same org unit have authorizations to approve time/visas for employees one level below in the org structure. This is done for vacation coverage but also because our staff can move between managers as they are given moved to help cover load/vacations etc.

We also have a process in place to give employees temp promotions/assignments that would allow them to preform a different job. This is a quick webform that allows our HR dept to assign this employee to the new function and allows us to assign the authorizations.

The problem we have is when one user decides that he doesn't want to be bothered with adhering to the processes above and they just give their subordinates access to their account while they are away (by providing their ID and password). We have also been informed that some mangers will give their account info to a subordinate so they don't have to be bothered with doing certain job functions, mainly approvals of Time and Visas.

As to SSO we have looked at it but the problem with that is the managers typically give their subordinates access to the Windows Domain ID as well. And in some cases they even leave their laptops behind.

[Former Member]

One way of dealing with this to hurt them...

Legal requirements can also be painfull when managers are personally liable for negligence.

Don't your auditors find this practiced process unacceptable and not alligned to the intended policy?

Cheers,

Julius

[mvoros]

Hi,

if the managers give their subordinates user name and password then subordinates become managers. Your current authentication process is based on one factor - something what you know. They share this knowledge hence you can't see the difference between manager and subordinate. The only proper technical solution is to use 2-factor authentication where the second factor will be something what you are (e.g. fingerprint reader or iris scan). I guess this solution is out of scope :-). You can try to push on them by issuing memo why it's not a good practice and they are liable for actions executed under their password but I guess that they will just ignore it

Cheers

[Former Member]

Thanks for your support, this is certainly a intresting situation. We have looked at a secureID two-factor solution, again though if the manager is willing to provide their userID and password to someone else they will most likely have no problem leaving their secureID in their desk drawer.

Right now we are looking into changing the login userexit to record all logins and capture the terminal the user accessed. We did this during the upgrade to notify users that their version of the gui needed to be updated. Instead of storing the userID and the terminal temporarely, we'll put it into a table and create a script to notify us of terminals that are using multiple ID's. It's not perfect but if we can catch a couple people in the act we might be able to set an example.

Thanks for the advise and the support.

Regards,

James.

Edited by: James Wright on Aug 19, 2010 4:22 PM

[Former Member]

Why dont you populate the user record with email-id , once a user calls you to reset password , look at his record

and send the password to the email-id mentioned for the user record. Only the user in scope will get the credentials.

This clearly shows that their is no proper procedure and policy followed.

If you have portal and SSO is still not configured, you can have self service enabled for users.

Regards