Skip to Content
Technical Articles

Kerberos/SPNEGO for SAP AS ABAP in a Multi-Domain Environment

This blog explains what to consider when implementing the Kerberos/SPNEGO scenario for SAP Application Server ABAP using the SAP Single Sign-On product in a multi-domain environment.



Windows domain and forest containers are used to meet different authentication and authorization requirements in the corporate landscape, like for example centralizing resource management, organizing network objects into a logical hierarchical structure, implementing rules for sharing resources across a network, etc. Domain containers can be segregated into Domain Name System (DNS) namespace hierarchies known as domain trees. The domain tree hierarchy is based on trust relationships.

When implementing Kerberos/SPNEGO using the SAP Single Sign-On product for a multi-domain environment, it is necessary to have in mind some specifics that are important, depending on the trust availability between the domains. In this blog, I will represent the specifics, using these two options:

  • Option 1: There is a trust relationship between Microsoft domains.
  • Option 2: There is no trust relationship between Microsoft domains.

Now lets see what you have to consider for these two options.


Service Account

The implementation of Kerberos/SPNEGO using the SAP Single Sign-On product requires a service account to be created on the Windows domain controller. This service account is used for the Kerberos-based authentication.

Option 1:

When there is a trust relationship between the domains it is enough to create a service account only on the central domain.

Option 2:

When there are domains in the landscape that are not trusted and the Kerberos-based single sign-on has to be working also for users from these domains, you have to make sure that a service account is created also on every non-trusted Windows domain controller.


Service Principal Name

A service principal name (SPN) is the name by which a client uniquely identifies an instance of a service. The SPN is configured, using ADSI Edit (LDAP editor for managing objects and attributes in Microsoft Active Directory). The Service Principal Name is required for the SNC configuration or SPNEGO for ABAP and is used to provide Kerberos service tokens to the requested users.

Option 1:

When there is a trust relationship between the domains, it is enough to create a service account and to configure the respective Service Principal Name for this account only on the central domain. Such a configuration is sufficient because the Microsoft technology ensures that users from all trusted domains are visible in the central domain. It is also ensured that the authentication chain will reach the required trusted domain, where the KDC (Kerberos Key Distribution Center) will issue the Kerberos token to this user for the requested service, coming from the SAP AS ABAP system.

Option 2:

When the trust between the domains is missing, you need to configure service accounts on all non-trusted domains and make sure that one and the same Service Principal Name is configured for these service accounts. This configuration is necessary because non-trusted domains work independent from each other and every one of them has to be configured to recognize the service, coming from the SAP AS ABAP system.


A common configuration mistake is to use different Service Principal Names on different domains. Even if it is possible to create different service account names on different Microsoft domain controllers, you have to make sure that these accounts are configured with one and the same Service Principal Name.


Kerberos Keytab

On the SAP ABAP server side, the implementation of SNC with Kerberos/SPNEGO requires the generation of a Keytab file with the SPNEGO or SNCWIZARD transactions, available with the new AS ABAP versions (for more details use the link to the documentation at the end of the blog). The Keytab includes information about the User Principal and the password of the service account for this service, created on the Windows domain controller.

For more details, see: Using the Single Sign-On Wizard to Configure SNC and SPNego.

Option 1 and Option 2:

Irrespective of the trust existence between the domains, when we have more than one Microsoft domain to integrate into our Kerberos/SPNEGO implementation, it is necessary to create a Keytab for every one of these domains. Such a configuration is required because the SAP AS ABAP server has to be configured to trust every one of these domains.


A common configuration mistake made for the Kerberos Keytab generation is the wrong typing of the User Principal. Please note that the User Principal from the Active Directory has the following format:

sAMAccountName@WINDOWS2000-DOMAIN, where sAMAccountName is case sensitive and the domain part is in upper case. Here is an example: SAPServiceUserABC@IT.CUSTOMER.DE.


More Information

For more details about SNC/SPNEGO, see the following documentation:

SNC Kerberos Configuration

Using the Single Sign-On Wizard to Configure SNC and SPNego


