Password Control

[Former Member]

We have a concern that what if the basis user administrator uses the user id, which he has just created, for sometime and then communicates it to the actual user. The user promptly changes his password and starts using it. But some damage has already been done which may come to light after some time (if at all).

Is there a facility in SAP which helps in this case? Any body who faced same questions? Any solution - technical or administrative?

[Wolfgang_Janzen]

When an user administrator creates a new account assigning a password, the user will be prompted to change the password (which is also known to the admin) on the very first time he is using that password to logon to the system (to make sure that the new password is then only known to him).

An user administrator might, of course, first use the newly created account to impersonate that user (in an unauthorized way). He will then be asked to change the password. If he informs the authorized user on that new password, the user should become suspicious by the fact that the system will not prompt him for password change - and will indeed even reject a password change request (submitted by that user) with the comment "You have already changed your password, today".

Well, the user administrator might be "smart" enough to reset the password after usage of the account. But in that case this will become visible in the change records (to be evaluated by an auditor). His actions might also be recorded by the Security Audit Log and occur in the Statistical Records as well.

After all: why should an administrator take that risk? Using the "segregation of duty" principle to separate User Administration tasks from Auditing tasks will increase the risk for disloyal administrators. Do not forget: they are employees and risk their job (and reputation). In contrast to hackers this is an effective deterrent.

[Former Member]

You can audit the changes from report rsusr100, assuming that the admin didn't delete / archive the entries of USH04.

If the admin created a purchase order / GL entry / changed a logged table / created a syslog entry etc as the user, then those records should be there as an audit trail too.

If the authentication (identity management) is managed from an active directory (there is lots of discussion around this and benefits from doing it), then the chances of the admin doing what you describe decreases rapidly depending on the tool and access which the admin has.

[Wolfgang_Janzen]

Sorry to disagree: using an Active Directory (=> Microsoft ADS => Domain Controler) as Identity Management solution and IDP (Identity Provider, performing User Authentication) you'll face exactly the same situation: it might not be prevented that disloyal user administrators misuse their power (e.g. to create user accounts, using them and resetting the passwords afterwards) - but that misuse can be detected by performing audits. Same is true for any other solution as well (e.g. using other LDAP servers).

It's not just the tools. More important is the frequency of audits and the skills of the auditors. If noone evaluates the audit logs then misuse will remain undetected. "Trust is good, control is better".

Regards, Wolfgang

