Skip to Content


Purpose

Here at SAP Active Global Support (SAP AGS) we constantly receive issues from our customers related to Single Sign On (SSO) between the J2EE and the ABAP Netweaver stacks.

The purpose of this document is help in “PROACTIVELY” checking common SSO issues on the actual servers involved and list steps on further troubleshooting if the need arises.


Example Scenario

Lets say the configured Single Sign On (SSO) setup between SAP Portal and the R/3 system fails and you get a logon page.


/wp-content/uploads/2015/03/1_668150.jpg


Another example of an error would be that you test a portal system connection (Configure System Connection in SAP Enterprise Portal) and this fails with an SSO error:

/wp-content/uploads/2015/03/2_668151.png



Common SSO Error Scenarios and Checks


To check if SSO between the ABAP and the J2ee server is working, test using the method mentioned in SAP Note 1903560. Similarly use the technique mentioned in SAP Note 2028229 to ascertain the SSO between 2 JAVA servers.

Some major SSO issue causes that we come across are mentioned below. Proactively checking the servers involved (both ABAP and J2EE) and comparing the below points will help in finding the root cause. This will help in faster resolution.

1)

Configure the SS0 settings again as per SAP note:1083421 as this will solve any inconsistencies on the server due to manual interventions.

More help:

http://wiki.sdn.sap.com/wiki/display/EP/Troubleshooting+SSO+between+AS-ABAP+and+AS-JAVA

2)

Check SAP note 842635, especially for the parameters: login.ticket_lifetime and SessionExpirationPeriod. Set the expiration of the security session and SSO ticket timeout to the same value as recommended in the note:

Setting security session and SSO timeout

Please set the timeout value for the security sessions (default 27h) and the timeout value for the SSO ticket (default 8h) to the same value. It should be a      value that is higher than the maximum working time of an employee, e.g. 16 hours.


3)

Do make sure that you are on the latest SAPJVM level so that the issues as mentioned in SAP Note: 1367871 do not occur.

4)

The client mentioned in the J2EE UME property login.ticket_client should be part of the TCode /nSTRUSTSSO2 ACL (Access Control List) on the R/3 server.

There is a possibility that say the login.ticket_client is set to 000, which is already a value that is a client in the ABAP server. If so, SSO may not work cause client 000 is also available on the ABAP server as this can lead to inconsistencies. The only option here would be to change the login.ticket_client value to a client that is not present in the ABAP server (say 678) and restart the J2EE server. Then run the SSO2 wizard (as per SAP note:1083421) and this will update the strustsso2 table. NOTE: See the comments section for more information.

5)

The SSO enabling parameters should be set on the R/3 server. The parameters are login/accept_sso2_ticket and login/create_sso2_ticket. More info:

Configuring the AS ABAP for Issuing Tickets for Logon – User Authentication and Single Sign-On – SAP Library

6)

Do see see SAP Note 1055856 which has more information on issues on the R/3 end.

7)

See SAP Note 1761987, point 7 and synchronize the ABAP and the J2EE server clocks. This will make sure that the ABAP and the J2EE servers have the same time as this can lead to issues with the validity of the cookie. You need to make sure that the J2EE and the ABAP server time zones are the same. You can change the timezone by setting the JVM parameter “-Duser.timezone=<desired timezone>” in ConfigTool. More help:

Time zone settings with SAP Process Integration – Process Integration – SCN Wiki

8)

If the actual ticket has expired (or is corrupt), then regenerate the ticket again (always keep a backup of the existing ticket before creating a new one). Check the below link for more info on creating a new certificate.

For 6.40 and 7.00:

http://help.sap.com/saphelp_nw70/helpdata/EN/75/c80b424c6cc717e10000000a155106/frameset.htm

For 7.1,7.2,7.3,7.4 and 7.5:

http://help.sap.com/saphelp_nw73ehp1/helpdata/en/75/c80b424c6cc717e10000000a155106/frameset.htm

9)

Another issue can be that when the connection is made from the SAP Application Server JAVA to the R/3 server, the MYSAPSSO2 cookie is not sent at all due to domain restrictions. As per Note SAP Note 701205 – Single Sign-On using SAP Logon Tickets

SSO with SAP Logon tickets for multiple domain is supported starting with EP6 SP6. You can also use domain relaxing if  the domains differ only in

a subdomain name. In this case, specify the number of subdomains to be cut from the J2EE domain name using the parameter ume.logon.security.relax_domain.level in the sapum.properties (under Direct Editing in the UM Configuration).

Example: If the host name for the Portal is portal.wdf.sap.com and ume.logon.security.relax_domain.level=2, then the MYSAPSSO2

cookie is sent to all servers within the domain sap.com.

An HTTPWATCH trace will help in such cases.

10)

Also MYSAPSSO2 cookies may not be forwarded due to incompatible hostnames (see SAP Note 611361 :  Hostnames of SAP servers )

The loadbalancer should also not halt the cookie being forwarded.

11)

The SAP Application Server JAVA and the SAP Application Server ABAP are in completely different domains. In this case, see SAP Note 1604482 to resolve the issue.

12)

The maximum validity of the certificate should not exceed the date January 01, 2038. Check SAP Note 1055856 for more on this and for other certificate criteria.


Further Troubleshooting

