Unlock Users

[Former Member]

Is it possible to allow a user to just UNLOCK a user and not reset his password ?

For eg. Say I (Kunal) have access to SU01, and I should be allowed to only unlock another user (Test) and not reset his password. Im not sure this is possible.

Why not ? Because I tried this

1. Created a role with only SU01 and disabled all objects in it.

2. Tried to unlock a user and checked which object it needed.

3. Gave access to just that ONE object.

Result : I was able to unlock the user, but also reset his password by giving access to that one object. The activity was also just Change.

Not sure if this is possible.

Thanks,

Kunal

Edited by: Kunal Belnekar on Feb 6, 2008 5:40 PM

[jurjen_heeck]

Could you please tell which object you tried? And with which field values?

[Former Member]

Hi Kunal

The authorisation to unlock a user and reset their password is U_USER_GRP ACTVT 05 + their user group

As the 2 activities share the same activity it's not possible to separate the 2 as standard

[WolfgangJanzen]

> As the 2 activities share the same activity it's not possible to separate the 2 as standard

Reason: in most cases it does not make sense only to remove the lock which was set due to too many failed password logon attempts ("password lock"). It might be required to set a new password (since the user has forgotten the old one). Some even demand that you shall not be able to remove a "password lock" without setting a new password.

But I'd agree with you regarding "account locks" - which are different from those "password locks" I've mentioned above. "Account locks" have a similiar meaning as the "account validity". Therefore it would be appropriete to control both with the same AUTHORITY-CHECK.

[Former Member]

Hi Wolfgang, I agree with the reason.

From an administrative perspective the activities are linked.

From memory I think this is the first time in many years that I have heard of this requirement, I would imagine that one of the user management BAPI's could be used to segregate the functions from a logical perspective even if the back ground auths are the same. Not a pretty solution but would work.

[Former Member]

> But I'd agree with you regarding "account locks" - which are different from those "password locks" I've mentioned above. "Account locks" have a similiar meaning as the "account validity". Therefore it would be appropriete to control both with the same AUTHORITY-CHECK.

I would second that.

Our auditors have actually suggested this in an SoD guideline, but did not distinguish between the reason for the lock. We interpreted it to be locks for all reasons, so told them it is not possible to distinguish between unlock and reset password. Basta.

However, for example with decentral user adminitration (using user groups), requirements for a local admin to be able to administrate locked passwords without being able to reactivate locked accounts or change their email addresses etc might arise.

In the mean while, the validity date restrictions on the user record could be used. They already perform those "change" (actvt ='02') checks.

Cheers,

Julius

[Former Member]

Thank you all for your replies.

Before I close the topic, I would like to explain the rather unusual requirement.

Our company has multiple stores and each of the store machines has an individual Generic Username and Password. Now, if someone gets mischievous and locks out some login (3 unsuccessful tries), we want the on duty Store Manager to be able to just unlock the Generic ID. He doesn't need to change the password since everyone knows what it is.

Now, the catch is, if the managers are able to reset passwords, he can reset anybody's password (including me, the Basis Admin) and we dont want that to happen.

Maybe there is another way to do this.

Our basic aim of doing this is saving time so that the Stores Registers do not have to be locked until they are unlocked.

[WolfgangJanzen]

Solution: use user groups and restrict the store managers only to perform user management tasks for "their" users.

[Former Member]

In addition to Wolfgang's comment, there are two comments I can make:

- Using user groups for the generic ID's of each of these "stores", you might want to consider a naming convention of the user groups, and ensure that all users (e.g. your ID) is assigned to a (different) user group name space. You can also have "nodes" in the name range, to enable "on duty store managers" of multiple stores to reset passwords from a certain range, and not only a single value (or set of them).

- If you are willing to invest a small bit in programming, you could develop a little transaction or service which, based on the authorization of the "on duty Store Manager" for user groups (and possibly user types as well...) will give them a screen via which they can, if authorized, only unlock the user. For such purposes, SAP has a function module called BAPI_USER_UNLOCK. In this case... the generic user ID can be unlocked without reset of the password... the store manager does not even need to know the password anymore... actually... you could give it to anyone or expose it to the internet for us all to click on because the intention is only that these users should remain unlocked (assuming that is the only thing which this development could ever do).

Cheers,

Julius

