Skip to Content

Unlashed: Kerberos ticket based single-sign-on with SAP J2EE engine

[ | ]
Yes! I heard some of you saying, another Kerberos blog. My blog will add to the information available through various sources like SAP help, SDN blogs, discussions and SAP notes. You can use this as starting point if you are new and planning to implement Kerberos based authentication with SAP first time or as a reference to know more about it and how it works.

I am arranging the blog in multiple sections. I suggest you to read / glance them as they appear for better understanding, but feel free to jump to any section of your interest.

My environment is based on Windows 2003 functional domain, IE, SUN JDK and J2EE NW04s. J2EE is clustered and we have multiple servers running KDC. I will add references to SAP notes, help, blogs and discussions and provide you tips so that you can avoid common mistakes and easily trouble shoot issues.

Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  

Few terms used in Kerberos world (In this context):


Was created at the Massachusetts Institute of Technology in the early 1980s!! Current version of Kerberos is version 5. Windows 2003 implements it as Security Service Provider (SSP). In fact, SSL and NTLM are also implemented as SSPs by Windows. Kerberos is now default distributed security protocol in windows environment, though NTLM is still supported as fall back mechanizm. If you want to know more about Kerberos please read following article . Be advised that Microsoft implementation is slightly different and classes which are used on SAP J2EE side are even different. Read it for general understanding of Kerberos. If you are skipping this article, key thing to remember about Kerberos is that it is based on private key mechanism against well known public key mechanism, with which you might already be dealing during SSL etc.

SPNego: The SAP Web AS Java enables you to use the Simple and Protected GSS API Negotiation Mechanism (SPNego) to negotiate Kerberos authentication with Web clients, such as Web browsers. In Simple terms it means that Kerberos token received by client to access J2EE resources, is bundled in SAPNego token which is exchanged during first communication from client under challenge and response cycle, for any protected resource.

KPN, UPN, SPN, User etc: Any principal which takes part in Kerberos world have to have Kerberos Principal Name. Each J2EE instance (SID) can be represented by one user in active directory (Yes one SID and not one server – Thanks to the implementation of SAP part). This user is called service principal. servicePrincipalName and userPrincipalName attributes of this user are key directory attributes which take part in Kerberos world.

Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  

How it works:

Quick: When client requests for a protected resource from J2EE engine which is properly configured, engine requests from Kerberos ticket. If client has not acquired the ticket earlier for this J2EE engine, it does so with the help of KDC now, and then passes the ticket rapped in SPNego token. J2EE finds this token and takes out user’s principal name in series of steps and then the logon name with configured logic. Logon succeeds, if this logon name matches with one account of configured UME datasources.


  • At successful logon to his/her desktop against the domain controller running KDC, a user gets TGT or ticket Generating ticket.
  • User has to request some protected resource from SAP J2EE with a GET request, for next action to happen.
  • Authschema.xml decides which authentication-template / login module stacks will be applied, Now for UME based authentication. By default it will be “ticket”.
  • SAP J2EE Engine sends back a 401 response code with a http header variable “WWW-Authenticate: Negotiate”, if you have configured SPNego module correctly!! (Yes that is the purpose of this article)
  • SAP J2EE reads its own service principal details and mainly gets hold of keytab file containing its key (private key). This happens only once after the restart of J2EE engine.
  • Next few steps happen outside SAP J2EE. You need to confirm that KDC can generate a proper ticket for client and SAP J2EE server combination. This ticket is generated with SAP J2EE server key and which is based on password of service user of J2EE engine. You can use klist.exe or kerbtray.exe tools to confirm this. If you have problem you have to locate that from client side.
  • Client sends a ticket (Kerberos if successful to get, or NTLM) packed within SPNego token to SAP J2EE.
  • Keep in mid that client (IE) settings must be correct for earlier two step to complete properly.
  • J2EE engine searches for Kerberos ticket, if one is not present SPNego module fails. Next modules in stack will decide further process. It can be header variable module or basic password based module.
  • J2EE takes out SPNego mech token. Can any body add what is it?
  • In next few steps it applies its own (service principal) key and takes out Kerberos Principal Name (KPN) of the client from the ticket which, is like User@COMPANY.NET.
  • J2EE will verify KPN or part of this with its user store to match and decide user account. This happens based on resolution mode you configured in SPNego module.
  • Now onwards, normal logon procedure starts. For example generating SAP Logon ticket or in case failure falling back to basic or any other authentication module in the stack (ticket).

Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  

