Skip to Content

The purpose of this document is to describe the steps to be done when the password restrictions are preventing STMS from functioning. This document describes the notes to be applied and the execution of report TMS_UPDATE_PWD_OF_TMSADM.

Before proceeding further with TMSADM please ensure that all related notes at the end of this document have been reviewed and/or applied to your system(s) if relevant.

 

Changing the TMSADM password

The password restrictions are preventing STMS from functioning. Some password restrictions that affect the TMS user TMSADM:

/wp-content/uploads/2014/07/1_493292.png

You can also run in SE38 reports RSPFPAR and RSPARAM to get information about the parameters.

Also check parameter login/password_downwards_compatibility, make sure it is set to ‘1’ in all systems. if it is set to ‘5’, it means “compatible to old release” and this forbids lowercase characters.

You will find further information in Profile Parameters for Logon and Password (Login Parameters).

And note 2467 – Password rules and preventing incorrect logons.

Make sure the RFC’s are not manipulated in all systems as detailed by article 1730407 – Internal error in TMS communication 5.

The trusted services are already activated:

/wp-content/uploads/2014/07/2_493293.png

You will find further information in Activating TMS Trusted Services.

The user TMSADM was already reset and the RFC’s were generated in STMS:

/wp-content/uploads/2014/07/3_493294.png

According to SAP note 1568362 – TMSADM password change, there are two ways of solving this problem. One is to execute some manual steps (as of release 7.3, table TMSCROUTE is not involved in the TMSADM change password configuration.) and the other one is if there is a large landscape, there are some notes to be applied and you should run a report. In this example, we will go with the second option:

1.Apply all the mentioned notes from note 2493023 – TMSADM Problems: Required notes in each Domain Controller and in all the other systems of the landscape.

2. Make sure the user TMSADM is not locked in all the systems of the landscape:

/wp-content/uploads/2014/07/7_493302.png

3. Run report TMS_UPDATE_PWD_OF_TMSADM which must be run in the DC (domain controller) client 000.

 

TMS_UPDATE_PWD_OF_TMSADM has three different options:

 

1.    Own Password as in System Settings
With this option the customer will select his own created password for TMSADM user. When choosing this option, the following fields are available:
– Password
– Confirm Password
It must be used by the customer to enter the password they want for TMSADM user.

 

2.    New Standard Password (see SAP Note 761637)
With this option the program will automatically set “New Default Password” for TMSADM;

 

3.    Old Standard Password
Finally, this option will set the “Old Default Password” for TMSADM user.

The “Old Default Password” is the password that SAP defined for TMSADM user long time ago and it has been used for years by our customers. That password only contains letters. But if a customer sets stringent password rules in a system (for example the password must contain at least one digit, or special characters), user TMSADM is affected by those restrictions. Therefore, SAP has created a “New Default Password” that complies with the general password restrictions that are set in a system. This new password contains uppercase and lowercase letters, digits and special characters.

 

As of SAP Note  2227412 (or SAP_BASIS SAPKB74014 / SAPK-75002INSAPBASIS).

 

For security reasons, the TMSADM default password is no longer allowed to be provided. For this reason, the options for this have been removed.

As such when you run Report TMS_UPDATE_PWD_OF_TMSADM you will only get the option to define your own TMSADM password. The same is true when joining a system to the domain or creating a domain link.

 

The results of its execution:

 

/wp-content/uploads/2014/07/9_493306.png

 

3. Should domain links exist then use SAP note 1515926. The note should be applied to all systems of the connected domains. Once the note is applied start the report that is described in Note 1414256 on all of the domain controllers of the connected domains. That means executing TMS_UPDATE_PWD_OF_TMSADM in client 000 on all domain controllers.

When domain links are involved TMS_UPDATE_PWD_OF_TMSADM is more complex.

Let’s illustrate with an example:

  • DOMAIN_A has 3 systems DEV1, QAS1, and PRD1.
  • DOMAIN_B has 3 systems DEV2, QAS2, and PRD2.

In DEV1, QAS1 and PRD1 the following TMSADM RFC’s exis

  1. TMSADM@DEV1.DOMAIN_A
  2. TMSADM@QAS1.DOMAIN_A
  3. TMSADM@PRD1.DOMAIN_A

In DEV2, QAS2 and PRD2 the following TMSADM RFC’s exist.

  1. TMSADM@DEV2.DOMAIN_B
  2. TMSADM@QAS2.DOMAIN_B
  3. TMSADM@PRD2.DOMAIN_B

You link DOMAIN_A with DOMAIN_B.

The following RFCs are added to systems DEV1, QAS1 and PRD1.

  1. TMSADM@DEV2.DOMAIN_B
  2. TMSADM@QAS2.DOMAIN_B
  3. TMSADM@PRD2.DOMAIN_B

The following RFC’s are added to systems DEV2, QAS2 and PRD2.

  1. TMSADM@DEV1.DOMAIN_A
  2. TMSADM@QAS1.DOMAIN_A
  3. TMSADM@PRD1.DOMAIN_A

This allows systems in DOMAIN_A to communicate with systems in DOMAIN_B.

As a result when you update the password for user TMSADM in DOMAIN_A (by running TMS_UPDATE_PWD_OF_TMSADM) it will also update
RFCs
TMSADM@*.DOMAIN_A in DOMAIN_B (when note 1515926 is implemented to all systems in both domains).

