Blogs
|
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 SSO to ABAP systems.
The SPNego Wizard that is available makes the configuration quite easy now. Additional there is a great support in the forums and via blogs. :-)
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 Diagtool trace 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.
Holger Bruchelt is working in the Duet Regional Implementation Group in Germany. Before that he has been working as a technical NetWeaver consultant since 2002.
Add to: del.icio.us | Digg | Reddit
| Showing messages 1 through 8 of 8. | ||
|
|
||
| Titles Only | Main Topics | Oldest First |
- any problem with Windows 2008 server
2010-01-07 18:04:47 Bonnie Ka Wai Lam Business Card [Reply]
Hi Holger,
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 ?
regards,
Bonnie- any problem with Windows 2008 server
2010-01-08 13:16:47 Holger Bruchelt
Business Card
[Reply]
Hi Bonnie,
this should not be related. Can you check the diagtrace log like mentioned here http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/8313
Does it show any error why SSO is failing?
Maybe re-running the SPNego-Wizard resolves the issue.
Regards,
Holger.
- Better options available already !!
2009-11-06 00:28:01 Tim Alsop Business Card [Reply]
I already have a login module which implements SPNEGO for Integrated Windows Authentication, and it support RC4 and AES (for Windows Server 2008 domain controllers) and does not just support DES like the current SAP supplied SPNEGO login module.
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.
- Better options available already !!
2009-11-06 01:06:03 Holger Bruchelt
Business Card
[Reply]
Hi Tim,
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 :-)
Regards,
Holger.
- Better options available already !!
2009-11-06 01:25:51 Tim Alsop Business Card [Reply]
Holger,
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.
Thanks,
Tim
- Better options available already !!
2009-11-06 00:50:02 Nirmal Sivakumar G
Business Card
[Reply]
Hello Tim,
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.
Thanks,
Nirmal sivakumar G- Better options available already !!
2009-11-06 01:20:33 Tim Alsop Business Card [Reply]
Nirmal,
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.
Thanks,
Tim
| Showing messages 1 through 8 of 8. |