SSO with SPNego not working on Windows 7 / Windows 2008 R2
The Single Sign On (SSO) solution via SPNego is quite popular now on the J2EE Engine. It is not only used very often in Portals or other SAP Applications, but also a popular way to achieve Single Sign On to BSP pages from Duet’s Action Pane.
The SPNego Wizard that is available makes the configuration quite easy now. Additional there is a great support in the forums and via Configuring and troubleshooting SPNego — Part 1. 🙂
Unfortunately the number of issues regarding SPNego increased in the last few weeks. Often when a customer is running Windows 7 or is using Windows Server 2008 R2, SSO stops working.
As you might know the SPNego solution used by the 7.00 & 6.40 AS Java is based on Java 1.4.2. Unfortunately Java 1.4.2 does only support the DES Encryption type for Kerberos (that is why you have to set the “User DES Encryption” flag when creating your SPNego Service user).
With Windows 7 and Windows 2008 R2, Microsoft decided to stop supporting DES Kerberos encryption by default. This is all documented in a TechNet article (Update: Microsoft has also published a KB explaining this topic: The security principals and the services that use only DES encryption for Kerberos authentication are incompatible with the default settings on a computer that is running Windows 7 or Windows Server 2008 R2). We also have a note available that points out the issue: Note 1396724 – SPNEGO fails with Windows 7 and Windows Server 2008 R2
Our develeopment is already working on a new SPNego login module so that you will not have to change anything on the client. However, until that is ready and tested I want to show you the steps that you need to perform in order to get SPNego working again on the affected clients.
First take a look at a fresh Windows 7 installation. If I call a portal page that was working before with SPNego I do get an error messages 401 Unauthorized.
A closer look with Wireshark reveals why this is the case. We can see the TGS Request for several Kerberos encryption types, but the required DES_CBC_MD5 is not there.
So logically instead of the Kerberos ticket we get an error:
Since now the client cannot send a Kerberos ticket to the J2EE Engine usually it defaults back to NTLM. In the Configuring and troubleshooting SPNego — Part 3 you will then see entries like this:
NTLM token found in authorization header during SPNego authentication.
As a result authentication via the SPNego login module fails.
In order to get SPNego working again we have to enable DES_CBC_MD5 encryption. Start GPEDIT.msc on the Windows 7 client (of course this can also be done centrally on the domain controller and rolled out to all Windows 7 clients)
Then go to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options [sorry for the German screenshot, but I hope you get the point where it is located]
Double click on “Network security: Configure encryption types allowed for Kerberos” and select (at least) the entry DES_CBC_MD5 which from now on allows Kerberos tokens that are encrypted with DES_CBC_MD5 (in order to prevent issues with other applications you might want to consider to enable all other encryption types as well or at least the ones that were active by default before).
Finally you should restart the client and try to access your SPNego enabled AS Java again — and it should work:
If you take a look at a Wireshark trace again you can see that the TGS Request contains now the previously missing DES_CBC_MD5 encryption type:
And of course with that we get a valid ticket which can be used for authentication
I hope this helps a little in order to get your Windows 7 / Windows 2008 R2 clients up and running again. Feel free to check the note 1396724 mentioned above in order to see when we have a final fix avaialable.
The new Login Module for 640 and 700 is here. Go to https://service.sap.com/sap/support/notes/1457499 and download the attached ZIP files. It also includes a PDF with installation instructions!
Also, this login module supports DNS discovery of AD domain controllers using AD site configuration, and canonical principal names, as well as Unicode principal names and passwords.
The above mentioned login module is SAP certified by SAP ICC.
Changing Windows 7 to enable DES is not a good solution.
Could you please give more details on the login module? Also it would be great if you could tell us why enabling DES is not good solution.
Nirmal sivakumar G
You can find out about the login module at http://ecohub.sdn.sap.com/irj/ecohub/solutions/trustbrokeradapter
- it is included with the TrustBroker Adapter product described on SAP EcoHub, which also includes other login modules to support other AD user authentication requirements.
Reasins why DES is not good:
1. It is not the default in AD, and Microsoft prefer RC4 (the default etype for accounts) or AES if you are using Windows Server 2008 version of AD
2. There are bugs in AD related to use of DES which MS will not fix becuase they prefer customers to use RC4 or AES
3. All implementations of Kerberos are having DES removed gradually, and this is why MS decided to remove DES from the etype list in the AS-REQ and TGS-REQ when using Windows 7 and Windows Server 2008 R2.
4. Kerberos DES ciphers are considered weak, compared to RC4 and AES ciphers.
BTW. The login module being discussed, also uses a computer account for the service principal keys so that the account is not subject to denial of service attacks. With the SAP documented method of creating the keytab (and service account) using ktpass.exe, the account can be subject to DoS attack because it is a user account.
I absolutely agree that enabling DES on Windows 7 is only a workaround. But if you have been using the standard SPNego login module (which used DES encryption all the time) than there should not be a negative impact from a security point of view.
I would also recommend to switch to a SPNego login module that does support RC4 encryption (which hopefully will be the case with the new SPNego login, development is currently working on) – especially if you are running only Windows 7 and an Windows 2008 ADS.
I have to admit that I was not aware of your login module. Maybe you should do some more advertising 🙂
I can guarantee that if I was given access to a customers network who has the SAP SPNEGO login module installed, I can cause a denial of service so that their SAP system will not start and their users cannot logon anymore. This is very easy to do and doesn't require any additional software 🙂 for obvious reasons I will not give the details here.
This is why there are alternatives available. The SAP EcoHub is there for customers to find partner products - you just need to visit the SAP EcoHuba nd search for SPNEGO.
I'm migrating the portal from Windows 2003 server to Windows 2008 (not R2). The AD server and client remain unchanged. The single sign-on does not work after migration. Would it be the same problem with Windows 2008 R2 (no support of DES encryption) or any other problem ?
this should not be related. Can you check the diagtrace log like mentioned here Configuring and troubleshooting SPNego -- Part 3
Does it show any error why SSO is failing?
Maybe re-running the SPNego-Wizard resolves the issue.
Just stay tuned 🙂
If you remember, I replied to your blog before and explained that we already have a login module which we sell to SAP customers, and it supprot RC4, AES and DES as well as many other AD features, and works with JDK 1.4.x. I am therefore interested to know how SAP are doing same. It will either be using another native Java Kerberos implementation, perhaps the one originally from Wedgetail corporation, or use the JNI to use an operating system Kerberos library (this is what our product does).
Maybe you can contact me offline if you are able to share this information, but not on this blog.
Are you aware of new issues with SPnego this month, since April 15th?
We have all these settings in place, used to work for everyone, but now several users are generating SPNego: NTLM ticket was sent. Other users can logon with no problem.
Though this has worked for them in the past, for few months, without any problem. There are no updates installed for Internet Explorer, Windows Integrated Authentication and the DES settings are applied and active using GPO. We have this behavior on XP's and Windows 7 clients. Authentication to Windows ASMX webservices goes well.
did you check the Diagtool? What error are you getting? Maybe a WireShark trace could also help to narrow down the issue.
Not sure if this is related (and the KB is definetly older than April 15th), but since I just saw this issue at another customer, can you check http://support.microsoft.com/kb/968389
Thanks for the info. This setting has unfortunatly no effect on Windows 7, according to an earlier call with Microsoft.
I opened a ticket at SAP support with High priority.
The weird thing is, the user I was investigating yesterday has no problem today, but now several others have. It's driving me insane.
I really hope the new LogonModule will be released soon, as we block more and more hotfixes and it's not a good idea to do this.
I tried to config the SPNego for our portal 7.01 SP08 with the new method. But it failed. The trace file only shows warnings, no errors. How can i tell what's wrong with it? It did show the warning of NTLM received. But i checked the IE settings, it is correct. What else i can check?