Skip to Content

Almost always when Single Sign-On is required to Java SAP applications, the SPNego login module is the answer. After the SPNego Wizard was introduced some years ago it got really simple to configure the AS Java for Single Sign-On (See Note 994791 – SPNego Wizard  and Configuring and troubleshooting SPNego — Part 1). When the AS Java was connected to an ABAP System it was possible to do the required mapping and SSO worked (Configuring SPNego with ABAP datasource — Part 2Configuring SPNego with ABAP datasource — Part 2). Even in scenarios where SSO to ABAP systems was required, the SPNego login model could easily be used to authenticate and create SAPLogon Tickets that would be accepted by the backend system (Single Sign On to BSP pages, Single Sign On to SAP NetWeaver Enterprise Search 7.2 Using Integrated Windows Authentication).

 

With Windows 7 and Windows 2008 R2 (and upcoming Vista SP3) there were some issues with the DES encryption that was required by the SPNego login module, but was no longer active by default. The reason for requiring DES encryption in the login module was that the APIs from Suns and IBMs Java 1.4.2 do not allow any other form of encryption. So the only workaround – if you wanted to use the SPNego login model – was to reactivate the DES encryption on Windows 7 and Windows 2008 R2 (see Note 1396724 – SPNEGO fails with Windows 7 and Windows Server 2008 R2  and SSO with SPNego not working on Windows 7 / Windows 2008 R2). Of course this was only a workaround and our development was working on a real solution.  Update:
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!

 

 

To report this post you need to login first.

