No authorization to log on as a Trusted System (L-RC=2 T-RC=0).

[Former Member]

Hi All,

I am getting the error "No authorization to log on as a Trusted System (L-RC=2 T-RC=0)." and  I don't know exactly what needs to be given here as I already provided authorization to the user in both the system  for S_RFCACL with full access still I am getting the error.

Already checked note 128447-But still no help.

Please help me in this regard.

Regards

Pradeep

[Former Member]

Dear Pradeep,

You need authorizations:

S_RFC   

ACTVT     *

RFC_NAME  *

RFC_TYPE  *

S_RFCACL

ACTVT     *

RFC_CLIENT*

RFC_EQUSERY

RFC_INFO  *

RFC_SYSID <SID or SIDs>

RFC_TCODE *

RFC_USER  ' '

values are given as an example (as I use them)

With best regards,

Alexander

[Former Member]

Hi Alexander,

I gave the same access still the same issue.

Regards

Pradeep

[Former Member]

Dear Pradeep,

Do you have user with same id and authorizations in target system?

With best regards,

Alexander

PS. I found in Note 128447 - Trusted/trusting systems

  "No authorization to log on as a trusted system (L-RC=A T-RC=0)."

           This error text means that the following occurred during the two-step test:

• The check of the trusted logon was successful (Trusted RC=0).

• Logging the user on to the target system in a different client failed because the authorization S_RFCACL was missing for the user in the target system or because the user does not exist in the target client.

• Solution: Navigate to transaction SMT2 and choose an ABAP system by double-clicking. You can now maintain the generated RFC destination by choosing "Maintain destination". When you are within the generated RFC destination, choose the "Administration" tab page and deselect the "Destination not modifiable" checkbox. By entering the SAP client in the generated RFC destination, you can correct the problem with the error text and the display of the ABAP runtime error in the trusting system.

                    Alternatively, you can use transaction SMT2 to perform a one-off test between trusted and trusting ABAP systems in a joint SAP client (the Single Sign-On test in transaction SMT2 for all clients is not required).

• In addition, refer to Note 204039.
• The settings of the generated destination TRUSTING_SYSTEM@S00 in the trusted system may be incorrect if the SAP host name contains the character '_' (such as "my_host"). This problem is solved with Support Package SAPKB46D09 (see below). For earlier releases, you can manually implement the required changes for correcting the problem as specified below.

[Former Member]

hello,

in what moment this error apear?

[Former Member]

Hi Anton,

I am trying to confirm a Business Agreement in CRM 7 system which actually checks the data in ISU system in this moment it is giving this error.

Regards

Pradeep

[Former Member]

Did  you check RFC in SM59 in both system? Connection and authorization test.

[ACE-SAP]

Hi

What are your sap systems versions ?

Did you grant S_RFC_TT auth obj ?

Best regards

1680501 - SMT1 SMT2 : No authorization for object S_ADMI_FCD

S_RFC_TT is a new authorization object introduced in SAP_BASIS 702 (and higher releases).
If at least one of the systems is running SAP_BASIS 702 (or higher), then there are two authorization objects involved - S_ADMI_FCD and S_RFC_TT.

1734607 - SM: Authorization object S_RFC_TT 7.02 and higher

With 7.02 a new authorization object has been introduced which is "s_rfc_tt". Have this object in your roles in both systems and assign it to all users who need to use these trusted rfcs.

[Former Member]

Hi Pradeep,

I was fighting with the same problem (error message) at a customer some time ago and we finally re-established the trusted connection via SMT1, because even with full authorizations for S_RFCACL it did not work. It seemed like the trusted relationship was broke, but we were not able to find out the root cause for it. Due to the fact that this happened in a QAS system, it might had something to do with system refresh actions after copying PRD to QAS systems - but I am not sure if that is really a reasonable explanation.

For using trusted RFC connections a normal enduser only needs authorizations for object S_RFCACL as well as authorizations for accessing the called function module via object S_RFC. Objects S_RFC_ADM and S_RFC_TT are not needed by endusers, these objects control whether you are authorized to manage RFC destinations and trusted connections.

Best regards,

Stefan

[Former Member]

No authorization to log on as a Trusted System (L-RC=2 T-RC=0).

T-RC equals TECHNICAL Remote Connection - this is created by SMT1 from the Target System.

L-RC equals LOGIN Remote Connection - this is maintained in the Calling System with SMT2.

An ABAP Dump will be generated in the Target System with various values for L-RC= ###. If T-RC is not equal to zero then the base RFC from the Target System must be fixed with SM59 first. However, if you have completed the Standard Security settings for the USER-ID Testing SMT2 and you still have issues (and you have applied all the solutions provided in the ABAP Dump) then;

You may need to maintain the Message Server FQHN Name in SMT2. The reason is, sometimes the servers are in different domains (for example, a Production SAP System that wants to make calls to a Development SAP System).

Going cross domains like this requires the Administrator to manually Maintain and SAVE a working Message Server FQHN Name (replacing the generated SMT1 parameters created from the Target System). Depending on your version of SAP, you may need to apply a SAP Note so you can actually change/maintain and SAVE the correct FQHN without getting the error pop-up when you try to exit SMT2.

Just a few heads up - if you have any issues with a Trusted Connection: it is broken and can usually be fixed in a few minutes with this method from the Target System. First, delete the Trusted Connection with SMT1. Second, Fix the base RFC with SM59 (if required). Then re-create the Trusted Connection with SMT1. Finally, maintain the Trusted Connection with SMT2. You basically always have to maintain the RFC connection in the Calling System with SMT2 because; SMT1 does not use the same parameters you set in the base RFC Connection from the Target SAP System.

The entries in SMT2 can be changed for a specific Server Client (leave language blank) and set Uni-code without changing the Message Server FQHN. It may be possible (in your SAP environment) to ask the Basis Team to possibly maintain an extra entry in the service/etc configuration file if you cannot install the SAP Note.

T-RC=0, in your case Pradeep,  means the TECHNICAL Connection or Trust is OK. You have a LOGIN issue described in the ABAP Dump - look with ST22 for L-RC=2 instructions. Also, you should see identical Authorization Errors in SMT1 & SMT2 ideally. Best to Maintain the correct settings in SMT2, Successfully test authorizations and SAVE. Exit and re-check the green Status from the main page of SMT2.

Trusted connections are a critical SAP concept - maybe simple - but, it has a lot of gotchas. Basically, these were all correct answers in this post.

[Former Member]

Super! Thanks for the insights!

I have tried to build roles for this, but what works quickly because of the call backs it to request SAP_ALL + S_RFCACL to run the setup and then remove the access again..

Mostly it is SOLMAN, so for the "back" call you must ensure that the "back" user also temporarily has this access if it is hardwired (which is correct).

If you get it wrong on both sides, then you have fixed users on both sides with SAP_ALL and S_RFCACL.

Conclusion: basis admins on the SOLMAN side need to temporarily give the "call backs" more access (auths) when attaching more systems so that those connections are not forced to be trusted back to the SOLMAN.

Outbound trust from SOLMAN is not avoidable. The other way around is a lesser idea.

Cheers,

Julius

[Former Member]

Hi All,

Thanks for your help.As per your suggestions I did assigned all the necessary authorizations required for the trusted RFC to work but it was not working,then I copied the same access to the other user it worked.So it seems some issue with that user still trying to figure out what was unusal about that userid.

Only S_RFC & S_RFCACL object is required for trusted RFC to work properly.

S_RFC_ADM &S_RFC_TT are not required ,those are mainly for administration of Trusted RFC's.

As of now issue is reoslved.

Regards

Pradeep