Single sign-on for SAP with Tivoli Access

Manager and Microsoft Windows

Using 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.

Back to top

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
solution that is
covered in this
section.

Figure 4.
Configuring
SAP R/3 for
Kerberos
authenticatio
n

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
accoun
t using
the
Active
Direct
ory
Users
and
Comp
uters
MMC
snap-
in.
2. Add
 the
new
accoun
t to the
local
Admin
istrator
s
groups
on the
SAP
R/3
server.
This is
done
using
the
Comp
uter
Manag
ement
MMC
snap-
in.
3. On the
SAP
R/3
server,
using
the
Servic
es
Contro
l Panel
applet,
config
ure the
SAP
R/3
service
to
logon
using
the
newly
created
 accoun
t. The
SAP
R/3
service
is
typical
ly
named
"SAPS
ervic
eName
_Serv
iceNu
mber".
Refer
to SAP
docum
entatio
n to
assist
with
locatin
g 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@COMPA
NY.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. Downl
oad
the
approp
riate
versio
 n from
the
SAP
market
place
from
OSS
note
35229
5.
2. Extract
the
code
and
copy
gsskrb
5.dll to
the
%wind
ir
%\syst
em32
directo
ry, e.g.
C:\WI
NNT\s
ystem
32
3. Set the
SNC_
LIB
enviro
nment
variabl
e to
the
locatio
n of
the
gsskrb
5.dll
file.

Step 4:
Configure
SNC to use
the Kerberos
runtime.

SAP Secure
Network
Communicati
on (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
transac
tion
SU01.
2. Enter
the
SAP
userna
me.
3. Select
the
SNC
tab.
4. Enter
the
user's
Kerber
os
Princip
al
Name
in the
followi
ng
format
:
Usern
ame@C
OMPAN
Y.COM.
Note
 the use
of
case.
5. Save
the
change
s.

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
.

Back to top

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
solution
covered in this
topic.

Figure 5.
Configuring
SAP GUI for
Kerberos
authenticatio
n

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. Downl
oad
the
 approp
riate
versio
n from
the
SAP
market
place
via
OSS
note
35229
5.
2. Extract
the
code
and
copy
gsskrb
5.dll to
the
%wind
ir
%\syst
em32
directo
ry, e.g.
C:\WI
NNT\s
ystem
32
3. Set the
SNC_
LIB
enviro
nment
variabl
e to
the
locatio
n
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
Communicati
on 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
.

Back to top

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

It is
requirement
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
communicatio
n based on the
Kerberos
protocol;
therefore, the
ITS must be
configured to
use the
Kerberos
protocol.

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

To configure
the SAP ITS
to use the
Kerberos
protocol:

1. Modif
y the
ITS
instanc
e
config
uration
file
(ITSR
egistry
WGate
.xml)
to
specify
the
SNC
name
of the
SAP
R/3
(referr
ed to
as the
Applic
ation
Gate,
or
Agate,
by
SAP
ITS):
SncNa
meAGa
te =
p:sap
r3@CO
MPANY
.COM
2. Using
transac
tion
SM30,
modify
the
USRA
 CLEX
T table
to add
an
entry
as
follow
s: *
->
p:sap
r3@CO
MPANY
.COM
3. Using
transac
tion
SM30,
run
report
RSSN
CCHK
to
confir
m the
SNC
param
eters
are
correct
.
4. Open
the
SNC
system
access
control
list
(table
SNCS
YSAC
L,
view
VSNC
SYSA
CL,
type=
E) and
perfor
m the
followi
ng
steps:
1.
Ent

2.
Ac


Entr


Entr

Entr


Entr
 
Entr

3.
Sa

The SAP ITS

is now
configured for
SNC
communicatio
n based on the
Kerberos
protocol.
 Back to top

Configuring
WebSEAL for
Kerberos
authentication

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

Figure 7.
Configuring
WebSEAL
for Kerberos
authenticatio
n

The minimum
steps required
to configure
WebSEAL for
Kerberos on a
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
documentatio
n for complete
details on how
to complete
this task. At
the very least
the following
actions are
required:

1. Using
the
Active
Direct
ory
Users
 and
Comp
uters
MMC
snap-
in, add
the
WebS
EAL
server
as a
memb
er of
the
AD
domai
n.
2. Using
the
DNC
MMC
snap-
in,
create
an
approp
riate
DNS
entry
for the
WebS
EAL
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
Administratio
n 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
require
d,
install
the
"Wind
ows
Suppor
t
Tools"
from
the
Windo
ws
install
CD.
2. From a
Comm
and
Promp
t, 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
WebS
EAL
server.
2. Modif
y the
WebS
EAL
config
ure file
to
enable
SPNE
GO
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
-
Intern
et
Optio
ns...
2. Select
the
Advan
ced
tab.
3. Scroll
down
to the
Securi
ty
section
.
4. Enable
Integr
ated
Windo
ws
Authe
 nticati
on.

WebSEAL is
now
configured for
Kerberos
authentication
.

Back to top

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
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.

Back to top

Configuring
SAP
NetWeaver
Portal trust
relationship
with
WebSEAL.

In order to
enable SSO to
the SAP
NetWeaver
Portal,
WebSEAL is
configured to
send the
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

Back to top

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
Authenticatio
n credentials
stored in
WebSEAL's
Global Sign-
On lockbox.

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

Refer to the
WebSEAL
Administratio
n 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.
 Back to top

Testing the
Solution

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

1. Login
to the
deskto
p.
2. Open
IE
and
naviga
te to
WebS
EAL's
defaul
t page.
The
user
should
be
authen
ticated
to
WebS
EAL
withou
ta
prompt
and
withou
t error.
This
indicat
es that
the
 user
has
succes
sfully
authen
ticated
to
WebS
EAL
using
SPNE
GO
(Kerbe
ros).
3. Using
IE,
naviga
te to
SAP
NetW
eaver
Portal
via a
WebS
EAL
juncti
on.
The
user
should
be
authen
ticated
to
Portal
withou
t an
SAP
login
prompt
and
withou
t error.
This
indicat
es that
 the
trust
betwee
n
WebS
EAL
and
SAP
NetWe
aver
Portal
is
establi
shed.
4. Using
IE,
naviga
te to
SAP
ITS
via a
WebS
EAL
juncti
on.
The
user
should
be
authen
ticated
to ITS
withou
t an
SAP
login
prompt
and
withou
t error.
This
indicat
es that
the
trust
betwee
 n
WebS
EAL
and
SAP
ITS is
establi
shed.
Additi
onally,
this
indicat
es that
SNC is
succes
sfully
config
ured
betwee
n SAP
ITS
and
SAP
R/3.
5. Using
IE,
naviga
te to
any
other
Web
Applic
ation
Server
s via a
WebS
EAL
juncti
on.
The
user
should
be
authen
ticated
to the
 applica
tion
withou
ta
prompt
and
withou
t error.
This
indicat
es that
the
trust
betwee
n
WebS
EAL
and
the
applica
tion is
establi
shed.
6. Open
SAP
GUI
and
select
the
appro
priate
SAP
R/3
server
. The
user
should
be
authen
ticated
to the
applica
tion
withou
ta
prompt
 and
withou
t error.
This
indicat
es that
the
Kerber
os
authen
ticatio
n is
config
ured
for
SAP
GUI.

Back to top

Troubleshooti
ng

Troubleshooti
ng 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
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
troubleshootin
g details.