138 Comments

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

  1. Olivier CHRETIEN
    Hello,

    Thanks for this good news and the very interesting blog. The only problem for my company is that the new module comes too late and that we had to buy an external certified product to overcome the DES and AD 2008 limitations.

    Anyway this a good move and I am happy to see that SAP listen to customers needs.

    Regards,
    Olivier

    (0) 
  2. John Travolta
    Where in the wizard, you specify the host and port for each realm?

    There is already a date when will it be available, and whether there patches for customers that doesn’t want to upgrade?

    Thanks
    John

    (0) 
    1. Dimitar Mihaylov
      Hi John,

      The host and port of the KDC (domain controller) are not necessary any more and are not entered in the wizard. Because the NW AS Java system only accepts Kerberos tokens and does not obtain such on its own there is no need to connect to the KDC. This is similar to the “isInitiator” option of Sun’s KerberosLoginModule. This approach have several benefits:
      – in case you have multi-realm setup but the KDC of ne realm is down this won’t affect the users from the other realms
      – there could be a firewall between the NW AS Java and the KDC (domain controller) and still you can configure SPNEGO authentication to the NW AS Java

      To best of my knowledge the patches for the existing SPs will be released in the next few weeks (if not already released). I’ll check the official release dates and update you accordingly. Later on the new SPNEGO implementation will replace the current one in the next officially released SPs.

      Regards,

      Dimitar

      (0) 
      1. Kalpana Juvvala
        Hi Dimitar,
        We implemented new add on tool to our AS Java system and started noticing issues with Windows XP SP2/SP3, Vista clients. The issue is-sometimes users get Netweaver login prompt screen and after rebooting the machine its resolved. Is there any clue why its happening? On a side note downloaded kerbtray.exe for viewing the ticket information when this is happening the kerberos ticket is expired , usually the kerberos tickets lifetime is by defualt 10 hours and when end time is reached SPNEGO SSO is failing and getting prompted for login.
        (0) 
        1. Holger Bruchelt Post author
          Hi,

          with Windows XP SP2 I could explain this behavior (see https://service.sap.com/sap/support/notes/934138 and ->
          “IE browser sends NTLM token when the Kerberos token has expired. IE browser must request a new Kerberos token but fails to get it due to Microsoft bug for Windows XP SP2 workstation.
          Please apply Microsoft hotfix KB899587.”

          But this should be fixed with SP3 already…

          Holger.

          (0) 
  3. Justin Burmeister
    Hi –

    We are very happy to see the RC4-HMAC option for our Win7 clients, with a stronger cipher.

    I downloaded and deployed the components attached to OSS 1457499 for 7.0 –

    Unfortunately, the new wizard (/spnego2/cfg) and pdf doc do not resemble the screenshots in this article, and there is no option to generate a new keytab manually – only import from an existing file.

    So I can add the old keytab in global/kerberos, but only have DES encryption keys from the previous SPNego implementation. 

    I run /spnego, and get the old wizard.

    We can do a policy to enable DES on Win7, and the new SPNEGO login module works fine – which demonstrates that the new deployed module specified in the ticket login stack is working, but we seem to be stuck with DES, which is not desirable to the enterprise.

    How do we generate keys for the RC4-HMAC encryption?? Is there a newer wizard forthcoming for NW70, as in the article above?

    thanks
    -Justin Burmeister

    (0) 
      1. Kishore Mallavarapu
        I deployed the new file from the note and ran the wizard from /spnego2/cfg and enabled realm. I observed new SPNEGOLoginModule has no options like uid resolution attributes etc., that were there for old SPNegoLoginModule. I am running 7.01 SP05 version of Java stack. Appreciate your help.

        Thanks
        Kishore

        (0) 
        1. Dimitar Mihaylov
          Hi Kishore,
          The new login module does not use login module options for its configuration. The whole configuration is stored in the configuration manager.
          You may proceed with the configuration – include the login module in the respective authentication stack.
          Regards,
          Dimitar
          (0) 
          1. Kishore Mallavarapu
            Thank you Dimitar.

            I went ahead and added the new SPNEGOLoginModule to ticket policy. I imported the keys from my existing keytab file which has only DES encryption. I am trying to login from my XP machine itself to test SSO now but I see a checksum error and SPNEGO invalid token errors in the default trace. I would like to validate with DES first before generating RC4 keytab and import the new keys. Appreciate your help

            Thanks
            Kishore

            (0) 
              1. Kishore Mallavarapu
                Hi Dimitar, I reset the password and completed the configuration again using old wizard. It works OK now. I will try the new wizard one more time now. Does the new module uses krb5.conf file and \usr\sap\trans\global\kerberos\keytab files as well?

                Thanks
                Kishore

                (0) 
                1. Dimitar Mihaylov
                  Hi Kishore,

                  No, the new module does not use anything from the file system. The whole configuration is stored in the Configuration Manager (system database).
                  When you upload a keytab file with keys those are stored also in the database (Configuration Manager) and afterwards used from there. That’s one of the reasons why the new module does not require restart when re-configuration is performed.

                  Regards,
                  Dimitar

                  (0) 
                  1. René Schubert
                    Hello again Dimitar,

                    I tried to install the new SPNEGO for another Portal now. I repeated every step that I took for the first system. The only difference: The old SPNego Module had NOT been installed on this system before.

                    Sorrily I now get the Checksum error, as well. I changed the LDAP service user password to a password that is similar to the one that works with the other portal, changed the UME configuration accordingly and recreated the keytab file. But nothing changed, I still get the checksum error.

                    Here’s what the Diag Tool log says:

                    SPNEGO token extracted from header: SPNEGO Token [
                        OID: 1.3.6.1.5.5.2
                        NegTokenInit [
                            mechTypes: 1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2, 1.3.6.1.4.1.311.2.2.30, 1.3.6.1.4.1.311.2.2.10
                            reqFlags:
                            mechToken (binary): 60820ed006092a864886f71201[…]
                            mechListMIC (binary):
                            Mech Token [
                                OID: 1.2.840.113554.1.2.2
                                AP-REQ (Kerberos) [
                                    pvno: 5
                                    msg-type: 14
                                    ap-options: 00100000000000000000000000000000
                                    ticket: Ticket [
                                        tkt-vno: 5
                                        realm: EU.MERCKGROUP.COM
                                        sname: [type: NT-SRV-INST, name: HTTP/deda1x0157.merck.de]
                                        enc-part: EncryptedData [
                                            etype: 23 (rc4-hmac)
                                            kvno: 2
                                            cipher: 0x9893a6529fec49ab[…]
                                        ]
                                    ]
                                    authenticator: EncryptedData [
                                        etype: 23 (rc4-hmac)
                                        kvno: 0
                                        cipher: 0xed472ff475921185e9[… (way shorter)]
                                    ]
                                ]
                            ]
                        ]
                    ]

                    Could the differing kvno be a cause for the checksum error? (What is the kvno?) What else could be the problem? Do you need any further information?

                    Thanks in advance!

                    Regards,
                    René

                    (0) 
                    1. Dimitar Mihaylov
                      Hi Rene,
                      Check the following:
                      1. The token is issued for service HTTP/deda1x0157.merck.de. Is this the correct SPN that you have registered with the service user? Could it be that this one is associated with another user?

                      2. Have you used the correct password to generate the keytab and the RC4-HMAC? Please double check and in case of doubt re-generate the keytab and re-import the key.

                      3. Check that the imported key has 32 hex digits. There was bug in one of the previous versions which trimmed leading zeros and this leads to wrongly imported keys. In case of doubt download the latest version from the SAP Note and deploy it with “deploy any version” option in SDM.

                      If nothing of this helps open a support ticket, attach complete traces and send me the ticket number.

                      Regards,

                      Dimitar

                      (0) 
                      1. René Schubert
                        Hello Dimitri,

                        thank you. The first point was what I hadn’t recognized. I added the second SPN to the LDAP service user and now everything works fine.

                        The reason why the error came up was, because we’re running two Portals on one server, using different ports. So we added the physical name of the server as SPN to the LDAP service user for the other portal, which caused the error. Now only the LDAP service user for this portal (the one that I tried to logon to) has the physical name of the server added as SPN.

                        Regards,
                        René

                        (0) 
                  2. Kishore Mallavarapu
                    Hi Dimitar,

                    All SSO works fine with the new module but we do see intermittent login screen pops up instead of SSO. I see the error “Cannot load login module class com.sap.security.spnego.SPNEGOLoginModule.” in NWA, followed by a warning message “getLoggedInUser[EXCEPTION] … No loginmodule succeeded..” whenver SSO doesn’t work. No more details after this. Will the note 1397872 help?

                    Thanks
                    Kishore

                    (0) 
                    1. Dimitar Dimkin
                      Hi Kishore,

                      I believe you have more than one server nodes, is that correct? If yes, redeploy the add-on solution from the note (1457499) and run the wizard again (simply run it, you don’t need to configure anything).

                      Best regards,
                      Dimitar Dimkin

                      (0) 
                      1. Kishore Mallavarapu
                        Hi Dimitar, I waited for Java upgrade to 1.4.2_29 on the portal servers (running NW 7.0 EHP1) to test the SSO again. I have CI + 2 app servers (with multiple server nodes on the app servers but only one node in CI). It is still throwing the login screen intermittently with the message in default trace –  “Unable to load spnego login module” message. I opened a message as well for this. Appreciate your insight on this issue.
                        (0) 
                          1. Kishore Mallavarapu
                            OSS Message# 342851.

                            After correcting the load libraries, SSO is working fine on individual servers. When I try to access the portal URLs via a hardware logon load balancer (Citrix NetScalar), I see the error “NTLM token received”. I made sure the alias hostnme I am using for loadbalancer is added as SPN to the Microsoft AD User.

                            Thanks
                            Kishore

                            (0) 
                            1. Dimitar Mihaylov
                              Hi,

                              Use Wireshark or similar tool on the client machine in order to check why it cannot obtain a Kerberos ticket. You have to clear the Kerberos cache on the system by logging off and on again or using “kerbtray” tool and purse the cached tickets.

                              Regards,
                              Dimitar

                              (0) 
  4. Paul Murgatroyd
    We implemented the new SPNEGOLoginModule on our NW7.01 Portal. Everything was working fine until we added a 3rd Server Node (due to SAP GoLive Check). What we have found is that when users are redirected to the 3rd Server Node, SPNEGO fails to that server not being able load the SPNEGOLoginModule.
    It appears as though the new login module, either when configured or deployed (via SDM), sets Local Properties in each Server Node, but does set anything at the Global Configuration Level. As a result, when you add a new server node, none of the SPNEGO functionality is carried over to the new node.
    In our case, this results in intermittent SSO failures. SSO works fine on the server nodes that were there when SPNEGO was configured, but any added after do not work.
    We’ll be opening a SAP Message to have the issue looked at, so this is just a heads up to anyone who may be experiencing the same problem. Since we don’t know exactly what Local Settings were added by the new LoginModule, we don’t know what is missing.

    Regards,

    Paul

    (0) 
  5. Daniel Rothmund
    Hello ,

    We have the requirement that we must deactivate SSO for some Users . f.e. ESS/MSS Scenario .

    Is in the new SPNEGO Module a option for this ? Or any ideas how can we solve this issue ? . I think that more customers have this Problem …

    Regards Daniel

    (0) 
    1. Dimitar Mihaylov
      Hi Daniel,

      Do you mean SSO only with SPNEGO/Kerberos or also with other authentication mechanisms – e.g. client certificates?
      The current SPNEGO solution does not support such feature. However there are several ways to restrict the users:
      1. Depending on the user mapping mode you may not maintain user mapping data for the restricted users and thus they cannot login because they cannot be looked up by the login module
      2. If the user mapping data is provisioned automatically for all users (e.g. ADS Data Source) you can implement custom login module that does enforce this restriction. It has to check who is the authenticated user and if not allowed to enter the system with SSO throw LoginException.

      However it might make also sense to provide more general solution. I will discuss it with my colleagues. What version of AS Java are you using? In case we decide to extend the functionality with such feature we may consider your version with highest priority.

      Regards,

      Dimitar

      (0) 
      1. Daniel Rothmund
        Hello Dimitar,

        We currently on NW7.01 SPS6. We use only SPNEGO/Kerberos and no other authentication mechanisms. The User Datasource is a Windows ADS Directory.

        I think the best solution is a UME attribute or ldap attribute to enable or disable spnego for the current user .

        Have you an example for a custom login module ?

        If SAP decide to develop this our company would be rampup candidate 

        Regards

        Daniel

        (0) 
        1. Dimitar Mihaylov
          Hi Daniel,

          I was thinking more in direction of assigning the restricted users to a group and then checking if they are members of this group. If one is a member then access to the system will be denied. Group assignment should be easily done also directly in the Active Directory. Is there a special reason to prefer user (LDAP/UME) attribute?
          I don’t have such ready to use custom login module but we can try to build one for test purposes.
          Just from curiosity what is the reason to restrict SSO access for certain users? You need higher security level for users with special rights or something else?

          Regards,

          Dimitar

          (0) 
          1. Daniel Rothmund
            Hi,

            there is no special reason for the UME Attribute. But for us the best solution is that the users can decide to activate or deactivate the SSO.

            The reason is that some user “need” a higher security level for the MSS Scenario. We have some discusion with our staff association about this problem ..

            Regards

            Daniel

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

              if it is “just” about makeing access to MSS Scenarios more secure, the Authenticatino Schemes (http://help.sap.com/saphelp_nw70ehp2/helpdata/en/d3/1dd4516c518645a59e5cff2628a5c1/frameset.htm  & http://help.sap.com/saphelp_nw70ehp2/helpdata/en/54/a334ed5bbfd5488b8cdd67b2c594a9/frameset.htm) in the portal might be an option. With this all users could log on to the “basic” portal pages via SSO, but once they try to access MSS iViews they would be prompted for username and password again.

              However, I also think that there are cases where it definetly makes sense to disable SSO for certfain users/groups

              Regards,

              Holger.

              (0) 
              1. Daniel Rothmund
                Hi Holger,

                the problem is with the Authenticatino Schemes all User must enter his password at the MSS IViews.
                But only some user need to enter the password for MSS.

                Regards

                (0) 
                1. Dimitar Mihaylov
                  Hi Daniel,

                  At help.sap.com you may find how to develop and deploy custom login module – http://help.sap.com/saphelp_nw70ehp1/helpdata/en/46/3ce9402f3f8031e10000000a1550b0/frameset.htm.
                  I’m attaching a source code of an example AccessControlLoginModule which I have tested successfully on AS Java 7.2 but cannot provide any warranty so you should use it on your own risk.
                  The example authentication stack that I have used is the following:
                  1. EvaluateTicketLoginModule SUFFICIENT
                  2. BasicPasswordLoginModule OPTIONAL
                  3. CreateTicketLoginModule SUFFICIENT
                  4. SPNegoLoginModule REQUISITE
                  5. AccessControlLoginModule REQUISITE
                  6. CreateTicketLoginModule OPTIONAL

                  Please note that this login module could be used only once in the stack and should be configured only after the last authentication mechanism – that’s why SPNegoLoginModule is after BasicPasswordLoginModule.
                  The login module has the following options:
                  access.control.type=group|attribute – checks group assignment or user attribute
                  access.control.mode=deny|allow – either deny access or allow access if the user is member of the group or has the specified user attribute
                  access.control.group.name – the unique name of the group to check, e.g. “GRUP.PRIVATE_DATASOURCE.un:Restricted Users”
                  access.control.attribute.name – the name of the user attribute to check (currently only the default UME namespace is supported)
                  access.control.attribute.value – the value of the user attribute to be checked

                  Hopefully this will help you.

                  Regards,

                  Dimitar

                  Here is the source of the login module:

                  package com.sap.security.authn;

                  import java.util.Map;

                  import javax.security.auth.Subject;
                  import javax.security.auth.callback.CallbackHandler;
                  import javax.security.auth.login.LoginException;

                  import com.sap.engine.interfaces.security.auth.AbstractLoginModule;
                  import com.sap.security.api.IUser;
                  import com.sap.security.api.UMException;
                  import com.sap.security.api.UMFactory;

                  public class AccessControlLoginModule extends AbstractLoginModule {
                   
                    public static final String OPTION_TYPE = “access.control.type”; 
                    public static final String TYPE_GROUP = “group”;
                    public static final String TYPE_ATTRIBUTE = “attribute”;
                    public static final String OPTION_MODE = “access.control.mode”; 
                    public static final String MODE_DENY = “deny”;
                    public static final String MODE_ALLOW = “allow”;
                    public static final String OPTION_GROUP_NAME = “access.control.group.name”; 
                    public static final String OPTION_ATTRIBUTE_NAME = “access.control.attribute.name”; 
                    public static final String OPTION_ATTRIBUTE_VALUE = “access.control.attribute.value”;
                   
                   
                    private String type;
                    private String mode;
                    private String groupName;
                    private String attrName;
                    private String attrValue;
                    private Map sharedState;
                   
                    public void initialize(Subject subject, CallbackHandler callbackHandler,
                        Map sharedState, Map options) {
                      this.sharedState = sharedState;
                      type = (String)options.get(OPTION_TYPE);
                      mode = (String)options.get(OPTION_MODE);
                      groupName = (String)options.get(OPTION_GROUP_NAME);
                      attrName = (String)options.get(OPTION_ATTRIBUTE_NAME);
                      attrValue = (String)options.get(OPTION_ATTRIBUTE_VALUE);
                    }
                   
                    private void processGroupMode(IUser user) throws LoginException {
                      if (groupName == null) {
                        throw new LoginException(“Option ” + OPTION_GROUP_NAME + ” not configured correctly but mandatory for ‘group mode’.”);
                      }
                      boolean memberof = user.isMemberOfGroup(groupName, true);
                      if (MODE_DENY.equalsIgnoreCase(mode)) {
                        if (memberof) {
                          throw new LoginException(“User [” + user.getUniqueName() + “] is a member of group [” + groupName + “]. Access denied.”);
                        }
                      } else if (MODE_ALLOW.equalsIgnoreCase(mode)) {
                        if (!memberof) {
                          throw new LoginException(“User [” + user.getUniqueName() + “] is not a member of group [” + groupName + “]. Access denied.”);             
                        }
                      } else {
                        throw new LoginException(“Access control mode not configured correctly. Accepted values for option [” + OPTION_MODE + “] are ‘allow’ and ‘deny’.”);
                      }             
                    }
                   
                    private void processAttributeMode(IUser user) throws LoginException {
                      if (attrName == null) {
                        throw new LoginException(“Option ” + OPTION_ATTRIBUTE_NAME + ” not configured correctly but mandatory for ‘attribute mode’.”);
                      }
                      if (attrValue == null) {
                        throw new LoginException(“Option ” + OPTION_ATTRIBUTE_VALUE + ” not configured correctly but mandatory for ‘attribute mode’.”);
                      }
                      String[] attrValues = user.getAttribute(IUser.DEFAULT_NAMESPACE, attrName);
                      boolean matchingAttr = false;
                      if (attrValues!=null && attrValues.length>0) {
                        // in case of multi-value attribute only the first value will be considered
                        matchingAttr = attrValue.equalsIgnoreCase(attrValues[0]);
                      }
                      if (MODE_DENY.equalsIgnoreCase(mode)) {
                        if (matchingAttr) {
                          throw new LoginException(“User [” + user.getUniqueName() + “] has attribute [” + attrName + “] with value [“+ attrValue +”]. Access denied.”);
                        }
                      } else if (MODE_ALLOW.equalsIgnoreCase(mode)) {
                        if (!matchingAttr) {
                          throw new LoginException(“User [” + user.getUniqueName() + “] does not have attribute [” + attrName + “] with value [“+ attrValue +”]. Access denied.”);
                        }
                      } else {
                        throw new LoginException(“Access control mode not configured correctly. Accepted values for option [” + OPTION_MODE + “] are ‘allow’ and ‘deny’.”);
                      }
                    }

                    public boolean login() throws LoginException {
                      String logonId = (String)sharedState.get(AbstractLoginModule.NAME);
                      if (logonId == null) {
                        return false;
                      } else {
                        try {
                          IUser user = UMFactory.getUserFactory().getUserByLogonID(logonId);
                          if (TYPE_GROUP.equalsIgnoreCase(type)) {
                            processGroupMode(user);
                          } else if (TYPE_ATTRIBUTE.equalsIgnoreCase(type)) {
                            processAttributeMode(user);
                          } else {
                            throw new LoginException(“Access control type not configured correctly. Accepted values for option [” + OPTION_TYPE + “] are ‘group’ and ‘attribute’.”);
                          }
                        } catch (UMException e) {
                          throwUserLoginException(e);
                        }
                        return true;
                      }
                    }

                    public boolean abort() throws LoginException {
                      return true;
                    }

                    public boolean commit() throws LoginException {
                      return true;
                    }

                    public boolean logout() throws LoginException {
                      return true;
                    }

                  }

                  (0) 
                    1. Daniel Rothmund
                      Hi ,

                      your LoginModule is working very well with my Ehp1 SPS6.  I have created a user attribute “sso” and created a AbstractPortalComponent to set the attribute to true or false. As soon I have finished the creation of this Iview and LoginModule . I will post a reply with the source.

                      Best Regards

                      Daniel

                      (0) 
                      1. Daniel Rothmund
                        Hi ,

                        Sry one more question .

                        I have change my J2EE autschemes.xml


                                   
                                        geb_sec
                                   

                                    99            2
                                    com.company.runtime.logon.basicauthentication
                               

                        and I have create a security provide with name geb_sec with your Abstract Login Module. And added this authscheme to portal iview. But it doesn’t work . I receive only a IE Login Prompt for this IView.

                        Should this work ?

                        The idea is to protect special iviews with the Abstract LoginModule and the user can active / deactive the SSO Feature for this Iviews by own.

                        I hope it was not desribed to confuse 🙂

                        Best Regards

                        (0) 
                        1. Dimitar Mihaylov
                          Hi Daniel,
                          I cannot immediately say what could be the problem. Some obersvations:
                          1. Priority 99 (more than the default one – 20) means that  when such iView is accessed for the first time re-authentication will be triggered.
                          2. Frontend target (basicauthentication) – it will be handled in a special way and instead of logon form an http header: “WWW-Authenticate: Basic” will be returned. This may conflict with the SPNegoLoginModule if configured in “geb_sec” because it tries to return http header with the same name but different value – “WWW-Authenticate: Negotiate”.
                          In order to further troubleshoot the problem please check note 1045019 and apply example 3 (security -> authentication). Have a look at the collected traces if you can see the reason for the problem – search for the login module tables with LOGIN.OK/LOGIN.FAILED events and the traces before them. You may send me also the generated ZIP file at [dimitar . mihaylov AT sap . com]

                          Regards,
                          Dimitar

                          (0) 
                    1. Dimitar Mihaylov
                      Hi James,
                      In the presentation you mentioned there is a general information what SSO technologies SAP supports as of 2008. I’m not sure about your concrete question – do you need an example how the ClientCertLoginModule is implemented?
                      Regards,
                      Dimitar
                      (0) 
  6. Herwig Rodehack
    Hello Holger,

    I’m trying to implement the new module in an enterprise portal 7 that is currently using the old fashioned way using a kerb5.conf file.
    After reading your blog I was able to successfully configure the sso to work with users of one domain in the forest (the one I created the service user), but any try outs to validate users of other domains of the forest failed for now.
    I still do not really understand what’s neccessary for a sso in an AD forest. May be you can give a a hint.
    In our env UME is configured for multiple-domain logon using ADS (from note 762419 using solution 1 -> we have more then 5 domains) -> is this really neccessary?
    We have 7 domains in the forest, the root domain and 6 domains under it.
    What I tried until now:
    Try out 1: I use a service account in lets say 1.com and I create a realm in portal for it.
    The service principal is set correct to the service account in this domain.
    Login on with a user of 1.com to the portal sso works fine, using a user of another domain it fails.
    Try out 2: I use a service account in the root domain com, and I create an additional realm for it. The service principal is set correct to the service account.
    Login on with a user of com sso works fine, also logon on with a user of 1.com works fine. All other users of other domains fail.
    Try out 3: I disable the realm for 1.com.
    Users of com are loggedon with sso, all other users fail.

    Viewing my try outs and the logs of webdiagtool I come to the result that maybe it is neccessary to have a service account in each domain. Am I right with my belief?

    I red several notes of the older modules and it seems that it was possible with the old spnego module to have only one service account in one domain of a forest to get sso to work.
    That’s the configuration we currently use.

    So, sorry for the long text. At the end I only want to get a hint on how to configure sso with the new spnego module in an active directory forest environment.

    Many thanks in advance, Herwig.

    (0) 
    1. Dimitar Mihaylov
      Hi Herwig,

      What is the error that you see in the webdiagtool traces? Is it that the token cannot be decrypted or that the user mapping fails or something else? What user mapping mode have you configured?
      I would propose that you open a CSS ticket in component BC-JAS-SEC-LGN and attach there webdiagtool traces from one working and one non-working test. Send me the number of the ticket at dimitar [dot] mihaylov [at] sap [dot] com.

      Regards,
      Dimitar

      (0) 
    2. Dimitar Mihaylov
      Hi Herwig,

      This reply is just to confirm that the new SPNEGO implementation works in AD forest. As before you need to create a single service user in one of the domains of the forest. In your particular case there were other reasons (wrong configuration) why it was not working from the beginning but after resolving them it works for you as well.

      Regards,

      Dimitar

      (0) 
  7. Günter Hoeth
    First of all let me say: The possibility to suppress SSO by URL-Parameter ?spnego=disabled is a great relief for all admins.

    Now my problem: The new SPNEGOLoginModule from the Attachment  SPNego_AddOn_700.ZIP of note 1457499 works fine with DES encryption but we always get “Checksum error!” if we try to use RC4-HMAC.
    As soon as I unmark “Use DES ecnryption types for this account” in the Account-tab of the service user in the ADS the Module “com.sap.security.spnego.krb5.crypto.Rc4Crypto” is involved and calculates a different checksum for the SPNEGO token.
    Our portal server is based on NW 7.01 SP6, SLES10SP2 and “J2RE 1.4.2 IBM build j9xa64142ifx-20100706b (SR13 FP5)”. Did anybody get RC4-HMAC-Encryption running in this environement? Could it be that RC4-HMAC encryption does not work with IBM-Java?
    Regards
    Günter


     

    (0) 
        1. Dimitar Mihaylov
          Hi Guenther,
          That’s great that you got it running. I have the following requests to you:
          1. Could you send me the number of the support ticket you have opened so that I can check why it was delayed?
          2. Could you send me a password with which it is not working – not necessary the same if you use it for other system? Please put it in the secure logon area of the support ticket – do not post it here or send it via email. The RC4-HMAC key is generated only based on the password of the service user and I should be able to reproduce the issue by myself. My first guess would be that the ktab tool from the JDK does not work correctly with some special characters – were there ‘umlauts’ or other non-ASCII characters in the non-working password. Second thing could be that our import procedure does not read the key correctly. Third – some error in the decryption algorithm :).
          Regards,
          Dimitar
          P.S.Please note that klist does not print the keys always correctly as you have already discovered this.
          (0) 
        2. R. Hellemons
          Hi Günter,

          I’m also facing the checksum error message. The steps I’ve been following are equal to your steps but still no positive result.

          I feel like I’m missing something small. Like you did, I changed the service user name and kept the password as simple as possible. Ëxported the keytab file and ran the SPNEGO wizard again. Unfortunately I’m still facing a checksum error.

          When I look at the steps you performed. Can I conclude that you use sapldap for the UME LDAP connection properties, but also use sapldap for the “use UME unique id with unique LDAP attribute”?

          Regards,

          Rob

          (0) 
          1. Dimitar Mihaylov
            Hi Rob,

            The problem that Guenther has experiensed was caused by a problem in reading keys which have leading zeros. You may check if you have the same problem by counting the hex digits of the RC4 key – they should be 32 (16 bytes).
            Meanwhile I have attached to note 1457499
            new “sap.com~spnego.cfg.wd.ear” in “SPNego_AddOn_700.zip” which fixes the problem. When deploying it select in SDM to deploy any version as the version is the same as before. If this does not solve the problem open a support ticket and send me the number.
            Regards,
            Dimitar

            (0) 
          2. Günter Hoeth
            Hi Rob,
            I suppose you mean the field
            “Use UME unique id with unique LDAP attribute” in the UME LDAP data of the configtool. Here we use the LDAP attribute “samaccountname”.
            Regards
            Günter
            (0) 
    1. Herwig Rodehack
      Hello Günter,

      you are right to deactivate “Use DES encryption type for this account” in AD for the service user.
      After you deactivate this option on the service user you have to create a new keytab file. Keep in mind that AD needs some time for replication the new setting, so wait some minutes before creating a new keytab file.
      For the creation of the new keytab file you need at least a java runtime installation 1.5 or higher, because java runtimes older 1.5 doesn’t support RC4-HMAC encryption. The java runtime can be installed on any computer, so it doesn’t have to be installed on the portal box itself.

      Now create the keytab file with e.g. command ktab.exe -a serviceuser@AD_DOMAIN -k Keytabfile.
      After that go to spnego/cfg wizard and delete the old keys and import the keys stored in the new keytab. Save it and that’s all.
      Should work like this.
      We run portal on Solaris, we have it running with DES and RC4-HMAC encryption.

      (0) 
      1. Günter Hoeth
        Hello Herwig,
        thanks for your answer. It convinced me that I what I have done was right. The solution was to change the password of the serviceuser. With the new password the RC-HMAC encryption works as fine as the DES encryption ever did. My impression is that there are some passwords which lead to the generation of wrong keys. May be that the old password was too short (8 Bytes) or that passwords for RC4-HMAC encryption are not allowed to start with a number (which tho old password did). I don’t know if there exists some password rules for that. But the problem is reproduceable. After I got SSO working with a RC4-HMAC key, I changed the password back and bang – I got the checksum error again.

        Kind regards
        Günter

        (0) 
  8. Jorge Flores
    Hi Holger, first of all, thanks a lot for your help to the comunity.

    I downloaded the SPNEGO add-on from sap note 1457499. I am trying to configure it for a client with Windows 2008 DCs and Clients running Windows 7.

    I followed all the steps including removing the Djava.security.krb5.conf from the config tool, generating the new keytab with ktab on the JDK, remove the “Use DES encryption type” and update the ticket component to include SPNEGOLoginModule (old one is SPNegoLoginmodule, SPNEGO on the new one is all capitals).

    I restarted the engine after that if I get “SPNEGO functionality is not enabled. All realms are disabled” wich tells me that is no longer taking the old configuration.

    After that, went to creat the new realm with User Mapping mode = principal and REALM and source = ADS Data Source, enabling RC4 and DES encryptions.

    I am getting the exception:

    —————————
    LOGIN.FAILED
    User: N/A
    Authentication Stack: ticket

    2. com.sap.security.spnego.SPNEGOLoginModule                               OPTIONAL    ok          exception             true       Trigger SPNEGO authentication.

    And on the next Login.Failed:
    —————————
    LOGIN.FAILED
    User: N/A
    Authentication Stack: ticket
    2. com.sap.security.spnego.SPNEGOLoginModule                               OPTIONAL    ok          exception             true       NTLM token received in authorization header.

    (Didn’t include the other login modules on the stack since I don’t think they are relevant, right?)

    It is as if the usernams is not being send by the browser.

    Any clues?

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

      you get an ” NTLM token received in authorization header” error. So probably your SPNEGO configuration is correct. Can you check the browser settings? (see http://help.sap.com/saphelp_nw70ehp1/helpdata/en/43/49a2aefd975f89e10000000a1553f6/frameset.htm).
      If that is OK, is it possible that you have set the ServicePrincipalName for two users (see Configuring and troubleshooting SPNego — Part 2 and search for “ldifde -r (serviceprincipalname=HTTP/vmw2053.wdf.sap.corp) -f spn_output.txt” — make sure that you only get one result)

      Thanks,

      Holger.

      (0) 
    2. Jorge Flores
      Just to let you know and for the benefit of others, my problem was that I was using Mapping mode = principal and REALM and source = ADS Data Source. I changed to Mapping mode = “principal only” and Source = “logon id” and that solved the problem, so, guys, make sure you are using the correct mapping mode and don’t assume you should use the default one.

      Regards!

      (0) 
    1. Dimitar Mihaylov
      Hi Rene,
      Could you provide the full error message?
      Does it contain something like this:
      com.sap.security.spnego.SPNEGOLoginModule                               OPTIONAL                                                 Cannot load login module class. com.sap.security.spnego.SPNEGOLoginModule
      ————————- Loader Info ————————-
      ClassLoader name: [library:spnegoauthlib]
      Parent loader name: [Frame ClassLoader]

      If yes then this means that you have an old SPNEGO implementation configured as library (before 6.40 SP15) and you have to remove it because of conflicting class loaders.

      Regards,

      Dimitar

      (0) 
      1. René Schubert
        Hi Dimitar,

        thank you for your quick response! That’s almost exactly the way it looks like. The full message for the SPNEGOLoginModule is as follows:

        2. com.sap.security.spnego.SPNEGOLoginModule                               OPTIONAL                                                 Cannot load login module class. com.sap.security.spnego.SPNEGOLoginModule
        ————————- Loader Info ————————-
        ClassLoader name: [library:ca.com~SiteMinderLoginModule]
        Parent loader name: [Frame ClassLoader]
        References:
           interface:security
        Resources:
           /usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/fedutil.jar
           /usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/fedsdk14.jar
           /usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/servlet-api.jar
           /usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/jsafeFIPS.jar
           /usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/smwebasagent.jar
           /usr/sap/TEP/JC03/j2ee/cluster/server0/bin/ext/ca.com~SiteMinderLoginModule/smjavaagentapi.jar
        Loading model: {parent,local,references}
        —————————————————————

        We’re now trying to remove the SiteMinderLoginModule library and see whether it fixes the problem – and if not, we at least got a clue of what we have to do, if other messages like this come up.

        I will keep you informed about the results.

        Regards,
        René

        (0) 
        1. Dimitar Mihaylov
          Hi Rene,

          The new SPNEGO login module tries to automate the registration in the security service – see property “LoginModuleClassLoaders” in  http://help.sap.com/saphelp_nw04/helpdata/en/d7/e08b17065b554ca57183a4c3a99340/frameset.htm
          However it seems that if this property has non blank value it does not update it correctly. You should be able to keep SiteMinderLoginModule and configure the new SPNEGO one too. For that purpose the value of the property should be:
          library:ca.com~SiteMinderLoginModule,library:spnego.lm
          If this does not work then try only with:
          library:spnego.lm

          Regards,
          Dimitar

          (0) 
          1. René Schubert
            Hi Dimitar,

            thank you, that was a good hint. I did what you said and the problem is gone now AND SSO is working now with Windows XP. Unfortunately another problem occured, when trying to use SSO with Windows 7: The error message has changed to

            2. com.sap.security.spnego.SPNEGOLoginModule                               OPTIONAL    ok          exception             true       Trigger SPNEGO authentication.

            (and afterwards)

            2. com.sap.security.spnego.SPNEGOLoginModule                               OPTIONAL    ok          exception             true       NTLM token received in authorization header.

            This is the warning that follows:

            getLoggedInUser
            [EXCEPTION]
            com.sap.engine.services.security.exceptions.BaseLoginException: Cannot authenticate the user.
            […]

            I already took a look at
            https://service.sap.com/sap/support/notes/934138
            http://help.sap.com/saphelp_nw70/helpdata/en/43/49a2aefd975f89e10000000a1553f6/frameset.htm

            But I am using IE8 and Win 7, so there shouldn’t be any Win XP bugs. And the login is working with Win XP now, anyway. So most of the “global” problems can be excluded.

            I found this comment here http://weblogs.sdn.sap.com/cs/user/view/cs_msg/66988, but as SSO works with Win XP, I don’t think the 2nd point applies? I’ve also checked the IE8 settings – we only have one difference to what is recommended: We’ve selected “Automatic logon with current username and password” instead of “Automatic logon only in Intranet zone” – but that shouldn’t make any difference in our case, or does is?

            Do you have any further ideas? Thank you in advance!

            (0) 
            1. Dimitar Mihaylov
              Hi Rene,
              One possible reason could be that the service user in the Active Drectory is still configured with DES encryption types. Windows 7 does not support DES by default and thus when requesting token woudn’t send such encryption type as supported one. As a result the domain controller will respond with error that no token could be returned because it can return only encrypted with DES but Windows 7 does not support it. In end effect an NTLM token will be send to the AS Java.
              The resolution is to disable DES for the service user and import valid RC4-HMAC key in the SPNEGO configuration.
              If this is not your problem then try to check what is the Kerberos communication between the client and the domain controller. For that purpose use Wireshark and filter the network traffic on UDP ot TCP port 88. Also before collecting network traffic logout and login again to reset the local Kerberos cache.

              Regards,

              Dimitar

              (0) 
              1. René Schubert
                Hello Dimitar,

                thank you VERY much. Disabling DES encryption for the service user was the final solution – SPNEGO is now working with Win XP & Win 7! I even didn’t have to recreate the keytab file.

                There’s just this question left: If I disable the DES encryption, does that mean that Windows XP has to use a weaker encryption method, or no encryption at all? And the other way around: If I enable DES encryption for Windows 7, does that mean that the stronger RC4-HMAC encryption is no longer used by Windows 7 for the Kerberos authentification?

                Is there a way to let Windows XP use DES and Windows 7 use RC4-HMAC encryption, or is this already the case?

                Thank you so much for your support, again!

                Regards,
                René

                (0) 
                1. Dimitar Mihaylov
                  Hi Rene,
                  – DES encryption is done with 56-bit key
                  – RC4 encryption is done with 128-bit key

                  DES is the weakest encryption algorithm supported by Windows and that’s why in the past it had to be enabled explicitly and since Windows 7/Vista SP3/Server 2008 R2 it is not supported by default but only through workarounds.

                  In your current setup RC4 is used for both Windows XP and 7 and this is stronger then pure DES or mixed DES/RC4.

                  Regards,

                  Dimitar

                  (0) 
  9. Vijay Velayutham
    Hi Holger,

    As usual is this an another good blog.

    We have already implemented the old SPNEGO in our double stack(NW7.0 SPS22) system. For Windows 7 users we have potential issue in the SPNEGO SSO.

    As a workaround to support our windows 7 users, we have have followed the steps provided in the SAP note #1457499 and deployed the files in the SPNego_AddOn_700.zip and followed all the steps in the pdf, but the SPENGO behavior is not consistent in XP and not even working for Windows 7.

    Inspite of this issue, we already have a ticket opened with SAP too, and not getting right assistance.

    Kindly help us.

    Kind regards,
    Vijay

    (0) 
    1. René Schubert
      Can you please provide us some more information? Please take a look at my comments below, compare it to your DiagTool logs and post them here, if you don’t come any further.
      (0) 
      1. Vijay Velayutham
        Hi Rene,

        The following are few details from diagtool trace file during the test in Windows 7 system.

        In that Windows 7 system, the kerberos setting as ‘No Minimum’ under Security option in GroupPolicy.

        And, in the SPNEGO add-on wizard, we have the following keys

        SPNEGOKey: code = 3,
        SPNEGOKey: code = 23,

        SPNEGO token extracted from header: SPNEGO Token [
            OID: 1.3.6.1.5.5.2
            NegTokenInit [
                mechTypes: 1.2.840.48018.1.2.2, 1.2.840.113554.1.2.2, 1.3.6.1.4.1.311.2.2.30, 1.3.6.1.4.1.311.2.2.10
                reqFlags:
                mechToken (binary): 6082066b06092a864886f71201020201006e82065a30820656a003020105a10302010ea20703050020000000a38204e6618204e2308204dea003020105a10c1b0a534552454e412e434f4da22b3029a003020102a12230201b04485454501b186f72642d7361707072746465762e736572656e612e636f6da382049a30820496a003020112a103020108a2820488048204842241968c5c30749b80756fad40ea7713f00f753df5de6640f230d3b88467bbb40f9d1f2764f47cf182eed0ae5f4d3d9885814e0a32df8dace3c6f0b132ca21ddf5cd920631bd9dcd8204785270a05bbcc55787301e8da47cb375e96f11016d967353fb2de79f960a400a9f40fbc238dc396e2e4498ca8f348aa71e04a77993fbd84eed20cb19723c49b6bc699bfe79b03d0fb5666c1baaa90f41d5bbb1e15889b4385491068f829abac4e79a7cee458b9417b8a61c749a56a65fda186acf67d3c2fcb8a03886a711ef3671e6838608b37416d2b338a5ca8f4b60ab4b409a21ad5c2695d541ed0e838e92f11dab82cc80a25c2c6fe06c27487f1703e7df6b705c13401b699da703ff726c53cba0ad6b3739457d5e9b0dddb82e8cf175dd4e08dbf4a2bdaf4f425e5c496a5d9d2ad9eaff66a7372768d62182af05e84c0e23ddfd58c624916aedbc15b489759bb880dc6d2cb2295e38cca80e90ce63b48f224261e6262af6d6c84eb0b832b31cbda6035c3a29740acefafab070b6765c9cb622e80e61b4c8a5d32d4d8ec94e98b35b32c4333ae6671ff1628208d534ec76ecddd307c106528c4a332120e524ff1a3710fa4e5164d4c4b00c0f95eac35dc318c0e9bd78607e8ed849afb945428b18f90b96f7dd7a987a1a40c4839781ad6d5c6c6493825818ac941fb11c180dfe8ccee017c905f737d1ccaa9f45fa0bde3a46afdf8c3ef398263372cad49f4e8bd00f0a860d188ffa03d42a5cdf52c36d7d82459716f07653862c38291f58d7dce782a31a9739e7abd973341f45f0d73e609cecf535f328c9577a3dcc0c692820d498eba161f64ac33ccdd228e3fe3a0a02758c8e78e6bc8fc6d84b5829abb7f2f3669eb19703776e7554f7e720c3435743d1458cfacc9bfc57e7ae2a9c44e6dcd7bf94ef0ea2cedba156795230f310717827c477d214ef7abfd486662a9e1214f843f0aa85ac9625b763f7b02d07636c8284fefbc28687f7d686c8ba92fbf9e8883fa5812280efdd5378fbdad86c46f0ab698f9bd842124677de6d05641a4a5d488b822c6bead00d5012c29c4c167afad1a728511c21dc46a8abc22683a71a6c415e1e9cedd16533d3bb70a48d32922bf4893d8a8a27ac0be9fcba052ebe8694e56f9df5645f0e21fe1bf0b89f1456ca9780dfc7536749e7b9539f30d487c918261c1fdf7421df75c4147816b3052379d58751a8b7d25939c565bf3cae7eb600f735a4961aed629589600ef43c5f021cc999e12c5d31beae3137021ebcce44b3ec545eac08f1feac6fe7a230e2ad04452fade816a450e52e2d5ae4afff28490b1f1d2b2bb11ab14da4714e13a9f4c9d18f198254e05ca7ce920411c35d293c3bcd0ee3955206d67b977a85e1f3288bfe443e21eb7882e6a502087c171346bbf682b27508faa808a263678fd2e4708b52c1b6bb156dafb8273d2502af6173b25e38bb7ce1196c249499c24a24bfe13e9fdb3499868c9a33ab5b16bc7c7bcc3fbd4d9db682a66ba7571607f19aac617a404a6cb1337ef452382bc7da7f5dfb9722ee5ef47c07210b53b8b98b44dd1f42d90f37414edb41c66516feec97e1b6d174a163c3a6cadb3567d4f24f0c3deb7d8352b915e1783f7049a482015530820151a003020112a28201480482014433cee50ba454392de08ebc4f48b0d40338ea00db8ee317c3e5ad5863b99f9d52f32493aed332d423f895b4390204450bbff7e81fb6f1d7afe2ac51b1acf72f3b3f56ceac5500e36f72fbb5a57879041b2ae00dca7aeaee4d650aa2d813cfa781a37a6c5f2b99a42dffbf935084afcb92e427ab49ecf20f99a14bf6400a66b8380382344baf56f378fff96100d9a324b17f50a7cd08887349f4d741c5756a39b6822866483388d23b4fde6656f28463a2d19602efd58b9bbda856cfd669ffb372f765dfb70476ec41619de619ef9d263a1fc548aebf8b9177bbb795754a974c412a921d3f32913dfe90e83024db476c2cb98ca58794542d7ae8a6af554025edd6fa23c4a0f0340f367bc8a9d9e659a95081b4c1d4c931b97d858ab09eb85ca7b01bc8c7bd7eadb56c08dd93a0369ea7d2d3a49b724dc607b5cbbacfd81fb939733ac4b50f
                mechListMIC (binary):
                Mech Token [
                    OID: 1.2.840.113554.1.2.2
                    AP-REQ (Kerberos) [
                        pvno: 5
                        msg-type: 14
                        ap-options: 00100000000000000000000000000000
                        ticket: Ticket [
                            tkt-vno: 5
                            realm: XYZ.COM
                            sname: [type: NT-SRV-INST, name: HTTP/xyzhost.XYZ.com]
                            enc-part: EncryptedData [
                                etype: 18 (aes256-cts-hmac-sha1-96)
                                kvno: 8
                                cipher: 0x2241968c5c30749b80756fad40ea7713f00f753df5de6640f230d3b88467bbb40f9d1f2764f47cf182eed0ae5f4d3d9885814e0a32df8dace3c6f0b132ca21ddf5cd920631bd9dcd8204785270a05bbcc55787301e8da47cb375e96f11016d967353fb2de79f960a400a9f40fbc238dc396e2e4498ca8f348aa71e04a77993fbd84eed20cb19723c49b6bc699bfe79b03d0fb5666c1baaa90f41d5bbb1e15889b4385491068f829abac4e79a7cee458b9417b8a61c749a56a65fda186acf67d3c2fcb8a03886a711ef3671e6838608b37416d2b338a5ca8f4b60ab4b409a21ad5c2695d541ed0e838e92f11dab82cc80a25c2c6fe06c27487f1703e7df6b705c13401b699da703ff726c53cba0ad6b3739457d5e9b0dddb82e8cf175dd4e08dbf4a2bdaf4f425e5c496a5d9d2ad9eaff66a7372768d62182af05e84c0e23ddfd58c624916aedbc15b489759bb880dc6d2cb2295e38cca80e90ce63b48f224261e6262af6d6c84eb0b832b31cbda6035c3a29740acefafab070b6765c9cb622e80e61b4c8a5d32d4d8ec94e98b35b32c4333ae6671ff1628208d534ec76ecddd307c106528c4a332120e524ff1a3710fa4e5164d4c4b00c0f95eac35dc318c0e9bd78607e8ed849afb945428b18f90b96f7dd7a987a1a40c4839781ad6d5c6c6493825818ac941fb11c180dfe8ccee017c905f737d1ccaa9f45fa0bde3a46afdf8c3ef398263372cad49f4e8bd00f0a860d188ffa03d42a5cdf52c36d7d82459716f07653862c38291f58d7dce782a31a9739e7abd973341f45f0d73e609cecf535f328c9577a3dcc0c692820d498eba161f64ac33ccdd228e3fe3a0a02758c8e78e6bc8fc6d84b5829abb7f2f3669eb19703776e7554f7e720c3435743d1458cfacc9bfc57e7ae2a9c44e6dcd7bf94ef0ea2cedba156795230f310717827c477d214ef7abfd486662a9e1214f843f0aa85ac9625b763f7b02d07636c8284fefbc28687f7d686c8ba92fbf9e8883fa5812280efdd5378fbdad86c46f0ab698f9bd842124677de6d05641a4a5d488b822c6bead00d5012c29c4c167afad1a728511c21dc46a8abc22683a71a6c415e1e9cedd16533d3bb70a48d32922bf4893d8a8a27ac0be9fcba052ebe8694e56f9df5645f0e21fe1bf0b89f1456ca9780dfc7536749e7b9539f30d487c918261c1fdf7421df75c4147816b3052379d58751a8b7d25939c565bf3cae7eb600f735a4961aed629589600ef43c5f021cc999e12c5d31beae3137021ebcce44b3ec545eac08f1feac6fe7a230e2ad04452fade816a450e52e2d5ae4afff28490b1f1d2b2bb11ab14da4714e13a9f4c9d18f198254e05ca7ce920411c35d293c3bcd0ee3955206d67b977a85e1f3288bfe443e21eb7882e6a502087c171346bbf682b27508faa808a263678fd2e4708b52c1b6bb156dafb8273d2502af6173b25e38bb7ce1196c249499c24a24bfe13e9fdb3499868c9a33ab5b16bc7c7bcc3fbd4d9db682a66ba7571607f19aac617a404a6cb1337ef452382bc7da7f5dfb9722ee5ef47c07210b53b8b98b44dd1f42d90f37414edb41c66516feec97e1b6d174a163c3a6cadb3567d4f24f0c3deb7d8352b915e1783f7049
                            ]
                        ]
                        authenticator: EncryptedData [
                            etype: 18 (aes256-cts-hmac-sha1-96)
                            kvno: 0
                            cipher: 0x33cee50ba454392de08ebc4f48b0d40338ea00db8ee317c3e5ad5863b99f9d52f32493aed332d423f895b4390204450bbff7e81fb6f1d7afe2ac51b1acf72f3b3f56ceac5500e36f72fbb5a57879041b2ae00dca7aeaee4d650aa2d813cfa781a37a6c5f2b99a42dffbf935084afcb92e427ab49ecf20f99a14bf6400a66b8380382344baf56f378fff96100d9a324b17f50a7cd08887349f4d741c5756a39b6822866483388d23b4fde6656f28463a2d19602efd58b9bbda856cfd669ffb372f765dfb70476ec41619de619ef9d263a1fc548aebf8b9177bbb795754a974c412a921d3f32913dfe90e83024db476c2cb98ca58794542d7ae8a6af554025edd6fa23c4a0f0340f367bc8a9d9e659a95081b4c1d4c931b97d858ab09eb85ca7b01bc8c7bd7eadb56c08dd93a0369ea7d2d3a49b724dc607b5cbbacfd81fb939733ac4b50f
                        ]
                    ]
                ]
            ]
        ]

        and…

        Login module com.sap.security.spnego.SPNEGOLoginModule from authentication stack ticket does not authenticate the caller.

        and…

        2. com.sap.security.spnego.SPNEGOLoginModule                               OPTIONAL    ok          exception             true       No key (etype: 18) for realm XYZ.COM available.

        Kind regards,
        Vijay

        (0) 
        1. Dimitar Mihaylov
          Hi Vijay,

          As far as I could see the ticket and authenticator are encrypted with etype: 18 (aes256-cts-hmac-sha1-96). This is not supported by the SPNEGO add-on version for AS Java 6.40 and 7.0. It is supported only on AS Java 7.2 and 7.3.
          In order to resolve your issue you have to disable AES128 and AES256 encryption types for the service user in Active Directory. In this case RC4 will be used for all clients – Windows XP and Windows 7.

          Regards,

          Dimitar

          (0) 
          1. René Schubert
            Is there a way to remove/edit the previous post of Vijay? Now I need to scroll to the right, to read all other comments, because of the long token and ciphers… Thanks!
            (0) 
          2. Vijay Velayutham
            Hi Dimitar,

            We have disable the AESxxx encryption for the service user in ADS as per your suggestion, and now IE8.0 in windows 7 system works fine with the SPNEGO SSO, where as Firefox(v – 3.6.10) shows just the Portal login screen without any errors.

            Note:
            In firefox, userid and password were saved for the portal and we have done the configuration settings specified in the SPNEGO Configuration Guide.pdf for Firefox browser, in spite of this when we try to access the Portal URL using the Firefox it shows only the Portal login screen without any errors.

            Please help.

            Kind regards,
            Vijay

            (0) 
            1. Dimitar Mihaylov
              Hi Vijay,
              This sounds line configurtion problem in Firefox. Please check the following:
              1. The host name you use to access the server is entered in Firefox option “network.negotiate-auth.trusted-uris”. Double check what host you do use – short name, FQDN, etc.
              2. Use HTTPWatch or similar tool to check if the browser sends SPNEGO token to the server – e.g. HTTP header “Authorization: Negotiate Y…”.
              3. If the setting in FF are ok, the browser sends SPNEGO token to the server then collect server traces with the web diagtool from SAP Note 1045019 and try to analyze them. If you see some errors/warnings and think they are relevant please paste here.

              Regards,

              Dimitar

              (0) 
              1. Vijay Velayutham

                Hi Dimitar,<br/><br/>Thanks for your response.<br/><br/>I have used webdiagtool in both the cases such as when I tested using Firefox(3.6.10) and IE(8.0) in windows 7 system.<br/><br/>From the diagtool traces, I found the following<br/><br/>When I tested with IE8, I have found the following entry in the log as follows:<br/><br/>Authorization header read from HTTP request: Negotiate YIIHqAY….<br/><br/>When I tested with Firefox(Note: firefox configuration were OK as per the SPNEGO Configuration Guide.pdf), I have found only the following entry in the log as follows:<br/><br/>Authorization header read from HTTP request: Vijay

                (0) 
                1. Dimitar Mihaylov
                  Hi Vijay,

                  The missing auhtorization header means that Firefox does not send SPNEGO token to the server. There should be some configuration error in the Firefox browser. Could you please double check the value of option “network.negotiate-auth.trusted-uris”. Is the host name you use to access the AS Java included there? If there are multiple entries could you please remove them and leave only this single host? Also check if proxy is used and temporary disable it.

                  Regards,

                  Dimitar

                  (0) 
                  1. Vijay Velayutham
                    Hi Dimitar,

                    I have verified this entry “network.negotiate-auth.trusted-uris” in firefox and that is having right AS Java host name mentioned.

                    And, I have tried with disabling the proxy too.

                    But I have no chance in the behavior of Firefox Version(3.6.10) browser.

                    Kind regards,
                    Vijay

                    (0) 
                    1. Dimitar Mihaylov
                      Hi Vijay,

                      I’m running out of ideas. If you are sure it is not a configuration issue then:
                      – try from another computer joined in the domain
                      – freshly install FF 3.6.11 on another computer and try from there
                      – uninstall FF, reboot, and freshly install 3.6.11 on your computer and try again

                      However the symptom to not send any token (neither SPNEGO nor NTLM) is in most of the cases caused by a configuration issue in the browser.

                      Regards,

                      Dimitar

                      (0) 
                  2. Vijay Velayutham
                    Hi Dimitar,

                    The user is the VPN user and does the VPN access influence in SPNEGO add-on behavior when the user is using Firefox browser while access the Portal?

                    Note:
                    IE8.0 works like charm, but the issue is with Firefox(V 3.6.11) only.

                    Kind regards,
                    Vijay

                    (0) 
                    1. Dimitar Mihaylov
                      Hi Vijay,

                      I do not know if the VPN setup affects the Firefox browser. Have you tried to use Firefox from the local Intranet? Does it work in this case?

                      Regards,

                      Dimitar

                      (0) 
                      1. Vijay Velayutham
                        Hi Dimitar,

                        Thanks for your precise guidance to resolve our issues.

                        Now the Firefox issue has been resolved.

                        But, we wanted to go over the configuration steps once again before we implement this solution in our PROD landscape, Please provide us a consolidated steps that needs to be followed especially in the ADS side by our ADS admin.

                        FYI, we already have a service user in ADS but we wanted to remove that and we are planning to follow the instructions starting from service user creation,…etc and disabling the encryption types in ADS

                        Thank you.

                        Kind regards,
                        Vijay

                        (0) 
                        1. Dimitar Mihaylov
                          Hi Vijay,

                          If you start from scratch then just follow the steps described in this blog. I think the major problem that you have encountered was that the service user was enabled for DES encryption types. This setting prevented it from working with Windows 7. But if you create a new service user this won’t be the case so just follow the instructions and it shall work without any troubles.

                          Regards,

                          Dimitar

                          (0) 
          3. Eamonn O'Sullivan
            We have a NW v7 running a portal where there is as a field called Customized Information on the portal, this does not look at the backend.
            Under this tab on the portal page it says krb5principlename – and in here we add the user’s details to logon via SSO.

            In the OLD SPNego wizard – Users can log on from multiple domains etc using windows XP.

            However I have now updated to try and use the new SPNEGO for windows 7, but cannot get it to use this field.

            I have tried most settings etc, but to no avail,
            Any chance you point me in the right direction top get this working?

            (0) 
  10. Arnaldo Acc Calcada
    Hello!

    I have already implemented the old SPNEGO in our NW7.1 SP3 Portal system.
    The UME is in a separate ABAP system ECC 6.0 (Enhancement Package 4/ NW 7.1).

    For Windows 7 users we have potential issue in the SPNEGO SSO.

    I have followed the steps provided in the SAP note #1457499 and deployed the files in the SPNego_AddOn_700.zip and followed all the steps in the pdf, but on the User Mapping tab, I don´t know exactly what Mapping Mode/Source do I should use.

    Using ‘principal only’ and ‘logon id’ i have the error: “User authentication failed” in the Portal logon screen.

    Can anyone help me?
    Thanks.

    (0) 
      1. Arnaldo Acc Calcada
        Hi Dimitar!

        Thanks for your reply.
        With the old SPnego I used Prefix-based.
        KPN Prefix: uniquename
        KPN Suffix: dn

        Another info: all users have the same Id in the AD and UME (SAP ABAP).

        Regards.
        Arnaldo Calçada.

        (0) 
        1. Dimitar Mihaylov
          Hi Arnaldo,

          If you have a single domain configuration then I would recommend to use mapping mode “principal only” with source “logon id”. This means that the SPNEGO login module will take only the principal (user id) from the received Kerberos Principal Name (KPN) – e.g. “john” from “john@COMPANY.COM“, and search afterwards in UME for user with such logon id.

          Regards,

          Dimitar

          (0) 
  11. Daniel Rothmund
    Hello ,

    since we have updated to the new spnego . We have trouble with UME Users from location without spnego. When we change the password to a inital password for a special UME User.
    And the users try to login with the new inital password the logon screen shown again. It look like the password is wrong but it is 100% right .

    The spengo Settings are :
    Mapping Mode : principa only
    Source : logon id

    Very strange

    Regards

    (0) 
  12. Navaid Rafiq
    We are on portal 7.01 SP3 on AIX and trying to get SPNego work first using old spnego but on failure SAP support recommended to go for the new one. We use MS AD as user storage on windows 2003 server and our clients use XP. Our Domain controller is on A-internal.net, while users are in B-internal.net & C-internal.net and A-internal.net is a global catalog which can see both B & C domains. Only service user was created in A-internal so we are using single domain data config file not multiple domain file.

    When we implemented old spnego we started getting windows pop-up for username/password on hitting portal URL. We are getting that in New SPNego too (following note 1457499) – probably that pop-up still coming from old one as we didn’t uninstall or undo anything to take out old one before applying new. We get to the portal logon screen regardless we provide user login info or cancell that pop-up. Diagtool shows that the SPNEGOLoginModule was triggered but failed to authenticate the user as follow;

    Login Module                                                              
    1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule      SUFFICIENT  ok  false   true      
            #1 ume.configuration.active = true
    2. com.sap.security.spnego.SPNEGOLoginModule    OPTIONAL  ok   exception     true     Trigger SPNEGO authentication.
    3. com.sap.security.core.server.jaas.CreateTicketLoginModule      SUFFICIENT  ok     false        true      
            #1 ume.configuration.active = true
    4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule   REQUISITE   ok          false                 false     
    5. com.sap.security.core.server.jaas.CreateTicketLoginModule               REQUISITE   ok          false                 true      
            #1 ume.configuration.active = true

    and the list of exceptions in the diagtool is;

    getLoggedInUser
    [EXCEPTION]
    com.sap.engine.services.security.exceptions.BaseLoginException: Cannot authenticate the user.
    at com.sap.engine.services.security.login.ModulesProcessAction.run(ModulesProcessAction.java:180)
    at java.security.AccessController.doPrivileged(AccessController.java:246)
    at com.sap.engine.services.security.login.FastLoginContext.login(FastLoginContext.java:181)
    at com.sap.engine.system.SystemLoginModule.login(SystemLoginModule.java:90)
    .
    .
    .
    .
    .
    at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
    at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
    Caused by: javax.security.auth.login.LoginException: Trigger SPNEGO authentication.

    Unfortunately not getting good help from SAP. If you or anyone please show me a right direction if I am making any mistake or missing anything then it it will be greatly appreciated.
    Thanks

    (0) 
    1. Dimitar Mihaylov
      Hi Navaid,

      Check that the portal host name is registered in the Local Intranet sites of the browser. SPNEGO authentication is working by default only if the host is in the Local Intranet. If this is already the case I would propose to open a support ticket with SAP, attach diagtool and HTTPWatch traces. Send me also the number so that I can check it.

      Regards,

      Dimitar

      (0) 
      1. Navaid Rafiq
        Hi Dimitar,
        Sorry for late reply as I have been on vacation since then. I confirmed earlier that hostname is registered in a way that if portal is myportal.domain.com then in Local Intranet sites it is listed as *.domain.com. I attached all of those supported files to the ticket# 651930 / 2010.

        Any help from your side would be greatly appreciated.
        Thanks

        (0) 
        1. Dimitar Mihaylov
          Hi Navaid,
          As far as I could see from the description in the support ticket the step to assign an SPN to the service user is failing. This could be because you are executing the command with user that does not have permissions to do this. Please check this with your AD administrator. Without an SPN assigned to the service user the SPNEGO authentication won’t work.
          Regards,
          Dimitar
          (0) 
            1. Dimitar Mihaylov
              The service user does not need special permissions. The user who runs the script with the “setspn” command needs to be an AD administrator. As already written if the SPN is not assigned to the service user the SPNEGO authentication won’t work.
              (0) 
  13. Rosun Raj Kumar
    Hi Holger,

    I am trying to deactive Kerberos so that I could log in as ADMINISTRATOR or as few other test users. UME is integrated to LDAP. Including the GET paramter in the URL doesnt seem to help both in IE and FF.

    Kindly help.

    Thanks and regards,
    Rosun

    (0) 
                    1. Rosun Raj Kumar
                      Hi Dimitar,

                      I am able to deactivate Kerberos in IE by unchecking ‘Enable Integrated Windows Authentication’. But the problem here is even the default login by ID and password also gets deactivated. This remains the same until I explicitly go to VA and remove SPNEGOLoginModule and rearrange the login modules.

                      Any inputs at this stage?

                      Regards,
                      Rosun

                      (0) 
                      1. Dimitar Mihaylov
                        Hi Rosun,

                        As already proposed please open a support ticket with SAP so that the colleagues could investigate the problem. If you want you can reply with the ticket number here so that I could forward it to them.

                        Regards,
                        Dimitar

                        (0) 
                        1. Rosun Raj Kumar
                          Hi Dimitar,

                          I happen to run diagtool today. The trace says:
                          com.sap.engine.services.security.exceptions.BaseLoginException: Call logout before login.

                          I have lodged an OSS message for the same.

                          Regards,
                          Rosun 

                          (0) 
                          1. Rosun Raj Kumar
                            Hi Dimitar,

                            It was a problem with my login modules. I had only one CreateTicketLoginModule in my stack. SAP advised me to add another one at the end. I am able to login with alternative ID’s too now.

                            Thanks a lot!
                            Rosun

                            (0) 
  14. Jorge Flores
    Hi guys, this blog has been of great help before. I deployed and successfully configured the new SPNego module, however I’m now facing a new problem.

    We needed to upgrade the portal to the newest SP (in this case SP23 for NW 7.0), but JSPM throws an error while deploying the LM-Tools I get Error: Aborted: software component ‘LM-TOOLS’/’sap.com’/’MAIN_APL70P23_D’/’1000.7.00.23.0.20101122115451’.

    On further investigation, I see that it it fails while trying to upgrade sap.com/tc~sec~auth~spnego~wizard, I get java.rmi.RemoteException: Cannot deploy application sap.com/tc~sec~auth~spnego~wizard, Reason: Clusterwide exception.

    Any of you have experienced similar problem? any ideas?

    (0) 
    1. Dimitar Dimkin
      Hi Jorge,

      Undeploy the “sap.com~spnego.cfg.wd.ear” application from the add-on solution and then continue with the upgrade. Then you should face no more problems related to the SPNego wizard.

      Best regards,
      Dimitar Dimkin

      (0) 
      1. Paul Murgatroyd
        Hi Dimitar,

        Can you please clarify something for me, as we have had the same issue when applying NW 7.01 SP08.

        After undeploying sap.com~spnego.cfg.wd.ear and then deploying the NW 7.01 SP08, we appear to have losr the spnego2 config wizard. We now get a “404 not found” error.
        In addition, according to Note 1457499, the new SPNego solution is included in NW 7.01 SP08. If we install a new NW system out of the box and patch it tp NW 7.01 SP08, do we need to deploy the SPNego Add-On as per Note 1457499. The reason I ask is that we also undeployed spnego.lm and spnego.cfg before applying the Support Pack, but there does not appear to be any spnego.lm or spnego.cfg in NW 7.01 SP08. Has spnego been delivered differently in the Support Pack vs the Add-On?

        (0) 
  15. Vipul Patel
    Hi Dimitar
    I have configured SPNEGO as mentioned in the SNote attached PDF on a trial Netweaver 7.01 SPS3 installation (JRE 1.4.2.26) with ABAP datasource without much luck (ABAP datasource is in sync with ADS accounts).

    Using Diagtool I have found that SPNegoLoginModule receives NTLM token in the header. All the requirements are confgured in IE v7 to avoid NTLM issue and correct Hotfix has been applied to the OS (confirmed that via regedit). Kerbtray reveals that I do have a valid kerberos ticket with RC4-HMAC encryption.

    I do notice an additional logon MS window pop-up (with ‘remember my password’ checkbox). I have entered both correct and incorrect passwords and don’t receive any feedback however on both occassions I am thrown onto portal logon screen which only accepts ABAP passwords. When I enter ADS credentials on this screen nothing happens and no feedbacks received still.

    Any help would be appreciated.

    Thanks
    Vipul

    (0) 
    1. Dimitar Mihaylov
      Hi Vipul,
      Use Wireshark to see why the client fails to obtain a Kerberos token from the domain controller. Before running the rool either logof/logon or purge the cached tickets with kerbtray tool.
      In most of the cases a browser popup for credentials appears because the system is not added to the local Intranet sites. Check also these settings of your browser.
      Regards,
      Dimitar
      (0) 
  16. Rob Bajan
    Great post, but I’m still not sure how to add second AD domain with spnego2.
    Kerberos is working for 1st domain ex. D1.COM:
    domain: D1.COM
    service account: D1\s1d1
    userPrincipalName: host/sapweb.d1.com@D1.COM
    servicePrincipalName: HTTP/sapweb.d1.com
    ktab -a host/sapweb.d1.com@D1.com -k ktd1.keytab
    ktab -a HTTP/sapweb.d1.com@D1.com -k ktd1.keytab

    To add the second realm, how do I set up service account and keytab file?
    Is this correct:
    domain: D2.COM
    service account: D2\s1d2
    userPrincipalName: host/sapweb.d1.com@D2.COM
    servicePrincipalName: HTTP/sapweb.d1.com
    ktab -a host/sapweb.d1.com@D2.com -k ktd2.keytab
    ktab -a HTTP/sapweb.d1.com@D2.com -k ktd2.keytab

    After I run spnego2 Kerberos is working for D1.COM users, but for D2.COM users I get the error:
    Could not validate SPNEGO token. Reason: Checksum error.

    Do I need to run keytab logged in to D2.COM domain?
    Any other comments regarding the setup?
    Thanks!

    (0) 
    1. Dimitar Mihaylov
      Hi Rob,
      I would propose to check the blog on how to create and configure service user in Active Directory. How to create a keytab file is described in the PDF attached to note 1457499. The number of domains/realms does not affect this procedure.
      I strongly recommend not to use “ktpass” at the domain controller because of the many issues with it. It seems that you have used it because of the “strange” userPrincipalName-s. If necessary delete the existing ones and create new ones.
      In your case the keytab files should contain keys for s1d1@D1.COM and s1d2@D2.COM.

      Regards,
      Dimitar

      (0) 
  17. Helge Stührmann
    Great post. But we have a problem regarding the mapping to our ADS data source.
    We configured userprincipalname as logon id.
    Userprincipalname in our ADS is identical to the emailadress, for example user.n@mycompany.de

    Now using new SPNego login module, no mapping method works. It comes with principal=user_n (samaccountname) and realm=DE.MYCOMPANY-NET.DE.

    Any help?

    (0) 
    1. Dimitar Dimkin
      Hi Helge,

      Try using mode=”principal@REALM” and source=”user attribute”, where the value of the attribute would be “userprincipalname”. This means that the whole string that arrives, “user.n@mycompany.de“, will be searched for in the “userprincipalname” attribute.

      Best regards,
      Dimitar

      (0) 
      1. Helge Stührmann
        Hi Dimitar,

        I tried to map to userprincipalname.
        But our microsoft staff defined upn as the user.n@mycompany.de.
        So there is no user found, searching by user_n@DE.MYCOMPANY-NET.DE.

        SSO works by using mapping method principal only and logon alias. But this is not correct, cause it could happen, that we have the same logon alias in different domains.

        I thought about the option principal AND realm. But it is not possible to choose different ADS Datasource attributes, for example sammaccountname and cn.

        Best regards
        Helge

        (0) 
        1. Dimitar Dimkin
          Hi Helge,

          Well, it all depends on what unique attributes you have and how they relate to the KPN used by Kerberos – as you say, user_n@DE.MYCOMPANY-NET.DE. If you separate the string, the value of principal will be “user_n” and the value of REALM – “DE.MYCOMPANY-NET.DE”. If the “samaccountname” and the “cn” attributes have the correct values assigned to them and if they are mapped to UME attributes, then you can use this mode, it should work. If not, you have to find an attribute which is unique.

          Best regards,
          Dimitar

          (0) 
        1. Helge Stührmann
          Hi Dimitar,

          the section                    
                                  
                                  
                                  
                             

          is missing in our datasource file. Could I just insert it?

          Best Regards
          Helge

          (0) 
          1. Dimitar Mihaylov

            Hi Helge,                              <physicalAttribute name=”null“/>                             <physicalAttribute name=”null“/>                             <physicalAttribute name=”null“/><br/>                        </attribute><br/>                   </nameSpace>                    <br/>               </principal><br/><br/>Regards,<br/><br/>Dimitar

            (0) 
            1. Helge Stührmann
              Hi Dimitar,

              I changed the xml-file as you told.
              But SPNego fails again. This is what the diagtool says:

              15:05:29:297 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~p.security.spnego.cfg.SPNEGOUserMapping User mapping SPNEGOUserMapping: mode = principal_and_REALM, source = ads converted to user mapping filter [[principal],[realm]]
              15:05:29:298 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~m.sap.security.spnego.SPNEGOLoginModule User mapping filter to be used for resolving local user: [principal],[realm]
              15:05:29:298 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~m.sap.security.spnego.SPNEGOLoginModule KPN extracted from encrypted ticket: stuehrman_h@DE.UHLMANN-NET.DE
              15:05:29:303 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil User mapping filter [[principal],[realm]] will be used to map KPN [stuehrman_h@DE.UHLMANN-NET.DE] to a local user.
              15:05:29:304 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil SPNEGOUserMapping case: [principal],[realm]
              15:05:29:305 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil Searching for user by account attributes: [[namespace: com.sap.security.core.authentication, name: principal, value: stuehrman_h], [namespace: com.sap.security.core.authentication, name: realm, value: DE.UHLMANN-NET.DE]]
              15:05:29:331 Warning Guest SAPEngine_Application_Thread[impl:3]_37 ~urity.spnego.util.SPNEGOUserMappingUtil User not found by account attributes: [[namespace: com.sap.security.core.authentication, name: principal, value: stuehrman_h], [namespace: com.sap.security.core.authentication, name: realm, value: DE.UHLMANN-NET.DE]]
              15:05:29:332 Debug Guest SAPEngine_Application_Thread[impl:3]_37 ~es.security.authentication.logincontext Login module com.sap.security.spnego.SPNEGOLoginModule from authentication stack ticket does not authenticate the caller.

              (0) 
              1. Dimitar Mihaylov
                Hi Helge,

                Could you please open a support ticket with SAP and send me the number? Please attach the used datasource file so that I could check it. Meanwhile I’ll write a small JSP page which shows the “principal” and “realm” account attributes so that you can check if they are at all retrieved from AD and and if yes what their values are. Unfortunately the standard User Admin application cannot show account attributes and cannot be used in this case.

                Regards,

                Dimitar

                (0) 
        2. Helge Stührmann
          Hi Dimitar,

          the section                    
                                  
                                  
                                  
                             

          is missing in our datasource file. Could I just insert it?

          Best Regards
          Helge

          (0) 
  18. Sasi Reddy
    Hi

    I read most of the blogs and everyone talks about SPNEGO set up with portals UME being LDAP. Our portal has database as the UME and I followed the steps specified and it doesn’t work (In the logs I find that NTLM token is found in the header and unable to authenticate). So my question is will the SSO work for CE 7.2 with Database UME?

    (0) 
    1. Dimitar Mihaylov
      Hi Sasi,
      The SPNEGO works with any UME persistency. It is just a matter to select the right mapping mode – for example if the user ids in the AD and in UME database are matching then select mapping mode “principal only” with source “logon id”.
      However the error that you get with the NTLM token is not related to how users are mapped because the server do not even receives a valid SPNEGO token. You have to check the configuration in the AD and in your browser:
      – do you use the correct hostname to access the CE system
      – is SPN registered in AD with this hostname
      – is the SPN unique in AD, e.g. assigned to a single user
      – do you use HTTP proxy
      Also you may check what is happening on the wire and why the browser fails to obtain Kerberos ticket from the domain controller:
      – logoff/logon or alternatively purge Kerberos tickets using Kerbtray
      – start Wireshark
      – repeat the test to logon to the CE system
      – stop Wireshark
      – filter the collected data on TCP or UDP port 88 and check what KRB5 messages were exchanged with the domain controller

      Regards,

      Dimitar

      (0) 
    2. Sasi Reddy
      Thanks Dimitri, this simply worked. Awesome.

      We had 2 service accounts registered for the same SPN, once we removed one service account, it worked just fine. New SPNego is really simple and easy to set up.

      I was trying to use Logon Alias to do the mapping between AD user account and portal user account, but the Logon Alias says “Logon Alias is mapped to Logon ID”. Is there anyway that I can use a different value in this Logon Alias? Please let me know.

      Thanks
      Sasi

      (0) 
  19. Paul Tomlinson
    Hi Holger,

    Good blog.  My client is using NetWeaver CE 7.1 (with SAP Sourcing on top).  From the documentation it suggests that this is not supported, but other comments suggest it will work.  Does this work on CE 7.1?

    Many Thanks

    Paul

    (0) 
    1. Paul Tomlinson
      Please ignore my comment above – I’m being thick and reading the wrong note (1488409 suggests that 7.1 / 7.11 are not supported).  I see in note 1457499 it is supported.

      Paul

      (0) 
    1. Amit Saini
      Resolved with modification in datasource xml.

      Changing with both Authenticationa and authorization to Email, SPNEGO worked for me.

      (0) 
  20. Ilgvars Lopatko
    Hi,

    Thanks for great blog.

    And I hope you will give me some advice why this is not working for me.
    I am trying to configure SAP Portal to login without login screen. I made all steps according to note 1488409 – New SPNego Implementation.
    Java SupPack level is 24.

    But after all steps portal login screen didn’t change, it still asking name/pass.

    How and where can I look, why SPNego configuration is not working?
    ABAP part has BASIS SupPack 22 level – can this be  a reason for problems?

    Thanks,
    Ilgvars

    (0) 
    1. Dimitar Dimkin
      Hi Ilgvars,

      Unfortunately without traces I can’t say anything. You can deploy the Web diagtool from Note 1045019 on the AS Java, start it with the locations described in Example 1 and collect the traces while reproducing the problem. If you are not able to figure out what is wrong by looking at them, the best option is to open a new OSS message in component BC-JAS-SEC, describe how you configured the engine and attach the generated ZIP file.

      Best regards,
      Dimitar

      (0) 
      1. Ilgvars Lopatko
        Hi Dimitar,

        I have reached a situation when portal logon screen says “User authentication failed”, before entering username and password.
        I would be very grateful if you would look at the following errors, may be you have some ideas what is wrong.

        Mapping mode is Principal only/Logon alias

        file ./j2ee/cluster/server0/log/defaultTrace.5.trc contains:

        *——————————————
        #1.#00096BEEC10E007400000003001250240004AC0DE4C60D66#1315075579579#com.sap.security.core.server.jaas.spnego.krb5.KrbApReq#sap.com/irj#com.sap.security.core.server.jaas.spnego.krb5.KrbApReq#J2EE_GUEST#0##n/a##033c6908d65d11e0b61c000008be0ba6#SAPEngine_Application_Thread[impl:3]_31##0#0#Error##Plain###Clock skew too great. Client time: 1315075949000#
        #1.#00096BEEC10E007400000004001250240004AC0DE4C60F71#1315075579579#com.sap.security.core.server.jaas.SPNegoLoginModule#sap.com/irj#com.sap.security.core.server.jaas.SPNegoLoginModule#J2EE_GUEST#0##n/a##033c6908d65d11e0b61c000008be0ba6#SAPEngine_Application_Thread[impl:3]_31##0#0#Error##Java###Could not validate SPNEGO token.
        [EXCEPTION]
        {0}#1#java.lang.Exception: Clock skew too great. Client time: 1315075949000
                at com.sap.security.core.server.jaas.spnego.krb5.KrbApReq.throwValidationException(KrbApReq.java:112)
                at com.sap.security.core.server.jaas.spnego.krb5.KrbApReq.validate(KrbApReq.java:105)
                at com.sap.security.core.server.jaas.SPNegoLoginModule.parseAndValidateSPNEGOToken(SPNegoLoginModule.java:294)
                at com.sap.security.core.server.jaas.SPNegoLoginModule.processAuthorizationHeader(SPNegoLoginModule.java:439)
                at com.sap.security.core.server.jaas.SPNegoLoginModule.login(SPNegoLoginModule.java:140)
                at com.sap.engine.services.security.login.LoginModuleLoggingWrapperImpl.login(LoginModuleLoggingWrapperImpl.java:194)
        *——————————————

        file ./j2ee/cluster/server0/log/system/server.3.log contains:

        *——————————————

        #1.#00096BEEC10E006100000009001250240004AC0E7EBA2383#1315078162490#/System/Security/Authentication#sap.com/irj#com.sap.engine.services.security.authentication.logincontext#J2EE_GUEST#0##n/a##06c6bb7dd66311e0972c000008be0ba6#SAPEngine_Application_Thread[impl:3]_38##0#0#Info#1#com.sap.engine.services.security.authentication.logincontext#Plain###LOGIN.FAILED
        User: N/A
        Authentication Stack: ticket

        Login Module                                                               Flag        Initialize  Login      Commit     Abort      Details
        1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule             SUFFICIENT  ok          false                 true      
        2. com.sap.security.core.server.jaas.SPNegoLoginModule                     OPTIONAL    ok          exception             true       Trigger SPNEGO authentication.
        3. com.sap.security.core.server.jaas.CreateTicketLoginModule               SUFFICIENT  ok          false                 true      
        4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule   REQUIRED    ok          false                 false     
        5. com.sap.security.core.server.jaas.CreateTicketLoginModule               REQUIRED    ok          false                 true      
        6. com.sap.engine.services.security.server.jaas.ClientCertLoginModule      SUFFICIENT  ok          false                 false      #
        #1.#00096BEEC10E00650000000F001250240004AC0E7EBAA3AC#1315078162523#/System/Security/Authentication#sap.com/irj#com.sap.engine.services.security.authentication.logincontext#J2EE_GUEST#0##n/a##06cb6e35d66311e0c2e0000008be0ba6#SAPEngine_Application_Thread[impl:3]_8##0#0#Info#1#com.sap.engine.services.security.authentication.logincontext#Plain###LOGIN.FAILED
        User: N/A
        Authentication Stack: ticket

        Login Module                                                               Flag        Initialize  Login      Commit     Abort      Details
        1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule             SUFFICIENT  ok          false                 true      
        2. com.sap.security.core.server.jaas.SPNegoLoginModule                     OPTIONAL    ok          exception             true       Could not validate SPNEGO token. Reason: Clock skew too great. Client time: 1315078532000
        3. com.sap.security.core.server.jaas.CreateTicketLoginModule               SUFFICIENT  ok          false                 true      
        4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule   REQUIRED    ok          false                 false     
        5. com.sap.security.core.server.jaas.CreateTicketLoginModule               REQUIRED    ok          false                 true      
        6. com.sap.engine.services.security.server.jaas.ClientCertLoginModule      SUFFICIENT  ok          false                 false      #
        #1.#00096BEEC10E006500000012001250240004AC0E7EBAC4AB#1315078162531#/System/Security/Authentication#sap.com/irj#com.sap.engine.services.security.authentication.logincontext#J2EE_GUEST#0##n/a##06cb6e35d66311e0c2e0000008be0ba6#SAPEngine_Application_Thread[impl:3]_8##0#0#Info#1#com.sap.engine.services.security.authentication.logincontext#Plain###LOGIN.FAILED
        User: N/A
        Authentication Stack: ticket

        Login Module                                                               Flag        Initialize  Login      Commit     Abort      Details
        1. com.sap.security.core.server.jaas.EvaluateTicketLoginModule             SUFFICIENT  ok          false                 true      
        2. com.sap.security.core.server.jaas.SPNegoLoginModule                     OPTIONAL    ok          exception             true       Could not validate SPNEGO token. Reason: Clock skew too great. Client time: 1315078532000
        3. com.sap.security.core.server.jaas.CreateTicketLoginModule               SUFFICIENT  ok          false                 true      
        4. com.sap.engine.services.security.server.jaas.BasicPasswordLoginModule   REQUIRED    ok          false                 false     
        5. com.sap.security.core.server.jaas.CreateTicketLoginModule               REQUIRED    ok          false                 true      
        6. com.sap.engine.services.security.server.jaas.ClientCertLoginModule      SUFFICIENT  ok          false                 false      #
        *——————————————

        Next week I will open OSS message, but I am not sure SAP will help because they will say it is not error.

        Thanks in advance,
        Ilgvars

        (0) 
        1. Dimitar Mihaylov
          Hi,

          The clock on your client machine and the clock on the AS Java system are not synchornized. The time difference is greater than 5 minutes. If the clocks seems to be in sync then especially check for different time zones, day light saving settings etc.

          Regards,

          Dimitar

          (0) 
          1. Ilgvars Lopatko
            Hi Dimitar,

            I can not express how much I am grateful for this advice. Indeed, time difference was 7 min. After time correcting automatic login works fine. Strange that SSO for SAP ABAP instance worked without problems with this difference.
            Thank you very much once more. Last thing for me is test current configuration on Windows 7 workstations.

            Thanks,
            Ilgvars

            (0) 
  21. Abraham Vadillo Nah
    In the previous version we could set the clockskew parameter on the krb5.conf file for the time difference between LDAP and SAP Server, On this version where I can set this parameter?
    I looked for this file krb5.conf but in this new version doesn’t used it.
    Best Regards
    (0) 
  22. diego quintana
    Hi Holger,

    This is my first time configuring SPNego and I would like to confirm with you the correct procedure to use. We are using EP (7.01 SPs 08) which uses an ABAP BI (7.01 SPs 08) system as its UME data source.

    If I’m not wrong I should follow the steps described in “SPNego Configuration Guide” (included in “Note 1488409 – New SPNego Implementation”). Also, as per your blogs, this one (“New SPNego login module – just around the corner”) is the one I should use as reference.
    My question maybe a silly one is……the steps described in docs “Configuring SPNego with ABAP data source” and “Configuring SPNego with ABAP data source –part 2” are not longer needed for this new Spnego version right? Specially those involving the config tool? Following only this blog is ok?

    The other question …Does this procedure described for the New Spnego also work on my scenario (UME in ABAP database)?

    Thanks for your help and for all these helpful blogs.

    Regards

    (0) 

Leave a Reply