Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
vagnerandrade
Employee
Employee


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:



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:



You will find further information in Activating TMS Trusted Services.


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



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:



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:

 



 

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.



 


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

5 Comments