topic Re: Avoid Change Password Request for single User in Application Development and Automation Discussions

Avoid Change Password Request for single User

Former Member — Fri, 30 Jun 2006 23:51:40 GMT

Hi folks,

I hope you can help me with this.

In my system i have activated parameters for password change requirement each 90 days. This parameter is cross system, i mean for every user in the system.

I have a system user used for many interfases with other systems, but eventually i need to use this user as a dialogue one, so i change the type of the user. But since last week, when i change the type as dialogue the system ask me for change the password.

I need to avoid this for this only user. I can't change the password because this means the password should also be changed in all the other systems.

Can i avoid this behaviour for this only user???

I tried setting field BCDA1 of table USR02 for a very distant date in the future, but this did not work out.

Help please,

Christian

Re: Avoid Change Password Request for single User

Former Member — Mon, 03 Jul 2006 04:57:56 GMT

Although not best practice if the user has sensitive access, you could use the 'service' user type - allows dialog login without password expiry.

Re: Avoid Change Password Request for single User

fredrik_borlie — Mon, 03 Jul 2006 07:35:01 GMT

Hi, it is not really a good way to use dialog users as an integration user. This means that all persons having access to SM59 can acutally log on to the other system as that integration user (usually with SAP_ALL as authorization).

However there are a multiple selection of choices to do.

One could be to update BCDA1 regularly. But it is a realy bad hack.

I will second Justins motion about setting the user as a service user, but then you will probably violate the license agreement.

But another way of doing it is maybe to use Trusted RFC destinations.

http://help.sap.com/saphelp_nw2004s/helpdata/en/d3/5b5c8ac5a93941b9f4e2f09b50beb4/frameset.htm

This actually removes the need of passwords.

Best wishes!

freppe

Re: Avoid Change Password Request for single User

Wolfgang_Janzen — Mon, 03 Jul 2006 08:48:26 GMT

The recommended user type (ABAP user management) for such system-to-system communication is SYSTEM.

The user type SERVICE is intended to be used for anonymous public services (=> e.g. logon data preset in ICF services or in service files of an external ITS).

Please notice that the user type COMMUNICATION is not excepted from password change requirements - same as user type DIALOG. Both are intended to be used by individual users.

All that is documented in <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/0622464">SAP note 622464</a>.

Best regards, Wolfgang

PS: please resist from updating table USR02 directly.

The data structure has changed several times.

Only use proper API functions.

Re: Avoid Change Password Request for single User

Former Member — Mon, 03 Jul 2006 15:34:22 GMT

It is not a good idea to use a SYSTEM user (or user of any type... Communication or Dialog or Service) for multiple connections as you become inflexible (as you have noticed) and troubleshooting when things go wrong is much more difficult.

Why changing BCDA1 is not working for you sounds like it may be caused by the fact that USR02-LTIME = 000000 from you resetting it 6 times in SU01 or putting the hash back?

The change password screen is not available for an rfc logon.

Logon via the SAPGUI first after resetting the 5th time (password is initial...), then change it to your pw you want and leave it.

If this does not work and LTIME is not 00000000, then you might also have implemented some new password rules which don't like the quality of your pw AT RFC LOGON TIME, not at 90 days.

(test editor to update "last post" date)

Message was edited by: jbussche

Re: Avoid Change Password Request for single User

Wolfgang_Janzen — Tue, 04 Jul 2006 06:52:21 GMT

Hi "jbussche",

I only partially agree with you:

Yes, it can be a problem when using the same technical account in multiple system-to-system communications (where still it is strongly recommended to use the proper user type SYSTEM, or SERVICE if GUI ability is required) for various reasons:

1. the more (different) scenarios such an account is used for, the more difficult it will become to assign a proper authorization profile / role to that account; very soon you'll end up with SAP_ALL ...

2. password-based authentication (which can be avoided for ABAP-to-ABAP calls by using "RFC Trusted System") will become more instable the more clients do share knowledge of the (same) password; if you change the password of the account all those RFC clients need to be notified (in order to update their password storage)

