Page tree
Skip to end of metadata
Go to start of metadata


<<<<CONTINUATION FROM  SAP KBA 2551642>>>>



PURPOSE:


The purpose of this document is to proactively check (and rectify) common Single Sign On (SSO) issues between SAP Application Server JAVA and SAP Application Server ABAP on the actual servers involved.


EXAMPLE SCENARIO:

Lets say the configured Single Sign On (SSO) setup between SAP Portal and the SAP Application Server ABAP 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:


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.

 

 

COMMON SSO ERROR SCENARIOS AND THEIR SOLUTIONS:

1)
ISSUE: SSO FAILS DUE TO USER ID MISSING/MISMATCH on the ABAP SERVER/ USER MAPPING FAILS. 

If the user which was used to login to the SAP Application Server JAVA does not have the same logon ID on the ticket accepting system (R/3 server), then the SSO logon will fail.

SOLUTION: 

Make sure that the user IDs are the same in the ticket issuing and the ticket acception server (but the passwords can be different). The User Mapping option is only available if there is an Enterprise Portal. User mapping option maps a portal user ID to the user ID of the back-end system. 
For different User mapping options, check:
https://help.sap.com/saphelp_nwmobile71/helpdata/en/46/3e52f9f3a502eae10000000a155369/frameset.htm

and

How User Mapping with SAP Logon Tickets works

If theer are issues with the user mapping, check SAP KBA ##1913922 - Single-Sign-On (SSO) failed with user mapping.

2)
ISSUE: BROWSER DOES NOT ALLOW COOKIES   

In the HTTPWATCH traces, you do not see the MYSAPSSO2 cookie.

SOLUTION: 

Firstly make sure that the browser employed is as per SAP standards (check PAM: https://support.sap.com/en/release-upgrade-maintenance.html ).
If the browser does not accept the SAP cookie, then this can be resolved by removing the cookie restriction in the browser:


3) 
ISSUE: SSO fails due to MYSAPSSO2 cookie not being created   

SOLUTION: 

The CreateTicketLoginModule should be part of the authentication stack. 

***************************
Ticket Login Module Stack*

***************************
_____________________________________________________
Login Modules Flag |
|
EvaluateTicketLoginModule SUFFICIENT |
|
BasicPasswordLoginModule REQUISITE |
|
CreateTicketLoginModule OPTIONAL |
_____________________________________________________

More information along with sample stacks are available here:

Sample Login Module Stacks for Using Logon Tickets


4) 
ISSUE: MYSAPSSO2 COOKIE IS NOT SENT TO THE ACCEPTING SYSTEM AS IT IS IN DIFFERENT DOMAIN   

If the accepting system is in a different domain, the MYSAPSSO2 cookie may not be sent since it is valid only for systems in the same domain as the issuing system.

SOLUTION: 

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 SAP Application Server JAVA domain name using the parameter ume.logon.security.relax_domain.level.
For more help, check SAP Note 701205.

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.

If the SAP Application Server JAVA and the ABAP server are on completely different domains, check point 16.


5) 

ISSUE: MYSAPSSO2 COOKIE VALUE IS OVERWRITTEN

When a user successfully authenticates on two systems where both systems do not accept SAP Logon Tickets issued by the other and if both systems set MYSAPSSO2 cookies with the same domain attribute, then the MYSAPSSO2 cookie set by the first system is overwritten.
This can cause authentication/SSO failures if there are subsequent requests where the SAP Logon Ticket issued by the first system should be used for authentication. 

SOLUTION: 

Create TRUST between the two servers using the SSO2 wizard (see SAP NOTE ##1083421) and configure domain parameters accordingly.


6) 
ISSUE: MULTIPLE MYSAPSSO2 COOKIES ARE BEING SENT BY THE BROWSER

In a multiple system scenario where a user has successfully authenticated on more than one system, it is possible that there are multiple MYSAPSSO2 cookies in the browser’s cookie store, each with different values and domain attribute values. It can occur with certain requests that, based on their domain attribute values; more than one MYSAPSSO2 cookie is sent. 

SOLUTION: 

