Password change parameters

[Former Member]

Hi,

I know that this will sound like one of those "refer the sticky thread" kind of questions, but it is a little different. I have gone through numerous threads but haven't found the answer or maybe I am just plain retarded

We need to implement password timeouts where the users will be forced to change their password after a certain period of time. I has followed the long thread where this was extensively discussed and a few others. However, here is my problem.

There are a few dialog users (540 to be precise) whose passwords are generic and known to all. These users have very minimum display access. The should be an exception to the rule since it is bound to cause a huge chaos. Exclusion to dialog users is not possible because of the profile parameter.

Would this work for what I need ?

From the sticky thread

1.

You'll need a programmer to get it done for multiple users, but here's wat to do if you're not afraid of editing table contents. (tested on WAS 610 but completely at your own risk )
For each user you want to force a password change for:
in USR02 set field LTIME to 00:00:00

This be done only for the users for which the password needs to be reset

2. Bounce the instance to activate the parameter login/password_compliance_to_current_policy.

We are on ECC 6.0.

Please let me know your comments if you think this would work or of there is any other efficient way of doing this. Also could there be any problems that you foresee. Any inputs will help me greatly.

Thanks,

Kunal

[Former Member]

You could implement the tip number 1 - but invert the logic:

+ activate the password expiration by setting the profile parameter

+ write an ABAP that sets the "last password change date" for all 540 special users to the current day (stored in BCDAn(?) in table USR02)

+ schedule this program as daily background job

... so the password for these users will never "expire",

Regards,

Alexander

PS. From a security consultant's view I can not approve what I wrote above

[Former Member]

Alexander,

Thank you for your reply. I will keep this thread open just in case someone has an equally interesting suggestion.

Kunal

[WolfgangJanzen]

>

> You could implement the tip number 1 - but invert the logic: 
> + activate the password expiration by setting the profile parameter
> + write an ABAP that sets the "last password change date" for all 540 special users to the current day (stored in BCDAn(?) in table USR02)
> + schedule this program as daily background job
> 
> ... so the password for these users will never "expire",  
> 
> Regards,
> Alexander

Well, you (hopefully) know that such direct table manipulations are endangering the auditability and also the supportability of your system (missing change records -> inconsistencies).

Furthermore: your "dirty trick" is release-dependent. It will not work in newer releases ...

Regards, Wolfgang

[Former Member]

Wolfgang,

I think the auditability of well known (anonymous) users is of low value anyway

The release dependency is indeed a good argument, I just checked it on a 4.7 system. So using user type Service is definetly more reliable, but I have no idea to deal with it during system measurement.

Regards,

Alexander

[Former Member]

Creative thinking... ... but perhaps you could also have added that it will screw up the referencial integrity of the database and could (as it also will) therefore prevent the system from using newer and better mechanisms and features for password management, or even prevent users from being able to logon to the system. Worst case your support could be cancelled and the tax auditors declare that the ordinary processing of data (including possibly tax relevant documents) in the system is no longer assured.

>

> PS. From a security consultant's view I can not approve what I wrote above 

I have also made a few posts at SDN which I subsequently regretted some parts of, and crashed 2 sandbox systems beyond repair once; 1 of which was from directly updating a USR table.

It is important to add a big smiley after those events and add lots of warnings if chosen to post it at all... ))

Cheers,

Julius

[jurjen_heeck]

> Also could there be any problems that you foresee.

As long as it's not a production system you're fine. Well known passwords sound to me like generic users and I'd strongly advise you to check your contracts and license agreements. Besides that it's a bit like locking the door and leaving the key in the lock......

For test and training users on testsystems I use SAPgui shortcuts which - after editing the PC's registry - can store hashed passwords as well. This way the enduser can log on without knowing the pasword. Since the actual SAPgui shortcuts are nothing but textfiles they're easy to replicate with different systems/clients, users and hashes. That way you can cope with password expiration a bit easier if you allow key users to change the password and store the new one in the shortcut(s).

The registry setting, store as .reg textfile and merge into the registry:

