Have any SAP NW SSO members had this issue?:
We have installed SAP NW SSO Secure Login X.509 Based Solution according to the Best Practice Guide and it is working fine.
However we rolled out the Secure Login Client to +4000 client computers and as soon as we did, we had hundreds of users reporting that 80% of the time that they run Internet Explorer it crashed stating:
Internet Explorer has stopped working
Windows can check online for a solution to the problem
* Check online for a solution and close the program
* Close the program
Looking at the problem in detail:
Problem Event Name: APPCRASH
Application name: iexplore.exe
Fault Module Name: ntdll.dll
If a user chooses to check online for a solution, Internet Explorer recovers the browser tab and continues ok, or the same error happens. This is not a situation we can continue with.
This is happening 80% of the time to our users when they run Internet Explorer, and we have analysed the Windows Event Viewer logs to verify this.
As soon as we remove the Secure Login Client from the client computers this error does not occur at all - again we can see straight away from analysing the Windows Event Viewer Logs.
Currently we have had to remove the Secure Login Client from our +4000 client computers so as to ensure this error does not occur - but this means SAP NW SSO does not work for us (we use SAP NWBC and IE to access SAP ABAP systems).
Have any other members experienced this issue?
Thanks for your help
yes we do!
And we are glad to have only some key users running NWSSO
We experienced crashes starting explorer.exe
and as far as it looks while running outlook2010 and winword2010 on win7-64bit .
Unfortunately the tasks are crashing randomly, we are not able to reproduce the scenario until now.
Not a matter of fact but a feeling: crashes are happening more often since 2 weeks.
And we are in trouble with cert handling too. Our PKCS#11 provider is handling certs well, they are to bee seen in IE or certmgr.exe correctly. But sometimes NWSSO does not show the certs or even worse is displaying the wrong cert details. As far as it looks it depends on different Smartcards. Analysis is ongoing. From the outer view the cards are looking all the same: card-os 4.4, 3-user certs. So I'm going to ask our PKI-team for the inner view.
Glad to hear we are not the only one to see this!
We have had to pull back the Secure Login Client from our +4000 clients and so the SAP Netweaver SSO project is in danger of being cancelled due to the issue.
Since we have removed the client Internet Explorer crashes have stopped. We have then tested re-adding to a small number of clients and the crashes start again, then removed and crashes stop - so we have proved it is the Secure Login Client.
I hope the experts here (Frane / Matthias) can help with this?
We are testing the Secure Login Web Client now as a possible alternative, but this is erroring too! - I have a SAP Message logged for this.
Thanks very much for your input Claus
Did you check if the user's systems have the certificates and Secure Login Client been installed on their systems?
Also the user configuration in the target backend system (SU01) should have the canonical name defined in the SNC tab.
Please let me know in case of any concerns.
Yes the actual NW SSO X.509 Solution is all working, user certificate is in place and user is able to login without username and password.
However after having the solution in place, our +4000 users then started reporting that Internet Explorer was crashing within hours of the solution being rolled out.
The only change was the Secure Login Client being rolled out.
We rolled back the SLC from a group of users and they reported IE stopped crashing. We repeated this process of roll-out / roll back oveer a number of days and verified it was the SLC causing it.
We have now had to remove the SLC from the +4000 clients.
The SLC communicates with IE to place the user certificate in the certificate store so that SSO can take place in a browser, so this must be causing the crashing as demonstrated by our tesing of roll-out / roll back of the SLC.
Hi Rohit, Hi Mark
Part 1 My cert registration problem: solved: CAPI filter and Smartcardlayout did not match exactly, so some cards/certs are showing up in NWSSO some did not.
Part 2 NWSSO SW and (selfsigning) certs are installed, no secureserver, no kerberos, no sap-smartcardsupport (but MS). base.xml is modified
sapcryptolib' of 'rfc2256' (default) specifies schema for order and keywords of name components
'99% of the day' SAP GUI with NWSSO with username/passwort are running fine as well as sapgui with smartcard/pin-logon. But 10 times a day a 'PKI aware software' crashes (sometimes) and/or sbus.exe stops working with logentries in application eventlog.
Our setup is completely as per X.509 Best Practice guide, no non-standard customisation, no external PKI etc.
It all works apart from Internet Explorer crashing - this happens when user is not even using SAP - but of course they do have Secure Login Client installed and user certificate issued to them.
We also seen sbus.exe crashes as well but not as much as Internet Explorer.
I hope the experts can help with this.
"arghh" - some of our installations have been 1.0.sp3 and caused crashes.
Now 1.0sp4 is running, and we are watching what's happening.
Other peeple do too: "we did some deep analysis in our implementation, and found a few
places which could have caused the reported issues."
Actually we are facing some issues while working with different profiles (smartcards) on clients in the lab. Selecting a different profile in Secure Logon e.g. from 'me' to 'metoo' and logging on to Secured Applications raises the PIN-dialogue of our csp provider (csp+) twice. Some other people are reporting they were asked to select the profile twice (with only one PIN-dialogue later on). So we are now working on 'credential' cashing/flushing in the csp.
Anyone who experienced the same?
please get the latest update from the market place: Secure Login Client 1.0 SP04 PL02, which was published right now.
It comes with fixes in certificate store provider and component communication, which caused crashes of applications using Windows certificates as well as of SLC itself.