How to enable STMS for SNC authentication

[tim_alsop]

Hi

When our customers use our SNC library for SNC authentication to ABAP AS, their SAP user password is typically not known or deactivated (due to login/password_change_for_SSO = 3).

When Basis Admin's use STMS transaction to move transports from one system to another they are prompted to enter user id and password. They cannot do this since their SAP password is deactivated.

We want to authenticate the user when they use STMS via SNC. Is this possible?

I tried to find some documentation on how to SNC enable the STMS authentication of users, but I cannot find anything on this.

How do companies authenticate users when using STMS and having SNC enabled for user logon ?

Thanks,

Tim

[Former Member]

Hi,

there is nothing like SNC for STMS. STMS is just a T-code used define transport  routes, transport system, imports.....

Once you are login to sap system using SNC...it is all authorizations which takes over security stuff..

If user has credentials for T-code...he should go thru..

Thanks,

Chitra

[tim_alsop]

I think you misunderstand my question, so perhaps I didn't explain well enough.

When using STMS and there are multiple systems listed, if I click on one of them which is not the one I am logged onto, I am prompted for SAP password. I need the authentication when user clicks on a remote system to be performed using SNC credentials, not using SAP user and password.

In sm59 I see there are various TMS related RFC destinations, so I thought we can setup SNC authentication in the RFC destination, but when I asked one of our customers to try this they said it didn't work.

[Former Member]

You cannot and should not maintain these generated RFC destinations in SM59. You must go to the domain controller, change the STMS config there and distribute it.

Cheers,

Julius

[tim_alsop]

understood, thanks.

[Former Member]

You must logon to client 000 of the domain controller. Go to the systems overview and select the domain controller. at the bottom of the Communications tab you can activate SNC. Then go back to the overview and via Extras -> Regenerate RFC destinations. The generated TMSADM* and TMSSUP* will then support SNC and the RFC login screen will suppress the password option.

Note that in the case of the TMSADM* destinations, there is a fixed user in the destination and it is only the system itself which is authenticating. In this case SNC is encrypting the communication but not authenticating the client user -> so the "password".. is still needed in the connection.

Cheers,

Julius

[tim_alsop]

This is just what we wanted. Thanks.

I will test this and update the result in this thread so anybody else will know your suggestion works. I am sure it will though 🙂

Thanks again,

Tim

[tim_alsop]

Julius,

We did what you said, but got an error because the SNCSYSACL table didn't contain an entry to trust the SNC connection. In this table there is a column for "RFC active" and one for "CPIC active". Do you know which we need to make active/allow for the connection ?

Thanks,

Tim

[Former Member]

I dont remember having to do that, but if anything then it is type RFC, so I would click on that or activate everything... 😉

Probably these the first connections ever to use SNC between the systems for RFC?

Cheers,

Julius

[tim_alsop]

yes, this is first connection between ABAP systems using SNC. From my experience, most companies that use SNC, use it for user logon and rarely find a need to protect server to server communications, especially when the systems are in the same datacenter.

I'll let you know what happens when we enable RFC and CPIC. I think it will work.

[Former Member]

In after-thought, the RFC login with current user is going to attach the SAPGui to present the login screen. So I suggest flagging RFC (for the TMSADM* destinations) and Dialog (for the TMSSUP* destinations) as well.

I checked in one system and they were all flagged for the system level control ACL. Dont see any harm in that.

Distributing the config from the domain controller will add the attribute to the destination itself then to use the STMS with SNC. Other destinations without "wizards" will need to be changed manually, if required.

Cheers,

Julius

[tim_alsop]

Julius

We have used SNC0 to add entries to VSNCSYSACL table, so that the DEV and QAS systems can communicate with each other using SNC. When we start a transport request, instead of getting a Sign-On screen, SAP GUI crashes and the user is logged off. We checked the logs written by the SNC library and found that SNC authentication between the systems is working perfectly, so it looks like DEV is authenticating to QAS, but after the authentication is complete, something is happening which is causing the SAP GUI crash. We see various RFC errors in the dev_w<n> logs but they are not very meaningful.

We are trying to understand what is supposed to happen when this works. Is SAP GUI going to logon to the target system (QAS) using the credentials of the user at the workstation when the transport request is started ? If so, do you know what might be causing SAP GUI to crash and how we can troubleshoot this ? Is it possible that it is due to authorisations ?

Thanks,

TIm

[Former Member]

Check in the target system for any St22 dumps and trace the caling dialog user in the target system with ST01 for failed auths.

If SAPGui is crashing, then also check for any AC_FLUSH dumps.

<speculation>Is the user a SERVICE type user instead of a DIALOG type user</speculation> (they might have used this to keep their passwords alive...). SERVICE type users have functional limitations for using "Professional" type transactions which are license relevant, as SERVICE users are not subjevct to license measurement.

The plot thickens...  😉

Cheers,

Julius

[Former Member]

Hi Tim,

Table SNCSYSACL must be maintained on the acceptor systems by means of transaction SNC0 whenever SNC is involved in RFC communications. Please refer to this page on SAP online help for your reference:

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/28/03f4ad8d9d490c99a3e8a57551d264/content.htm

