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

[Martina_K]

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.

 

Overview

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.

Note:

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.

Note:

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:

UserPrincipalName@DOMAIN, where UserPrincipalName 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

 

[Colt]

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

[gautam_jamang3]

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  p:CN=user123@corp.xyz.com )  and sometime they use Citrix which will be another domain ( snc name p:CN=user123@citrix.xyz.com ) . 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@*.xyz.com but it do not work.

[Martina_K]

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,

Martina

[AndreasG]

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.

[Martina_K]

Hi Andreas,

no, that is not possible. AS ABAP (as HTTP client) cannot request a Kerberos token from the KDC.

Best regards,

Martina

[AndreasG]

Hello Martina, thanks for this clarification.

[former_member231251]

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_K]

Hi,

on the client side, you need the Secure Login Client. No additional server component is required (the Secure Login Server component is not required for this scenario).

Yes, you need a license for the SAP Single Sign-On 3.0 product.

For configuration information, please also refer to the blog:

SAP Single Sign-On: Authenticate with Kerberos/SPNEGO

Best regards,

Martina

[surojiit]

@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?

 

Thanks
Surojit

[cognizant_serviceuser]

Hi martina.kirschenmann

In our Project the central domain name is XXX.corp, while the user mail IDs are in xyz.co, xyz.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.

Regards,

Sujitha

[martin_gajdos]

HI martina.kirschenmann

Is the SPNEGO technology supported even in AZURE environment ?

Can we use SPNEGO for ABAP(SAPGUI) connection and SAML for web applications (FIORI, PORTALS, SAP AC, SAP CC) ?

Thank you,

Best Regards,

Martin

[Martina_K]

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,

Martina

[martin_gajdos]

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,

Martin

[former_member189462]

Hi Martina,

We are working on a Kerbero-based SSO scenario where multiple domains are involved.

Domains trust each other (bidirectional way) with no restrictions.

AD Service account (svcSSO) has been created in “DOMAIN.A” only.

We are performing the AS ABAP configurations from a PC joined to “DOMAIN.B”.

While creating a keytab (using the only serv account in “DOMAIN.A”) through Tx SNCWIZARD, we got the error “No Service Principal Names found - Message no. SPN016”

According to what is mentioned in “Kerberos/SPNEGO for SAP AS ABAP in a Multi Domain Environment.”, only an AD service account on the central domain is required.

However, under section “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. 

As mentioned, we have created only one account in DOMAIN.A and add it in the form of svcSSO@DOMAIN.A in Tx SPNEGO.

Should an account in “DOMAIN.B” to be created as well? How a new keytab (in Tx SPNEGO) for DOMAIN.B show be created if no service account exists for that domain?

Thank you

Regards

 

[Martina_K]

Hello,

You need to configure a Service Principal Name (SPN) for your service account. Please check that you have configured the SPN in the Active Directory.

And you need to create a second Keytab for your domain B via svcSSO@DOMAIN.B. You don’t need a new service account in the Active Directory because there is a trust relationship.

Best regards,

Martina

[walid_nttdata]

Hello Martina and SMEs,

Thanks all for the valuable input on this topic.

I just want to stay with this question and ask you again:

 

-> how to create a second keytab for new domain?

 

We currently use spnego for domain.A and it works fine. Now we also need it for the new domain.B.
For both domains there is a Service-User (SSOSAP@Domain.A and SSOSAP@Domain.B) created with the same SPNs.

There is no trust between both domains.

I tried on OS level with:

sapgenpse keytab -p SAPSNCSKERB.pse -x <pw-sidadm> -y <pw-sidadm> -a SSOSAP@Domain.B

to create the new keytab. However, I get the error:
keytab ERROR: PSE already exists "/usr/sap/<SID>/<D00>/sec/SAPSNCSKERB.pse"

In SNCWIZARD there is no way to add the new keytab and in SPNEGO the login with SSOSAP@Domain.B failed!

Thanks for your feedback and support.

Walid

[Martina_K]

Hello Hamid,

You need to create a new Keytab for domain B in transaction SPNEGO. Please note that if your machine is in domain A then you cannot verify the password. Your machine must be in domain B.

Best regards,

Martina