Are we the only group that has Vintela SSO configured with Kerberos encryption on Windows servers and whose client PCs using Internet Explorer have started to display HTTP Status 500...Channel binding mismatch? We see NOTHING on the web or in any of the forums on this. Client PCs effected have the Microsoft Updates of 10/13/09 applied (especially KB974455).
- Business Objects Enterprise XI 3.1 with FixPack 1_7
- Windows 2003 Servers for the Vintela and Business Objects Enterprise installation and authentication. On the client side, any version of IE (6, 7, 8) is impacted as soon as the Microsoft Updates are applied (removing KB974455 seems to clear up the problem, but it is a combination of updates that need to be in place for it to occur).
Manual login is not impacted (thank goodness), but we'd much prefer SSO. Suggestions?
I would need tracing information to verify the issue, when updates cause the issue it could be DES which we used to use in XIR2 as Microsoft may be preventing it due to security liability. To trace look at the admin forum sticky post where I have my vintela 3.1 doc. The tracing instructions for vintela (djcsi) are at the end. Also if you upgraded to 2008 DC's there is an SAP note on how this could cause an issue and link to Microsoft patch.
Since the system is in-use, I would prefer not to switch from using the keytab to a straight password to enable tracing -- at least not until the weekend (when there are less users). I assure you that we are not using DES -- I configured it for RC4. We also have not upgraded our DCs to 2008 yet, and the SSO continues to work perfectly for any client PC which has not applied the recent Microsoft patches. If necessary, I will come in this weekend and get a trace for you. Thanks a bunch!
We also have the same issue. Running BO 3.1 with kerberos SSO. After applying KB974455 getting http status 500. Have opened case with support as this is our production envionment. We went live on Monday, patch came out Tueday. Great timing eh?
Any help would be appreciated.
A similar phenomenon is caused in the our environment .
We use EP of the SAP.
I realized SSO which used kerberos between AD and EP.
However, I was not able to use SSO when I applied Microsoft update KB974455.
The version of the OS of our client PC is windows XP Professional SP3.
Because Microsoft update KB974455 is a patch preventing serious security, I want to apply it.
However, I am troubled with SSO because I want to continue using it.
If there is a solution, please show me it.
...from the following forum thread, it looks like perhaps the next update for Java might help:
...but I don't suggest disabling the Microsoft patch through the registry key edit -- kinda defeats the purpose, eh?
looking at the patch details I can't see what's happening. My guess is that it's either changing IE settings or IE SSO behavior (since the patch seems to refer to only IE stuff). It is very likely that at least kerberos SSO will also be affected as they both use spnego. NTLM may be ok but who knows.
I did not get a chance to test this today so we'll have to see next week. It sounds like this could be a serious issue so create cases if you can.
Also see the following SAP notes 1379894 for IE rules for configuration or 1245342 for manual logon instructions or 1263764 for firefox (kerberos) SSO instructions.
Looking at the initial findings it looks like this may need to be escalated to Microsoft
The update in Microsoft Knowledge Base Article 968389 modifies the SSPI in order to enhance the way Windows authentication works so that credentials are not easily forwarded when Integrated Windows Authentication (IWA) is enabled.
When Extended Protection for Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server the client attempts to connect to and to the outer Transport Layer Security (TLS) channel over which the IWA authentication takes place. This is a base update which enables applications to opt in to the new feature.
Future updates will modify individual system components that perform IWA authentication so the components use this protection mechanism. Customers must install both the Microsoft Knowledge Base Article 968389 update and the respective application-specific updates for the client applications and servers on which Extended Protection for Authentication needs to be activated. Upon installation, Extended Protection for Authentication is controlled on the client through the use of registry keys. On the server, configuration is specific to the application.
This is probably red-herring material. I could not find the reg keys and MS says they'd be disabled on default anyways.
Edited by: K Joyner on Oct 19, 2009 8:49 PM
We haven't applied the 10/13/2009 patches yet (but intend to do so this weekend) - and have a couple of questions...
1.) Does this effect all the "flavours" of Enterprise 3.1 (eg. Crystal Report 2008 Server, Business Objects Edge 3.1) - or is it Enterprise 3.1 specific...?
2.) Does it effect WinAD SSO into both the Java (Tomcat) and .Net (IIS) InfoView applications - or is it specific to a certain web-platform....?
Thanks in advance!
1.) We do not have Crystal Report 2008 Server, nor Business Objects Edge 3.1 -- we can only attest to the impact on Enterprise 3.1 logins.
2.) We only use the Java (Tomcat) portion since the .NET/IIS stuff is being phased out.
So, basically, I can't answer either of your questions. Sorry.
we have the same problem: we have realized SSO between EP and AD. Before installing KB974455 the integrated Window Authentification worked fine. Now, with KB974455 we get the following exception:
org.ietf.jgss.GSSException, major code: 1, minor code: 0
major string: Channel binding mismatch
minor string: ChannelBinding checksum failed verification
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Client: Windows XP SP2, IE 7.0.5730.13
Server OS: Linux (amd64) 126.96.36.199-0.33-smp
ADS LDAP: Windows 2003 Server
SAP Version: NetWeaver 7.0 SP18
JDK: j2sdk1.4.2_16-x64, IBM
With Firefox the IWA works still fine.
What can we do to fix the problem with IE?
We are also experiencing Kerberos SSO error with SAP EP and AD after our client PC is patch with Microsoft KB974455.
The error is as follows:
1.5 #001B24EFE9E200210000016800000D500004763EB54C644D#1255911608619#com.sap.engine.services.security.authentication.loginmodule.spnego. SPNegoLoginModule#sap.com/irj#com.sap.engine.services.security.authentication.loginmodule.spnego. SPNegoLoginModule#Guest#0####2883dfb0bc4511dea0ae001b24efe9e2#SAPEngine_Application_Thread[impl:3]_ 33##0#0#Error##Java###CreateContext failed: GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)
#1#GSSException: Channel binding mismatch (Mechanism level: ChannelBinding not provided!)
Server : Windows 2003 SP2
Client PC : IE 7.0 and IE8.0
Client PC OS : Windows XP Professional SP2.
Any help on the resolution would be greatly appreciated.
We have raised this issue with Microsoft and I have provided the solution to them.
Microsoft have reverted and provided some information on the registry setting :
0x00 u2013 Enable protection technology.
0x01 - This makes the client appear unpatched to remote servers except in cases where caller of SSPI on the client provides both a channel binding token and a target SPN. The security implication of setting this flag is this: it makes clients that do not use channel binding correctly, and clients that do not go over SSL vulnerable to authentication relay, even to partially hardened servers.
0x02 - This makes the client set Kerberos channel binding value to zero even if calling application correctly supplies the value. In our issue, IE 7 will not use the extended authentication in Kerberos authentication. 0x02 has no effect on NTLM.
0x03 - Combination of 0x01 and 0x02. It disables channel binding always for Kerberos (0x02) and suppresses both channel binding and service bindings for those NTLM callers that do not supply channel binding (0x01)
Microsoft has recommended to use 0x03 for my case. But in the forum I am seeing Microsoft recommend to use 0x02. So which one to use 0x02 or 0x03?
Oh by the way, both 0x02 and 0x03 setting allow SSO to work successfully.
Edited by: Mike Lee on Oct 21, 2009 11:43 AM
After I go through this Microsoft Article I will update the SAP note.
It appears we have an [official explanation of the feature here |http://support.microsoft.com/kb/968389]
Thank you for providing specifics (Mike Lee) , MS's article below doesn't yet detail more than the "0" and "1" setting.
Edited by: OrlandoS on Oct 23, 2009 2:40 PM
You really need to direct that question to Microsoft as we are dealing with an enhancement added to IE by Microsoft. It's very new and there are some tech net article links to it above in this thread. My best guess is that it disables this enhancement and everything starts working as before. Again that's just my best guess and I do not work for Microsoft.
We are having same 'loss of sso' problem with our EP ESS system with AD.
It worked fine until latest MS patch KB974455 was applied to test group.
As stated in other posts, the patch is desired for security it provides, but sso problems will be substantial headache.
client = MS XP Pro 7.0.5730
server = MS Windows 2003 SP2
SAP version = NetWeaver 7.0 SP 18
JDK = j2sdk1.4.2_19 x64
Would appreciate any news or progress.
This is the fix we got from Microsoft on a ticket we opened regarging failing SSO i Internet Explorer to our SAP Enterprise Portal 700.
Please change the following registry entry on each of the affected users
Add DWORD value SuppressExtendedProtection - 0x02
Hope this helps,
The reg key worked for me after reboot and cache clear.
Question. Is this posted by Microsoft anyplace or can someone who called them for the solution post a reference number?
Knowing my secuity team they're much more willing to break my app with the seciroty patch then they are to install a reg key without some formal looking documentation.
Based on the information in this thread I have released an SAP note 1397872 - Microsoft Internet Explorer patch KB974455 causing kerberos SSO (spnego) to fail
This note is subject to change but considering the seriousness of the situation I thought it best to have something out there. Thanks to everyone who has contributed to the topic so far.
I have not located anything specific from Microsoft (as the note states) but I would expect that something comes out soon. You can open a case with SAP/BO to wait for an official solution or watch this thread and the above note for updates. If you have the capability to open a case with Microsoft then that would probably be the fastest way to a solution.
I agree the solution is risky at this point and more information is needed.
EDIT: the note has been updated at this point we are urging customers to open cases with Microsoft as the issue involves their patch, Internet Explorer, kerberos and spnego (none of which are SAP/BO products)
We were aware that SSO didnu2019t work for SAP using Windows 7. We were not worried about it too much until this week when KB974455 also broke SSO for XP boxes.
Extended Protection for Authentication is enabled by default in Windows 7. Changing the registry keys does not make SSO for SAP work in Windows 7 though. I searched the registry for SuppressExtendedProtection and set each to 1, there were two entries for it. I also added one per the KB http://support.microsoft.com/kb/968389 and set it to 1. Still no SSO from Windows 7. Has anyone else gotten Windows 7 to work with kerberos SSO?
This gave me a workaround for XP client workstations failing to SSO when going to https until we move to XI 3.1 SP3
1. On the client workstation create a new DWORD key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\SuppressExtendedProtection
2. Set the decimal value to 2
3. Clear all browser cache and restart the client workstation
4. After a reboot navigate to https://your-server.domain.com:ssl-port/InfoViewApp/logon/logonService.do
>This gave me a workaround for XP client workstations failing to SSO when going to https until we move to XI 3.1 SP3
Is there a timeframe for Edge Series 3.1 SP3?
And has SAP confirmed SP3 will resolve this issue with IE8?
I'm about to roll out Edge 3.1 to the business and it looks like auto Vintela SSO/Kerberos will not part of the roll out. The SOE guys won't implement this registry hack workaround >.<
We ran into this problem with SSO and SSL too and decided that since the problem affects only the auto login (logon.do), prompting for the login (logonForm.do) was more reasonable than changing the registry. Making the following modifications on InfoView got us going:
1. In the file ...Tomcat\webapps\businessobjects\enterprise115\desktoplaunch\InfoView\default.htm,
change the redirect to location.replace("logon/logonForm.do");
2. In the file ...Tomcat\webapps\businessobjects\enterprise115\desktoplaunch\WEB-INF\web.xml
change the session.timeout.opendoc.redirecturl to /InfoView/logon/logonForm.do
3. If all unsecured pages to be redirected to secure, we also added to the web.xml