Usually this is a SAP system landscape design issue. Most likely the adjusting the value of ume.logon.security.relax_domain.level in the SAP Application Server JAVA can work around the problem. For more help, check SAP Note 701205 and SAP NOTE 1368384.
There is a known issue when tabbed browsing is used. More details are available in SAP KBA ##2097889 - Using tabs with different Systems and users with SAP Netweaver AS Java can lead to issues.

 

7) 
ISSUE: MISSING SAPLogonTicketKeypair ON THE ISSUING SYSTEM
   

If the issuing server does not have a key pair exactly named SAPLogonTicketKeypair, it cannot sign the ticket. That way the ticket won’t be created at all. Another similar issue is when the below error occurs in the traces:

************************************************************************
Cannot verify ticket. A file entry with the name <ticket name> cannot be found in the configuration "keystore..”
************************************************************************

SOLUTION: 


Create or replace the key pair as per requirement. More help: 


Creating a Key Pair and Public-Key Certificate

http://help.sap.com/saphelp_nw73/helpdata/en/36/7627aa3fe440369150a434f8137eda/frameset.htm

Replacing the Key Pair to Use for Logon Tickets

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

Final configuration should look like this:



Also see SAP Note ##791649User unable to logon by ticket


8) 
ISSUE: MYSAPSSO2 SECURITY ISSUE: 

If a user manages to get hold of a logon ticket, as long as this ticket is valid, it will be accepted even if the user has logged off from the system in the meantime.

SOLUTION: 

Set the login.ticket_revocation as mentioned in SAP NOTE ##1598793 - Logon ticket revocation. Possible values are:

 

  • none - no logon tickets will be revoked

 

  • all - the logon ticket of the user will be revoked as soon as they log off, regardless of which system actually issued it

 

  • own - the logon ticket of the user will be revoked as soon as they log off only if they log off from the same system that issued the ticket

 


9) 
ISSUE: : RECEIVING SERVER DOES NOT HAVE THE ISSUING SERVER'S PUBLIC CERTIFICATE


If this certificate is not present, the accepting system cannot verify the ticket, which was signed with issuing system’s private key and can be verified only by its public key (contained in the certificate).

SOLUTION: 

The SAP Application Server JAVA certificate should be added to the /nSTRUSTSSO2 Tcode on the accepting ABAP server.

 


Do note that if the SAP Application Server ABAP has several instances, a "DISTRIBUTE" needs to be one for the ocnfiguration changes to be available on other servers as well.


10) 
ISSUE: SSO FAILS CAUSE THE MAXIMUM VALIDITY IS SET TO A VERY HIGH LIMIT 

SOLUTION: 

The maximum validity of the certificate should not exceed the date: January 01, 2038 (See SAP Note ##1055856 for more details).



11) 
ISSUE: DISCREPANCIES IN THE VALUES OF SESSIONEXPIRATIONPERIOD and the LOGON TICKET VALIDITY

SOLUTION: 

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

 


and




12) 
ISSUE: TIMEZONE ISSUES

An example from actual traces:

************************************************************************

N Got content client = 000.
N Got content sysid = BJP .
N Got date 201306271516 from ticket.
N Cur time = 201306271519.
N Computing validity in hours.
N Computing validity in minutes.
N CurTime_t = 1372432740, CreTime_t = 1372432560
N validity: 120, difference: 180.000.
N *** ERROR => HMskiCheckValidity failed. [ssoxxkrn.c 1080]
N {root-id=51BA347B347A0E24E10000000AF00318}_{conn-id=00000000000000000
000000000000000}_0
N dy_signi_ext: ticket expired
"
************************************************************************

The Ticket is valid for 120 seconds = 2 Mins and it seems to have expired as there is a difference of 3 minutes between the SAP Application Server JAVA and the SAP Application Server ABAP clocks. The ticket has the time 201306271516 (that is 27/06/2013 15:16) while the ABAP server time is 201306271519 (that is 27/06/2013 15:19).

SOLUTION: 

Synchronize the SAP Application Server JAVA and the SAP Application Server JAVA clocks. This will make sure that the ABAP and the JAVA servers have the same time as this can lead to issues with the validity of the cookie. 

