User |TMSADM has no RFC authorization for function group SYST

[Former Member]

Hi All,

When we release any transports we are getting the above error, this is basically due to the fact that implificaiton of complex password parameters, to supress this we had followed the note 761637.

I had regenerated RFCs and reset TMS user, but still no use any ideas?

This is definely not the issue with Authorization as user TMSADM has right profiles.

Reg,

VV

[Former Member]

It might be the reset for some reason did not reset all the relevant user tables in all the systems.

Try logon to the domain controller client 000 (this should be your production system), call transaction SU01 and display TMSADM, enter 'RSET' or 'RBUF' (cannot remember off-hand) into the transaction command window and hit enter. A green "reset" message should appear.

Try the same in the source of the transport (if required).

Alternately run report RSUSR405.

Does the release work after that?

Cheers,

Julius

[Former Member]

hi,

we have 21 servers.i have seen the attributes of user "TMSADM" in all the systems.

for us transports are working fine.

here i am giving the attributes of user "TMSADM".

make the changes accodinglly in su01 and try transports

profile for TMSADM is "S_A.TMSADM"

no user group for this user

no user group for ahthorization check

it is a communicational user

make these changes and try .still if problem please let me know

regards,

narayana

[Former Member]

When you reset the user TMSADM from the domain controller, it will reset (amongst other things) the user type to "SYSTEM".

This means that the user ID is not subject to password change rules (amongst other things).

It also sets somewhat limited access (role S_A.TMSADM) for the user to perform administrative SYSTEM tasks for the TMS (such as, for example, running programs to check the authority, authenticity and location of the actual user, and run the commands required to add or import the files).

Bar these admin tasks, the STMS checks the authority (and prompts for the authenticity) of the calling user (the user who is actually logged on). So SYST (or a more refined FUNC) might even be a missing authorization for the actual user (the one sitting in the chair), and the authority check is failing before the authentication prompt appears?

Cheers,

Julius

[Former Member]

Hi Julius and Narayuan,

Many thanks for your reply, when I reset my TMSADM user though it says it was reset, but SU01 for TMSAMD user is intact , it did not change the user type to SYSTEM, it kept as it was before Communication data.

I did not get the user to test the release , but I am checking in the RFC connection for this RFS desitnatation and it failes with same error.

SM59=> Particular RFC connection data==> Utilites => test=> Authorization test =>

COnnection test is okay , but authorization test fails and the user is also getting the same error.

TMSADM has profile "S_A.TMSADM"

Reg,

VV

[Former Member]

>

> ... when I reset my TMSADM user though it says it was reset, but SU01 for TMSAMD user is intact , it did not change the user type to SYSTEM, it kept as it was before Communication data.

Then the reset is not working (which would be consistent with the note). You can administrate the connections (SM59) and user (SU01) manually now. Try to change the user type in SU01.

>

> I did not get the user to test the release , but I am checking in the RFC connection for this RFS desitnatation and it failes with same error.

You stated before that releasing the transport was failing, not the authorization test in SM59.

Note that default system settings for the "Connection Test" only verifies that there are no network gremlins between the servers and the RFC settings, it does not verify that the logon was successfull. The "Authorization Test" on the other hand verifies the authentication was successfull and the authorization to perform the RFC call was checked and successfull.

Most likely, the problem is caused either by the user type AND / OR the password is in fact not correct (or is arriving incorrectly - See SAP Note 1023437).

Some other suggestions:

- Check ST22 to see whether more details are available on the error (check source and target destination).

- Check whether the user doing the release is missing an authorization to use the TMS.

- Check the value of your system profile parameters auth/rfc_authority_check and rfc/reject_expired_password?

Cheers,

Julius

[Former Member]

I had the same problem, User TMSADM has no RFC auths for function group SYST. and although my dialog user has RFC auths, it still failed. Tried the afroementioned troubleshooting but no success.

Checked the short dumps which showed the TMSADM user is missing the AUTHORITY_CHECK_RFC, and I don't know why.

I added the RFC role to the user TMSADM, and now the RFC authority check works fine.

Regards,

altin

[Former Member]

> Checked the short dumps which showed the TMSADM user is missing the AUTHORITY_CHECK_RFC,

Not necessarily critical.

But...

> and I don't know why.

combined with...

> I added the RFC role to the user TMSADM, and now the RFC authority check works fine.

... might be.

What is the user type of your TMSADM?

What is in this "the RFC role"?

Cheers,

Julius

[former_member582060]

Hi,

Well I also got the same problem when I reconfigured the TMS.

The TMSADM was assigned the profile<font color=blue> S_A.TMSADM </font>by default.

Then I found out that apart from this profile, the TMSADM needs authorization S_CTS_CONFIG contained in the profile <font color=blue> S_A.SYSTEM </font>

When I assigned this profile, the authorization check is working fine.

check this thing out and let me know.

Regards,

Ashutosh

[Former Member]

That is not a good solution and would be very security critical. You should check SAP Notes for the user TMSADM.

Most likely it is faulty config and possibly you had entered the user into the TMSSUP destinations of the transport domain? The "authorization test" in SM59's menu is understood as an "authentication test" by many, but to test the correctness of the password, it needs to invoke an authority-check so that the user can be determined. This happens to be in function group SYST, but the user does not have to have it.

In TMSADM's case it must run on the absolute minimum authorizations which are not critical on their own. It does not need SYST.

I would make sure the domain controller is on PROD and redistribute the config and reset the user from client 000. That should normally fix and cure config which has been fiddled with. Then use the destinations from STMS and not SM59.