Other than this, I would like to rise up another alternative I think nobody mentioned before in the thread. Basically it is based on SAP note 761637 which describes a procedure to make RFC destinations generated by STMS modifiable. The implementation of this note allows you to maintain a password for user TMSADM in client 000 and enter such into the RFC destinations. In this way you will avoid to be prompted for a password every now and then while working with STMS. This for sure should work in the environment you are describing since I saw same settings in one of our customers who are using also SNC for logging in onto their SAP systems. The drawback of this alternative is that you need to maintain TMSADMxxx RFC destination on each of the systems included into the transport landscape.

I hope you find this alternative helpful as well.

Cheers,

José M. Prieto

[tim_alsop]

Jose,

Thank you for the SAP help page - this is useful background info.

We will try the alternative if we are not able to get the other approach to work.

Thanks,

TIm

[Former Member]

ps: The ability to edit the generated RFC destination might seem tempting. For example you can also do that from SE37 because STMS does exactly that as well.

You could add the trusted flag option and current user and then establish trust between  the DEV and WAS and PROD systems.

Down side is that they must be subject to the same user administration and auditablility (you must ensure that the user name remains the same and enforce it via S:RFCACL authorizations)  and changing the local setting can be wipped out by future STMS config changes from the domain contoller which are re-distributed again.

It does work with PKI certificates and the SAP SSO (at first it did not and logon screens appeared again because the SNC did not work - that was fixed about 12 months ago, so you should also checj the release and SP level of the system!),

Cheers,

Julius

[Former Member]

Hello Tim,

we have the same symptom of GUI CRASH once we try to transport from DEV to QAS.

Woudl you mind to tell us how did you solve your problem?

Did you change the password of TMSADM on client 000?

Please let us know.

[tim_alsop]

We haven't managed to find a solution yet.

It is good to know we are not only ones having the issue.

When you find a solution, please let me know and I will do same.

[Former Member]

The password of TMSADM is unrelated to this as it always needs a password for the domain - the question is just which one.

At most if the TMSADM cannot even connect for the "uncritical" functions via the TMSADM* destinations as this has a fixed user in it, then it will not even reach the TMSSUP* destinations which is where Tim's problem is for the "critical" functions.

I suspect that these are two different problems for which the symptom appears to be the same -> it does not work.

Cheers,

Julius

[Former Member]

hello Tim and Juilius,

the crash of SAP GUI once the SNC has been enabled can be only be overcame giving SAP_ALL to TMSADM on client 000 of the destination systems.

This way it works however it has the very bad side-effect that all the transport will be transported with the users TMSADM so we decided to dismiss this scenario, disable SNC for STMS and rebuild the RFC in every single system involved.

[Former Member]

Yes, giving TMSADM SAP_ALL is just about the worst thing available to do.

Cheers,

Julius

[tim_alsop]

If SNC has to be turned off in STMS, does that mean that the users who are using STMS to transport between systems needs to enter an SAP user and password ? If so, this is bad, since it means these users will have multiple passwords to remember, one for the SNC SAP GUI logon (e.g. their AD credentials) and one for when they use STMS. It would be better if SNC could be used so that the user doesn't have to remember their SAP password. Then, the users SAP password can be disabled.

Do you think that SNC should be supported with STMS without using SAP_ALL on TMSADM user ? If so, is it worth opening an OSS message with SAP to get this fixed ? I would be happy to do that if you agree that this is a bug.

Thanks,

Tim

[martin_voros]

Hi Tim,

a user that is logged to a system that is receiving transport does not have to authenticate again. Hence a "workaround" is to logon on to receiving system directly and then import transport from there. Or am I missing something? I know that it's not ideal but if they use SNC for SSO then logging into another system will be pretty quick.

As a customer I would not be afraid to open an OSS message.

Cheers

[tim_alsop]

Martin,

I like your workaround. We will try this. It is certainly a better workaround than using SAP password instead of SNC...

Only concern with opening OSS is that this is a very slow process since the person who gets assigned the message is often not the right person and it usually takes many weeks/months to get the message escalated to somebody who understands what we want. This is my personal experience anyway 🙂

Nevertheless, we will open a message and see what happens.

Thanks,

Tim

[martin_voros]

Tim,

we are sharing same experience :-). At least with workaround you can wait. In the worst case they will point you to this thread.

Cheers

[Former Member]

Actually I don't have this problem. Perhaps it is only the SAP SSO 2.0 which works with the RFC calls of the TMSSUP* destinations, but I don't believe that. I am pretty sure there is something wrong in the SNC setup and TMS config distribution if SNC is not working.

SAP support also works for me. Delays are not enough to complain about if dealt with tactfully. Mostly things are very fast but at time a co-ordination for features to make them more easily implementable are needed. Sometimes you even need to wait for a major release change if there are compatibility concerns and both kernel and application coding corrections are needed.

Cheers,

Julius

[jason_craun]

Hello,

I see this wasn't ever answered, here is my 2 cents.

For our systems, so that users are not prompted to logon when connecting to other systems via STMS, we just use a trusted connection in STMS. Here are the steps in case this is needed.

• Logon to the STMS domain controller, client 000.

• Cal STMS > Systems > Go To > Transport Domain

• On the Management tab you can set the Security options:

          Trusted Services - Active.

This setup assumes\requires that you have trusted connections(tcode:SMT1) between the other STMS systems, and that any users that will be using STMS in these remote systems have the needed authorization(please see auth objects: S_RFC and S_RFCACL).

I hope this is helpful.

Best regards,

Jason