Preparation and must do: Part of this is specific to windows KDC

  1. I am not including anything required to setup KDC itself as that is out side the scope of this article.
  2. Make sure you use all characters in upper and lower case knowingly. Case matters in Kerberos world. Keep this telling to operations if they are doing some of the tasks for you.
  3. Almost in all cases our J2EE engine will be clustered instance. So select a name of the service user which does NOT contain hostname (of server) but contains SID of SAP J2EE. For example xyzj2ee assuming XYZ is SID.
  4. Take your time; decide a userPrincipalName for this user which will be of the form host/ Syntax and case are very important. Make sure that this entry is not configured against any other service user of any other SAP J2EE engine. This may be quite possible if your sid is something like J2E. This entry will automatically appear in servicePrincipalName when you complete configuration step.
  5. Take your time; decide servicePrincipalName. You need to consider all the URLs, which user may use to access any of the SAP J2EE host. This condition is specially true If you are going via some proxy or load balancer between Client (IE) and server (J2EE). You must add entries which resolves through DNS in windows environment (that mean they are CNnames)
  6. Make sure you do not select the same entry for more then one service user. So if you have more then one instance running on one host and use different ports, you have to make adjustments in the URLs. If you do not stick to the requirement then Kerberos ticket will not be issued for that double entry so obviously SSO will fail. Come up with a list like this (You can see case in server part does not matter)
      1. HTTP/
      2. HTTP/
      3. HTTP/
      4. HTTP/
      5. HTTP/

Half of the problems can be avoided if you can correctly select these entries for your environment, and believe me these are hard to detect.


Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  

Outside J2EE

Before you start you should make sure that you refer the prerequisite section. This is also the main SAP help link on the subject.

Confirm that browser settings are correct FireFox fans can refer this article.

Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  

Now you are ready with xyzj2ee.keytab which represents your J2EE instance XYZ on directory server via service user xyzj2ee.

Create a directory common to all hosts where you will keep Kerberos related files. For example

    1. Copy xyzj2ee.keytab file here.
    2. Confirm that the JDK used by J2EE can understand this keytab file with the command klist -e -f -k -K D:usrsapxyzSYSglobalkerberosxyzj2ee.keytab. Output should look like (KVNO changes if you change say password)


     Key tab: D:usrsapxyzSYSglobalkerberosxyzj2ee.keytab, 1 entry found.

      Service principal: host/


Key type: 3

Key: 0x64c8a494e9bf623e

At this time you may like to refer kerberos implementation with ADS made easy, for details and screen shots. Refer details to be configured below.

Create krb5.conf file here with following content. You can change name if that helps. This is very important file to tell J2EE about KDC so be careful especially with case. Find good details and explaination on kerb5.conf.</li>


default_keytab_name = //server/sapmnt/XYZ/SYS/global/kerberos/xyzj2ee.keytab

default_realm = COMPANY.NET

default_tgs_enctypes = des-cbc-md5;des-cbc-crc

default_tkt_enctypes = des-cbc-md5;des-cbc-crc

dns_lookup_kdc = true






admin_server = KDC1. COMPANY.NET

default_domain = COMPANY.NET




Add following JAVA parameters to all of you server nodes. You can use configtool for this.

    1. Make a copy of dataSourceConfiguration file which you are using ( value of ume.persistence.data_source_configuration) for LDAP source and make following changes. You should use config tool in direct edit mode and navigate to cluster_data -> server -> persistent -> After making changes upload file with some different name like dataSourceConfiguration_ads_readonly_db_with_krb5.xml. Make sure every thing is written in lower case!!.

I suggest you include all three parameters because this will enable you to use any of the resolution mode (explained latter).

     You will find that my settings are similar to as detailed Windows Integrated Authentication via Kerberos on an LDAP data source.</li>

Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  

