cancel
Showing results for 
Search instead for 
Did you mean: 

No authorization to logon as trusted system

Former Member
0 Kudos

Hi All,

i'm really getting confused and started scratching my head, but i won't allow SAP to be the reason for loosing my hair hence decided to stop scratching and post this message.

i have a strange behaviour here, we have two solution managers one productive SM1 another is for testing SM2

both SM1, SM2 are connected to the sandbox SB, i can logon to SB from SM1, and was also able to do the same from SM2, but now i get the above error message when i try to logon from SM2 though the RFC connection setup is exactly the same in both cases SM1, SM2

i have tried logon with current user or without current user but no use.

the strange is that weeks back and for long time back SM1 connection logon to SB was functiong.

can someone take me out of this ?

Reg. Daher Abdeen.

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

Hi,

Trusted Authorization error iPossible reasons

1. Authorization objects - S_RFCACL. which has to be maintained in both systems SB, SM1 and SM2 Check is there any changes made in your role in any of the systems.

Maintain the values in that object properly,

2. In tcode SMT1 maintain the trusting and Trusted Releationship

regards

Naveen

Former Member
0 Kudos

Thanks Naveen for your quick respose

when you say maintain authorization object S_RFCACL i'm aware about this, and i'm using so in some placed. This can be used when in the RFC connection "Trusted System" = NO or "Current User" is ticked here system will use a user logon which should have S_RFCACL

but when "Trusted System" = Yes and "Current User" left UnTicked then there is no user id used for logon. Why in this case it still does not allow the logon.

i've created an RFC through SMT1 for problem causing SM2 but still the same problem exists.

Logon with Current User Option

i'm able to do logon with current user if the logon is not trusted,,, but with trusted selection it does not allow.

maybe something i'm not understanding when you say

"trusting and Trusted Releationship" what do you mean ?

Former Member
0 Kudos

I also have pulled out a lot of hair over trusting relationships - particularily if you do any system copies as the RFC's stop working. We also found that Support Stacks seemed to mess up the trusting relationship, but when we just put in EHP1 SP03 we had no problems.

One quick thing to looks at is the TRUSTING_SYSTEM@<SID> RFC (or any trusting RFC). After creation, it always seems to change to Load Balancing =YES with Group = SPACE even if you select No Load Balancing in SMSY RFC setup. By maintaining the destination in SMT2 (check both Solman and satelite). Once saved, it doesn't change back.

However, this is one of the few "easy" problem resolutions. What I have found that trying to troubleshoot the problem is so much harder than just starting over. Go in and delete the RFCs, Trusting (SMT1) and Trusted (SMT2) in both SolMan AND the satelite system. Particularly after system copies as the host name is in the trusting systems and can't be changed once created.

If roles are correct, it should be created easily.

Former Member
0 Kudos

but when "Trusted System" = Yes and "Current User" left UnTicked then there is no user id used for logon. Why in this case it still does not allow the logon.

For all Trusted RFCs, Trusted System should be Yes.

When the Current user checkbox is checked, the user who executes Remote logon/Authorization test will be taken as the RFC user. In this case this user should have the authorization S_RFCACL.

If Currect user is disabled, then you should have maintained a user with S_RFCACL and his respective password for that RFC under Logon and Security tab.

Note : I believe you have the same user name and trusted authorizations in the both systems.

trusting and Trusted Releationship what do you mean ?

Lets say you are connecting from SM1 to SM2 using the trusted RFC created from SM1,

in that case SM1 is your trusting system and SM2 is your trusted system.

Former Member
0 Kudos

Hi Naveen,

it looks that i'm disturbing you alot.

all what you say above is fine. Let me put the final conclusion as folows :

RFCA in SM1, trusted = yes, current user = ticked, IP address is pointing to sandbox

RFCB in SM2, trusted = yes, current user = ticked, IP address is pointing to sandbox

hence the RFC setup in SM1, SM2 are exactly the same.

now the current user is myid hence myid U9426 is defined in SM1, SM2, sandbox.

still i'm able to logon to sandbox via RFCA where not able to do so via RFCB.

secondly in RFCB system was able to logon as trusted weeks back, we even generated EWA from sandbox to this solman box and transmitted to SAP as well.

no body other than myself has access to SM2.

this simple problem has started really frustrating me i wish it can be solved by a hammer on the screen when the message not authorized to logon as trusted uers is displayed.

Reg. Daher

Former Member
0 Kudos

It looks strange,,

i hope the authorization for your userid in SM2 is extactly same as in SM1.

Once check the values also for that authorization object.

Former Member
0 Kudos

Hi,

gone through all the comments.

1. Check if one user has S_RFCACL auth.

2. go to SMT1 and create an RFC to the satellite and log on once using this user.

3. Forget the user part and the RFC created in AMT1, create trusted RFC seperately or in SMSY to the satellite.

4. Repeat the smae steps for ur satellite system.

It has to work.

Regards,

Kaustubh.

Former Member
0 Kudos

Hi Naveen / kaustubh

Finaly this got solved, i think there was a misunderstanding from my side. I have to setup the trusted system using SMT1 in both the source and destination system. i missed to do so in the destination.

once again thanks for your patient with me.

Solution Summary

(1) using SM59 in solman create an RFC connection of trusted type pointing to destination "sattalite"

(2) using SMT1 in solman, create a trustig system and assinge this RFC to it.

do (1) (2) also in sattalite system

for such trusted systems you need not to logon with current user, since it is trusted and hence need not to bother yourself with the authorization objects needed or having the logon user id defined in the sattalite system.

Former Member
0 Kudos

i missed the name of Christine Kattas who has attended my message at early stage.

Thanks Christine too.

Reg. Daher