SSO Troubleshooting

Profile Parameters
Check for the parameter login/accept_sso2_ticket and login/create_sso2_ticket exists in the default or instance profile.

If you cant find it, insert the following parameters in the default profile, activate it and restart the system:
login/accept_sso2_ticket = 1
login/create_sso2_ticket = 2

A nice way to check this out is by running the transaction SSO2, set NONE as the RFC Destinations. This checks if the profile parameters is set correctly and the imported / existing certificates

Different Username
If you have a different username in the Portal as in the Backend System, the SSO will fail.

Full Host Name
SSO require full host name. Enter transaction RZ10 in your Backend System
Open the default or instance profile and check for the paramter icm/host_name_full. This profile tells you the full hostname that you must use to make SSO works properly.

If you can't find the parameter, talk to the basis team or add it your self.

This full hostname must be used when you refering to the system you want to connect from the Portal, and the same value shoud be used when defining the system in the Portal

Cookies
The logon ticket itself is stored as a cookie (MYSAPSSO2) on the client and is sent with each request. Log in with your browser to check if the cookie is created. Firebug and FireCookie for Firefox are extremely useful tools for checking session based browser cookies. HTTPWatch is a very useful IE Plug-in to inspect the HTTP request including cookies when using Internet Explorer.

Not valid certificates ?
Sometimes there are client copy may remove your certicate and replacing the owner certificate from the copied client. Run transaction STRUSTSSO2 and choose Replace on the System PSE, and then export it to the Portal

Locked user ?
If the user you are using is locked in the backend and not in the Portal, the SSO may not work. Use transaction SU01 to lock up the user.

ACL
Check if the ACL in the Backen: Transaction STRUSTSSO2 and the Portal : Choose Server --> Services --> Security --> Provider --> Ticket is correct.

Log files

It is also useful to check the SM50 logs on the target SAP system to see if there are any associated security/sso errors in the log. Sometimes they can give you a clue as to why SSO is not working.

This is just pointers of where to look when getting SSO to work. You should also use the DefaultTrace file for "debugging" the situations.