topic Re: Password Control in Application Development and Automation Discussions

Password Control

Former Member — Thu, 27 Jul 2006 10:52:10 GMT

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?

Re: Password Control

Wolfgang_Janzen — Thu, 27 Jul 2006 11:07:48 GMT

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.

Re: Password Control

Former Member — Thu, 27 Jul 2006 12:14:52 GMT

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.

Re: Password Control

Wolfgang_Janzen — Thu, 27 Jul 2006 13:00:43 GMT

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>).

Re: Password Control

Former Member — Thu, 27 Jul 2006 15:47:20 GMT

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

Re: Password Control

Former Member — Thu, 27 Jul 2006 18:08:44 GMT

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

Re: Password Control

Former Member — Thu, 27 Jul 2006 20:45:23 GMT

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

Re: Password Control

Former Member — Fri, 28 Jul 2006 04:45:03 GMT

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.

Re: Password Control

Wolfgang_Janzen — Fri, 28 Jul 2006 06:53:49 GMT

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).

Re: Password Control

Former Member — Fri, 28 Jul 2006 09:28:00 GMT

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.

Re: Password Control

Wolfgang_Janzen — Fri, 28 Jul 2006 09:55:35 GMT

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

I'm not sure whether you are referring to "internal RFC calls" (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".

Re: Password Control

Former Member — Fri, 28 Jul 2006 10:11:48 GMT

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.

Re: Password Control

Wolfgang_Janzen — Fri, 28 Jul 2006 10:36:16 GMT

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"). No, he cannot logon with incorrect logon data but he can call "public" RFC functions (see above: function group SRFC), only.

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.

Re: Password Control

Former Member — Fri, 28 Jul 2006 11:15:04 GMT

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."

Re: Password Control

Wolfgang_Janzen — Fri, 28 Jul 2006 12:02:37 GMT

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.

Re: Password Control

Former Member — Fri, 28 Jul 2006 13:41:29 GMT

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

Re: Password Control

Former Member — Wed, 02 Aug 2006 09:35:41 GMT

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

Re: Password Control

Wolfgang_Janzen — Wed, 02 Aug 2006 10:32:15 GMT

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

Re: Password Control

Former Member — Wed, 02 Aug 2006 13:52:35 GMT

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

Re: Password Control

Wolfgang_Janzen — Wed, 02 Aug 2006 15:05:25 GMT

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").