Skip to Content


You must be Logged on to comment or reply to a post.

    1. Matt Fraser Post author

      Hi Lutz, and thank you for your comments and the links to those discussions. You do raise an important point.

      I haven’t yet found documentation to indicate at what release and SP levels the AS Java will support AES (I know that Active Directory with Windows 2012 DCs will), so until I know that I hesitate to document the process for others. One of the discussions you linked is talking about BusinessObjects, which is a different beast, and so it’s not necessarily a translation across to AS Java. However, you are quite correct that AES is more secure than RC4 (and considerably more so than DES).

      The only blogs I was able to find about configuring the SPNego SSO for an AS Java before writing this one still recommended enabling DES, as below the SP levels I mention in this post that was apparently the highest encryption that the “old” SPNego would support. Much of the older documentation floating around on SCN and SMP still advises to do this. So, I’m hopefully at least disabusing people of that notion.

      Over the next few weeks and months I will be doing further experimentation with our own servers, both to determine a working method for mismatched AD<->SAP usernames, and to validate that AES encryption can be made to work with NW 7.01 (I don’t like to blog about anything I haven’t actually done myself in “real life”). Meanwhile, I’m hoping that here I’ll have clarified a few misconceptions that may be floating around out there (that I myself had, until I embarked on this project).

      Doing so should help with clarifying some of the questions you raised in your discussion thread, i.e. what limitations are imposed when restricting the algorithm to AES, and just how does Kerberos negotiate which algorithm to use. From documentation I’ve read, Kerberos should negotiate between client and server to identify the highest common supported algorithm, in which case if the server supports DES, RC4, and AES, and the client supports RC4 and AES, then AES should in theory be chosen. However, that will take some testing to validate. If true, and a downlevel AS Java only supports up to RC4, but AES is enabled on the client (via the AD service user), then SSO should still work even though the negotiation will result in RC4 being chosen.

      On a side note, although 95% of the workstations in my organization are now running Windows 7 (and only just — it was about a four-year project to get 20,000 PCs upgraded), I still have a very small handful of XP clients out there. Thankfully I think it’s down to numbers I can count on my hands (perhaps just one hand), but there it is.

      Once I’ve confirmed that AES works in my environment, I’ll update the blog.

      Thanks again, and I look forward to further discussions!



      1. Lutz Rottmann

        Hi Matt,

        I am really glad that you did a refresh of this subject, because most stuff on this subject is very old indeed.

        AES for SPNEGO on AS Java was introduces by note :

        • NetWeaver 04 (6.40) SP27
        • NetWeaver 04S (7.00) SP23
        • NetWeaver 04S EhP1 (7.01) SP08
        • NetWeaver 04S EhP2 (7.02) SP06

        AES should be no problem with Windows XP as long as it is SP3 and the AD is 2008 or newer according to this:

        Unfortunately I have no XP system left so I am not able to verify.

        I would be glad if we could all collect more facts about compatibility and incompatibility of AES and Kerberos/SPNego. My impression currently is that rollout of AES is typically prevented based on rumours. SAP’s product management is also adding to this unspecific rumours when questiones instead of communicating facts.



        1. Matt Fraser Post author

          Thanks! That’s what I was looking for.

          Yes, I suspect the information may be somewhat buried because of a general push of customers toward the separately-licensed NWSSO product. But of course, I would never suspect this of being intentional!

        2. Matt Fraser Post author

          It turns out that AES encryption for Kerberos tokens requires NetWeaver 7.20 or higher (SPNego Kerberos Authentication – SAP Netweaver Application Server Java – SCN Wiki) (Note 2218506). It is possible to enable AES128 and AES256 for the service user in AD, and doing so has no adverse effect on the existing SPNego implementation. You can also regenerate the keytab file and see in the contents of the file that the new encryption protocols are included (note that you need the “unlimited” JCE policy files in your JRE to generate AES256 keys). However, when you go to upload the new keytab in the SPNego Wizard, only the RC4 key will be available to import.

          In my example here, I am enabling SSO on a NetWeaver 7.01 AS Java system, so RC4 remains the best option, unfortunately. Nevertheless, for those with portals on a higher NetWeaver version, I would strongly encourage you to turn on AES and use it.

  1. Former Member

    Hello Matt,

    thank you for this detailed documentation. I am trying to configure SAP SSO 3.0 for SPNEGO to a SAP Portal with own user store.

    You wrote “At a later time I will follow up with a blog about how you can set up SSO to work for mismatched usernames as well”. I am looking for a documentation of this. The Guide “SecureLoginforSAPSSO3.0_UACP” is not very detailed at this point.

    Can you recommend further documentation?

    Best Regards



    1. Matt Fraser Post author

      Hi Andreas,

      Unfortunately, I never did get to writing that follow-up blog about mismatched usernames, as I never did get around to configuring that in my organization. As so often happens, other priorities took over. The areas of interest that I planned to research and experiment with involved finding a way to have a mix-and-match of username-matching and email-matching. In the end, it might become purely email-matching as a replacement for username-matching.

      In addition, another follow-up item for me is to move away from the obsolete RC4 encryption algorithm and up to AES256. Since the time when I wrote this blog, I have upgraded our Portal to NetWeaver 7.5, so the incompatibility I encountered (and mentioned in comments above) should now be a non-issue. One nice point is that the upgrade itself did not break anything in the SPNEGO configuration; it just kept on working without any particular effort on my part.

      If you get this figured out, please do come back and let us know what you found.



Leave a Reply