cancel
Showing results for 
Search instead for 
Did you mean: 

login to multiple SAP systems using pwd of single SAP system

former_member188019
Active Participant
0 Kudos

Hi All,

We have 3 different SAP servers, with sids: ECD, BWD, HRD.

for each user, a user with the same username is created in all three systems.

the user does not want to maintain 3 different passwords, instead only single password to be used in all systems. i.e. when he changes the password in system ECD, the changed password should work in other systems BWD and HRD as well.

if we were using SAP EP, we checked the possiblity of username based SSO and having portal login using only on system ECD.

but we are not using the portal, and all the users will access 3 sap systems using SAPGUI.

is there any way, where one system's password will work to login to other systems.

thanks in advance,

Madhu_1980

Accepted Solutions (0)

Answers (4)

Answers (4)

Former Member
0 Kudos

Thanks Tim, yes indeed the token will be riding on the unprotected DIAG protocol.

As for selecting the client via the Portal method, you normally pass the client parameter as part of the transaction iview. So technically you can select which system and which client.

As for the other comments I have, Id be interested to continue the discussion. I'll drop you a message!

tim_alsop
Active Contributor
0 Kudos

Regarding portal option. See below:

If I am at my desk/workstation and I want to logon to a specific SAP ABAP system with a specific client, how do I do that ? Imaging a SAP Basis person who wants to logon to client 000 for a specific task, but also wants to be able to logon to the productive client in same system to test/configure the application. Meanwhile, and end user might want to logon to the productive client only.

My point is that SPNEGO (or whatever login module is configured on Java stack) is going to authenticate the user and then the SSO2 logon ticket will be created by the CreateTicketLoginModule, but the SSO2 ticket will have a fixed client in it (e.g. client = 999) since Java stack doesn't have clients like ABAP stack does. If I then want to present this logon ticket to SAP GUI or onto a backend ABAP system via web browser, then how does the ABAP system know whether I want to login to client 000, 100, 200 etc. ? It is possible to configure an ACL on ABAP side to allow the logon ticket issued on Java stack to login to a specific client, but how do I tell the ABAP system which client I want ?

Thanks

Tim

Former Member
0 Kudos

Hi Tim,

You're right about the fixed client for the MYSAPSSO2-ticket-issuing system. In the case for Java, the "client" is specified inthe UME parameter login.ticket_client. And the trusting ABAP system will have to add the Java system + "client" into its ACL (in addition to the certificate). This "client" will only play a role in that "trust" relationship.

As for launching the actual transaction via SSO, this is how it works.

SAPGUI transaction will be launched by a thing called Portal transaction iview. That iview will have a parameter called the System Object. The System Object will determine which ABAP system-client it will connect and logon on to. So if you want to logon to multiple clients, then create one System Object for each of the system-client combination, and then create transaction iviews to each of the corresponding system object. The iviews will be presented to the user which then allows the user to launch the transaction iview (specificy SAPGUI link in the iview property)

https://help.sap.com/saphelp_nw74/helpdata/en/4e/1262711e3d2287e10000000a15822b/content.htm

I hope I understood your questions.

Cheers

Donald

tim_alsop
Active Contributor
0 Kudos

Donald,

Thanks for giving the implementation specifics for using the portal method of launching SAP GUI. This doesn't however address the security issues we discussed with the cookie being sent over the network. I would always recommend that a customer considers security as a priority when implementing any kind of authentication system. Also, in my experience a lot of customers don't want to setup and maintain a Java stack just to login to an ABAP system, and some companies have a no-Java policy. In summary, this is a valid option (no doubt on that) but it is not for everybody, and not the best option.

I'm sure we could spend continue discussing the pros/cons of using a portal if we wanted to, as I can think of many reasons not to do it that haven't been mentioned on this thread. I don't think we need to go into any more details on this thread since we have clearly highlighted the options and we should let Madhu ask any questions if he has any.

Thanks

Tim

Former Member
0 Kudos

Tim,

Yes I totally agree with you, security is paramount to any implementation. As for the Portal option, it is really in the context to Madhu's original requirement - mentioning Portal as one option. If the customer already uses it for a gateway or as the word suggests a "portal" to access information from SAP (whichever backend that is) and SSO is active, then extending the benefits of that SSO solution to launch SAPGUI will be very valuable.

SNC is the next thing, as in my previous comment, it is not surprising and is unfortunate that most customers (especially those old ones) did not SNC for SAPGUI from the start.

Anyway other points to ponder on are - for how long would SAPGUI stay relevant, especially when SAP's campaign on new UI technologies - starting with the Business Client (suits well with customers not wanting Java, rendering WDA and WebGUI in seamless client), then on to the new UI5 and Fiori screens, and ultimately to HANA and the cloud (SAP S/4 HANA in particular). Then I guess majority if not all will boil down to one protocol - HTTPS