3. auditing will become nearly impossible for such multiple-purpose accounts

Once more again:

Please resist from updating (single fields of) table USR02. All those implementation details are subject of change - and that's not only theoretical, but does happen (potentially with each release). <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/0862989">A lot of things have changed with ABAP release 7.0 (NetWeaver 2004s)</a>, for example.

Regards, Wolfgang

Re: Avoid Change Password Request for single User

Former Member — Tue, 04 Jul 2006 08:52:14 GMT

Hi Wolfgang,

I agree with you completely. What I meant was only that updating usr02 is possible, at logon time to show where the problem could be coming from.

Using an account of ANY type with saved logon data in any form (no matter how well hidden or encrypted) from multiple communication sources is asking for trouble. If it must by used, then user type SYSTEM is the least worst option.

I do not have access to a 7.0 system Does Type C still exist?

Regarding point #2: It is a good thing to change passwords periodically, and in this case particularly so as an abap -> abap call has a password hash which can be converted back to plaintext and could be found in any (just one) of the multiple systems involved. If the hash is only 16 characters long in any of those multiple systems, then the client and other attributes of saving the data in SM59 do not matter either. If it is non-abap -> abap, it is likely to be saved in plaintext anyway.

Re point #3: Auditing multiple-purpose accounts is possible, but a pain. If you are lucky, then table SNAP (St22) can help to detect where the problems come from when they happen, and by the sound of things there might be one more user ID locked in the system. If you are unlucky, then you need to look via table MONI (ST03N).

You can also add your own coding to LSTUWU49.

* call user exit with statistic records

  SELECT SINGLE * FROM tfdir WHERE funcname = 'Z_USEREXIT_WORKLOAD'.
  IF sy-subrc = 0 AND rc = 0 AND tfdir-fmode = 'R'.
    CALL FUNCTION 'Z_USEREXIT_WORKLOAD'
       STARTING NEW TASK 'USEREXIT'
       EXPORTING
            instance                   = my_name
            server                     = sy-host
       TABLES
            v2_normal_records          = v2_normal_records
            v2_btc_step_records        = v2_btc_step_records
            v2_table_records           = v2_table_records
            v2_rfc_client_records      = v2_rfc_client_records
            v2_rfc_server_records      = v2_rfc_server_records
            v2_rfc_client_dest_records = v2_rfc_client_dest_records
            v2_rfc_server_dest_records = v2_rfc_server_dest_records
            v2_spool_print_records     = v2_spool_print_records
            v2_spool_activity_records  = v2_spool_activity_records
            norm_subrecord_index       = norm_subrecord_index
       EXCEPTIONS
            system_failure             = 1
            communication_failure      = 2.
    COMMIT WORK.
  ENDIF.

Regards, Julius

Re: Avoid Change Password Request for single User

Wolfgang_Janzen — Tue, 04 Jul 2006 11:43:28 GMT

Well, if you want to analyse logon problems, you should use the tracing approach described in SAP note 495911.

In SDN you can <a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/downloaditem?rid=/library/uuid/cfc19866-0401-0010-35b2-dc8158247fb6">download the "Sneak Preview SAP NetWeaver 2004s" version</a>.

Yes, the user types are still the same.

And they still have the same semantics as described in <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/0622464">SAP note 622464</a>.

New in NW2004s (ABAP 7.0), <a href="http://service.sap.com/~iron/fm/011000358700000431401997E/0862989">amongst various other things</a>, is the storage of logon data which has been entered for outbound communication (SM59) and of local ICF service users (SICF): this data is no longer stored in ordinary database tables but in the "secure storage".

