Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

SSO2 ticket validation problem

tim_alsop
Active Contributor
0 Kudos

We have a J2EE engine which is installed as an add-in to an ABAP system. The J2EE engine login module is creating an SSO2 login ticket (we can see this is working from defaultTrace), but when the application on ABAP engine is accessed via browser we get the following message in dev_w0 log, and the login fails by showing the browser signon screen, instead of using the SSO2 ticket to login to the application.

N *** ERROR => Ticket validation failed with rc = 1703941. [ssoxxkrn.c 720]

N

N Mon Apr 16 15:47:14 2007

N *** ERROR => Verify failed with rc = 5. [ssoxxsgn.c 142]

N uResult=26.

N Certificate not found.

N *** ERROR => MskiDefaultVerify failed with rc = 1703941. [ssoxxsgn.c 216]

N *** ERROR => ValidateTicket returns 1703941. [ssoxxapi.c 220] [ssoxxapi.c 2

20]

N *** ERROR => Ticket validation failed with rc = 1703941. [ssoxxkrn.c 720]

We have searched in SDN, in SAP Service Marketplace, and in SAP Help Library, but cannot find what this error code means. The SSO2 trust seems to be correctly setup, but we don't know why it is not working.

Can somebody help me find out what this error means ?

Thanks,

Tim

4 REPLIES 4

Former Member
0 Kudos

Hi Tim,

this just means what it says. Ticket verification fails. Reasons are usually either the cert not loaded into the PSE or not haveing created the ACL correctly. Please note, that the client for a STANDARD J2EE engine is 000 and thus this needs to be maintained in the ACL.

BTW: you can enable the security tracing, which will give you more detailed information. Maybe this is of help. Please see <a href="https://service.sap.com/sap/support/notes/457222">SAP note 457222</a> for more details

regards,

Patrick

0 Kudos

Patrick,

The text makes sense, but I was hoping that the return code would tell us the exact reason for the validation failure.

Anyway, last night I was informed by the customer that they deleted the SSO2 trust and added it again, and now it is working. So, they must have done something wrong the firs time, and caused this error.

I will assume that the return code is not useful in future, and suggest that the customer just rechecks that they setup the trust using STRUSTSSO2.

We already recommend changing the client used by J2EE engine from its default of 000. We normally suggest J2E is used.

Thank you for the information about SAP security tracing.

I consider this topic closed now, so will award points.

Take care,

Tim

0 Kudos

Hi Tim,

please do not mix SID and Client. For an add-in, the SID HAS TO BE THE SAME AS THE ABAP SID. The client in all cases is a 3 digit number. You should leave it at 000 (the default) unless there is a conflict for some reason (which usually only occurs in training environements).

regards,

Patrick

0 Kudos

Patrick,

Regarding the client, I refer to SAP help library at <a href="http://help.sap.com/saphelp_erp2005/helpdata/en/cb/ac3d41a5a9ef23e10000000a155106/content.htm">this location</a> where it says :

The system ID and client combination must be unique when tickets are to be accepted by an SAP Web AS ABAP system. Therefore, in an Add-In installation, where the system IDs are the same, you <b>must </b> change the default client for the J2EE Engine (000) to a client that does not exist on the SAP Web AS ABAP system.

Since the word must is in bold, we took this to mean that it should always be changed to something other than 000 when an add-in is used. If not, then an SSO2 ticket issued by J2EE engine for a user in client 000 in ABAP engine will not work, since the client number is the same in both.

Also, in the documentation for changing login.ticket_client it is suggested that J2E is used (e.g. not numeric), so that you can be 100% sure the client is not same as a client used in ABAP engine, and therefore it will ALWAYS work.

Regards,

Tim