www.botzandassociates.com
E-mail: botz@botzandassociates.com
iSeries Servers and Single SignSign-on Made
Simple How It REALLY All Fits Together
Kerberos
S o l vi n g I n f o r m a t i o n S e c u r i t y P r o b l e m s
© 2009 Botz & Associates, Inc. All Rights Reserved.
Single SignSign-on Overview
GOAL: Sign-on once, be authenticated everywhere!
2
Single SignSign-on End
End--to
to--End
OBJECTIVE:
Explain Single Sign-On by stepping
through a SSO operation beginning to end.
Explain Kerberos as we go
Explain EIM as we go
3
Single SignSign-on Overview
iSeries Single Sign-On (SSO) implementation
• Uses Kerberos protocol for authentication.
– Network authentication protocol invented by MIT.
– Freely available from MIT.
– Ticket based, third party authentication scheme.
• Uses EIM (Enterprise Identity Mapping) to manage users in an
enterprise.
– Uses LDAP technology to keep track of who users are in an enterprise.
Did NOT implement a user ID and password synchronization tool.
4
Single SignSign-on: Step 1
Authenticate to the network, not a device.
•
There are several network authentication servers available.
− Example: Microsoft Windows 2000/2003 Servers, AIX, LINUX, and i5/OS
PASE (V5R3)
•
Microsoft Windows Servers use Kerberos for authentication.
− The server has a Kerberos KDC (Key Distribution Center)
− KDC - Place where network IDs (principals) and passwords are stored.
− KDC - Place where Kerberos tickets are generated.
NOTE: When you sign into a Windows Domain, you use Kerberos authentication.
5
Real World for Step 1
• Example: Microsoft Windows 2000 Server.
− Contains list of network users and their
associated passwords.
6
Real World for Step 1
Work station users sign into a Windows Domain.
7
SSO Step 1
• Workstation user signs into Kerberos realm. (Kerberos kinit command)
• User unaware that a Kerberos request for a Ticket-Granting-Ticket
(TGT) is sent to the Kerberos KDC.
NOTE: Request includes the user name and other stuff. The user’s
password is NOT sent
TGT request: User name (ws01)
KDC for
IBMROCHESTERMN
Work Station
8
SSO Step 1: KDC builds a TGT
• The KDC receives the TGT request.
• The KDC builds a TGT for the requestor.
Data includes:
─ Requesting user principal
ws01
─ Requesting Kerberos Realm
IBMROCHESTERMN
─ KDC generated session key for future communications
between this user and the KDC
• TGT encrypted so users can’t decrypt their TGT.
• Kerberos protocol calls for KDC to have a master password.
• TGT encrypted with the KDC master key
TGT request from ws01
Principal
KRBTGT
9
Password
KDC for
IBMROCHESTERMN
SSO Step 1: KDC builds a TGT
• In addition to TGT, user gets “data”:
• The session key for future communications with
the KDC
• Data so user can validate they got a response
from the expected KDC.
Password
KRBTGT
ws01
ws02
…
…
• “Data” must be encrypted so only the TGT
requester can decrypt it.
Principal
• Encrypt the “data” with the user’s password
Data
KDC for
IBMROCHESTERMN
10
SSO Step 1: Workstation signsign-on
Complete
• TGT and Data are sent back to the work station
• Workstation decrypts “data” with its password
• Session key is extracted and put in local cache
• TGT, unaltered, put in local cache
Work Station
11
KDC for
IBMROCHESTERMN
Ticket--Granting
Ticket
Granting--Ticket
Contains the “principal” that requested it.
ws01
IBMROCHESTERMN
Contains the realm name of
where it was created.
Encrypted with secret key of the KDC. “ws01” can’t
decrypt it.
Required to be included with any furture requests to
the KDC for other tickets. (More later)
12
Single SignSign-on: Step 2
KDC
User provide PROOF to servers that they have
authenticated to the network WITHOUT reentering
their passwords.
13
SSO Step 2: Authenticating to a server
Server X uses
Kerberos
authentication
ws01
KDC
Service Ticket for X
Request a Service Ticket for X
Service Ticket for X
14
SSO Step 2: Previous Chart in
Words
Kerberos client on workstation sends TGS_REQ to
KDC.
KDC Validates TGT, builds and returns Service-Ticket
(ST).
Kerberos client places ST in user’s credentials cache.
The application sends ST with its request to the service.
Service validates the ST.
Service does NOT go to the KDC for any reason.
ST decrypted using local copy of service’s PRINCIPAL PWD.
KDC and Service share the password secret.
15
Service determines valid service ticket built by KDC for
“ws01”.
Service trusts KDC, authentication is accepted.
SSO Step 2: Server Authentication
• iSeries Server single sign-on solution relies on Kerberos
Authentication.
• iSeries Server single sign-on enabled functions use specific
Kerberos Principal names.
16
iSeries Function Enabled for SSO
iSeries Navigator: Connection is enabled for Single Sign-on!
Note: Per connection. Not all or nothing.
17
iSeries Function Enabled for SSO
iSeries Navigator: What really happens when you open the connection?
Kerberos STUFF!
• iSeries Navigator client code requests a Kerberos ServiceTicket (ST) that it can pass to the iSeries.
• What is the PRINCIPAL name used to identify the
“server”?
• krbsvr400/<host name>
• iSeries Navigator client code requests a Kerberos
Service-Ticket (ST) for krbsvr400/<host name>
• The Kerberos ST will be the PROOF to the server
that the user has authenticated to the network.
18
Single SignSign-on Step 2: Authenticating to a server
Example: iSeries Navigator
ws01
KDC
Service Ticket for
krbsvr400/<host name>
Request a Service Ticket
krbsvr400/<host name>
Service Ticket for
krbsvr400/<host name>
19
Important: How <host name> is
Built
During Open Connection processing iSeries Navigator:
Resolves the host name.
• On PC hostname is resolved through a local hosts
file or by querying DNS.
<host name> = rchasdmm
20
Important: How <host name> is
Built
Extremely important: all workstations must generate same server host name!
BE AWARE of search order:
1) Search the local host table for the workstation.
NOTE: This overrides the Domain Name Server (DNS).
2) Search the DNS for the workstation.
WARNING: When different workstations in the same domain use different
combinations of host tables and DNS’s, the iSeries Navigator code may
build different krbsvr400/<host name> on different workstations.
THEREFORE: Setup all workstations in the domain to generate the same
krbsvr400/<host name> service principal name by:
Pointing all workstations to same DNS.
And/or setting up all workstation host tables to be the same.
21
Getting krbsvr400/<host name>
principal into the KDC
Steps:
•
iSeries and the KDC agreed on a name.
─ Examples:
• krbsvr400/rchasxxx
(a short name)
• krbsvr400/rchasxxx.aaa.bbb.com (a long name)
─ Most likely reflected in a DNS.
•
Administrator puts the entry or entries in the active directory.
• Example for a Microsoft Windows 2000 Server shown on
next several pages.
22
Example: Creating KDC principal
Goal:
• Create a service account into a Microsoft Windows 2000 Active Directory.
• Map krbsvr400/rchasdmm.rchland.ibm.com to the user.
Sequence of Administrator Steps:
2. Select Manage
1. Select the Active Directory
23
Example: Creating KDC principal…
3. From the Users context
menu select New -> User
4. Enter a meaningful User Logon
Name to represent the target iSeries
server and press Next. Suggestion:
krbsvr400<connection name>
Example:
krbsvr400rchasdmm
24
Example: Creating KDC principal…
5. Enter a password for the
user and press Next.
25
6. Press Finish to complete the create
user process.
Example: Creating KDC principal…
7. Find the new user and select
Properties from its context
menu.
26
8. If you would like this account to delegate
authority, select the Account tab. Setup the
account for delegation and press OK.
Example: Creating KDC principal…
Are we done?
No.
Not quite.
27
Example: Creating KDC principal…
• We’re not done because:
• iSeries Navigator is going to request service tickets for the principal
krbsvr400/rchasdmm.rchland.ibm.com.
• Principal name will contain “/” and may contain “.”
− Note: host names often contain “.” characters.
• The Windows Active Directory user names aren’t allowed to contain
either “/” or “.” characters.
• The Windows Active Directory requires the principals to be identified
as “service principals”.
28
Example: Creating KDC principal…
Final Step:
• Map the krbsvr400/<host name> to the Active Directory user name
using the ktpass command.
9. Form a command prompt, run the ktpass command. Sample, below:
29
Example: Creating KDC principal…
With i5/OS this can be done with one step by executing the batch file on the
Windows Server.
• The Network Authentication Service Wizard will generate this file for you.
From a command prompt on the KDC, run the batch
file. A portion of the batch file is shown below
30
Example: Alternative creating KDC principal in
PASE
With i5/OS this can be done with the KDC supported on i5/OS.
1) To enter PASE “call QP2TERM”
2) Authenticate to the kadmin server “kadmin
“kadmin –p admin/admin”
3) Create the principal “addprinc krbsvr400/rchasdmm.rchland.ibm.com
31
What Have We Learned about
Kerberos?
• When you authenticate using Kerberos you get a Ticket-GrantingTicket
• Services that use Kerberos authentication require the caller to
provide an appropriate Service-Ticket (ST).
• iSeries Navigator client code requests a ST for krbsvr400/rchasdmm
when using Kerberos.
ws01
Request ST for krbsvr400/rchasdmm
32
KDC
krbsvr400/rchasdmm
Single SignSign-on Step 2: What happens on the
Server?
ws01
Service Ticket for
krbsvr400/rchasdmm
33
KDC
Single SignSign-on Step 2: Kerberos Authentication On The
Server?
Service Ticket for
krbsvr400/rchasdmm
iSeries Host Server Code receives request and performs validation.
• Extracts service name (krbsvr400/rchasdmm) from incoming ST.
• Extracts krbsvr400/rchasdmm password from local “keytab” file.
NOTES:
- Service does NOT contact the KDC.
- Keytab file *PUBLIC EXCLUDE.
- Passwords in keytab encrypted.
• Once ST decrypted with the local password, we are able to:
− Verify ST is valid.
− Extract principal that requested ST, which will be used to complete the
single sign-on operation.
34
“Server Side” Requirements
To Validate a ST, Kerberos must be configured on Server:
• Must have the name of the Kerberos realm or Windows Domain
• Must have a keytab file to store passwords for local service principals.
• In current example, Keytab file must contain a password for the service
principal krbsvr400/rchasdmm.rchland.ibm.com
How do you set these three things up?
All items can be set through the Network
Authentication Service (NAS) wizard!
35
“Server Side” Requirements…
Using Network Authentication Service (NAS) wizard!
1. Launch point
36
2. Welcome Screen
“Server Side” Requirements…
3. Kerberos realm name.
• Needed for ST validation.
37
4. DNS name of the Kerberos KDC.
• Not used for ST validation.
• Used if KDC is contacted.
“Server Side” Requirements…
5. DNS name of the KDC’s password server.
• Not needed for ST validation.
6. Select which iSeries Single Sign• Usually the KDC has its own.
on principals to setup.
•
38
Needed for ST validation.
“Server Side” Requirements…
7. Set passwords for iSeries Single
Sign--On kerberos Service
Sign
Principals in keytab
Needed for ST validation.
39
“Server Side” Requirements…
7. New in V5R3,, if using a Microsoft
KDC, you can choose to create a
“bat” file to do all the Windows
Active Directory work for you!!
40
“Server Side” Requirements…
8. Wizard is Complete
• Keytab entries used for ST validation.
• Information in config file used for ST validation.
41
Managing the Keytab File
TASK: Show the existing keytab entries. New in i5/OS.
Choose service to manage…
Use Manage Keytab…
42
Managing the Keytab File
TASK: Show the existing keytab entries. New in i5/OS.
View the existing entries…
43
Create new or update entries…
Kerberos Review
When a user authenticates to a Kerberos KDC, they get a TGT
• By authenticating to a Windows Domain or MIT KDC.
Once authenticated, the user (client) can authenticate to services by
acquiring Service Tickets (ST) from the KDC.
• For example krbsvr400/rchasdmm
The service receives the ST from client application and validates it.
• The service principal’s secret key, stored in a secure keytab file, is used to
decrypt and validate it.
• Once the ST is validated, the client principal stored inside the ticket is used
to continue single sign-on process.
44
Single SignSign-on Steps for kerberos
Get password for krbsvr400/rchasdmm
KEYTAB File
Decrypt and validate ST
Extract user name & domain:
ws01 IBMROCHESTERMN
ws01
TGT request: User name ws01
KDC
Service Ticket for
krbsvr400/rchasdmm
Request ST for krbsvr400/rchasdmm
Service Ticket for
krbsvr400/rchasdmm
45
KDC for Windows Domain
IBMROCHESTRMN
EIM’s role in Single SignSign-on
• At this point, Kerberos authentication is complete!!!!
However, Single Sign-On is not.
• iSeries rchasdmm knows they received a valid ST from ws01 in the
domain IBMROCHESTERMN
What iSeries OS/400 profile should be used to complete the iSeries
Navigator “open connection” for rchasdmm?
EIM will provide that answer!
46
How EIM Helps SSO
SITUATION:
I have a network (or enterprise).
Using a Kerberos server to manage workstation IDs.
People have access to many systems and APPs in network.
People have to “sign-on” to many systems and APPs in my
enterprise.
KDC
GOAL of SSO:
Reduce the number of systems and APPs people have to
directly “sign-on” and the number of passwords to manage.
I DON’T WANT:
A user ID and password synchronization tool.
A new authentication scheme.
A new authorization scheme.
I DO WANT:
To Identify people in the enterprise.
To map enterprise individuals to the different users they are in all the systems or APPs
in the enterprise.
To be able to find out who I should be “here” based on knowing who I authenticated as.
47
Building an EIM Mapping
Joseph Accountant
rchasdmm
rchasrc2
JOE
JOEA
Receives
Service--Tickets
Service
Target
Receives
Service--Tickets
Service
IBMROCHESTRMN
rchasdmm
JOE
TARGET
Kerberos
KDC
KDC
ws01
Target
rchasrc2
JOEA
TARGET
Source
IBMROCHESTERMN
ws01
SOURCE
EIM Identifier:
Registry Name
48
Registry User
Association Type
Building an EIM Domain
rchasdmm
rchasrc2
IBMROCHESTRMN
KDC
EIM Domain
EIM Identifier:
EIM Identifier:
EIM Identifier:
Registry
Registry
User
Joseph
Accountant
Association Type
EIMName
Identifier:
Registry
Name
Registry User
Association Type
Registry Name
Registry User
Association Type
Registry Name
Registry User
Association Type
ws01
SOURCE
rchasrc2
JOEA
TARGET
rchasdmm
JOE
TARGET
IBMROCHESTERMN
49
EIM Domain Stored in LDAP
rchasdmm
rchasrc2
EIM
Domain
IBMROCHESTRMN
KDC
EIM Identifier:
EIM Identifier:
EIM Identifier:
Registry
Registry
User
Joseph
Accountant
Association Type
EIMName
Identifier:
Registry
Name
Registry User
Association Type
Registry Name
Registry User
Association Type
Registry Name
Registry User
Association Type
ws01
SOURCE
rchasrc2
JOEA
TARGET
rchasdmm
JOE
TARGET
IBMROCHESTERMN
50
LDAP
Back to Single SignSign-On: EIM Steps
Server side of iSeries Navigator “open connection”
rchasdmm
KEYTAB File
Kerberos authentication complete for
ws01@IBMROCHESTERMN
Use EIM to find the OS/400 profile to use:
Issue “eim get target from source” passing ws01 and
IBMROCHESTERMN
During process:
EIM API retrieves appropriate data from EIM domain.
iSeries Navigator server code starts job under the profile
returned.
User is not prompted for the password.
51
EIM Lookup: Get Target From Source
rchasdmm
iSeries
Navigator
code
“Query”
Get Target
from:
Submits
job
using
user
ws01 in IBMROCHESTERMN
Profile JOE
rchasrc2
IBMROCHESTRMN
Single SignSign
-ON COMPLETE!!!!!!
52
EIM
Domain
KDC
EIM Identifier:
Return ws01 =
JOE on rchasdmm
LDAP
Joseph Accountant
Registry Name
Registry User
Association Type
IBMROCHESTERMN
ws01
SOURCE
rchasrc2
JOEA
TARGET
rchasdmm
JOE
TARGET
What Does the EIM Wizard Do
• Pointed the iSeries to the LDAP server that has EIM
data.
• Provided an LDAP ID for EIM functions to use when
reading or changing EIM data.
• Added the local server in the list of registries
for the EIM domain.
• Added the Kerberos Realm into the list of registries
for the EIM domain, if it wasn’t already there.
53
Network Authentication
Enhancements in i5/OS
Network Authentication iSeries Navigator Enhancements
• Host name resolution conflict warning.
• Batch file creation to create Active Directory Users.
• HTTP support.
• Manage Keytab Wizard.
KDC running natively in OS/400 PASE
• Provides an alternative to Microsoft Servers.
• Configured/administered like AIX KDC.
54
Summary
EIM and Kerberos are underpinnings for Single SignOn implementation.
• Kerberos provides the authentication.
• EIM provides the association (mapping) between the
Kerberos identity and the local identity.
SSO implementation leaves all local security semantics
intact. (authority, auditing, user privilege)
• Reduced implementation cost.
• Seamless to the user.
55
Summary
iSeries functions that support
Kerberos authentication with EIM
associations:
56
DRDA
IBM iSeries Access for Windows
ODBC
JDBC (Java Toolbox for iSeries, JTOpen)
NetServer
PC5250 Emulation
QFileSvr.400
HTTP
Management Central
Windows integration via IXS and IXA attached xSeries
Trademark & Disclosure Statements
The following terms and marks are trademarks of Botz & Associates, Inc.:
is a trademark of Group8 Security, Inc.
Other company, brand and product names are trademarks or registered trademarks of
their respective holders.
Information is provided “AS IS” without warranty of any kind. All examples described are
presented as illustrations of how customers have used BAI recommendations, products
or services and are the results they may have achieved. Actual results may vary by
customer. Information concerning non-BAI products or services was obtained from a
supplier of these products, published announcement materials, or other publicly available
sources and does not constitute an endorsement of such products by BAI.
P.O. Box 7498 Rochester, MN 55903 Telephone: (507) 319-5206 www.botzandassociates.com
© 2009 Botz & Associates, Inc. All Rights Reserved.
ABOUT THE SPEAKER
Patrick Botz is the founder and president of Botz & Associates, Inc.
Prior to starting Botz & Associates, Pat served as the Lead Security Architect and Team Leader for the
IBM, working on some of the most widely used midrange servers is the business world with a focus on
authentication, authorization, auditing, and ease of use. Following his work primary focus on helping
customers meet various industry regulations such as SOX, PCI DSS, and SAS 70. He additionally
worked to help customers improve the effectiveness and efficiency of their current security
management processes, assisting them with moving to exclusionary access control models, eliminating
passwords in various environments, managing User IDs, implementing encryption, and auditing on
various platforms.
Pat is co-author of the book /Expert’s Guide to OS/400
and i5/OS Security/, and has published numerous
articles in the trade press and IBM magazines. He is
also a noted worldwide security conference speaker,
presenting at various conferences and in webcasts
including COMMON, IBM Technical Conference,
various user groups, St. Cloud State University Security
conference, and IBM Business Partner conferences.
P.O. Box 7498 Rochester, MN 55903 Telephone: (507) 319-5206 www.botzandassociates.com
© 2009 Botz & Associates, Inc. All Rights Reserved.
P.O. Box 7498
Rochester, MN 55903
Telephone: (507) 319-5206
www.botzandassociates.com
ABOUT Botz & Associates, Inc.
We specialize in helping customers understand and execute the
business AND technical aspects of the security management
process.
© 2009 Botz & Associates, Inc. All Rights Reserved.