Windows Registry Editor Version 5.00
 
[HKEY_CURRENT_USER\Software\SAP\SAPShortcut\Security]
"EnablePassword"="1"
 

This setting needs to be done on every PC using the shortcut. Otherwise the password gets erased from the shortcut. Storing the shortcuts as 'read only' also helps.

Jurjen

[Former Member]

>

> For test and training users on testsystems I use SAPgui shortcuts which - after editing the PC's registry - can store hashed passwords as well. This way the enduser can log on without knowing the pasword. 
>
> ... 
>
> Storing the shortcuts as 'read only' also helps.

Don't place any big bets on that. Those "hashes" in the shortcuts are reversable (they have to be) and are not even encrypted (which which still imply decryptable).

I guess for some training systems on training PCs it could be usefull though, however in some environments it is legally required to show proof of training and keep records of this - so it probably not "cut-the-grade" for those requirements.

Imagine someone administrating a nuclear power station or operating a machine which is keeping you alive, and their eTraining on the machine was done by their cousin's friend....

Cheers,

Julius

[WolfgangJanzen]

>

> Those "hashes" in the shortcuts are reversable (they have to be) and are not even encrypted (which which still imply decryptable).

Sorry, Julius - but that's wrong.

SAP Shortcut does indeed encrypt the passwords (in order to be able to decrypt them - something that would not be possible using hash functions). But it's like using a door where the key is stuck in the lock - anyone can simply press the handle down and walk through the door - irregardless how good your door lock mechanism is. "Deposited Passwords" actually jeopardize the access control concept (since it's not really an authentication that takes place).

For those cashier solutions (PoS - Point of Sales) where the user is switched rapidly, I'd propose a SSO solution which is based on hardware tokens (not Smartcards - they are too costly, but maybe something based on RFID chips?). Well, in a sales store you need to be able to tell apart customers from staff. And you might be interested in proper auditing (who did what - requires to identify the employee). The sensitivity of the access-controlled data is moderate (mainly: wholesale price - which should not be made visible to the customers and maybe not to all employees, as well). What is most important is: the SSO solution needs to be fast (in operation) and cheap (temporary staff might "forget" to return the hardware token).

[Former Member]

Wow. I did expect some response, but that was definitely beyond my expectation.Thank you all for sharing your knowledge...again !

I will try and answer all the questions. Please let me know if I miss something here.

1. SAP licensing questions.

I don't think that this should be a problem, but I will still check with my Management.

Basically as some of you guys said, these generic logins were used by shop floor attendants and cashiers (PoS systems) to check things such as inventories of other stores in case they run out of something, if transfers have been made or not etc . These floor attendants as such do not have Windows logins, nor do they have a machine of their own.

One other thing that I would like to mention here is that there are as many logins as the number of cash registers. So there is no need of using 1 login multiple number of times.

I think our licensing is based on the number of users and these users are just not user specific but machine specific. And that is why they have generic passwords and very basic display authorizations.

2. Auditing concerns

This is a good point. However, as far as I know, these Tcodes have been reviewed by internal auditors. Again, I will convey this message to my Management as well.

3.

As long as it's not a production system you're fine

That is the problem. This IS a Production system

4.

Are these users still the same young men and women on the shopfloor using the terminal which we discussed last time?

@ Julius. Yes. That is absolutely correct. The users that the thread mentions are the generic users with display access and your suggestion for the tcode was for the Managers of the Store so that they would not have to waste time waiting for us to unlock these generic users. Store Managers and Asst Mgrs get their own desktops, Windows logins and SAP logins and they have change authorizations.

5.

I would be interested to know whether the main hassle is having to logoff and logon again when changing shifts or cashiers "on the fly" or whether it is indeed license cost related.

Well its neither actually. I hate to say it, but it is again some what a "convenience" issue. Having to reset generic id passwords every 3 months will cause a great deal of confusion in the stores ( we all know end users:-) ).

Also to us, it means having to set passwords to 540 users every 3 months. Unless this can be done by a ECATT script, we would need to log in into each user manually and set the new password. But if this has to be done, it has to be done.

