User XYZ has no authorization for tp command IMPORT

[gshrivastava]

Dear friends,

We have several users who are facing the issue while importing TR in QA system from DEV system. We have checked with the users by assigning them SAP_ALL and even then they are facing same issue. Could you please help us in this ? I have attached screenshot of the error. We are using Solman for transports.

Thanks

Gaurav

[martin_voros]

Do they have sufficient authorization in target system?

Cheers

[gshrivastava]

Hi Martin,

Yes we have checked the object S_CTS_ADMIN with user and they have all required access in target system. We have even checked by assigning SAP_ALL to them. Still no luck.

Thanks

Gaurav

[martin_voros]

It should be OK. Have you tried to trace it for failed authorization checks? If you have basic debugging skills the check should happen in FM TR_AUTHORITY_CHECK_ADMIN.

Cheers

[Former Member]

Hi Gaurav,

Please request security or basis mates to switch on the Trace by using ST01 t-code and execute the same functionality once trace is on.

And then request them to stop the trace and go for analysis, it will surely show up what exact authroization is missing for that user.

Hope this would help you out in resolve your issue.

Thanks,

Kumar

[gshrivastava]

Hi Kumar and Martin,

Irony is trace does not shows any missing authorization for user. We received RC=0 for all auth checks.

Martin,

I checked the FM and user has all required access.

I am thinking that there might be something which went wrong for users in business partner id or there might be something which has been made unmodifiable by basis. Or there may be some settings changed for these users in some table for them. We have tried almost everything from auth perspective but still no luck.

Regards

Gaurav

[Former Member]

IMPORT is a function within the external program TP. This is controlled via the Access Control List for external programs and not ABAP authorization objects.

SMGW -> Go to -> expert functions -> external security -> Display secinfo -> you will need to get someone from infrastructure security or basis to add you to the ACL file, or perhaps you are not allowed to import transport requests from anywhere and must find the correct person who can (you will also see their names in the file).

Cheers,

Julius

[gshrivastava]

Hi Julius,

Thanks for your response. However i can see that all values in sec info are maintained as star (*). . Users are not having issue with other system but only one system/landscape.

P TP=* USER=* USER-HOST=* HOST=*

Thanks

Gaurav

[martin_voros]

You can try to debug that program and see why it's raising that message. It's not the easiest way but it looks like you are running out of options.

Cheers

[Former Member]

I suggest extra troubleshooting:

- does this happen for all users, or only one?  Who are the users for which it works?  what is different about them?

- note that SAP_ALL is famous for not including "all" authorizations, especially some RFC related auths such as S_RFCACL (unless you specifically switch that on) and these RFC failures rarely appear in traces (but they do appear in SM21 sometimes).  also, unless you are consistent with regenerating SAP_ALL after installing support packs it will get out of date and not contain everything.

- have you checked TMS logs on operating system as advised by the error message?  Those logs usually have extra details.  you can probably read them yourself with AL11.

- have the generated RFC destinations used by TMS been altered?  You first need to identify the RFCs within STMS then go into SM59 and look at them.  They should not be using "current user" authentication, because tp should be run by the sidadm or sapservice users on the OS.  Maybe basis has altered those RFC.

let us know what you find.

UPDATE:

thinking about this further.

I bet you are hitting S_RFCACL errors.   Give the user SAP_ALL plus a dummy role having S_RFCACL and try.   Activate a trace.  If I'm right, you will see the S_RFCACL proper value needed in a role.   compare that to a user for whom it works.  Bet it's something like that.    Might as well add several S_RFC* authorizations to the dummy role too.

Message was edited by: Kesayamol Siriporn

[Former Member]

Hello Gaurav,

Is the issue solved at your end??

I am facing the similar issue.

Could you please update in the thread.

Regards

Arya

[gshrivastava]

Arya,

Please assign profile S_A.SYSTEM to user in test system. I did this and issue was resolved.

[Colleen]

don't assign S_A:SYSTEM. Find the actual missing value and add it to the role

[Former Member]

Neither the profile assignment works nor anything is coming up in the trace.

Please let me know if some solution is realized.

Regards

Arya

[Bernhard_SAP]

...as Martin suggested already earlier: use the debugger...

I had a similar case today, where a dedicated user had to be locked out from the possibility to modify coding in SE38, and that was done like this:

*   §§§ Begin of Safety Measure in   <system SID> 

          if sy-uname = '<user-ID>'.      

          if MODUS            ne 'SHOW' and        ( P_TRDIR_INF-APPL =  'S' or "System          P_OBJECT(4) = 'Z_ZX' ).

*       l_ber_obj = 'S_DEVELOP'.

*       MESSAGE s519(eu) RAISING no_modify_permission WITH l_ber_obj.

*       EXIT.       

          l_subrc = 4.

-->and later on l_subrc was evaluated to present a 'no authorizaiton' message, although SAP_ALL, etc.had been assigned to the user...

That explained, why no result was found in st01,su53, as in fact no auth-check failed, but the faiilure was programmatically simulated...

b.rgds, Bernhard

[Former Member]

Hello All,

The solution lies with the authorization object S_CTS_ADMI with value IMPS in the field CTS_ADMFCT.

Please have this authorization assigned in the QA system.

BR
Arya

@Gaurav:- If you find the solution feasible then please close the thread.

[Former Member]

Either direct Tp calls and gw/no_reg_con_info is set too high without a physical default file, or hard coding as suggested by Bernhard.

Or your transport routes / groups are too complicated and which system the message is coming from is not included in the message.

I place my bets of transport groups as that seems to be the latest fashion to centralize support of developments, authorizations and TMS passwords (and Z-object names) which then collide and produce messages in application pings even (SM59 -> Test -> Authorization Test)

Cheers,

Julius

[Giridharan]

There should be System user used for connecting each Child system from SOLMAN.

Assign the profile S_A.SYSTEM to that user in quality system, to which you need to Transport (error occurred system) as this profile contains S_CTS_ADMIN object which is required.

[former_member201158]

In our case, user who is performing tp import validity date is the problem. After we extended. It got resolved.