SAP J2EE – LoginModule

  1. Create Krb5LoginModule login module based on class This you can do with visual admin -> Security Provider -> User management. Change to Edit Mode. Navigate to Manage Security Stote -> UME User Store.
  2. Make sure that you have SPNegoLoginModule login module based on class
  3. Create a new policy configuration named and populate it with following details.
  4. First Level REQUISITE
      useKeyTab true
      debug true
      doNotPrompt true
      storeKey true
      keyTab //server/sapmnt/XYZ/SYS/global/kerberos/xyzj2ee.keytab
      principal host/
      useTicketCache true
    Second Level OPTIONAL krb5principalname

To know details of these parameters their meaning and possible values see Class Krb5LoginModule documentation.

    1. Now it is time to modify main logon stack. In this example it is “ticket”. SPNego login module needs to be inserted after SAP ticket evaluation module. If you are using SSL certificate you may want to keep certificate module as second. Your modified stack should look like this.

BasicPasswordLoginModule  REQUISITE  OPTIONAL

    1. Set the properties of the module like this.

       1  prefixbased  kpnprefix  host/  true

    1. You can configure following resolution modes to determine the user account from the KPN: (In my case only prefixbased worked)
    1. none – for this mode, the User Principal Name (UPN) attribute in ADS is identical to the KPN. You can use this mode if you did not configure an alternative UPN suffix in ADS.
    2. simple – This is the default mode when the KPN is an ADS attribute other than the UPN.
    3. prefixbased – For this mode, the UME searches for a user based on the KPN prefix. The algorithm works as follows
        1. KPN is in the form of User@CUSOMER.NET
        2. SPNegoLoginModule splits the KPN into the parts User and CUSTOMER.NET, and performs a search in UME for a user with kpnprefix=User (Which is samaccountname in my example). If the search result is unique, then it is returned as a logon user id to the UME.
        3. If the result is not unique, SPNegoLoginModule uses the user’s attribute distinguishedName to exclude from the search those who are not in the domain CUSTOMER.NET.

    1. Once you are ready with login module restar your J2EE engine.
    2. Try from properly configured client (Use IE for first test) with one of the URL matching with SPN entry.
    3. If it works, Enjoy; else take a break. Check your settings once again. If you still have problem check next section for some tips.

Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  


  1. As I said earlier make sure that you are getting ticket for the J2EE engine with the help of klist.exe or kerbtray.exe tools.
  2. Use visual administrator to change location and change severity to info. This will give you very good view what is happening on J2EE side. You may want to restart engine if you suspect J2EE engine is not able to get hold to its own key.
  3. Two blogs which I have maintained in configuration section (and mine if you agree) contans some good points and leads to good discussions on forum.
  4. Client settings are quite different, if you are using firefox. look for details in one of the blog.
  5. Search SAP notes with SPNego search term. There are only twelve right now.
  6. There is one configuration wizard available.
  7. One very recent SAP note talks about down porting of J2EE engine’s negotiation challenge behavior.
  8. If login fails and you get double logon screen another SAP note available.
  9. One of the sap notes defines how to collect inputs for SAP if you can not resolve the issue.