PS: since you are (same as me) assuming that Suneel was referring to the ABAP stack I want to emphasize that the ABAP stack does not support LDAP authentication (except the special case of MS ADS and using the SNC libraries provided in <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/352295">SAP note 352295</a>).

[Former Member]

I agree that monitoring is indispensable irrespective of the state of the technology and the skills of the auditors... but considering the abundance of these two commodities without even mentioning the cost, a "Nothing is better than something" approach is typically encountered long before the "Trust is good, control is better".

Besides, if the admin were smart they could logon without changing the password even if it was initial (technically they could even logon with an incorrect password) so checking the change report wouldn't work either. One would need to audit all the logons of all types and gain evidence of the authenticity from the caller. Imagine that with 10000 users IDs!

When that becomes a legal requirement and / or generally accepted practice, then I will open an Audit Institute

[Former Member]

Hi

Your statement sends shivers down my spine!

"Besides, if the admin were smart they could logon without changing the password even if it was initial (technically they could even logon with an incorrect password) so checking the change report wouldn't work either."

Can you elaborate? I see this as a bigger threat than the original one mentioned in this thread.

[Wolfgang_Janzen]

I also consider this an offensive statement and would like so see some evidence. Especially for the statement that admins "could even logon with an incorrect password".

Regarding the comments on the remarks of Oliver Derksen:

I agree with Julius in that point - it's like a "hen-and-egg" problem: what is first - the user account or his assignment to the HR org structure (allowing to derive the proper role assignments)?

After all: you still need to perform audits.

But of course: good tools make life easier (or even enable such auditing, only).

[Former Member]

No shivers or offense intended. Please accept my apologies.

Of course, the access of the admin can be restricted and the installation configuration of the system can be performed such that these things are not possible. I am also confident that the ECC 7.0 will have many restrictions available which I am not aware of, and therefore I will with almost certainty be proven wrong.

But, purely as an academic excersize, let us consider that history has shown that when someone can maintain their own authorizations, then they will tend to give themself SAP_ALL. So we have an admin who has an entry in table USREFUS with the value SAP*. Vartually invisible, virtually no audit trail.

He goes to SM59 end sets up a temporary destination to the same system and enters the business user and password and saves it as 'TEMP'. Default installation = no audit trail.

He then types .ys into the ok-code field and navigates into the workbench (no security audit log entry for a transaction used) and selects any of a number of functions (e.g. abap4_call_transaction or perhaps even remote_test could work) and single tests it via destination 'TEMP'. USR02-TRDAT is ignored, LTIME as 000000000 is ignored, but updated.

If the admin made a typo when entering the login dates in SM59, then he would not have noticed the difference if his choice of call had been system_invisible_gui.

The security audit log writes a successfull rfc call entry... one of 50 MB worth of entries.

He then goes to the Tip&Tricks report and removes the USREFUS entry again. The application stats show transaction RSHOWTIM, but the contents of it are unknown.

Of course one can prevent this, but if it happens then an auditor has little chance of finding it.

I consider this purely as an theoretical evidence in a worste case scenario. If you find it offensive, I will remove it.

[Wolfgang_Janzen]

Where (in your lengthy but detailed description) is the part describing how an administrator can <b>logon to the system using invalid credentials</b>?

I'm not sure whether you are referring to "<b>internal RFC calls</b>" (contraint: calling <user, client, system> = remote <user, client, system>). Those are indeed treated identical to "local function calls" regarding "logon" - since you are already "inside" there is no need for authentication.

So, if you are entering your own logon data (<user, client>) into an RFC destination that targets at your current system, do not be surprised that this is not treated as logon attempt; the <password> entered in the RFC destination will not be evaluated in that case. However: if another user (different client or userID) is using that RFC destination the logon data (stored in that destination) will be evaluated.

PS: table USREFUS contains the assignment of "reference users" (and "alias names") to "users". Those assignments are displayed and maintained via the normal user management functions (transaction SU01). As described in the documentation "refence users" are similiar to "collective roles" (and therefore listed on the "roles" tab in SU01).

PS: performing a "connection test" in SM59 will also not evaluate the logon data; this is just a physical connectivity test. In order to validate the logon data you need to perform an "Authorization test" (menu path: Utilities > Test) - do not get irritated by the wrong expression; it should be read as "Authentication test".

[Former Member]

The logon data will be evaluated and must be there, but if the call is assigned to a system function, then it does not (necessarily) have to be correct.

This occurred when the admin made a typo (typing error in SM59).

Personally, I find the expression "Authorization test" correct. My understanding is that if the "authorization test" is performed (active), the system needs to log the user on to get a result for the authority check. This triggers the authentication.

[Wolfgang_Janzen]

Yes, "RFC system functions" (i.e. functions belonging to function group SRFC, e.g. "RFC_PING" which is used by the "connection test") can be called without providing (valid) logon data. In that sense they are "public" RFC functions.

But that's much less critical than what you have been posting previously ("[admin] could even logon with an incorrect password"). <b>No, he cannot logon with incorrect logon data but he can call "public" RFC functions (see above: function group SRFC), only.</b>

PS: "authorization test" / "authentication test" - well, prior to any authorization checks (answering the question "Is the user allowed to perform a certain action?") you need to identify the user (=> authentication). Yes, if such an "authorization test" was successful you can deduce that the "authentication test" also has to have been successful.

[Former Member]

Yes, you are correct Wolfgang. I guess you would know...

At least "I will with almost certainty be proven wrong." was correct ))

As a consolation, I could have said that "admin could supply a correct password without triggering a change, if he prior supplied an incorrect password."

[Wolfgang_Janzen]

Well, yes: it does not make any difference whether you provide a correct or incorrect password when no authentication is required ...

I'm glad that we both agree on that.

[Former Member]

Hi,

I am kind of new to this forum. Hello and: My apologies if I raise strange issues.

My reply relates to the detailed (and not too lenghty) description jbussche provided. Specifically to the sentence:

"Of course one can prevent this, but if it happens then an auditor has little chance of finding it."

Well - of course one of the important questions after reading such a description on how to log on without changing the initial password is: How to prevent this ?

And I know a few ways to prevent or at least make visible the detailed steps described there. But the problem is: Most of these detailed steps (USREFUS, SM59, .ys, ...) do not have to be done on the system on which the user master record resides ("production"). They could be done on any system in the network ("sandbox" - good old WAS would be enough. Did anybody try startrfc.exe on "abap4_call_transaction" ?).

To me it seems that the core problem is the production system behaviour when RFCing modules like "abap4_call_transaction".

1) It could be tackled by limiting production user S_RFC authorizations excluding those function groups that contain modules that are regarded dangerous (i.e. all function modules that actually do something):

This may work for specifically dangerous cases, but does not really address the problem at hand. It is more like: We have a problem with the password, let's limit user authorization so that the user can't do any damage anymore. You run the risk that this user also can't do any work then

2) It could also be tackled by some production system parameters that may change the system behaviour (e.g. "rfc/reject_expired_passwd"):

I have no experience with them but nevertheless expect that most RFC based interfaces break when these system parameters are actually effective( )