On the AS JAVA, check SAP NOTE ##1867012 - SAP JVM Time zone values in SAP AS Java and SAP Note ##1367871 - Timezone updates for SAP JVM.

On the AS ABAP, check Timezone changes best practices .

 

13) 
ISSUE: ABAP SERVER REJECTS THE MYSAPSSO2 COOKIE 

If the user which was used to login to the SAP Application Server JAVA does not have the same logon ID on the ticket accepting system (R/3 server), then the SSO logon will fail.

In this case the response from the ABAP system includes a cookie named sap-ssolist. The sap-ssolist cookie contains base64 encoded information about the application server which received the MYSAPSSO2 cookie but did not accept the SAP Logon Ticket. The cookie value can be decoded to get this information which is very useful particularly in the case where there are multiple instances of the ABAP system.

SOLUTION: 

Set the profile parameters:

login/accept_sso2_ticket = 1
and
login/create_sso2_ticket = 2

on the ABAP server. Once done, make sure that the /nSTRUSTSSO2 “distribution” has been done. More help:
Configuring the AS ABAP for Issuing Tickets for Logon


14) 
ISSUE: OLD PSE FILE ON THE AS ABAP LEADS TO ISSUES

SOLUTION: 


15) 
ISSUE: MYSAPSSO2 COOKIE IS NOT FORWARDED FROM AS JAVA TO AS ABAP 

SOLUTION: 

Checks to be done in such cases:

1) Check if hostnames of the servers involved are as per SAP standard. (see SAP Note 611361: Hostnames of SAP servers). 

"
General rule for hostnames according to RFCs 952, 1101, 1123, 1178: Alphanumerical string of alpha characters [A-Z] and [a-z] and digits [0-9] and the hyphen (or minus) character "-". Although the newer RFCs permit hostnames beginning with digits we recommend hostnames to begin with an alpha character.
"
Also check SAP Note ##654982 : URL requirements due to Internet standards, SAP Note ##1334956: Various problems that are solved by using FQDN in portal URL and
SAP Note 2497800 - SSO fails with underscore character in hostname.



2) Load balancer should not halt the cookie transfer. To isolate the issue further, try to check bypassing the load balancer.
More info:

http://wiki.scn.sap.com/wiki/display/ASJAVA/MYSAPSSO2+-+browser+and+proxy+handling

 

3) The browser that is being used is not as per SAP standards. If so, make sure that the browser employed is as per SAP standards (check PAM: https://support.sap.com/en/release-upgrade-maintenance.html ). 

 


16) 
ISSUE: THE TICKET ISSUING SERVER AND THE RECEIVING SERVER ARE ON COMPLETELY DIFFERENT DOMAINS 

The MYSAPSSO2 cookie is not forwarded in such a scenario.

SOLUTION: 

A setup similar to the one mentioned in SAP Note No. ##1604482 needs to be considered to get the configuration to work. In this case, the UME parameter : ume.login.mdc.hosts may have to be amended. For more help:
Configuring Logon Tickets for Multiple Domains

 

https://help.sap.com/viewer/7ba199e10fdc488293db33f0709f9225/7.3.17/en-US/e0fa984050a13354e10000000a1550b0.html


 

17) 
ISSUE: SSO BETWEEN SAP Application Server JAVA TO 3rd PARTY SERVER FAILS 

SOLUTION: 

Only SAPSSOEXT solution is supported in such cases. For more help, check:

http://service.sap.com -> Technology Components -> SAP SSOEXT-> SAP SSOEXT
and:

https://wiki.scn.sap.com/wiki/display/ERPHCM/SAP+SSO+Authentication+with+verify.pse+using+SAPSSOEXT


18) 
ISSUE: AFTER CONNECTION IS MADE TO THE AS ABAP, NO DATA IS DISPLAYED 

From the HTTPWATCH traces, the content-length header is 0. This means that the client (browser) will close the connection right after receiving the headers and any following attempt to send something will fail.  Any Content-Length greater than zero is a valid value.

SOLUTION: 

-> Check network proxy.
-> Browser being used.

-> Connection between the servers involved.
→ The Load balancer might have an effect on this


19) 
ISSUE: LOGIN.TICKET_CLIENT AND THE VALUE OF THE ABAP CLIENT ARE SAME IN AN ADD IN SERVER 