The same happens when you update the user password for TMSADM in DOMAIN_B (by running TMS_UPDATE_PWD_OF_TMSADM). The report will update RFCs TMSADM@*.DOMAIN_B in DOMAIN_A.

As a result communication between the two domains will remain. If note 1515926 were not applied to all systems of both domains and you ran the report TMS_UPDATE_PWD_OF_TMSADM from one or both domain controllers then communication between DOMAIN_A and DOMAIN_B is no longer possible . This is the result of the user TMSADM locking due to too many failed logon attempts with the wrong TMSADM password.

It is important to check (via RZ11) parameter login/password_downwards_compatibility.

/wp-content/uploads/2014/07/10_493308.png

 

As of Basis release (SAP_BASIS) 7.0, the system supports logon with passwords that can consist of up to 40 characters (previously: 8), and for which the system differentiates between upper- and lower-case (previously: system automatically converted to upper-case). All Unicode characters are also supported.

Unfortunately, this change is not backward compatible. The passwords are stored as backward incompatible hash values. If this system is operated with other systems, which only support
backward compatible password hash values, the system must react appropriately.

The values of this profile parameter define the desired behavior (Default value = 1):

0 :  No backward compatibility; system generates only new
(backward incompatible) password hash values.

1 :  System also generates backward compatible password hash
values internally, but does not evaluate these for logons
(to this system) using a password; this setting is required
if this system is the central system of a Central User
Administration and systems that only support backward
compatible password hash values are also connected to the
system group.

2:  The system also generates backward compatible password hash
values internally and evaluates these if a logon using a
backward incompatible password failed, to check whether logo
with the backward compatible password (truncated after eight
characters and converted to upper-case) would have been
accepted. This is logged in the system log; the logon
fails.  (Identification of backward incompatibility problems).

3 :  As with 2; however, the logon is regarded as successful.
(Avoidance of backward incompatibility problems).

4 :  As with 3, but no system log entry is written.

5 :  System only issues backward compatible password hash values.

login/password_downwards_compatibility = 5 will not work with TMSADM using “new standard” password as this means that only downward compatible passwords are allowed, which are in uppercase and max. 8 characters long.

FINALLY :

There is now the addition of new destinations in TMS_UPDATE_PWD_OF_TMSADM because in large systems using the above report is a complex matter.

The TMSADM update report requires an RFC connection for each system in the landscape and if you have a very large landscape it means logging onto alot of systems. Previously, there was no option to use trusted RFC for this. As a result note # 1801805 was created. Please implement the correction instructions in the domain controller (remember if the domain controller changes, the note must be implemented there too) and follow the manual instructions in the note.


Related Notes

1568362 – TMSADM password change
1414256 – Changing TMSADM password is too complex
1515926 – Update #1 to Security Note 1414256
1691028 – Fix for TMS_UPDATE_PWD_OF_TMSADM
1679157 – Improvement of log for TMS_UPDATE_PWD_OF_TMSADM
761637 – Logon restrictions prevent TMSADM logon
1835912 – TMSADM password change across domains with component CTSPLUG;
1730407 – Internal error in TMS communication 5.
1412609 – DUPREC when configuring the transport domain
1801805 – Addition of new destinations in TMS_UPDATE_PWD_OF_TMSADM;
1968772 – Changing TMSADM Password Changes Host Name in RFCDES;
1975845 – RFC_MODIFY_R3_DESTINATION unable to inactivate SNC for destination;

2090808 – Deactivation of TMS SNC

2222357 – SUSR_RFC_USER_INTERFACE: Dump when you lock/unlock.

2227412 – TMSADM default password is no longer used

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

  1. Balaji Guru

    Hello Vagner,

    Can you please let me know how to change the password for Netweaver 740.

    I understand we have to run the report TMS_UPDATE_PWD_OF_TMSADM, but in the destination field when I enter the RFC destination TMSADM@SID.DOMAIN_SID & TMSSUP@SID.DOMAIN_SID I get the pop-up Destination pattern must contain SID and domain, please help me know how to key in the Destination field.

    Thanks in advance

    (0) 
    1. Jason ORiordan

      Hi Balaji,

      You do not have to fill in anything for “Destination Pattern”. You can leave it as TMSSUP@<sid>.<domain> (which is default). That concerns the setup in note # 1801805 and trusted RFCs.

      Regards,
      Jason

      (0) 
      1. Balaji Guru

        Thanks Jaso for the response.

        So we do not have to follow the procedure set up in the note 1801805?

        We just can run the report TMS_UPDATE_PWD_OF_TMSADM with the default destination and password will be updated through the domain?
        Also should we use the same password for TMSADM throghout the landscape D, Q and P?

        (0) 
        1. Jason ORiordan

          Hi Balaji,

          Note # 1801805 is a nice feature if you have a very large landscape as it means you do not have to logon to each system in the domain when you run the report because trusted RFCs can be used. Setting up the trusted RFCs as per the note is a little difficult and only worth the effort if the landscape is very large. For a 3 system landscape it is not worth the effort. You run the report from the domain controller and the password you pick (if you pick your own) will be the same password for all systems in that domain. Alternatively you can choose the new standard password option which contains a mixture of uppercase, lowercase, digits and special characters that suit most customer’s password rules.

          Regards,
          Jason

          (0) 
          1. Balaji Guru

            Thank you very much for the clarification.

            It is indeed very helpful.

            However in my case I scrapped and recreated the TMS configuration.

            (0) 

Leave a Reply