Kind regards

Donald

tim_alsop
Active Contributor
0 Kudos

Donald

I agree that HTTP authentication is the future. That is why I gave 2 x 1 hour lectures on this subject at a recent SAP TechEd conference in Bangalore. I described how our products can be used to implement this strategy. I recommend using an authentication product on the ABAP stack that handles HTTP auth so that products like Personas 3.0, Fiori, NWBC etc. can be supported, but SNC still has it's many benefits for both authentication and session encryption.

These are the reasons why I recommend short, medium and long term to go with option 1 or 2 and not 3 or 4.

Lets not discuss this anymore via SCN, since this thread is already too busy. If you have any need to discuss more, please contact me. Lets give Madhu a chance to ask his questions or add comments since this his his thread that have been chatting on.

Take care,

Tim

tim_alsop
Active Contributor
0 Kudos

You can use an SSO product (via SNC interface for SAP GUI logon) so that when the user logs on to the 3 systems, the authentication will be performed by the SSO product and using the credentials (e.g. the same password), so no need to sync passwords and no need to use a java stack (e.g. portal).

Thanks

Tim

Former Member
0 Kudos

Hi Tim, I'm a big fan of NW SSO but with your suggestion does that mean the SAP NW client also need to be installed and configured for each of the computers?

I guess the other option would be to activate "SSO for SAPGUI" with MS Kerberos SSP or the old NTLM; which doesn't need extra software but does need the SSO library and then still configure SSO on each PC

Or the easiest without any changes to the SAPGUI is to utilise Portal's SSO capability and able to launch SAPGUI

tim_alsop
Active Contributor
0 Kudos

The options are:

1. Use SAP NW SSO product

2. Use an SSO product from an SAP partner, such as the one I work for 🙂

3. Use Kerberos SSP (if SAP system is on Windows)

4. Use portal with iview to launch SAP GUI

I would recommend option 1 or 2.

I wouldn't recommend using NTLM since this is old and you might get problems when you upgrade Active Directory in the future.

Note: The easiest isn't always the best or most secure option.

Thanks

TIm

Former Member
0 Kudos

I knew a plug is on the way but kidding aside

True and I agree with you 1 and 2 are indeed the more secure option as it also takes care of SNC on data transit. However, I will not be surprised as to how many customers still not use SNC within corporate networks.

Just for the sake of authentication though, Im not sure how SSO product will make it more secure than the Portal passing the MYSAPSSO2 token? or the Kerberos SSP providing SSO token to SAPGUI?

On data transit. The other question is, why cant SAP just bundle SNC on SAPGUI at transport level the same way as HTTPS being readily available on internet browsers.

Anyway, I think we're getting off topic so its up to Madhu to decide.

tim_alsop
Active Contributor
0 Kudos

Donald,

I won't respond to all of your comments, since (like you) I want to keep this thread so it is helpful to Madhu. I'm happy to discuss the other questions outside of SCN if needed.

Regarding MYSAPSSO2 method, when portal issues a mysapsso2 cookie and then launches SAP GUI the SAP GUI software takes the cookie and sends it to the ABAP system over the network, so this cookie can be intercepted and used to replay the logon. So, security is lost because you are not protecting the cookie. Some companies who recognise this have enabled SNC to protect the DIAG protocol used by SAP GUI to send the cookie to the AS. However, if you are going to invest time implementing SNC you might as well use SNC to authenticate the user as well, and then the user doesn't have to logon to the portal each time they want to logon to a SAP system using SAP GUI.

Also, if you use the portal method, when a user has an identify in more than one SAP client, it will not be possible for them to select which client they want because the MYSAPSSO2 cookie issued on JAVA stack doesn't have a useful SAP client in it (it does, but it will be fixed / same for every user).

Thanks

TIm

Former Member
0 Kudos

I dont think there is the possibility to replicate productive passwords from one system to another. Even the SAP CUA doesnt have that facility, only to set and replicate initial passwords and not productive passwords.

However if you do have a portal, why not create Transaction iview which will launch as SAPGUI? (launch type = shortcut so it launches on its own and not within Web Browser)

Then you provide a different launchpad to your end users (from Portla) replacing their usual SAPGUI logon Pad

former_member185954
Active Contributor
0 Kudos

Hello Madhu,

You may have to configure SSO product from SAP to provide for SSO using SAPGUI

Single Sign-On for the SAP GUI - User Authentication and Single Sign-On - SAP Library

If you can live with SAP WEBGUI (Integrated ITS), this can be achieved using SAP Logon Tickets.

Using Logon Tickets - User Authentication and Single Sign-On - SAP Library

Regards,

Siddhesh