Password Question Interesting --

[Former Member]

Here is a requirement;

1.Normally when a user is created , when he logs in first time there is a prompt for a new password.

2. Is it possible to take off this prompt ? Ie to say the user need to use the same password as he is created with.

Th ereason is , Ihave created a sequenc eof abut10 users who comes inat various shifts and wil need to use the pwds so want to use it that way with one pwd, never to change !

Thanks

[WolfgangJanzen]

Thanks for disclosing your motivation for that requirement (but anyway: I'd have assumed it - there are typically only two reasons for such a requirement: 1. account sharing, 2. password synchronization / poor-man's SSO).

Well, aside of license reasons there are other good reasons why you should not perform such account sharing. One good reason is the loss of auditibility: you'll be unable to tell which data was changed by which user - and you'll not be able to hold anyone accountable for any action taken. That sort of thing is what auditors are looking for ...

[Former Member]

This does nto answer howitcan beaccomplished ! i agree however theirroles ar every minimal and has internal controls in place.

so do I create a service user ? hw can this be accomplished ?

[WolfgangJanzen]

Still remains the license issue ...

PS: I am a SAP employee ...

[Former Member]

To elaborate a bit on the issue of accountability:

All SAP data are seen as part of financial data for which a lot of Laws exist in every country i have worked for.

So if acount sharing is to be allowed can ONLY be judged by the CFO of the company as he will be held responsible for misuse of the SAP system. So it is not a technical question to be compeletely answered in this forum! I have seen security administrators being sacked because they allowed this without the writen OK of the Finance manager/director.

second things i teh licence fee with SAP, but that can be discussed and solved between the company and SAP

[former_member74904]

you can change the user-type in one of the tabs in SU01. dialog user/background/service etc.

but I have to say I agree with Wolfgang's point of view regarding auditing.

[WolfgangJanzen]

... and it needs to be mentioned that a SERVICE user has some functional restrictions (see <a href="https://service.sap.com/sap/support/notes/622464">SAP Note 622464</a>).

[Former Member]

We are deviating frm the question.BTW Active users should ring a bell!!

[Former Member]

exactoy like we do for firefighter id !!

[WolfgangJanzen]

Well, you got statements from three differrent persons.

Are you looking for more persons trying to tell you that you are on the wrong track?!

[Former Member]

In fact I was the first to say so !! that its not the practice !! We need to delve deep in reasons for the term ' active user ' and service ids.

Thanks

[Former Member]

Hi George,

Please do not with a new thread.

Kind regards,

Julius

PS: <b><self_moderated></b>

[Former Member]

Juluis I dont want to reply to your statement of recreation. One is a question other is a thought for knowledge share.

Also, "PS: <b><removed_by_moderator></b>

[Former Member]

Also,I was closing my open questions..which were just 6( SIX) and not50 As you pointed !!

[WolfgangJanzen]

> One is a question other is a thought for knowledge share.

I agree (sorry Julius).

Regarding :

1. each user account should be assigned to individual credentials (e.g. userID and password)

2. multiple user accounts might be assigned to the same authorizations (e.g. using the "reference user" concept, introduced with SAP R/3 4.6C)

[Former Member]

>> Th ereason is , Ihave created a sequenc eof abut10 users who comes inat

>> various shifts and wil need to use the pwds so want to use it that way with

>> one pwd, never to change !

It sounds unmistakenly the same "topic" to me.

Due to popular demand, the other thread is now open to thoughts again.

Kind regards,

Julius

[Former Member]

Folks,

I need to put the record straight here.

1.The points raised and mentioned by my learned members of the forum was discussed at length with the External Auditors- :

--There is and continues to be no breaches there is already processes for this and is established verified and corroborated. I cannot give the specifics.

--Licensing issue: Absolutely no violation. Again I cannot give the specifics. But suffice to say its not a poor mans SSO implementation. Our thoughts are limited by our knowledge..this is not to cast a doubt on the knowledge of the members who contributed (and cried wolf !) but the technology supporting the engineering is so wide that one is unable to see all the corners of its application.

One final statement ..majority need not be always right ..its thundering voice can at times be blown away by whisper of truth.

Thanks!!

--George

[Former Member]

Hi George, a few points in response to your post

External Auditors are 90% of the time <i>not</i> SAP security experts. What they say and agree is not necessarily bet practice from an SAP point of view.

There are always exceptions to this rule though as a few posters on here demonstrate!

The majority are not always right - I agree, but when that majority represent a cross section of respected practitioners with considerable amassed experience, then the likelyhood of consensus being accrate is reasonably high based on the original facts they were given.

[Former Member]

Alex,

I dealt this at the highest level..as personaly I am very strict with these matters, included SAP experts from one of the top audit firms.

All I wanted to share was as you pointed here was ..." There are exceptions".

Any way it was indeed an Interesting .and wide area discussion!!

Thanks Again !

[Former Member]

George, though not relevant to this topic any more, I am very glad you are comfortable with your solution or findings for your situation. Without knowing more about the situation (which for understandable reasons you have not submitted) it is difficult to judge the advice in the exact context in which it was applied to.

From experience of the industry the knowledge of "SAP experts" provided by the Big4 can range from dire to excellent. I hope you had one of the latter

[Former Member]

Hello George,

Regardless of the audit- and license-freindliness of your solution, vendors and customers both have a governance responsibility, right?

Here is a thought (nothing more)...

<b>License by authority</b> => No named user or functionality restrictions.

~ If SAP wants a fee for something, they need to code an authority-check or rule for access.

