07-18-2007 1:34 PM
Hi Everyone,
We are using EP 7.0 and ECC 6.0. We need to establish a SSO connection between the portal and the backend system.We have done the necessary configuration for the same but we are getting the following error while we are trying to access the backend services.
"SSO logon not possible; invalid host name for issuing cookie".
Please let us know how to resolve the issue.Also if any specific settings are required for the services in SICF, do let us know.
With Regards,
Kaustuv Goswami.
07-19-2007 3:27 PM
Hi Kaustuv,
the following check list can assist you in isolating and troubleshooting the cause of the problem:
1. R/3 System:
- Have you taken care of the trust issue? Check in STRUST and SM30
or STRUSTSSO2 that the portal is trusted by R/3 (releases>=4.6C)
or by importing the certificate manually as outlined in the admin
guide (releases <4.6C). This has to be done BEFORE the data source
is created.
- Has table TWPSSO2ACL been maintained? This is done automatically if
the transaction STRUSTSSO2 is used.
- Have the relevant R/3 Parameters been set
(login/accept_sso2_ticket, login/create_sso2_ticket,
wp/pi/enable_drag_and_relate in the instance profile)? Is
SAPSECULIB pointing to the library file itself (releases 4.0 and
4.5)?
- Has SAPSSO2.pse been copied to $DIR_PROFILE (for example:
/usr/sap/<SYSID>/SYS/profile/SAPSSO2.pse)?
- Users must have the proper authorizations in the R/3 system. See
note #452508 for more details.
- Were the WP-Plugin (transaction saint) and Drag&Relate Metadata
imported (BOR transport completed successfully)? Have you applied
the most recent Service Pack for the plugin?
- Is the SAPSECULIB up-to-date (see also note #177895)? This library
is required to verify the digital signature of the ticket issuer.
It is downwards compatible. You can download the most recent
version for your operating system from one of the sapserv servers:
/general/misc/security/SAPSECU/<platform>
You can determine the version by calling transaction sso2 and
entering 'NONE' (Upper Case!) in the field 'RFC Destination'. The
'SECUDE(tm) Version' at the end of the list gives you the version
(works only for 4.6C or higher).
- You can run a security trace to find out more about the ticket
and certificate handling within R/3 and for possible reasons of
failure. Run sm50 and select some of the dialog workprocesses
(around 5). Then go to 'Processes -> Trace -> Active components' or
simply hit CTRL-SHIFT-F7. Set trace level to 2 and select
'Security'. Reproduce the error in the portal and note the time.
Return to the R/3 to check the traces you just started
(CTRL-SHIFT-F8 in sm50). This procedure is described in note
#495911 in more detail.
2. Portal:
- Do not use the user 'admin' in any case, it is only a user to make
the portal accessible via hardcoded means. You should assign
another user to the proper admin roles and use this one for
creating data sources and the like.
- Please ensure that the UserID are the same in the R/3 and the
portal if you are not using UserMapping.
- Are the files systems.xml and JCoDestinations.xml configured
properly? You can send the files to us if you need assistance in
verifying the setup (refer to note #40024 for more details).
Problems arise from incorrect settings and missing(!) parameters.
Even if you followed the Admin Guide strictly, there might still be
changes and settings to be added here. Please make sure that you
always upload the new systems.xml and JCoDestinations.xml into the
System Landscape. Otherwise it might happen that there are multiple
files on the system and the wrong one might be used by the portal.
Please see note #543870 for help when connecting via an Application
server (ASHOST, ApplicationServer) or Message server (MSHOST,
MessageServer).
- Refer to note #490154 for important information when getting errors
while creating data sources (no data sources displayed in pull-down
menu etc.). Are the Data Source Settings set to 'Automatic
Synchronisation' for the Authorization Level and 'Anonymous/SSO'?
It is vital that the verify.pse file on the Portal and Unifier
server are identical! If the files differ for some reason (this
typically happens when you reinstall the portal without changing
the Unifier or when you install the portal and the Unifier on
different machines), copy the verify.pse from the Portal server to
the same location on the Unifier and replace the old one. The
*.pse file can be found in //WINNT/system32.
- You can run tests for the RFCs using the Example.JCo* servlets
under http://<Your Portal>:<Your Port>/irj/servlet/prt. With the
release of Support Package 2, two new test tools for the files
systems.xml and JCoDestinations.xml are available under 'System
Configuration -> System Landscape'.
- Are the logon tickets for the portal issued properly in the first
place? You can verify this by telling the Internet Explorer to
prompt you when new tickets are created. Navigate to 'Tools ->
Internet Options -> Security' and select the zone in which the
portal is accessed. Choose 'Custom Level', scroll to the 'Cookies'
section and select 'Prompt' under 'Allow per-session cookies'.
You will be prompted when the MYSAPSSO2 cookie is created during
portal logon. If you click on the button 'More info', you can find
out about the name, domain(!) and path for which the cookie was
created.
if it helpful reward points are appreciated
07-20-2007 3:55 PM
Have a kind look on <a href="https://service.sap.com/sap/support/notes/654982">SAP Note 654982</a>