Start   [Terms Used | #TU]  [How It Works | #HIW]  [Preparation | #MD]   (Configuration&nbsp[Outside J2EE | #C_OJ2EE] [UME | #C_UME]&nbsp[Logon Modules | #C_LM])  [Tips | #TOP]  [End | #END]  

At the end

Please let me know if it helps. One of my colleague said it is too lengthy. Is it?

You must be Logged on to comment or reply to a post.
  • I think you need to stress that the configuration wizard is a major improvement over the manual tasks. Unless there are very good reasons to not use, then its use should be encouraged.

    Yes, automating a process without understanding the fundamentals can lead to a quicker way to mess things up, but as the wizard removes a lot of the messy typing in the Visual Administrator it is worth using.


    • If your binding to AD must you use userprincipalname ?

      Can you use any attribute in AD ?

      We have a userprincipalname that changes as its a concatination of department, section, initial and surname with domain….

      If we bind to this as part of the token, it might change… but we do store employeeID in ’employeeID’ in AD and this is constant

  • Thanks for the Blog Ashutosh!

    We are planning to implement Windows authentication but we are wondering how would SSO with windows behave for open/shared computers. Would the user be challenged to login using username/password then?

    Also, if I want to login to the Portal on someone else’s computer, how can I do that? Can I set up something like two urls, one for SSO and another prompting user credentials?


    • If you login to a shared desktop with an account that account will be taken for login. If you do not login with domain account, then you do not have ticket and based on rest of the logonStack userid and password screen will appear.

      Even if you login with domain account, you have ways of loging in with different ID on portal, for Example Administrator. Either use URL which is not configured as SPN (So have two URLs) or change your browser settings for that brower session so that it does not take part in windows integrated authentication and does not forward token. You be presented with logon screen.

      Hope this explains.

      • You explained it very clearly. But I would like know whether SPNegoLoginModule stack will prompt for the Domain authentication or not? Will authentication will be taken care ONLY by the next logonstack like BasicPasswordLoginModule.

        Actually my problem is that I am using an AD attribute as user ID in portal (j_user and employeeNumber mapping). So if prompt comes from SPNegoLoginModule stack then I have to give AD user ID (samaccountname) and passsword. And if it comes from BasicPasswordLoginModule stack I have to give EP user ID i.e. employeeNumber and password same as of AD.

        So we will have to educate user to give employeeNumber as user ID and password of AD when they get prompt for BasicPasswordLoginModule on shared computer.


  • Hi,

    nice Blog, I don’t think it’s too long. Where would you want to shorten it anyway? It’s some complicated stuff, but cool explanation

    You can create a portallauncher iView (based on component) using a different authscheme (only UID / Password) and call this via a different URL.
    At the moment we are even trying to build a redirection login module and add it to the SPNego stack in case the Kerberos Authentication fails.

  • Hi Ashutosh,

    Wanted to check regarding the experience on SSO based on this configuration. I am referring from a performance perspective. Also are there any errors. for Microsoft IIS, this works seamlessly as all the products are from the same stack. But in this case, because of integration at different layers, have you seen any noticeable issues?

    We have configured Weblogic Server with the Microsoft Active Directory using a similar procedure but many times, we see that there are issues pertaining to autentication performance, SSO not working, etc.

    My email id is


    • performance wise it looks better. Probably because we could avoid one proxy.

      Support and problem solving front it can be more involved. We have used MS ADS and desktops are XP etc so the complete kerberos solution is microsoft based. I will say getting a ticket for NW server is then a completely separate process involving products from one client.

      I have not seen any issue once set properly, if you get kerberos ticket. I would like to add that this verification part is supplied from SAP so nedded support should be available.

      Best regards

  • Integrating J2EE users with Kerberos is explained as it was meant for. I have comments upon this
    1. How about Unix users can be integrated,
    2. How unix users can be stored in Windows AD.
    Whether we have to follow another Protocol for the above,
    because our portal implementation was on Sun Solairs, and our email client is Out look, we are planning to Implement SSO for Exchange server and Sun Solaris.
  • Hi,

    Our portal are configured with spnego with single domain, now i configured multi domain and wizard based spnego configuration and we have a remote role assignment on our consumer portal we are prompting the login screen while accesing the reports and I can see two key tab files with two diffrent dates , My questin is how the keytab will work? i’m prompting login screen while accesing producer portal?

    plz help me…

    thanks in advance

  • For an environment where the SAP Gui and the SAP back-end systems are both running on the Microsoft Windows platform, we are considering using Kerberos to achieve SSO.  Do you have any experience where BOBJ (EQRA) tools are utilized within the SAP Landscape?  In our proposed integration approach, two sets of user accounts and roles (Windows & ECC) must be maintained and mapped to secure the solution architecture. Additional roles/user groups in Microsoft AD other than “SAP BI, SAP ECC6.0, CRM” need to be provisioned during deployment process.

    Thanks for any comments,