SAP Single Sign-On Insider Tips – Volume #4

Welcome to volume #4 of our “SSO Insider Tips” blog series in which we like to share best practices with you to make your SSO projects even more successfully and save yourself many headaches.

Other articles in this blog series include:

• SAP Single Sign-On Insider Tips – Volume #3
• SAP Single Sign-On Insider Tips – Volume #2
• SAP Single Sign-On Insider Tips – Volume #1

This blog is about implementing SAP SSO 3.0 with Kerberos authentication in multi-domain or multi-forest environments. We’ve already done lots of projects in this area, from small to mid-sized and even large environments consisting of multiple autonomous forests with dozens of domains. Often in such projects, we are faced with common misunderstandings related to potential limitations when using Kerberos in larger landscapes where multiple Active Directory domains or even Active Directory forests are involved.

This blog helps you to make the right decisions for the design of the solution. As our “insider tips series” isn’t meant to be a beginner blog, please make sure you understand the basic principles of Kerberos authentication (TGS, KDC, TGT, ST) and already know what keytabs, service accounts, and SPNs are.

Active Directory forests and domains

An Active Directory forest (AD forest) is the first logical container in an Active Directory configuration that contains domains, users, computers, and group policies. A single domain also forms a forest, which can later be supplemented with additional domains. Below the so-called forest root domain (the first domain in a forest) you can have multiple child domains, which in turn can have child domains. Under each domain, you can have several trees. That’s why it is called a forest.

Nowadays a single AD forest/domain environment is generally considered best practice. All objects can be structured via organizational units (OUs) and thus be assigned to different management units and admin staff following the least privileged approach. In recent years, many complex AD structures have been simplified following this approach. As long as all domains belong to the same forest, mutual trust is inherent between the domains. Users can thus use resources from all domains throughout the forest, provided they are authorized to do so. This is also called a transitive trust relationship.

Nevertheless, it happens sometimes, be it due to historical reasons, company acquisitions or mergers, that an organization operates several AD forests. By default, no trust exists to other forests. Trust relationships between forests can allow access to some resources that live in outside forests. There are bidirectional or unidirectional forest trusts.

Get started the right way

If you are working within the SAP department or as an SAP security consultant, you are not dealing with all the details around the Active Directory. One of the most important things is first to understand exactly your (or the customers) Active Directory landscape, its domains, its forests (if there are multiple) and the trust-relationships between them. We made the experience, that often a considerably greater effort was made than was necessary like the creation of many service users in different domains.

Tipp: Involve experts from the Active Directory team and get an accurate understanding before starting the project. Even the people you work within your SSO project sometimes have no clue about the exact Active Directory structure. Get started with a workshop to gather the required details and to avoid architectural mistakes.

SPNEGO Authentication flow in multiple domains (same forest)

To better illustrate the Kerberos authentication-flow let’s start with an example. Here, the user John Doe located in the SALES domain (which child of the COMPANY forest) is accessing the Fiori Launchpad, which runs on a NetWeaver AS ABAP configured for SPNEGO authentication and has one keytab trusting the COMPANY forest. In such case, there is only one service account and keytab required for the AS ABAP, in the best case the service account and SPN are created in the forest root domain.

1. JDOE logs on to a domain-joined computer in SALES.INTRA, which is a domain in the COMPANY.INTRA forest. This Authentication Service (AS) request results in a TGT for krbtgt/[email protected].
2. JDOE then attempts to access an SSO enabled SAP web application. The SPNEGO setup is invoked, and the SAP ICM returns a 401 Unauthorized message with a WWW-Authenticate: Negotiate header variable.
3. JDOE then makes a Ticket Granting Server (TGS) request to a Key Distribution Center (aka domain controller) in the SALES.INTRA domain. Being as this SPN isn’t registered on any principals in the SALES.INTRA domain, the domain controller sends a referral to a Global Catalog (GC) in the COMPANY.INTRA forest. The GC knows this TGS request is for a principal in a different trusted domain, so it sends the client a referral to its parent domain COMPANY.INTRA
4. The client obtains a TGT for the parent-child trust between SALES.INTRA and COMPANY.INTRA: krbtgt/[email protected]
5. Once JDOE finally has a TGT for the COMPANY.INTRA domain, he makes a TGS request to a KDC in that domain, and it returns a service ticket (ST) for the SPN such as HTTP/<URL>
6. JDOE’s browser encodes the ST and included in the Authorization header of his subsequent request to the resume path. The SAP system then authenticates him.

Tipp: In case the user accessing the SSO enabled resource, is located in another AD forest, we talk about the so-called cross-realm authentication. For clients in one forest to be authenticated to a service in another remote trusted forest, they must obtain cross-realm authentication before requesting a Kerberos service ticket in the remote domain. Here, step 4 would look different here as the client first obtains a Ticket Granting Ticket (TGT) in its domain (if not already authenticated), then obtains cross-realm TGTs for each intermediate domain across the forest trust. Of course, that only applies to trusted forests. If there is no such trust, you need to create a separate service user and SPN for each forest.

Recommendations using SNC in multi-domain or multi-forest environments

• In scenarios where you have a forest trust or 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).
• With SAP SSO 3.0 it’s best practice to define the SNC Name of the SAP Server snc/identity/as like an X.509 DN, for example, p:CN=<SID>, O=Organization, C=US. Don’t worry. This works fine even with Kerberos. SNC using the SAP CommonCryptoLib can handle certificate-based authentication (e.g., for server-to-server communication) and Kerberos in parallel. Depending on the authentication method, the Secure Login Client uses either the existing X.509 (DN) for certificate-based authentication or tries to map the CN part to a Service Principal Name – SAP/<SID> where SID equals CN – that can be used for Kerberos authentication. In other words, the SAP Secure Login Client 3.0 constructs the proper SPN, adds the user’s domain and queries the local KDC for SAP/<SID>@<USERDOMAIN> the other elements of the SNC name such as O, OU, C, etc. are not considered in this case. For more details check out SAP Note 1696905
• If there are multiple forests where no trust exists, you need to create one service user (representing your SAP application server) and SPN(s) within each forest root domain. This way your SAP systems may have multiple keytabs for the different forests, but that’s fine. Even here, the Secure Login Client (SLC) constructs the SPN from the SNC-Name maintained in the SAP Logon (Pad), which forces the SLC to always add the current USERDNSDOMAIN of the user to the SAP/<SID>. In the end, the user will receive a proper TGT/ST from his responsible KDC in the corresponding forest root domain.
• If there are multiple trusted AD forests, you usually would have only one service account for your SAP system, for example in the main AD forest. To allow users from different trusted AD forests, to request a service ticket for your SAP system (SPN) in the trusted forest root domain, you need to make sure to add the domain name to the SNC-Name in SAP Logon. Example: p:CN=<SID>@YOURFORESTROOTDOMAIN.INTRA
• In case you are using logon groups (message server) the SNC name is obtained dynamically from the profile parameter snc/identity/as of the respective application server. This may have implications on your solution design, and you need to carefully consider if you need to add the domain part already in the profile parameter or not.

As you see, implementing SAP Single Sign-On 3.0 based on Kerberos even within environments with multiple forests isn’t such a hard thing. Of course, many other important points need to be taken into account in such projects.

You need to have a naming concept for your required AD service accounts, use secure passwords and encryption algorithms and create the correct SPNs. You need to consider DNS resolution, reverse proxies or NLBs and correct system-time.

You need to have a concept on how to create and maintain your keytabs within the SAP PSE files or global keytab in the SAP database. Let us know if you need our support in your next Kerberos based SAP Single Sign-On project.