So the remaining question still is: Does anybody know an effective way to prevent this RFC logon with an initial password ?

Ralf

[Wolfgang_Janzen]

Hi Ralf,

you are referring to the problem of "remote function calls with SAPGUI usage" (option -GUI when using external RFC clients).

Yes, indeed this is a (general) problem - not limited to just the function module you have mentioned. Actually an "RFC connection with attached SAPGUI" is functionally similiar to an ordinary "SAPGUI connection". Consequently, the ability to interact with the user should be used to perform a (mandatory) password change dialog (when required). The fact that this is currently not done (although technically possible) could be considered a "functional deficit" (=> feature request) or "functional defect" (=> bug report).

Well, you can set profile parameter rfc/reject_expired_passwd = 1 (see <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/161146">SAP note 161146</a>) but it impacts the entire system.

A more decent way to limit the impacts is to restrict the lifetime of initial passwords. This is possible as of ABAP 6.20 (see <a href="http://service.sap.com/_{iron/fm/011000358700000431401997E/450452">SAP note 450452</a>: profile parameter login/password_max_reset_valid and was refined with ABAP 7.00 (see <a href="http://service.sap.com/}iron/fm/011000358700000431401997E/862989">SAP note 862989</a>: profile parameter login/password_max_idle_initial and login/password_max_idle_productive).

(Don't get confused: all those profile parameters are referring to initial/reset/expired passwords, except login/password_max_idle_productive, of course).

On the other hand:

under certain circumstances it might be desired to ignore password change requirements (e.g. when accessing backend systems through an Enterprise Portal), see <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/869218">SAP note 869218</a>.

In general it is not possible for an ABAP backend to interact with the user in order to enforce a password change. In that case it is the responsibility of the RFC client to determine whether a password change is required and to react accordingly, resulting in password change requests (using RFC function module SUSR_USER_CHANGE_PASSWORD_RFC). <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/899614">SAP note 899614</a> contains some corrections which enable the external RFC client to display detailed error messages (in case of rejected password change requests).

Regards, Wolfgang

[Former Member]

Yes, the suggestion of "prevent[ing]" was overstated, unfortunately. It would be nice if there were a master switch to turn all security on and automatically adjust all the archtecture, but there isn't.

However it is possible to improve the protection from the various possibilities for misuse and monitor abusers, in addition to just buying bigger and better architecture.

SAP default installation has improved to protect zero security investment customers from the average auditor, but it takes some skills, experience and infrastructure to activate or extend the default installation to become a formidable hurdle for abuse. It also requires significant controls and discipline from an organization.

I agree with Wolfgang, if an admin is risking their job / reputation by being insubordinate or fraudulent, then they sooner or later dig their own hole.

[Wolfgang_Janzen]

Yes, I'd also like to have such a "master switch" (to turn all security on) ...

Well, I'll dream of that during my vacation ...

... starting tomorrow. So don't be surprised if I do not reply to any postings in the next few weeks.

Cheers,

Wolfgang

[Former Member]

Hi,

a possible technical and administrative solution would be using an enterprise identity management solution. In such a scenario, the IdM solution takes care about handling accounts, not a human administrator anymore. Imagine the following scenario:

- an employee requires access to an SAP system. He has to fullfill certain tasks that require certain ABAP roles.

- The employee uses a web interface to request the desired roles. This generates an approval request sent to the employee´s line manager for approval.

- The line manager approves, an account is created by the IdM solution, the requested roles are assigned to the account, the initial password is sent to the user by encrypted e-mail and the whole thing is logged in a digitally signed audit file.

This of cause requires 3rd party software like the Siemens identity management solution called DirX Identity. Fore more information chek out

SAP´s strategic choice for IdM: Siemens DirX or <a href="http://www.siemens.com/secure-communications">Siemens DirX Identity Homepage</a>

Regards,

Oliver

[Former Member]

Hi Oliver,

Nice concept, but it has consequences / prerequisites which go beyond passwords and can dig deep into the costs or culture of a company:

a) The company needs a hierarchical org structure. This may conflict with some modern management philosophies..

b) Even with a complete org structure, you need the data and you need to maintain this data realtime...

d) You need to maintain, monitor and secure the workflows...

In the absence of the org structure to ear-mark every employee neetly into a box, the possibility of routing the workflow to the role owner is an alternative, but:

1) You would need roles which are robust and more negative testing...

2) You would need to do a code review of every transaction added or brought in from a tcode indicator or lying in an unmaintained call relationship as the role owner would not have the overview which the admin had. SU24 and SE97 will become your best friends...

3) You would need some rudamentary org structure anyway and the function of the role owner to be able to tie it to the workflow, and you need to maintain it realtime...