Say the above settings are all fine but the issue persists. Now it is time to delve deep into the server logs and investigate further. This is needed to narrow down the issue as to  whether it is an ABAP server, J2ee, tickets, browser issue etc and help in an END TO END trace. The detailed steps are:

1)
Clear all the browser cache.

2)

Set the security trace level in the ticket accepting system (R/3 server)

======================================================

2.1. Call transaction SM50 (process list):

2.2. Process -> Trace -> Reset -> Workprocess Files

2.3. Key combination: F5 (select all), CTRL-Shift-F7 => Dialog box;

2.4. Set trace level=3 and ONLY(!) check the “Security” component;

If necessary, you must repeat these steps for each server (see transaction SM51), unless you can use a specific server for reproducing the error (for example, by excluding the load distribution).

======================================================

3)

Run the web diagtool as outlined in SAP Note 1045019 (example 1) if you are on SAP Netweaver release 6.40 or 7.00 or as per SAP Note 1332726 (incident “General Security”) if you are on 7.1, 7,2, 7.3, 7.4 or 7.5 version. It will be ideal to run it on the server 0 (check SAP Note 1589567).

4)

While the diagtool is running, reproduce a failed SSO scenario to the backend.

5)

When the SSO fails, wait for a minute and then press return in the diagtool console so that the resulting traces are picked up.

6)
Also download the httpwatch tool (free from www.httpwatch.com) and take a complete end to end trace (by reproducing the issue). More information is available in SAP Note 1558903 – How To Trace a Portal Scenario Using HttpWatch.

The HTTPWATCH file should show the MYSAPSSO2 cookie being forwarded from the SAP Application Server JAVA to the SAP Application Server ABAP.
7)

Check the diagtool traces and the ABAP workprocess traces for more details on the exact error. You can use the technique mentioned in How to search for specific error content in ABAP server logs and How to check logs for particular J2EE application issue to narrow down and pin point on the exact cause.

NOTE: If you are still uncertain after all the steps mentioned in this blog and the issue still persists, contact SAP Support / SDN and attach the below documents/logs:

—  The html Diagtool log
—  The J2EE server default traces
—  The /nSM50 trace
—  Step by step screenshots of error reproduction
—  the exact time at the issue was reproduced and the user ID involved.
—  The screenshots ofthe TCode /nSTRUSSSO2 and the ACL.

Possible Workaround to Consider: assertion tickets


The usage of the option “Assertion ticket” will help in such issues cause the ticket used for Single Sign On in the connection to the R/3 backend system is only used once thus avoiding problems inherent to the SSO ticket mechanism. Refer the below links for more on this:

Assertion Tickets – SAP Netweaver Application Server Java – SCN Wiki

Authentication Assertion Tickets

References

Configure System Connection in SAP Enterprise Portal

SAP note:1083421: SSO2 Wizard

Troubleshooting SSO between AS-ABAP and AS-JAVA – Portal – SCN Wiki

Replacing the Key Pair to Use for Logon Tickets – User Authentication and Single Sign-On – SAP Library

SAP note 842635: Session Management for Web Dynpro Applications

SAP note:1083421; SSO2 Wizard


Configuring the AS ABAP for Issuing Tickets for Logon – User Authentication and Single Sign-On – SAP Library

SAP Note 1055856:Common error messages when setting up Single Sign-On

SAP Note 1761987: SAP Logon Tickets Rejected Due to Clock Synchronization Issue

Time zone settings with SAP Process Integration – Process Integration – SCN Wiki

SAP Note 1045019: Web diagtool for collecting traces


SAP Note 1332726:Troubleshooting Wizard


SAP Note 1589567: How to login to a specific J2EE engine server node

SAP Note 1055856 Common error messages when setting up Single Sign-On


SAP Note 1604482 – SSO in multiple domain where no Ticket-issuing server exist

SAP Note 1558903 – How To Trace a Portal Scenario Using HttpWatch

How to search for specific error content in ABAP server logs


How to check logs for particular J2EE application issue

To report this post you need to login first.

8 Comments

You must be Logged on to comment or reply to a post.

  1. Matt Fraser

    Hi Hemanth,

    Great outline of troubleshooting steps, thanks.

    I have one question, though. Under Common Error Scenarios, point 4, you talk about login.ticket_client being set to 000 as a problem. However, at least with older J2EE/Portal systems (such as 7.01) this is the default setting, and in years past the instructions for setting up SSO between a Portal and an ABAP system involved importing the ticket issued by the portal via STRUSTSSO2 and setting the client to 000 during the import. I’d have to dig to find it, but I recall this being a distinct instruction, and indeed it is how I’ve configured our portal to work. It has been this way for ten years now, without an issue (it was originally on NetWeaver 7.00, but since upgraded to 7.01).

    On the other hand, I always did the STRUSTSSO2 import in the working client, not client 000, despite some warnings indicating this should be done in 000. This never caused a problem, either.

    Cheers,

    Matt

    (0) 
    1. Hemanth Kumar Post author

      Hi Matt,

      Thank you for your inputs. Nice catch 🙂 .

      I knew someone was going to notice this 🙂 as this is part of the standard setup. However we have seen (very very rarely if I may add) a particular consistency issue with the ACL table on the R/3 side (error with the “verify” process) when both the values are the same.
      I will try to dig out some incidents so that I can post the exact error here.

      Kind Regards,
      Hemanth

      (0) 

Leave a Reply