PS: If I remember correctly, BAPI_USER_UNLOCK even has some logic in it already regarding the reason for the lock. Correction: First call function 'BAPI_USER_GET_DETAIL' ( [use search|https://forums.sdn.sap.com/search.jspa?threadID=&q=BAPI_USER_GET_DETAIL&objID=f208&dateRange=all&numResults=15&rankBy=10001] ) to get the reason for the lock. I am sure that you could quite easily create a little application which does exactly that which you want it to do.

PPS: You mentioned that the generic user ID gets locked by users... because of this password reset... the above suggestion could eliminate the knowledge of the password (it changes??? change it?) and regardless of that, it is advisable to restrict the access of the user ID... who knows where the password is saved... or where it can be found...

Edited by: Julius Bussche on Feb 7, 2008 8:29 PM

[Former Member]

Thanks Julius. I spoke to a developer and he was able to get a custom transaction made so that we could get this.

Thank you everyone for helping out too.

[Former Member]

Glad to hear that!

I would however not completely ignore the cause of unsuccessfull logon events, when you intentionally change the password to an unknown one. Some tools for monitoring are report RSUSR006, the security audit log (SM20 etc), the system log (Sm21), etc.

Cheers,

Julius

[WolfgangJanzen]

Well, the "password lock" mechanism is a protective countermeasure (in order to prevent brute force / dictionary attacks on passwords).

It's like a power switch - usually there is a good reason why the electric power was cut off.

You should first search for the reason before forcing the power switch back to "on" ...

[Former Member]

Yes, that was my thought as well.

Actually with report RSUSR006 you can monitor the power surges and disconnect the UPS from the mains before the bolt of lightning strikes.

Cheers,

Julius

[Former Member]

I appreciate the advice. I did not think about that. But the scenario in the stores is that young men/women on the registers can lock out someone just for the fun of doing it or to even make life miserable. We do not have a big IT team and need the Manager on duty to help out unlocking the Store Machines.

As far as access for those machines is concerned, they have display only access to the inventory.

[Former Member]

Thanks for the additional infos.

Apart from monitoring where the "just for fun" failed logon attempts are coming from, you might want to consider sending a bolt of lightning back to them...

If you have named users for all these "young men / women", then I can think of a way how you can spoil their fun quite easily => when failed logon attempts on an ID appear from a terminal which is otherwise not used by that ID, you could determine the ID which is also successfully logged on at that terminal, close all their sessions and apply an administrator lock on the ID. They would then need to contact you, and not the store manager... (who might also be one of those "funny people"...?). After all, by locking the user ID, he / she has had the ability to know the password until now...

There is an old SAP note which explains how to do that, but I don't know whether it is still supported or even possible... let alone "permitted".

I haven't looked into that for years, but if you are interested, I can try to dig around in my box of tricks to find it again.

Cheers,

Julius

[Former Member]

Thanks for all the help Julius. As much as I would love to know how that is done, I wouldn't want you to spend time on it. I know you guys have much bigger things to take care of.

And besides, it would not help since the usernames and passwords are generic. For example, Store 21 would have Username : RegisterA and password: RegisterA . That is why everyone knows all the usernames and passwords to all the registers in the stores.

We have training going on right now in the stores and people lock out other registers just for fun by typing in the password incorrectly. The problem is everyone is using a generic id to log on the registers, except for the manager.

But ya, if you come across the note sometime, I would love to know how it is done. Could be extremely handy.

Thanks for your help again. Appreciate it.

Kunal

[Former Member]

Hi Kunal,

I don't think it would make sense to protect generic ID's in this way, when the named people do not have named user ID's to send the exclusive lightning bolt to.

I would think that once you have named users for the young men / women to identify with (and perhaps take more personal responsibility for), then these "funny tricks" might relax of their own accord... and then you wouldn't need a Darth Vader either...

Cheers,

Julius

[WolfgangJanzen]

> ... the scenario in the stores is that young men/women on the registers can lock out someone just for the fun of doing it or to even make life miserable.

Well, that's harming your business - and the penalty for such behavior should be clear to everybody ...

Those young men/women will learn very fast ... (e.g. if a surveillance camera is recording the usage of that machine ...).

> We do not have a big IT team and need the Manager on duty to help out unlocking the Store Machines.

> As far as access for those machines is concerned, they have display only access to the inventory.

Well, that only keeps the Store Manager busy ...

How about a different approach: it seems that the generic account is actually assigned to a machine - rather than to a human being. In that case the user type SYSTEM is appropriete. Furthermore you could consider to use SNC for authentication rather than UID/PWD (if RFC is used as communication protocol). By that, it will no longer happen that the generic account gets locked. However, there will be no access control - your customers (or anyone who gains physical access to that machine) will be able to display the inventory. But, if I got you right, that does not seem to be a major concern.

[Former Member]

Thanks !

I will need to discuss the pros and cons of using SNC on the Store Machines. Im not sure if the Management will agree to have a store register which does not have a password (Im not too sure how SNC works, but that is the idea I got).

Having a password rather than not having one may sound like a better option. I also need to find out more about what the Store Machines can/cannot do apart from displaying the inventory.

All said and done, I appreciate the response I have got. I am fairly new to SAP and it helps a lot.

[Former Member]

>

> Having a password rather than not having one may sound like a better option.

That depends on how well known the password is to a group of persons who are an unknown. It might make sense in some cases to isolate the calling machine (physically and logically) and then let it do it's thing unhindered by passwords and locks (but only from that machine!).

> I also need to find out more about what the Store Machines can/cannot do apart from displaying the inventory.

I would agree to that. In addition to isolating the machine, you can also isolate the impact of the risk of possible unauthorized access, IF someone gets their hands on the machine and wants to have "fun" or "abap" in your backend system...

Cheers,

Julius

[WolfgangJanzen]

>

> Having a password rather than not having one may sound like a better option.

Using SNC does indeed mean: do not rely on passwords for authentication.

But it does not necessarily mean: anyone who gains physical access to the frontend machine can use it without any authentication. It's possible to request an authentication before activating the SNC credentials. That could be a PIN/password (but that you do not win much), a piece of hardware (from a simple magnet card up to a smartcard with PIN and biometric scanner) which needs to be presented or some biometric checks. SNC is based on the GSS API (Generic Security Services) - so the vendors a free to design a security solution which supplies the specific customer requirements.

Cheers, Wolfgang

[Former Member]

Any links that give more information about SNC ? Sorry I didn't really put in much effort to look. I'm being a bit lazy here

I'm hoping that you guys could pin point me to the place so that I can save myself some time in digging around.

[Former Member]

To pin point you to a good place to start digging around: http://help.sap.com/saphelp_nw70/helpdata/en/e6/56f466e99a11d1a5b00000e835363f/frameset.htm

Good luck!

Julius