Compatibility Issues can occur on ADD IN (DUAL STACK) servers when the client in the SAP Application Server JAVA UME property login.ticket_client is the same as the TCode /nSTRUSTSSO2 ACL (Access Control List) on the R/3 server.

SOLUTION: 

 

Change the login.ticket_client value to a client that is not present in the ABAP server (say 678) and restart the Application Server JAVA server. Then run the SSO2 wizard (as per SAP NOTE: ##1083421) again and then update the /nStrustsso2.

20) 
ISSUE: SSO VIA PROTOCOL: HTTPs WORKS, BUT FAILS WITH PROTOCOL: HTTP 

SOLUTION: 

Using the Config Tool, check the value of the ume property ume.logon.security.enforce_secure_cookie.
If it has value true -> only https will work.
and
If it has value false -> https and https will work

More help: Ticket issuing - UME properties

 

21) 
ISSUE: "TICKET" POLICY CONFIGURATION IS INCORRECT 

SOLUTION: 

The 'ticket' policy configuration's login module stack must contain at a minimum EvaluateTicketLoginModule, BasicPasswordLoginModule and CreateTicketLoginModule in that order from top to bottom with appropriate flags at some point in the stack.

EvaluateTicketLoginModule to accept logon tickets for SSO.

CreateTicketLoginModule for creating logon tickets

BasicPasswordLoginModule and DigestLoginModule to perform the authentication with user ID and password. For more help, check:

https://help.sap.com/saphelp_nw70/helpdata/de/99/f66e424925c253e10000000a1550b0/frameset.htm

and

SAP NOTE ##2273981: Configuring Authentication stacks for Netweaver Application Server JAVA.


22) 
ISSUE: NO PORTAL AND NO ABAP USER. TICKET CREATION IS ABORTED


Neither a portal user ID nor ABAP user ID could be written to the logon ticket  so the creation of the ticket was aborted.

SOLUTION: 

This can occur if the user that is logging on has a logon ID greater than 12 characters, for example the 'Administrator' user, and either the UME property login.ticket_portalid has value no or login.ticket_portalid has value auto but no Enterprise Portal is installed. Since ABAP user IDs must be 12 characters or less, longer IDs cannot be written as the ABAP user in the logon ticket. As the login.ticket_portalid is NO, this means that the logon ID will not be written as the portal user ID in the ticket either. Therefore ticket creation is aborted.

Configuring a value of yes for login.ticket_portalid will ensure that the logon ID is written as the portal ID in the ticket and the ticket creation will succeed.

 


23) 
ISSUE: TICKET SIGNING CERTIFICATE DOES NOT USE DSA ALGORITHM

SOLUTION: 

Recreate the key pair used for SAP Logon Tickets

NOTE: Be aware that if you have configured SSO with SAP Logon Tickets where the Netweaver AS Java is the ticket issuing system you must re-import the public key certificate of the AS Java into all ticket accepting systems after recreating the key pair 

 

24) 
ISSUE: AFTER SAML AUTHETICATION, MYSAPSSO2 COOKIE IS NOT CREATED (FOR SSO TO AS ABAP)

 

In this case, the SAP Application Server JAVA is the SP (Service provider). Once the SAML logon happens the MYSAPSSO2 cookie is not generated and subsequent SSO to the AS ABAP does not occur.

 

 

SOLUTION: 

 

Check SAP KBA ##2435661 - MYSAPSSO2 cookie (logon ticket) not created after SAML logon for SSO

 


NOTE: ALSO CHECK SAP NOTE 1055856Common error messages when setting up Single Sign-On for other comon  issues. 


FURTHER TROUBLESHOOTING


 

Say the above checks have been done and the issue still 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 SAP Application Server JAVA or an SAP Application Server ABAP or a browser issue (the list can go on) . For this, an END TO END trace is needed.
For more help, check SAP KBA ##2487383: How to Troubleshoot SSO with Logon Tickets with the SAP Netweaver Java AS.

 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.
Incase a Firefox browser is being used, use the Live HTTP Headers.

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

 

and

Authentication Assertion Tickets


  • No labels