4) You would need to give the role owners a view, or a programmed control to protect them from themselves, which does a role to role analysis based on an auth value result before they are able to "click away" at the screen. This would need to be set up...

Besides this, most people I know have a reasonably good relationship to their bosses. Just because SAP does not roll out login/multi_user_disabled defaulted to 0 anymore does not mean that the "you scratch my back, I´ll scratch yours" has disappeared.

There is nothing which comes close to a well trained, responsible and alert human admin.

Kind regards,

Julius

[Former Member]

Folks,

agreed, it has consequences and agreed, it goes far beyond Suneels initial question. I want to keep my answer short, because it is not really related to the original question. Just some quotes:

The intention of an IdM solution is not to create/maintain application roles (ABAP roles, NW Portal roles, Active Directory Groups, Exchange mailboxes ..). the IdM solution uses these app roles for enterprise wide role-/rule-based entitlement.

Imagine a "typical" sales rep: He needs access to portal based applications. In order to be able to log on to the portal, he requires access to the network. Sales guys without e-mail? Unimaginable! In this simplified example, our sales rep already requires

- An Active Directory account and some group membership

- An Exchange mailbox

- A Portal account and some roles assigned to it

The IdM solution would combine these - at least - 3 application roles (let´s consider the mailbox as a role in Active Directory) to an enterprise role called "Sales". Very simplified, I know If you want to know more about how it works and what it can do, check out this screen cam demo .

As I said, I want to keep it short here. If some of you are interested in how Siemens manages more than 400.000 accounts for its NetWeaver based Employee Portal (by the way, the largest NW Portal installation in the world), feel free to contact me.

Cheers,

Oliver

Message was edited by: Oliver Derksen

[Former Member]

Hi,

Well, here's my 2 cents to this discussion. The way we do it in our organization is to create a fire fighter id and assign that out when requested. That has all the roles needed to just create a user id, set/reset password, etc, but no business roles or technical roles whatsoever. The usage of that id is logged through the VRAT tool and reviewed every week by an internal audit team. They also check the change documents for that user id and also the system tables. All our system tables are logged.

There are ways and means around this control, but so far we didn't have any instance of misuse. Also per the SOD policy, the person who has the fire fighter id is not allowed to use the id(dosen't mean he/she can't)....

Cheers,

Kedar

[Wolfgang_Janzen]

Hi Kedar,

thanks for your contribution to this thread.

I fully agree with you:

- there is a need for such a "fire fighter" account

- its usage needs to be restricted and reviewed

- misuse can not be prevented by technical means but by organizational measures (e.g. firing the employee which violated the SOD policy)

Cheers, Wolfgang

PS: if even the "fire figher" account somehow gets locked or lost, the time has come to activate the emergency account - but only then (as last resort - when "someone has locked the door and thrown away the key").

[Former Member]

I don't know whether its possible or not with SAP.

But in Portals we have an option in SMTP configuration

to send an email immideately to the user with logon details whenever his ID is created.

and email address is mandatory to create an user.

So even if administrator try doing something with this ID and change the password to initial one. then also it sends an email saying password is changed.

[MichaelShea]

Just a minor correction Keerti (unless I am just misunderstanding your comment), an e-mail address is not mandatory for creating a user in the portal. But it sure does make it easier to pass on logon information.

-Michael

[Wolfgang_Janzen]

Well, disloyal administrators might first assign their own mail address when creating the user and change it afterwards ... (if the mail is only sent out when a user is created but not when changing the attributes or if the mail contains the information whether the account was created or modified, the admin might delete and recreate the account to avoid the divulging effect).

=> technically misuse cannot be prevented completely

But: the effort to erase all evidence (change documents, traces, log entries, ...) might be sufficiently high to deter the majority of disloyal administrators .

In antique times people used line printers (printer which prints information one band at a time) as logging device. Such append-only devices are a solid and reliable evidence storage solution. But even here: the guy who has physical access to that device could manipulate it ... (or simply delete the evidence ...).

Keep in mind: there is never a 100% secure solution.

And the effort becomes higher the closer you reach that magic watermark. But that also means: it's quite easy to increase the security level from low to medium. The starting point should be a medium security level. That's why many security-relevant profile parameters have new default values as of NetWeaver 2004s (ABAP 7.0).

The <a href="http://service.sap.com/SOS">SAP Security Optimization Service</a> aims at the same target: to increase the security of the SAP system at a customer site.

[Former Member]

Shea, I am working on EP6.0 SP14. and email address is mandatory to create an user. and I know in earlier patches of EP6.0 its not mandatory.

and administrator cannot use his own email address, because we can configure different text messages for different activities that can be carried on a users logon data.

For R/3 we can get audits, logs,traces,etc but everything is a cure but not prevention.

Probably SAP should include a checkpoint from user side also to get his userID activated. or we have to use a 3rd party tool.