~ Based on the "value" of the authority-check (if okay and used), a fee is recorded.

~ The recorded fee is then multiplied by the authority of the caller (at runtime).

~ All functionality is wrapped into License Units of Work.

~ License cost saving is included in the bonus plans of business managers.

Example:

Using VA02 when only authorized for VA02 costs 10 widgets.

Using VA02 with a mashed up composite role concept costs 1 000 widgets.

Using VA02 with SAP_ALL sets the customer back 1 000 000 widgets

Affect:

=> Who uses VA02 does not matter to SAP, as long as the authority is correctly checked.

=> A mechanism to measure the true authority of the caller will be transparent.

=> Who has access (and which additional access) matters to the customer.

An "out of the box" thought for your thread(s)

Cheers,

Julius

[WolfgangJanzen]

> ~ If SAP wants a fee for something, they need to code an authority-check or rule for access.

> ~ Based on the "value" of the authority-check (if okay and used), a fee is recorded.

> ~ The recorded fee is then multiplied by the authority of the caller (at runtime).

Sorry, but the rules are defined by the [SAP License department|http://service.sap.com/GLAS] - neither me nor you can change them. And I'm pretty sure that you cannot influence the licence policy of any other vendor as well.

[Former Member]

Juluius,

The example you quoted is interesting , to be frank I did not grasp understand it ..( Monday fever !!) please could you explain it ?

Looking forward to hear from you

Thanks

George

[Former Member]

In addition to Wolfgang's comment, I could imagine that the above would have dire consequences for the performance of the authority-check and would open another audit unfreindly motivation -> clubbing transactions into collective record entries, to avoid the costs of individual transactions.

Nothing more than a thought

Cheers,

Julius

[Former Member]

Hi Wolfgang,

I've always found the Licence agreements to be "negotiable", though I would like to see them try and hammer Julius' Licence Model (now referred to as JLM ) into their existing setup

[WolfgangJanzen]

License agreements (as any agreements in general) might be negotiable (to a certain degree).

However, that does not apply to legal requirements. And that's why I've stressed more on that aspect ...

[Former Member]

Here is another idea (to depart from the JLM )

- The 10 persons have the password of a single service user.

- The service user can do nothing other than logon and reset the password of the "shared" dialog user (person can select PW).

- The service user is then kicked out the system after resetting the password and cannot continue.

- The person then logs on with the shared dialog user (after logon the password is reset again).

- Anybody wanting to logon with that dialog user (even the current person) must first reset the password.

Gotcha 1: Each shared dialog user needs an individual user group?

Gotcha 2: Adventurous user tries to bypasses the user exit?

Gotcha 3: Based on any single record created by the dialog user, the audit trail to the person is broken (or significantly more difficult to reconstruct.

Still (to return to the original advice) why not use named users for each person?

[WolfgangJanzen]

> Still (to return to the original advice) why not use named users for each person?

Yes, especially if the "license agreement is negotiable" ...

[Former Member]

Hi,

Just a trickey way to work it out ( Not a direct solution)

Create user

assign password

Now as you know the id and password

log in to that client and use the id you have created and log in now it will prompt for change pasword

change the password now

now tell the users the id and password.

Regards

Vamsi

[Former Member]

NO NO !! This is not acceptable !! for reasons so well enunciated above

[Former Member]

More over the system is asks you to change thePWD so that the noone other thanthe user knows it..

[WolfgangJanzen]

> ... change the PWD so that noone other than the user knows it ...

Yes, that's intended (by design).

We do consider the password to be a secret - it should only be known to one single user and one single system. In principle, credentials should never be shared between more than only two parties.

I'm afraid that it is useless to continue discussing if we do not agree on this important point.

[Former Member]

Wolfgang,

I agree, when even the most basic security rules are not adhered to and people in the discussion are wanting to change them, it is better to stop the discussion.

I think we now have heard all arguments, and I am not convinced that sharing the accounts by more than one user is really needed. But if customers want to go that way???

[WolfgangJanzen]

> ... But if customers want to go that way???

Well, of course they can try to do so - I don't think that anyone can prevent them from doing so.

But they have to be made aware that this is not supported by the vendor and that they might loose the ability to perform proper system audits (and therefore might get into trouble regarding legal requirements).

It is like this: if you ask me, I'll provide an answer (in most cases ....).

But I'm not playing police ...

[sreekanth_sunkara]

Hi,

If you create your user as service user.

Then it wont prompt for password change.

you can use same password that you entered while creating.

Thanks,

sree

[WolfgangJanzen]

Back to the original question (

)

> Here is a requirement;

>

> 1.Normally when a user is created , when he logs in first time there is a prompt for a new password.

>

> 2. Is it possible to take off this prompt ? Ie to say the user need to use the same password as he is created with.

>

> The reason is: I have created a sequence of about 10 users who comes in at various shifts and will need to use the pwds so want to use it that way with one pwd, never to change !

Well, there is a good reason why the user is asked to change his password: that password has been set by the admin, so the admin does know the password. But passwords should only be known to a single invididual user (= general security policy). If a password is known to other users, the user cannot be identified reliably. That endangers the system auditibility (notice: that might impact legal requirements).

For so-called self-registration scenarios the situation is different: the user requests the creation of an account providing all required data (such as fullname, e-mail address, postal address, etc.). The password chosen by the user is then only known to him (but not to any other person). In that case he is not prompted to change this password when using it the first time to logon.

But in any case it is assumed / demanded that each user has his own account - and is treating his password as secret data (i.e. not sharing with others).