Single sign-on for SAP with Tivoli Access Manager and Microsoft WindowsUsing Kerberos and WebSEAL

This article describes how to configure single sign-on for common SAP applications by using IBM Tivoli Access Manager WebSEAL in conjunction with Microsoft Windows utilizing the Kerberos protocol.

Introduction

The question is often asked, "How can we configure single sign-on for SAP GUI using IBM Tivoli Access Manager WebSEAL like we can do for our other SAP applications...?" Unfortunately, the immediate answer is usually: "You cannot, because WebSEAL cannot provide security for non web-facing applications - SAP GUI is a non web-facing application". Of course this is correct; however, by utilizing the Kerberos protocol in Microsoft Windows, SAP GUI can be configured to automatically use desktop credentials with which to sign-on. When used in conjunction with WebSEAL, and WebSEAL is configured to support Kerberos, the user is only required to sign-on once, i.e. to the desktop.

This article describes how to configure WebSEAL and SAP applications, including SAP GUI, to leverage the Kerberos protocol in order to provide a single sign-on environment for SAP and other applications. A brief comparison is made to demonstrate the added value of using WebSEAL instead of a solution based solely on the SAP SSO ticket.

The method to integrate WebSEAL with SAP web-facing applications is only briefly covered in this article. This provides the complete single sign-on picture and avoids rewriting the integration guides. A link to the location of the relevant integration package is provided.

The SAP applications covered in the document include: SAP GUI, SAP WebGUI, SAP Internet Transaction Server (ITS), SAP NetWeaver Portal, and SAP R/3. All servers, including WebSEAL, are assumed to be running on Windows.

The specifics of the Kerberos protocol are not covered. Refer to the references section for a link to the Windows implementation of the Kerberos protocol.

Scenario

Consider an intranet environment where a company's users logon to a Microsoft Windows desktop by authenticating to Active Directory. From their desktop, users access an SAP R/3 instance using the SAP GUI or SAP WebGUI using a browser via the SAP Internet Transaction Server (ITS). Additionally, Internet Explorer (IE) is used to access the company's corporate portal hosted on SAP NetWeaver Portal. Finally, a number of Web application servers, providing various other mission critical applications, are available to users via their browser.