Thank you again for all your responses. I appreciate every bit. My next step will be showing this to my Management and see what they have to say about it. I guess in the interest of the company, if the best option is to change the passwords of these users, then we will have to do that.

Regards,

Kunal

[jurjen_heeck]

Considering your situation and provided your license isn't the problem I think a single sign on may be the most pragmatic solution. I suppose (or rather hope) your windows logon is checked against some sort of directory......

Nice to know you appreciate the answers given an please come back to the forum to discuss further.

[Former Member]

> Wolfgang Janzen wrote:

> Sorry, Julius - but that's wrong.

> SAP Shortcut does indeed encrypt the passwords (in order to be able to decrypt them - something that would not be possible using hash functions). But it's like using a door where the key is stuck in the lock - anyone can simply press the handle down and walk through the door - irregardless how good your door lock mechanism is. "Deposited Passwords" actually jeopardize the access control concept (since it's not really an authentication that takes place).

Thanks Wolfgang.

I didn't know that it was encrypted, but was not implying plain text either. That a submit of an accessable shortcut did not require knowledge of the pwd was clear to me. I looked into this a few years ago and we ended up concluding that protecting the registry key and stripping the file extentions (together with 2 others) from the mail system was the best approach. There were a few accountants and managers who were upset by this at the time, but there are better ways of doing it.

Regarding RFID there is still the risk that a cat with an implanted marker might walk past the terminal and the ID's are switched...

> What is most important is: the SSO solution needs to be fast (in operation) and cheap (temporary staff might "forget" to return the hardware token).

I need to read the original thread again in more detail and think about it, but this sounds like a good solution to me.

Nice weekend to all,

Julius

[WolfgangJanzen]

>

> There are a few dialog users (540 to be precise) whose passwords are generic and known to all. 

You are (hopefully) aware that this has a (negative) impact on the auditibilty (if it is required to tell which users have been able to gain read access to data).

Oh, and yes - this might also be considered a violation of the software license agreement (with SAP).

Edited by: Wolfgang Janzen on Nov 27, 2008 9:55 AM

[Bernhard_SAP]

Hi,

as Jurjen stated already: first check your contract and licensing agreement, if you are allowed to use

'generic' IDs for multiple logins. then, if you are allowed to use such, why not simply change the user type of those users to 'Service'? (See SAP note #622464 and #327917) That will solve the password-change-issue....

b.rgds,

Bernhard

[Former Member]

Hi Kunal,

Are these users still the same young men and women on the shopfloor using the terminal which we discussed [last time|;?

I assume this is a productively used system and the access is not just display.

If so, it will still not solve the problem of them locking each other out intentionally or accidentally if they still have the password to an account they can share.

Cheers,

Julius

[WolfgangJanzen]

Good point, Julius.

Now I can recall that thread, as well ...

PS: "display" operations are not always harmless ... (thinking of HR, CO and many more).

Sometimes even a simple boolean statement can be critical ("Is the salary of person ... subject of distraint claims?") - in that case you might be interested to control which persons get an answer. And you might want to keep track of that ... (for auditing purposes). In some countries you are under legal obligation for such track keeping ... (e.g. Danmark, if I remember correctly)

[Former Member]

> ... (thinking of HR, CO and many more).

From what I can tell it is luckily not HR data being displayed. It is only the cash registers...

Kchangggg....

@ Kunal: I would be interested to know whether the main hassle is having to logoff and logon again when changing shifts or cashiers "on the fly" or whether it is indeed license cost related.

Perhaps negotiating an appropriate enterprize license and then creating personalized dialog users ad infinitum is a better option?

As I learnt recently, this can even be done from the same terminal (PC) with SAPGui SNC based Single-Sign-On used for different users. We were looking into this for users who exist in the AD but don't have their own PC's, but we did not want them having an ABAP password either.

Perhaps that would of interest for you, if you have proceeded with the SNC investigations from your previous thread about the "young naughty lads"?

Cheers and thanks for raising an interesting question again,

Julius