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.
Lets say the configured Single Sign On (SSO) setup between SAP Portal and the R/3 system fails and you get a logon page.
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:
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.
Configure the SS0 settings again as per SAP note:1083421 as this will solve any inconsistencies on the server due to manual interventions.
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.
Do make sure that you are on the latest SAPJVM level so that the issues as mentioned in SAP Note: 1367871 do not occur.
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.
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:
Do see see SAP Note 1055856 which has more information on issues on the R/3 end.
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
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:
For 7.1,7.2,7.3,7.4 and 7.5:
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.
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.
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.
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.
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:
Clear all the browser cache.
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).
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).
While the diagtool is running, reproduce a failed SSO scenario to the backend.
When the SSO fails, wait for a minute and then press return in the diagtool console so that the resulting traces are picked up.
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.
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:
SAP Note 1558903 – How To Trace a Portal Scenario Using HttpWatch