Skip to Content

In the Configuring and troubleshooting SPNego — Part 1 I explained how to configure SPNego with the help of the SPNego Wizard. Now, that everything is set up we are going to check the configuration. At first I will simply use some tools (see below to get a summary of tools used) to “verify” the configuration, e.g. I will use the tools but the results will always be OK. I think it is always good to have one working example and then see what is different / what it should look like if you acutally have a problem.
In this blog I will not use the diagtool or Web Diagtool. Instead I am going to concentrate on some basic things you can check on the client before using these tools. So let’s get startet…

For all the screenshots and description I have used the same setup as in Part 1: my user is yange1 and the server is installed on the server vmw2053.wdf.sap.corp.

The server side

First let me show you what the SPNego Wizard has done. Start the Visual Administrator and take a look at Server -> Services -> Security Provider. A new component com.sun.security.jgss.accept was created which contains two LoginModules: Krb5LoginModule and SPNegoMappingLoginModule. Both contain the options you chose when clicking through the wizard. Among other settings the Krb5LoginModule contains the properties of the Kerberos Principal user (service user) and the SPNegoMappingLoginModule the user resolution mode.

image

Then there is also the spnego template which contains the login modules required for a succesful login. The first entry is the EvaluateTicketLoginModule (com.sap.security.core.server.jass.EvaluateTicketLoginModule). The Login module checks whether you already have a valid SAPLogonTicket (in a federated portal scenario this ticket could also come from another portal and if you have chosen to trust this portal then the check would succeed and because of the Flag “Sufficient” you would simply skip the next modules). If the Evaluate did not work, then the next login module will be used: SPNegoLoginModule. This module does the actual SPNego/Kerberos check. The flag is Requisite so that if it succeeds it will continue with the next login module. When this login module was successful then the last login module CreateTicketLoginModule will be executed. This time a SAPLogonTicket will be created so the next time you query the portal the EvaluateTicketLoginModule will succeed right away. (For a more detailed list of what the different Flags mean, please check: http://help.sap.com/saphelp_nw70/helpdata/en/d0/ee244134a56532e10000000a1550b0/frameset.htm)

image

On the file system a new folder has been created under usrsapSIDSYSglobalkerberos. This folder contains the keytab file which allows the J2EE Engine to access the service user (you created in the very first step in the LDAP directory) and the krb5.conf file which contains all the information about the Key Distribution Center, the Realm and the encryption type.

image

Maybe you have started the SPNego Wizard a second time and were wondering why only four configuration steps (instead of five) were available. Just delete the folder kerberos and you can (almost) start from scratch.

If you start the config-tool you can see that the Wizard did also add some Java start-up parameters to the server node. Among them is the location of the krb5.conf file.

image

One last thing (that was not done by the Wizard, but by you) is the dataSourceConfiguration file. This file (if you are using the Microsoft ADS variant) is just an enhancement of the default dataSourceConfiguration_ads_readonly_db file that comes with the J2EE Engine. The new file includes new attributes which are used by SPNego (e.g. krb5principalname, kpnprefix, dn).

The Client side

First of all log on to the client and check if you have Kerberos tokens which can be sent to the J2EE engine. In order to do this, download the tool kerbtray from Microsoft. Kerbtray is part of the Windows Resource Kit and can be very helpful.
After running the tool you can see a small green icon in your task bar. Simply right-click on it and choose List Tickets. You will see your Client Principal in the first line. This name will be used for the lookup in the UME (in the screenshot it is YANG1@DEV16.DEV-WDF.SAP.CORP).

image

Before explaining what is done with this ticket we want to check that a Kerberos ticket and not a NTLM ticket is sent to the J2EE Engine. The easiest way to do this is to use a HTTP Tracer like HTTPWatch. Since HTTPWatch is not freeware you can also use other tools to collect HTTP traffic (if you are going to send log files to SAP Support you can still use this tool and save the full trace which can be evaluated by SAP). A very nice (freeware) tool is YaTT. This tool allows you to easily trace the traffic. Just download it from here and install it on your client. Now start the tool and enter the URL of your J2EE engine as a Name Filter (you can also specify the port).
The tool is collecting the TCP trafic to the J2EE Engine. So start a new browser and access the URL. The first request you will see is a 401: Access denied — which is good! The J2EE engine tells the browser that it requires some kind of authentication. Now the Client can check the Ticket Granting Server (TGS) if a ticket for this engine is available (we will come to this later). When this check was successful the client can sent a Kerberos ticket to the Engine. This ticket can be identified by the starting string YII… [NTLM starts with TIRM…].

image

Now that we have accessed the J2EE Engine check the Kerbtray tool again (in order to see any changes, you have to close and open the tool). You should see a new entry HTTP/yourServername. This means that your Client has requested a ticket for the J2EE Engine on this servername, which it then could provide for authentication.

image

This ticket contains your user name (as seen before YANG1@DEV16.DEV-WDF.SAP.CORP). Since I have chosen prefix based in my SPNego configuration the name will be split in KPN-Prefix=YANG1 and KPN-Suffix=DEV16.DEV-WDF.SAP.CORP and the J2EE Engine will try to search for YANG1 first and if this is not unique will use the suffix information to get a unique user.

That’s it. Now you should be logged in.

Provided that everything is going well, we have the above scenario. However, there are plenty of pitfalls that you might encounter. One problem I encountered pretty often is, that a NTLM ticket but not a Kerberos ticket is sent. This can have plenty of reasons and the first step would be to check help.sap.com
* Enable Windows Integrated Authentication in your Web browser.
* Enable automatic logon in Intranet zone.
* Add the AS Java’s DNS host name to the list of local intranet sites.

 image

image

 image

   

If you did all these checks and Kerberos is still not working try it from another client (just to be sure). Then check Note 934138 where some issues with (missing) Bug-Fixes from Microsoft are deal with (Hotfixes 885887 and 899587 from Microsoft).
If it is still not working, then you will have to do a more detailed traffic trace. I will cover this in my next blog. 

If no ticket is sent at all then you might have to check whether the client is able to find the J2EE Engine in the ADS. In order to setup SPNego we had to create a service user and set certain Service Principal Names to it. If there was a typo or if the name is not unique the lookup will fail. So use the next tool also available from Microsoft (it may be already installed): ldifde. ldifde allows you to query the ADS and search for any attributes.
At first I will try to find the user I created for SPNego. This can be done by issuing the command

ldifde -r (samaccountname=j2ee-j2e-vmw2053) -f sam_output.txt

-r means that ldifde is searching recursivly and -f specifies a file into which the results are written (see http://support.microsoft.com/kb/555636/en for further details).

image

If you take a look at the output file you will (hopefully) see entries like:

sAMAccountName: j2ee-j2e-vmw2053
userPrincipalName: j2ee-j2e-vmw2053@dev16.dev-wdf.sap.corp
servicePrincipalName: HTTP/vmw2053
servicePrincipalName: HTTP/vmw2053.wdf.sap.corp
 

Now that I know that my user was created (and I can see that the ServicePrincipalName (SPN) are set and correct) I want to make sure that the SPN is unique. So I am going to issue the command:

ldifde -r (serviceprincipalname=HTTP/vmw2053.wdf.sap.corp) -f spn_output.txt

It is important, that you will only get the result “1 entry exported“. If you get more than one entry, then open the file and see what other user is using this SPN.
(In order to get other information about a user in the ADS you can use a LDAP browser like Softerra. It is free and I find it very helpful to get a quick overview of your LDAP structure and the user configured.)

image

You might also have a problem, that you are accessing the portal not with the real physical hostname, but with a DNS alias. To check whether you have really added all relevant SPNs to the user do a nslookup on the servername. Make sure that all listed aliases are also added as a SPN.
nslookup vmw2053.wdf.sap.corp

If it is still not working …

Well, then we should take a look at the Kerberos token acquisition. For this we are going to use Wireshark. Just start Wireshark on the client and (in order to decrease the amount of data being displayed) set the filters: ip.addr == YourKDCName.
Again, I will show screenshots where the acquisition is working. In the final blog I will deal with several issues by looking not only at the Wireshark traces, but also the logs from the J2EE engine.

Start the trace (Capture -> Start) and access the J2EE via the browser.
The first thing you will see is a TGS-REQ, where the client connects to the ticket granting server to request a ticket for the J2EE engine. The J2EE Engine is known to the TGS only via the URL you are accessing the Engine: http://vmw2053.wdf.sap.corp => HTTP/vmw2053.wdf.sap.corp. This can be seen in the trace:

image

The next step is the response from the TGS TGS-REP: it contains the ticket which will be sent to the J2EE engine.

image

Here you can see the client name (this is the user that logged on to the client) and you see the ticket in the response. This is the ticket for our user and the server which we requested the ticket for.
This ticket will now be sent to the J2EE engine and from there the client name will be used and extracted (yange1@DEV16.DEV-WDF.SAP.CORP) for authentication.

You can also run the Wireshark on the server. The J2EE Engine has to acquire a ticket for the service user. That’s why a firewall cannot block the access to the KDC from the server. In the logs you can see the request for this user first:

image

Then the KDC sends the response and this ticket is cached by the engine:

image

 

OK, that’s it for the second part. In the next part I will take a look at the log files from the J2EE engine. By increasing the log level you will get valuable information about what errors are causing SPNego to fail. 

Tools used so far

To report this post you need to login first.

24 Comments

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

  1. Lars Schrader
    Hi,

    does anybody knows, where the ticket is located on the client. In my case i have had to delete the profile of the user. Then it works. But i can´t always delete users profile….

    Greetingz
    Lars

    (0) 
    1. Holger Bruchelt Post author
      Hi Lars,

      are you talking about the Kerberos ticket on the client? If you have the kerbtray tool running you can simply right-click on the tool and click on Purge Tickets. Otherwise you can log off and log in again — this should also clear all the users tickets.

      Regards,

      Holger.

      (0) 
      1. Nawanandana Edirisinghe
        Hi Holger

        many thnx for your professional blog..

        i have used SUN JDK 1.4.2_15..as per your blog
        (com.sun.security.auth.module.Krb5LoginModule in the  com.sun.security.jgss.accept component via the Visual Administrator)
        i couldnt find that login module (com.sun.security.auth.module.Krb5LoginModule) in com.sun.security.jgss.accept. hol;ger how can i retrive this module?
        if possible could you email ur mail id to me(buddhike.sgit@keells.com) whre i need your assitance in analysing the extract of the diag tool out put..

        Regards

        nawa

        (0) 
  2. Vineeth k
    Hello Holger,
    our spnego is having some problems of late.
    this error comes up in the logs and user have to login manually.

    com.sap.security.core.server.jaas.SPNegoLoginModule -Access Denied. No authorization header received

    Could you help us out?
    Thank you and regards

    (0) 
    1. Holger Bruchelt Post author
      Hi,

      can you send me an email? I am sure we can solve this somehow. The “no authorization header received” is a pretty general error and it might have several causes.

      Regards,

      Holger.

      (0) 
  3. Armando Martines Neto
    Hi,

    I made the settings as mentioned in your blog, but when I came back to the Portal and tryed to log in to set up the SPNEGO, the authentication failed. Now nobody can Log in the Dev Environment… any Idea about what is happening?

    cheers

    Armando

    (0) 
  4. Gerardo Jiménez
    Hi Holger,
    Thanx alot for all the help provided in your SPNego Blogs, really apreciate it!
    I have a question, I have Portal with ABAP Data Source, and I see no LDAP config in examples of how to configure SPNego when Portal has ABAP as Datasource, is this OK? or we still have to go to ConfigTool and configure LDAP?
    Kind Regards!

    Gerardo J

    (0) 
    1. Holger Bruchelt Post author
      Hi,

      for ABAP configuration, please also take a look at the two blogs Configuring SPNego with ABAP datasource and https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13265. [original link is broken] [original link is broken]
      You might also want to check out the new SPNEGO Login Modul http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/18567. [original link is broken] [original link is broken]
      There is no need to connect the UME to the LDAP server. However, you have to make the mapping from Kerberosprincipalname to your ABAP user ID.

      Let me know if it doesn’t work out.

      Regards,

      Holger.

      (0) 
      1. Gerardo Jiménez
        Hi Again Holger,
        I´ll let you know if it worked fine or if I had problems :O)
        There is a posibility that in the future the requirement will be that the mapping between ADS user and Portal User will be kept in the ADS in a ADS attribute, can the configuration be changed to fill that requirement in the future even if I have already configured the mapping to take place in SAP Portal with the krb5principalname attribute? or there can be problems to change the aproach in the future?
        Thanx in Advanced!

        Kind Regards,

        Gerardo J

        (0) 
        1. Holger Bruchelt Post author
          Hi,

          the main problem I see is that you have already connect the Portal to the ABAP system (using the ABAP dataSource). Now you will not be able to switch the dataSource (see https://service.sap.com/sap/support/notes/718383) back to LDAP.
          With that it will be hard to retrieve the additional LDAP attribute and use it for the SPNEGO authentication.

          Regards,

          Holger.

          You just have to run the SPNEGO Wizard again and change the settings from where the lookup should be done.

          Regards,

          Holger.

          (0) 
          1. Gerardo Jiménez
            Hi Holger,

            How are you?
            I finished the configuration and I´m facing that is not working, I just asked to get the Web Diagtool installed or that they let me install it, in the mean time I noticed something that was confusing for me, in the test resolution mode I got this:
            I type in the user j2ee-dml and click in test, and the result says Kerberos principal name j2ee-dml@mx.clientname.net is resolved to user j2ee-dml in UME.
            It is confusing for me cause in the krb5principalname attribute of the user j2ee_admin is where I typed in j2ee-dml@mx.clientname.net and not in the user j2ee-dml well that user(j2ee-dml) don´t even exist in SAP Portal users :O)
            You think I´m I doing something wrong?

            (0) 
            1. Gerardo Jiménez
              Also I forgot to tell you, the way I´m testing at this moment is that I force the Authentication Window to popup and type in j2ee-dml@mx.clientname.net and password cause I don´t have access to the client network an we are looking forward that the client can test it but I remember that in the past when I configured SPNego you could also log that way :O)
              Kind Regards!
              Gerardo J
              (0) 
  5. Steve Pavey
    Hi Holger,

    I am using EP 7.0 hhosted on AIC/Oracle to connect through to backend ECC 6.0 (also on AIX/Oracle) which is configured as the Java UME. i have followed your excellent blog to set up SSO using SPNego using the wizard which all completed successfully. Now for some users SSO is working but others are getting the logon screen. So I start the troubleshooting and in your part 2 blog one of the first things mentioned is to check what’s been created by the SPNego wizard. However when I go into VA and look for component com.sun.security.jgss.accept it is not there. Do you know why this might be missing?

    However the spnego template is present and is in the order…

    EvaluateTicketLoginModule  SUFFICIENT
    SPNegoLoginTicketModule    OPTIONAL
    CreateTicketLoginModule    SUFFICIENT
    BasicPasswordLoginModule   REQUISITE
    CreateTicketLoginModule    REQUISITE 

    The SPNego module contains all the information that I entered in the wizard.

    I am at a loss as to why this works fine for some users and not for others.

    Any ideas would be much appreciated..

    Best regards

    Steve

    (0) 
    1. Holger Bruchelt Post author
      Hi Steve,

      since you are saying it is working for some, not not for others, I would take a look at my third blog (Configuring and troubleshooting SPNego — Part 3).
      Use the WebDiagtool to check the traces from a user that does not work. Is it maybe that an NTLM instead of Kerberos Token is sent?
      Could it be a Windows 7 / Vista SP3 problem? ->
      SSO with SPNego not working on Windows 7 / Windows 2008 R2
      -> New SPNego login module – just around the corner

      Let me know what you find out.

      Regards,

      Holger.

      (0) 
      1. Steve Pavey
        Hi Holger,

        Thanks for you response. I think I have discovered the reason for SSO not working for some of our users. These users have been set up on the backend ECC (where our UME is pointed to) without passwords because it was never intended that they should logon directly. Once they have been given a password and logged on with it once SSO then works for them. Does the authentication stack somehow check whether a valid password is in place and therefore do I need to set up all SSO users with a password that’s set to never expire? 

        Best regards,

        Steve

        (0) 
        1. Holger Bruchelt Post author
          Hi Steve,

          I think there is a way to still get it working (however, I don’t remember the exact configuration). Maybe it was a setting on the ABAP profile(http://help.sap.com/saphelp_nw70/helpdata/en/6a/3faf42ede3b911e10000000a1550b0/frameset.htm -> login/password_change_for_SSO=0).
          Or something on the Java side (http://help.sap.com/saphelp_nw70/helpdata/EN/52/4c6c3e58d0d064e10000000a114084/frameset.htm -> ume.logon.force_password_change_on_sso)

          If that does not work, let me know and I will continue to look for the correct parameter.

          Regards,

          Holger.

          (0) 
          1. Steve Pavey
            Hi again Holger,

            Thanks again for your response. I tried the Java side without any luck and on the ABAP side RZ10 wouldn’t accept a value of 0 for parameter login/password_change_for_SSO. It comes up with an erro saying that the value is less than the default of 1 ?! Anyway I’ve posted a message to SAP support for that.     

            The other possibility to explore is using a two
            other profile parameters in combination. These are login/disable_password_logon and login/password_logon_usergroup. Have you seen this being used before? The drawback to this solution seems to be that for all our GUI based (non SSO) users we would have to change the value of their “User Group for Authorization Check” field (in SU01 under the Logon Data) to a single common group that we would enter as the value for the in the login/password_logon_usergroup parameter.

            Your thoughts on this will be appreciated as ever.

            Best regards,

            Steve

            (0) 
  6. Bishnu Priya Sahoo
    Hi Holger,

    I have followed all the steps and completed all the steps in the wizards.
    In Visual Adminstration,the component com.sun.security.jgss.accept was created but the LoginModule – SPNegoMappingLoginModule is missing.
    I have used Resolution Mode as ‘Simple’ and KPN as ‘krb5principalname’.

    Please let me know if I am missing anything and is it required to add the ‘SPNegoMappingLoginModule’.

    Cheers!
    Priya

    (0) 
  7. bobby basis

    Hi Holger,

    Thanks for your blog. We are having issues configuring SPNego even though we have configured as mentioned in the guide attached to the note 1488409 and your steps in the first blog.

    I tried looking at the troubleshooting as mentioned above but I dont see component “com.sun.security.jgss.accept” at all. Also there is no separate directory structure under usr\sap\j2ee\sys\global\kerberos (I’ve read somewhere this directory structure is not available with the newer version).

    Also when we logon to SPNego wizard it always shows error: “System does not provide a model for authentication management” with a button “Migrate”(this is seen everytime we login to http://<servername:port>/spnego)

    Could you please provide us any suggestions. We are on NW 7.02, J2ee was upgraded but SPNego was never configured before, Windows vista OS and AD on Windows 2003 server.

    Thanks.

    (0) 

Leave a Reply