In such a heterogeneous environment, without an access management solution, users are required to authenticate to a number of systems. Specifically, the user is required to logon to their Windows desktop and subsequently to each application - a total of at least 5 logons. Moreover, the user is required to manage the credentials for each of these systems (hopefully the user doesn't use 'sticky-notes' to store these credentials!).

A basic illustration of the environment is shown in Figure 1.

Figure 1. No access management solution

Solution

The described environment is difficult to manage, is inconvenient for the user, and is potentially insecure as users write their passwords in insecure locations. Therefore, a solution is required to manage user access to the applications and to assist with the management of the user's identities for each application.

The solution for the environment can be broken into two general areas:

1. Access Management. Reduce the number of times a user is required to provide authentication credentials to the applications, i.e., through the use of Single Sign-On (SSO) techniques; and,

2. Identity Management. Reduce the administrative overhead of managing the user's identity for each application's user registry.

This article focuses on the Access Management part of the solution.

As shown in Figure 2, the ideal access management solution requires the user to provide one set of authentication credentials; that is, to Active Directory when logging into Windows. Any subsequent authentication requests are then handled by the client machine by supplying authentication information using Kerberos tickets.

Figure 2. Access Management Solution using IBM Tivoli and MS Windows

When using Kerberos (without discussing the specifics of the Kerberos protocol in detail), on successful authentication to Active Directory the user is supplied a Kerberos ticket. The Kerberos ticket is then used to authenticate the user to any application that implements the Kerberos protocol.

For the web applications that are not configured for Kerberos, IBM Tivoli Access Manager WebSEAL is used to establish a trust relationship with the web applications in order to provide the sign-on information. Subsequently, the web application does not require specific coding to handle the Kerberos protocol. Additionally, the trust relationship enables the SSO techniques to be extended to the Internet.

Why use a WebSEAL SSO solution instead of a SAP solution based on the SAP SSO ticket?

SAP makes use of its SSO ticket through the use of the MYSAPSSO cookie in order to provide SSO to SAP systems. Furthermore, the SSO ticket can be utilized in a heterogeneous environment by extending the non-SAP applications to read and decode the SSO ticket. Therefore, you might ask why wouldn't we use SAP SSO tickets? In addition to the obvious benefits provided by Tivoli Access Manager through centralized authentication, access, and audit policy (to name just a few), the answer is simple:

• Less integration overhead. A significant amount of overhead is required in order to establish trust between SAP applications based on the SAP SSO ticket. In comparison, the process of establishing a WebSEAL SSO solution for SAP applications is simple.

• Less modification to non-SAP applications. For a heterogeneous environment - i.e., an environment containing non-SAP applications - no modification, or very little modification, is required to establish a WebSEAL SSO solution; whereas, a significant development effort is usually required in order to support the use of the SAP SSO ticket. Refer to the Configuring other Web Application Servers trust relationship with WebSEAL section below for more details on non-SAP SSO solutions.

• More suitable for mobile users. As mentioned above, a WebSEAL SSO solution is easily extended to provide secure access to internet users. Therefore, for mobile users, the user experience is greatly enhanced when accessing the applications from the internet. By making use of WebSEAL's ability to use both Kerberos authentication alongside other methods of authentication suitable for the internet (for example, Basic Authentication and forms authentication), the user can sign-on to WebSEAL from the internet using the same login credentials as when signing-on to their desktop (or laptop) from within the intranet.

In summary, a WebSEAL solution provides a flexible method of access management without the overhead of a SAP proprietary solution.

Configuring the Desktop for Kerberos authentication

No action is required to enable Kerberos authentication for the initial user login to their desktop. Figure 3 shows a very basic illustration of the Active Directory login process, including provision of the Kerberos ticket.

Figure 3. Active Directory Login

For more information on the Kerberos protocol implementation in Windows, refer to the resources section later in this article.

The following tasks are required in order to implement SSO for the remaining systems:

1. Configuring SAP R/3 for Kerberos authentication; 2. Configuring SAP GUI for Kerberos authentication; 3. Configuring SAP ITS for Kerberos authentication to SAP R/3; 4. Configuring WebSEAL for Kerberos authentication; 5. Configuring SAP ITS trust relationship with WebSEAL; 6. Configuring SAP NetWeaver Portal trust relationship with WebSEAL; and, 7. Configuring other Web Application Servers trust relationship with WebSEAL. 8. Testing the Solution.

Configuring SAP R/3 for Kerberos authentication

The following steps outline how to configure the SAP R/3 Application Server for the Kerberos protocol. Figure 4 shows the relevant section of the overall

Back to top

solution that is covered in this section.

Figure 4. Configuring SAP R/3 for Kerberos authentication

Step 1: Configure SAP R/3 server into the Active Directory domain

To participate in a Kerberos exchange, the SAP R/3 Application Server must be a member of, and have an identity in, the Active Directory domain. Once the SAP R/3 server is added to the Active Directory domain, the SAP R/3 service account be

then be registered with the Active Directory domain controller. This enables client applications to obtain a Kerberos ticket from the Active Directory domain controller in order to access the SAP R/3 server.

To create and configure the SAP R/3 service account:

1. Create a service account using the Active Directory Users and Computers MMC snap-in.

2. Add

the new account to the local Administrators groups on the SAP R/3 server. This is done using the Computer Management MMC snap-in.

3. On the SAP R/3 server, using the Services Control Panel applet, configure the SAP R/3 service to logon using the newly created

account. The SAP R/3 service is typically named "SAPServiceName_ServiceNu

mber". Refer to SAP documentation to assist with locating the correct service.

This article assumes the service account is called <DOMAIN>\sa

pr3 (where <DOMAIN> is the name of the Windows NetBIOS domain).

Therefore, for the remainder of this article, the SAP R/3 service account's

Kerberos Principal Name will be referred to as: sapr3@COMPANY.COM

(where COMPANY.COM

is the Active Directory domain name) and the SAP R/3 service account's SNC name is: p:sapr3@COM

PANY.COM.

Step 2: Map the Kerberos principal to the Active Directory user

The SAP client does not request the service principal name (SPN) when requiring access to the SAP R/3 server; however, the SPN must be set because the Kerberos Domain Controller will invoke the Kerberos user2user protocol for any account

that does not have an SPN. Therefore, the SAP R/3 Kerberos Principal Name must be mapped to the Active Directory user that represents the SAP R/3 service account, created in Step 1.

This mapping requires the Windows setspn utility. The setspn utility is not loaded on a Windows system by default. It can be obtained from the Windows Support Tools package on the Windows CDs.

To create an SPN for the SAP R/3 service account, login as a domain administrator and execute the following

command:

C:\>SETSPN -A SAPService<ServiceName>/<SAP R/3 host name> <DOMAIN>\sapr3

Where <ServiceNam

e> is the name of the SAP R/3 service and <SAP R/3 host name>

is the fully qualified name of the SAP R/3 server.

Step 3: Install the Kerberos runtime on the SAP R/3 server.

To enable the use of the Kerberos protocol by SAP R/3, the Kerberos runtime must be installed on the SAP R/3 server.

To obtain and install the Kerberos client:

1. Download the appropriate versio

n from the SAP marketplace from OSS note 352295.

2. Extract the code and copy gsskrb5.dll to the %windir%\system32 directory, e.g. C:\WINNT\system32

3. Set the SNC_LIB environment variable to the location of the gsskrb5.dll file.

Step 4: Configure SNC to use

the Kerberos runtime.

SAP Secure Network Communication (SNC) is required to be enabled and configured to use the Kerberos runtime.

Using the SAP GUI, run transaction RZ10 and set the following parameters:

snc/enable =1 snc/gssapi_lib = %windir%\system32\gsskrb5.dll snc/identity/as = p:sapr3@COMPANY.COM

Step 5: Map the SAP R/3 user accounts to Active Directory users.

For each user requiring access to the SAP R/3 using the SAP GUI, the user's Kerberos Principal Name must map to an SAP

username.

To set a user's Kerberos Principal Name, use SAP GUI (or some other means of running an SAP transaction) to perform the following:

1. Run transaction SU01.

2. Enter the SAP username.

3. Select the SNC tab.

4. Enter the user's Kerberos Principal Name in the following format: Username@COMPAN

Y.COM. Note

the use of case.

5. Save the changes.

Step 6: Restart the SAP R/3.

Restart the SAP R/3 service in order to enable the changes.

The SAP R/3 is now configured to accept Kerberos authentication.

Configuring SAP GUI for Kerberos authentication

The following steps outline how to configure the SAP GUI for Kerberos authentication. Figure 5 shows the relevant section of the

Back to top

solution covered in this topic.

Figure 5. Configuring SAP GUI for Kerberos authentication

Step 1: Install the Kerberos runtime on the Windows Desktop

The Kerberos runtime is required to be installed on each Windows Desktop in order to enable the use of the Kerberos protocol by SAP GUI.

To obtain and install the Kerberos client:

1. Download the

appropriate version from the SAP marketplace via OSS note 352295.

2. Extract the code and copy gsskrb5.dll to the %windir%\system32 directory, e.g. C:\WINNT\system32

3. Set the SNC_LIB environment variable to the location above.

Step 2: Configure SAP GUI to

use SNC

Modify the properties of the SAP R/3 connection in the Advanced Options pane in the initial screen of the SAP GUI. Select Enable Secure Network Communication and set the SNC name to value of the SAP service account, e.g. p:sapr3@COM

PANY.COM.

After restarting the SAP GUI, it is now configured to use Kerberos authentication.

Configuring SAP ITS for Kerberos (SNC) authentication to SAP R/3

It is requirement

Back to top

by SAP when configuring the SAP ITS for SSO to configure SNC to the SAP R/3. The SAP R/3 is expecting the SNC communication based on the Kerberos protocol; therefore, the ITS must be configured to use the Kerberos protocol.

Figure 6. Configuring SAP ITS for Kerberos (SNC) authentication to SAP R/3

To configure the SAP ITS to use the Kerberos

protocol:

1. Modify the ITS instance configuration file (ITSRegistryWGate.xml) to specify the SNC name of the SAP R/3 (referred to as the Application Gate, or Agate, by SAP ITS): SncNameAGate = p:sapr3@COMPANY.COM

2. Using transaction SM30, modify the USRA

CLEXT table to add an entry as follows: * -> p:sapr3@COMPANY.COM

3. Using transaction SM30, run report RSSNCCHK to confirm the SNC parameters are correct.

4. Open the SNC system access control list (table SNCSYSACL, view VSNCSYSACL, type=E) and

perform the following steps:

1.Ent

2.Ac

Entr

Entr

Entr

Entr

Entr

3.Sa

The SAP ITS is now configured for SNC communication based on the Kerberos protocol.

Configuring WebSEAL for Kerberos authentication

The final system requiring configuration for the Kerberos protocol is the WebSEAL server. Refer to the WebSEAL Administration Guide for complete details on how to configure WebSEAL for Kerberos.

Figure 7. Configuring WebSEAL for Kerberos authentication

The minimum steps required to configure WebSEAL for Kerberos on a

Back to top

Windows systems are outlined below.

Step 1: Configure WebSEAL server into Active Directory domain.

As for the SAP R/3 server, in order to participate in a Kerberos exchange the WebSEAL server must be a member of, and have an identity in, the Active Directory domain. Refer to Microsoft documentation for complete details on how to complete this task. At the very least the following actions are required:

1. Using the Active Directory Users

and Computers MMC snap-in, add the WebSEAL server as a member of the AD domain.

2. Using the DNC MMC snap-in, create an appropriate DNS entry for the WebSEAL server.

Note: When WebSEAL is installed on a non-Windows platform, the WebSEAL server is not required to be a member of the AD domain. Refer

to the WebSEAL Administration Guide for details on how to configure WebSEAL for the Kerberos protocol when using a non-Windows platform.

Step 2: Map Kerberos principal to Active Directory user.

1. If required, install the "Windows Support Tools" from the Windows install CD.

2. From a Command Prompt, run:

ktpass -princ HTTP/<webseal.company.com>@<COMAPNY.COM> -mapuser <webseal>$

Where

<webseal> is the hostname of the WebSEAL server, and <COMAPNY.CO

M> is the domain name of the AD domain.

Note: <webseal>$

represents the WebSEAL service running as the machine's "Local Server Account". For multiple instances of WebSEAL on the same machine, or when WebSEAL is configured to log in as an AD service account, the NT style username is required to be specified instead of <webseal>$

(as is done for the SAP R/3 service account).

Step 3: Enable Kerberos for WebSEAL.

Modify the WebSEAL configuration file to enable SPNEGO as follows:

1. Stop the WebSEAL server.

2. Modify the WebSEAL configure file to enable SPNEGO over SSL:

[spnego]spnego-auth = https

[authentication-mechanisms]kerberosv5 =

Step 4: Restart WebSEAL.

Restart WebSEAL to enable the changes to the configuration.

Step 5: Configure Internet Explorer.

Internet Explorer (IE) must be configured to use the SPNEGO protocol to negotiate authentication mechanisms. Perform the follows steps in IE to enable Kerberos authentication:

1. From the menu, select Tools - Internet Options...

2. Select the Advanced tab.

3. Scroll down to the Security section.

4. Enable Integrated Windows Authe

ntication.

WebSEAL is now configured for Kerberos authentication.

Configuring SAP ITS trust relationship with WebSEAL

In order to enable SSO to the SAP ITS, WebSEAL is configured to send the authenticated user-id to the ITS using an HTTP header. The ITS is then configured to trust the user-id provided by WebSEAL and proceeds with normal processing for the authenticated user.

Figure 8. Configuring

Back to top

SAP ITS trust relationship with WebSEAL

Refer to the Integration Guide available on the IBM website for details on how to configure the trust relationship between WebSEAL and SAP ITS.

Configuring SAP NetWeaver Portal trust relationship with WebSEAL.

In order to enable SSO to the SAP NetWeaver Portal, WebSEAL is configured to send the

Back to top

authenticated user-id to the Portal using an HTTP header. The Portal is then configured to trust the user-id provided by WebSEAL and proceeds with normal processing for the authenticated user.

Figure 9. Configuring SAP NetWeaver Portal trust relationship with WebSEAL

Refer to the Integration Guide available on the IBM website for details on how to configure the trust relationship between WebSEAL

and SAP NetWeaver Portal

Configuring other Web Application Servers trust relationship with WebSEAL

For most Web applications, WebSEAL can provide the sign-on credentials for authenticated users. This is done using a variety of mechanisms ranging from supplying an HTTP header containing the authenticated user-id (as is done in the SAP ITS and SAP NetWeaver Portal integrations) to supplying Basic Authentication credentials stored in WebSEAL's

Back to top

Global Sign-On lockbox.

Figure 10. Configuring other Web Application Servers trust relationship with WebSEAL

Refer to the WebSEAL Administration Guide, or the list of Integration Packages available on the IBM website (using search term TIVOIAM00), for details on how to configure the trust relationship between WebSEAL and any Web applications requiring an SSO solution.

Testing the Solution

The following tasks should be completed in order to test the access management solution:

1. Login to the desktop.

2. Open IE and navigate to WebSEAL's default page. The user should be authenticated to WebSEAL without a prompt and without error. This indicates that the

Back to top

user has successfully authenticated to WebSEAL using SPNEGO (Kerberos).

3. Using IE, navigate to SAP NetWeaver Portal via a WebSEAL junction. The user should be authenticated to Portal without an SAP login prompt and without error. This indicates that

the trust between WebSEAL and SAP NetWeaver Portal is established.

4. Using IE, navigate to SAP ITS via a WebSEAL junction. The user should be authenticated to ITS without an SAP login prompt and without error. This indicates that the trust betwee

n WebSEAL and SAP ITS is established. Additionally, this indicates that SNC is successfully configured between SAP ITS and SAP R/3.

5. Using IE, navigate to any other Web Application Servers via a WebSEAL junction. The user should be authenticated to the

application without a prompt and without error. This indicates that the trust between WebSEAL and the application is established.

6. Open SAP GUI and select the appropriate SAP R/3 server. The user should be authenticated to the application without a prompt

and without error. This indicates that the Kerberos authentication is configured for SAP GUI.

Troubleshooting

Troubleshooting a solution involving Kerberos can be somewhat difficult without knowledge of the Kerberos protocol. A common cause of problems is that the Kerberos Principal Name is case-sensitive. Ensure that all entries for Kerberos

Back to top

Principal Names are entered in the correct case.

If problems are encountered with the establishment of trust between WebSEAL and the junctioned servers, refer to the relevant integration guide for troubleshooting details.