(PS: the user master records (USR02) contain only the hash values of the passwords; since hash functions are not invertible you'll not be able to retrieve the plaintext passwords; the "secure storage" however uses encryption - and provides methods to retrieve the plaintext information, but allows to control and restrict the callers).

Well, I do not think that you'll be able to convince system auditors to use such tools like ST22 (analysis of runtime errors - not the suitable tool at all) and ST03N. Keep in mind that the ability to trace back actions to individual users is an essential (legal) requirement in some countries of this world ...

Cheers, Wolfgang

Re: Avoid Change Password Request for single User

Former Member — Tue, 04 Jul 2006 14:12:07 GMT

Thanks for that Wolfang! Once I have saved up enough pocket money to buy a big enough server, I will download the preview version. )

My concern with USR02 is less inverting the hash, than just copy & pasting it. Have the attributes of the hash become more unique now in 7.0?

Regarding system auditors, this time I only partly agree. It may be difficult to convince them, but that does not make ST22 and ST03 less usefull. SNAP and MONI can be very efficient, cost effective and risk based approaches to systems auditing.

SNAP can tell interesting stories about the system design, self developments and the runtime habits of the application support, admins, users, auditors, developers, consultants, system accounts and rfc users. Particularly if things are going seriously wrong, or process monitoring is being seriously neglected, or rfc connections are being seriously misused, or short-dumpers are developing in the production system... then you can literally find detailed information on it in a SNAP.

Same goes for MONI - Auditors can be easily convinced to spend days and weeks analyzing profiles, the assignment of these to users and the tools available to maintain them - a huge and complex task - only to realize to themselves that the tool used is reading the wrong tables anyway, didn't consider customizing & config and then they still don't know about the one user who shared their almost invisible access with all the others, nor what the other clients and the development system looks like. Looking at the system via a corrected view of MONI and knowing what to look for and what to expect, or how to spot something odd, is a faster start to assessing the system - but requires more experienced auditors and could mean less hours billed on the client.

Kind regards, good luck for this evening and thanks for the soccer ball which arived today!

Julius

Message was edited by: jbussche

Re: Avoid Change Password Request for single User

Former Member — Fri, 29 Sep 2006 10:32:09 GMT

Hello all,

Just some comments about this "problem".

ALEREMOTE user should be usertype "service"

RFC user should be usertype "communication"

You do not logon with this 2 users, and we are never prompted for changed of passwords.

I hope that you change password on your "superuser"

hint: service.sap.com/security

Regards,

Karl Yngve

Re: Avoid Change Password Request for single User

Wolfgang_Janzen — Fri, 29 Sep 2006 12:03:12 GMT

Almost - but not entirely - right:

you should assign the usertype "SYSTEM" to technical accounts (such as ALEREMOTE, TMSADM, WF-BATCH, ...) which do not require any SAPGUI capabilities (since the services are running without any user interaction).

Notice: the usertype "COMMUNICATION" is also subject of password aging (see note 622464), just that it is hard to enforce (interactive) password change dialogs to be supported/provided by all (external RFC) clients.

Regards, Wolfgang

Re: Avoid Change Password Request for single User

Former Member — Fri, 29 Sep 2006 12:29:58 GMT

Hi Karl,

How are you preventing someone (anyone) from not logging on with these 2 users?

Cheers,

Julius

Re: Avoid Change Password Request for single User

Former Member — Wed, 17 Jan 2007 13:29:01 GMT

Hello,

I will put ALEREMOTE and the RFC user in user group SUPER. Reason is that not every one can do useradmin for that usergroup..

My ALEREMOTE and RFC user is standard as communication user - and there is not need for password and login on day to day basis. Therefor those passwords are stored on a secure place (not on a yellow post-it note... ).

If i need to schedule a new job with for the RFC user, i switch it to dialog, and log in.

When this task is done, i switch back to communication.

br,

Karl

Re: Avoid Change Password Request for single User

Wolfgang_Janzen — Wed, 17 Jan 2007 17:38:51 GMT

See above:

you should assign usertype SYSTEM to user ALEREMOTE.

And you might (temporarily) change the usertype to SERVICE in case you require SAPGUI capabilities (e.g. for debugging purposes). Reasons are provided in my previous postings.

Regards, Wolfgang