Cheers,

Julius

Edited by: Julius Bussche on Mar 15, 2010 1:24 AM

[Former Member]

>

> I would make sure the domain controller is on PROD and redistribute the config and reset the user from client 000.

I disagree. Yes, PRD systems mostly use some kind of HA and therefore it is quite save to have your domain controller there - but all those who have to do without a HA, think twice - use your SolMan instead!

[Former Member]

It's not only about the High Availability, but also the security aspects of the controller of the transport domain configuration and not everyone uses ChaRm.

Production systems have a higher security level than development system and (contrary to popular basis folklore) you are not "alone" in client 000...

This is particularly true of SolMans and all their "call back" connections... which should be classed and treated as production systems.

I normally use the authorization object S_ICF to class the connections in SolMan into their own security classifications. It makes sense.

Cheers,

Julius

[Former Member]

This message was moderated.

[Former Member]

<nonsense_removed_by_moderator>

Edited by: Julius Bussche on Jun 24, 2011 1:43 PM

Why was my comment nonsense? Please explain instead of deleting by random.

Thanks

Edited by: saplaz on Jun 24, 2011 1:48 PM

[Former Member]

Did you read the other answers?

Do you understand the implications of assigning SAP_ALL equivalent authorizations to this user?

I think not... hence nonsense. Sorry.

Cheers,

Julius

[Former Member]

Otherwise I wouldn´t have comment one particular answer of this thread. I hope this makes sense to you. I think you should consider this before you delete answers by random. Otherwise you have to delete 70% of answers in the whole SDN forum. Thanks and please don´t be so arrogant. Moderator role doesn´t make you better or god. Cheers.

[Former Member]

You dig up an old thread to post very dangerous answer, without reading the existing answers.

Of course it will be deleted...

Cheers,

Julius

[Former Member]

Hello,

We are experiencing the same issue of getting error when setup STMS: "TMS has no RFC authorization for function group SYST"

We have tried delete and rescreate TMS. Upgrade kernel. But non seems working at this point.

Can you let us know how you get this problem resolved.

thank you

Jingying

[Former Member]

Is it possible that someone is expecting to hit the "remote logon" button in SM59?

This should not work for SYSTEM type user's anyway, so the authorization is not needed and will write a ST22 dump in the target to tell you that someone is "clicking around".

Check whether your TMSSUP* destinations are generated properly? These use the remote login to verify the dialog caller is authorized.

Cheers,

Julius

[Bernhard_SAP]

maybe we can close this thread after everybody who received 'TMSADM has no RFC authorization for function group SYST' would stop testing the connection out of SM59, but from STMS->System overview.

The message only appears, if you test from SM59. I suppose this is a 'functionality' or bug in SM59.

b.rgs, Bernhard

[sdipanjan]

You already have got many suggestions on your issue. I would like to add one more... playing with Login profile parameters is good but it should not be set in such a fashion that the security for login bacome a pain point. So, make it normal and workable.

Now you may need to check the following SAP Notes:

456677 User TMSADM has no RFC authorization for function

1414256 Changing TMSADM password is too complex

1061649 Upgrade to SAP NetWeaver Process Integration 7.1

412496 OPEN_DATASET_NO_AUTHORITY, object S_PATH

Please check the version dependency of the above mentioned Notes.

Regards,

Dipanjan

[krysta_osborn]

Weird that this is close to the top of the list for today. Our Basis Admin is working through a similar issue (not sure what it is exactly) and SAP told her to add the missing auth to profile S_A.TMSADM and then try again.

[Former Member]

This is an old and interesting thread with was "bounced" by the above plaintif with a very speculative and bad advice answer. I removed them to avoid further urban legends about non-dialog users being OK with SAP_ALL type access -> nonsense.

In you case you are possibly using the optional "path hook" feature of object S_PATH. This uses a grouping concept and SAP cannot know nor define the groups for your transport directories.

Therefore there is a feature to adjust the standard profile of user TMSADM - but it should only ever have this restricted profile.

Other useful and relatively easy controls for it are:

- User type SYSTEM.

- Domain controller and TP mounts on prod system.

- QA steps and backup controller on QA system.

- Manage the passwords via SNC protection (there is a new report for this now, if you read the notes).

If you give TMSADM more access (as suggested above), then you do not need to spend any firther money on security because it will not matter anymore...

Cheers,

Julius

[Michael_Chohrac]

We are having issues with our transport system and a Basis consultant is requesting I give S_CTS_TR_ALL and S_CTS_ADMIN authorizations to the TMSADM user in all systems / clients. However, based on everything I've read previously in this thread as well as others, I am against doing so. I would think these should only be given to the user who is actually trying to setup the TMS, and not to the TMSADM user - correct? Currently, TMSADM user only has the S_A.TMSADM profile assigned to it. Appreciate any comments.

[Former Member]

There is a special case for object S_PATH to be added to the default profile of TMSADM, but this is optional and not default.

I am not aware of any S_CTS_ADMI or other additional profiles needed. Sounds like guess-work to me. Basis solution is sometimes a case of selective memory --> give things SAP_ALL just to see whether it works in principle, and if it does then do not change anything afterwards...

Cheers,

Julius

[Former Member]

Hi

Solution is very simple, add the profile SAP_ALL to user TMSADM and it works,

just to see whether it works in principle,

and if it does then do not change anything afterwards... 

[Former Member]

Is this a joke?

[shindead1]

This message was moderated.