You must be Logged on to comment or reply to a post.
  • Hello together,

    here is the experience I’ve made:

    Option 1: Trust relationship between domains

    • In scenarios where you have one forest with multiple domains (transitive trusts), you’ll only need to create the service account and register the SPN in the forest root domain (or even in any of the domains). This way your AS ABAP will have just one Keytab entry which you have to create in transaction SPNEGO.

    Option 2: No trust relationship between domains 

    • If there are multiple domains and no trust exists between them, you need to create one service user (representing your SAP application server) and SPN(s) within each domain. This way your SAP systems may have multiple keytabs for the different domains or forests, but that’s fine.

    It is possible to use Kerberos authentication for SAP SSO even in an environment with multiple AD forests and domains. In such an environment, it is the best to have a trust relationship between the different domains and forests. Every user is able to obtain the required authentication tickets from the Domain Controller of his the central domain, regardless in which of the other child domains the user or machine resides in the AD structure.

    The steps are outlined in more detail in one of my blogs here

    Cheers Colt

  • Hi ,

    Thanks for this article.

    I was able to configure multi-domain (option 2  ) for SAPGUI SSO and successfully test it. I have one more situation. We have users who user who use multi-domain. Example sometime they use laptop which will be corp domain ( snc name )  and sometime they use Citrix which will be another domain ( snc name ) . To configure SSO we have to keep changing SNC name when they switch from corp to citrix or citrix to corp. Is there way to overcome this situation where we don't need to change SNC name for user who are in multiple domain. I tried p:CN=user123@* but it do not work.

    • Hi Gautam,

      you can use parameter ccl/snc/server_partner_name_kerb to do this. Please refer to SAP Note 2338952.

      Use the value PrincipalOnly. There are the following limitations:

      • The parameter is only valid for SNC, not for SPNego (browser-based logon).
      • If you configure this, you have to configure all user SNC names without domain part. Does not work for individual users.
      • You have to configure it explicitly for Secure Login Client. Use parameter ccl/snc/server_partner_name_mapping_for_SLC_only=1

      Best regards,


  • Hello Martina,

    thanks a lot for the great blogs and explanations. We are successfully running SSO with Kerberos/SPNEGO for all our SAPGUIs and Browser based client systems.

    I have a question that is a bit beyond these typical use-cases. We are trying to call from our SAP ERP system an external  Restful API that is using Kerberos for authentication. This means that the SAP AS ABAP will be in the "client" role. In our ERP 6.0 EHP7 system we did try to use the Class library CL_HTTP_CLIENT, but did not find any option to configure it so that it uses SPNEGO (neither in the code nor via RFC destinations).

    Are you aware of any solution that would enable this? Thanks for your help.

  • Hi Martina, Thanks for the blog. Had one query. We are planning to implement SAP Single Sign On using Kerberos and SNC in our ABAP systems. Do we need to install SAP Single Sign On 3.0 components in our ABAP system. and do we have to purchase a valid license for it?

  • @Martina Kirschenmann

    We use external product (Quest Authentication) to achieve SNC/SSO for ABAP stack and now we are looking if we can enable SPNEGO with same product.

    Most of the blogs on SPENO with ABAP refers to SAP Single Sign-On 3.0 product.

    Can you please let us know if ABAP SPNego can be achieved using 3rd party products as well?



  • Hi Martina Kirschenmann,

    In our Project the central domain name is XXX.corp, while the user mail IDs are in,,,etc. So the SPNEGO SSO for webgui is not working with XXX.corp service account. We are not able to create service account in each alias, where token check fails since the domain name and UPN name differs. Please help us in this scenario.



    • Hi Martin,

      Azure AD is a cloud-based SAML Identity Provider and can be used with browser-based business applications.

      However, Azure AD does not support desktop clients such as SAP GUI, as these are not compatible with the SAML protocol. For these desktop clients, SAP Single Sign-On is required, using Kerberos or X.509 certificates as SSO tokens.

      Best regards,


      • Hello Martina,

        Thank you for you answer, this is very helpful for me .

        Of course, my company is using AZURE AD and even AD on-prem. We have got very good experience with SPNEGO even this is let say legacy technology in cloud environment.

        But, we have got teams as example financial which use only ABAP - SAPGUI connection, but of course there are teams which works fully with SAP WEB applications.

        So could I combine both technology (SPNEGO, SAML 2.0) in one SAP system ?

        Any special configuration ?

        Thank you in advance,

        Best Regards,