Front cover
Case Study: AIX and
WebSphere in an
Enterprise Infrastructure
Integrate AIX with Microsoft Active Directory-based
authentication and directory services
Use Microsoft Identity Information
Server and Active Directory
Application Mode LDAP
Integration details from an
actual enterprise scenario
Colin Renouf
ibm.com/redbooks
Redpaper
International Technical Support Organization
Case Study: AIX and WebSphere in an Enterprise
Infrastructure
September 2008
REDP-4436-00
Note: Before using this information and the product it supports, read the information in “Notices” on page v.
First Edition (September 2008)
This edition applies to IBM AIX v5.3 and IBM WebSphere Application Server v6.1
© Copyright International Business Machines Corporation 2008. All rights reserved.
Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule
Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .v
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Author. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
You can become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Comments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Chapter 1. The Application Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Overall infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 The middle tier: WebSphere MQ and high availability . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 WebSphere Portal Server and WSRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.1 Using Workload Partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.7 Design for expected load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 2. Active Directory Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Integrating WAS 6.1 and AIX with Windows 2003 R2 Active Directory security . . . . . .
2.1.1 RFC 1510 Kerberos authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 RFC 2307 POSIX user and group mappings for LDAP based directories . . . . . .
2.1.3 RFC 2478 SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 System configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Ensure Windows 2003 Server R2 Active Directory is configured . . . . . . . . . . . . .
2.2.2 Add user accounts for the AIX system and WAS . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Export the Keytab file from Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Prepare the AIX environment for Kerberos support . . . . . . . . . . . . . . . . . . . . . . .
2.2.5 Configure AIX Administrative users and groups . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6 Configure the AIX Environment for LDAP support . . . . . . . . . . . . . . . . . . . . . . . .
2.2.7 Configure Windows Internet Explorer clients . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.8 Set up the WebSphere Application Server 6.1 for SPNEGO . . . . . . . . . . . . . . . .
2.2.9 Set up the directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.10 Results for WebSphere Application Server single sign-on users . . . . . . . . . . . .
2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
12
13
14
14
15
15
17
19
20
23
24
26
27
36
40
41
Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
How to get Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
43
43
43
44
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
© Copyright IBM Corp. 2008. All rights reserved.
iii
iv
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Notices
This information was developed for products and services offered in the U.S.A.
IBM may not offer the products, services, or features discussed in this document in other countries. Consult
your local IBM representative for information on the products and services currently available in your area. Any
reference to an IBM product, program, or service is not intended to state or imply that only that IBM product,
program, or service may be used. Any functionally equivalent product, program, or service that does not
infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to
evaluate and verify the operation of any non-IBM product, program, or service.
IBM may have patents or pending patent applications covering subject matter described in this document. The
furnishing of this document does not give you any license to these patents. You can send license inquiries, in
writing, to:
IBM Director of Licensing, IBM Corporation, North Castle Drive, Armonk, NY 10504-1785 U.S.A.
The following paragraph does not apply to the United Kingdom or any other country where such
provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION
PROVIDES THIS PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT,
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of
express or implied warranties in certain transactions, therefore, this statement may not apply to you.
This information could include technical inaccuracies or typographical errors. Changes are periodically made
to the information herein; these changes will be incorporated in new editions of the publication. IBM may make
improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time
without notice.
Any references in this information to non-IBM Web sites are provided for convenience only and do not in any
manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the
materials for this IBM product and use of those Web sites is at your own risk.
IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring
any obligation to you.
Information concerning non-IBM products was obtained from the suppliers of those products, their published
announcements or other publicly available sources. IBM has not tested those products and cannot confirm the
accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the
capabilities of non-IBM products should be addressed to the suppliers of those products.
This information contains examples of data and reports used in daily business operations. To illustrate them
as completely as possible, the examples include the names of individuals, companies, brands, and products.
All of these names are fictitious and any similarity to the names and addresses used by an actual business
enterprise is entirely coincidental.
COPYRIGHT LICENSE:
This information contains sample application programs in source language, which illustrate programming
techniques on various operating platforms. You may copy, modify, and distribute these sample programs in
any form without payment to IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating platform for which the sample
programs are written. These examples have not been thoroughly tested under all conditions. IBM, therefore,
cannot guarantee or imply reliability, serviceability, or function of these programs.
© Copyright IBM Corp. 2008. All rights reserved.
v
Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines
Corporation in the United States, other countries, or both. These and other IBM trademarked terms are
marked on their first occurrence in this information with the appropriate symbol (® or ™), indicating US
registered or common law trademarks owned by IBM at the time this information was published. Such
trademarks may also be registered or common law trademarks in other countries. A current list of IBM
trademarks is available on the Web at http://www.ibm.com/legal/copytrade.shtml
The following terms are trademarks of the International Business Machines Corporation in the United States,
other countries, or both:
AIX®
Ascential®
BladeCenter®
CICS®
DataStage®
DB2®
FileNet®
HACMP™
IBM®
IMS™
POWER™
POWER3™
POWER5™
POWER5+™
POWER6™
Redbooks®
Redbooks (logo)
System p™
Tivoli®
WebSphere®
®
The following terms are trademarks of other companies:
FileNet, and the FileNet logo are registered trademarks of FileNet Corporation in the United States, other
countries or both.
Oracle, JD Edwards, PeopleSoft, Siebel, and TopLink are registered trademarks of Oracle Corporation and/or
its affiliates.
SAP, and SAP logos are trademarks or registered trademarks of SAP AG in Germany and in several other
countries.
J2EE, Java, JDK, JVM, and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the
United States, other countries, or both.
Active Directory, Internet Explorer, Microsoft, PowerPoint, SQL Server, Windows Server, Windows Vista,
Windows, and the Windows logo are trademarks of Microsoft Corporation in the United States, other
countries, or both.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Linux is a trademark of Linus Torvalds in the United States, other countries, or both.
Other company, product, or service names may be trademarks or service marks of others.
vi
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Preface
This IBM® Redpaper presents a technical case study describing, in detail, how a realistic
enterprise level application and system architecture would look for an environment that
provides AIX® and WebSphere®-hosted applications integrated with Microsoft® Active
Directory®-based authentication and directory services.
We recommend that readers of this paper also become familiar with the IBM Redbooks®
publication Running IBM WebSphere Application Server on System p and AIX, SG24-7347.
In addition to the topics covered in that book, this paper provides a reference architecture and
technical guide for the design and integration of highly available WebSphere applications
hosted on AIX with Active Directory-based services.
Author
Colin Renouf is a Solutions and Infrastructure Architect, working for a large UK-based bank.
With about 25 years in the IT industry, having formerly been an Aeronautical Engineer at an
aircraft engines company, he specialized in Windows® development and infrastructure.
However, being familiar with AIX since its early days, and having a keen interest in Java™ and
J2EE™, Colin added WAS and AIX to his specialties. As an active member of the user
communities, he runs some of the largest user groups in the world, notably for AIX and jointly
for all things related to WebSphere. Colin has a BSc degree in Aeronautical Engineering, a
BA in IT and Social Sciences, and has studied several other subjects at the degree level.
You can become a published author
Join us for a two- to six-week residency program! Help write a book dealing with specific
products or solutions, while getting hands-on experience with leading-edge technologies. You
will have the opportunity to team with IBM technical professionals, Business Partners, and
Clients.
Your efforts will help increase product acceptance and customer satisfaction. As a bonus, you
will develop a network of contacts in IBM development labs, and increase your productivity
and marketability.
Find out more about the residency program, browse the residency index, and apply online at:
ibm.com/redbooks/residencies.html
Comments welcome
Your comments are important to us!
We want our papers to be as helpful as possible. Send us your comments about this paper or
other IBM Redbooks in one of the following ways:
򐂰 Use the online Contact us review Redbooks form found at:
ibm.com/redbooks
© Copyright IBM Corp. 2008. All rights reserved.
vii
򐂰 Send your comments in an e-mail to:
redbooks@us.ibm.com
򐂰 Mail your comments to:
IBM Corporation, International Technical Support Organization
Dept. HYTD Mail Station P099
2455 South Road
Poughkeepsie, NY 12601-5400
viii
Case Study: AIX and WebSphere in an Enterprise Infrastructure
1
Chapter 1.
The Application Infrastructure
In the IBM Redbook, Running IBM WebSphere Application Server on System p and AIX,
SG24-7347, we examined a simplified, but fairly standard online transaction processing
(OLTP) infrastructure for WebSphere Application Server (WAS) on AIX. The infrastructure
consisted of a set of IBM JS/21 BladeCenter® Web servers, two IBM POWER5+™ Power
570 application servers in the middle tier, and two IBM POWER5+ Power 570 database
servers, all spread across two geographically dispersed data centers. Each data center had
an IBM N5500 NAS. A third data center maintained quorum.
In reality, an enterprise is more complex, with additional earlier platforms and systems at the
back end, a mix of software packages, and software and hardware combinations from other
vendors, all of which have to be secured end-to-end. Add to this mix, a set of users, the
majority of whom are probably Windows users. The only remedy for the complexity, and that
does not greatly complicate the environment, is to maintain industry standards wherever
possible. Therefore, Windows Active Directory would most likely be used for system
authentication.
In this chapter, we provide a technical overview of the overall applications and systems
infrastructure for this case study.
Note: We highly recommend that you first review a copy of Running IBM WebSphere
Application Server on System p and AIX, SG24-7347, available at the following location:
http://www.redbooks.ibm.com/abstracts/sg247347.html
© Copyright IBM Corp. 2008. All rights reserved.
1
1.1 Context
We start by placing our example infrastructure in the enterprise context and add security to it.
To do this we adhere to the following principles:
򐂰 Users should authenticate themselves to the enterprise only once.
򐂰 Administrators should authenticate themselves to each system they administer.
򐂰 Internet users are application users only, but intranet users are a mix of administrators and
application users.
򐂰 Internet and intranet traffic should be segmented.
򐂰 Security must be configured end-to-end throughout the environment; however, wherever
possible, group and OU membership are used for user authorization and permissions,
only up to the Web layer presentation logic tier, with system service-level security beyond
this and the user identity as data.
Thus, user A is a member of group B and the J2EE Web tier. Supporting presentation logic
is secured for access by group B, but the database and ESB tier are secured for access by
the WebSphere user account and any administrators only. The user identity is passed to
back-end services as data for auditing and any fine-grained control for use in code. This
simplifies management of user information and permissions.
򐂰 Industry standard solutions should be used wherever possible to avoid platform
dependencies.
򐂰 Virtualization should be exploited to maximize utilization and minimize infrastructure costs
򐂰 As near to 100 percent application availability as possible should be maintained
We assume System p™ and AIX form the core of our infrastructure.
From a security perspective we exploit the Kerberos RFC 1510 and LDAP standards, with the
RFC 2307 standard for our user representation.
To understand the context of the case study, our sample company is a worldwide travel
company that sells, over the Internet, tickets for holidays and flights, but still maintains an
earlier environment that supports its considerable worldwide office network. We name our
company “Rest’n’Relaxation Enterprises UK” (RnREnterprise). The company is
headquartered in the U.K., but has regional offices, which from an organizational perspective
are part of the Head Office, and has branch offices around the world. Within a country, a
dedicated network is used, but for communications between countries, a virtual private
network (VPN) is used over the Internet.
1.2 Overall infrastructure
Because most of the company’s users are Windows XP and Windows Vista® users internally,
Windows Active Directory most likely will be used for their system authentication. Windows
2003 Server R2 Active Directory supports the RFC 1510 Kerberos standard for Windows
login, with the user information available through LDAP to Windows clients. With the R2
release, the user information can be mapped to the RFC 2307 standard that can be used for
UNIX® logins. This allows AIX to use Active Directory for authentication of internal users and
checking their user information, but also allows WAS to use Active Directory for a transparent
Web-based single sign-on with the use of the WebSphere Application Server 6.1 Simple and
Protected GSS-API Negotiation Mechanism (SPNEGO) Trust Association Interceptor (TAI).
2
Case Study: AIX and WebSphere in an Enterprise Infrastructure
For external Internet users, a simple IBM Tivoli® Directory Server environment is used and
the users are presented with a login page to fill in their user IDs and passwords.
In general, the enterprise is complex and also has workflow services using the IBM FileNet®
P8 application and various components of an Enterprise Service Bus (ESB) for integrating the
earlier systems the company has with the rest of the enterprise. The earlier systems on
various platforms support a multitude of technologies ranging from WebSphere MQ, to
CICS®, to IMS™ and various non-IBM proprietary environments. To front some of these
systems, a multi-tiered approach is adopted in which the earlier system presents WebSphere
MQ or Web services interface wrappers wherever possible, but without security beyond
Secure Sockets Layer (SSL) and IP routing table settings. IBM WebSphere Data Power XI50
broker-in-a-box XML security appliances present WS-Security-compliant interfaces to the
outside world and onto the ESB.
Our overall infrastructure, with the networking-specific components simplified, is shown in
Figure 1-1 on page 4. This is a very complex environment, but essentially the Web traffic from
the Internet comes in from the top through a load balancer and is passed through a firewall
layer to get to the WebSphere Application Server (WAS) environment hosting the application
layer. The user initially gets a login page and the user ID and password are validated against
the active IBM Tivoli Directory Server LDAP environment before a session is initiated. The
session is valid for all applications on the given WAS environment. If the application layer
requires database-hosted data, it goes to the Oracle® 10G R2 or IBM DB2® v9 with
Gridscale environment, and if it requires legacy data, it enters the ESB layer. Similarly,
workflows can be initiated by the WAS layer by redirecting to a FileNet-hosted page. The
Network Attached Storage (NAS) environments help maintain transactional integrity as they
host the WAS logs. For access to earlier systems, the ESB layer uses WS-Security presented
by the DataPowerXI50 security appliances, which have controlled static routes that act as the
only path from these data center zones to the earlier systems.
Chapter 1. The Application Infrastructure
3
Figure 1-1 Overall infrastructure
For intranet users, the flow is a little different. The users initially log into Active Directory from
the Windows XP environment; similar behavior can be obtained by using Mac OS X or Linux®
desktops. Under the covers, the initial login uses Kerberos, first to get a ticket granting ticket
from the Key Distribution Center (KDC) component of the Kerberos subsystem within Active
Directory using mutual authentication, and then to get further tickets to access services. The
LDAP support is used for obtaining further group and organizational unit membership
information for the user.
When any Windows services are accessed, a ticket is obtained by the client in the
background of the user request and is presented to the server hosting the service that
mutually authenticates with the KDC before granting access. The user community using the
WAS application goes through a different firewall configuration and accesses a different set of
Web servers. We do this to segment the security information between the Internet and
intranet worlds. When their requests are forwarded to WAS, the SPNEGO Trust Association
Interceptor (TAI) intercepts the request and transparently forwards it to the Active Directory
KDC for validation before setting up the appropriate session headers for the user and allowing
access to the application. This is all done without presenting a login window because the
browser forwards the credentials in a header after the first Web access is transparently
rejected with a request for authentication. After this, the remaining behavior is the same for
the application.
4
Case Study: AIX and WebSphere in an Enterprise Infrastructure
1.3 Enterprise Service Bus
We mentioned an Enterprise Service Bus (ESB) as part of our deployment architecture, so
we should explain how this architecture, shown in Figure 1-2, all fits together.
Figure 1-2 Architecture overview
This environment supports both batch and online requirements. On a regular basis,
organizations have to move and manipulate data from earlier systems to support online
databases that sit behind online systems; organization have to do this without negatively
affecting the earlier systems and their clients. For this, organizations use the IBM
DataStage®, QualityStage and ProfileStage products, which are the current IBM versions of
the former Ascential® ETL (Extraction, Transformation, and Load) tools. The behavior of the
DataStage environment is very resource-intensive under high loads, so a conscious decision
has been made to provide two dedicated physical POWER6™-based System p machines
that run the DataStage Enterprise environment and feed the database servers of the online
system. This also assists in allowing the online system to meet its 24x7 requirement as the
systems are physically independent. Loads of the transformed legacy data can be undertaken
into temporary copies of the tables on the database servers that are then transactionally
swapped with the current online tables. Note that the interconnect between the database
servers must be able to support the volume of the data loads; tuning of the load process itself
is required. This batch environment is not shown in Figure 1-2 as being external to the main
components under consideration, but is still a critical part of the overall solution.
Chapter 1. The Application Infrastructure
5
1.4 The middle tier: WebSphere MQ and high availability
In the middle tier, most of the remaining online WebSphere components are housed on a
single platform. One exception is a WebSphere MQ Server environment for a high volume
and high availability WebSphere MQ cluster. A WebSphere MQ cluster allows a message to
be sent to any queue manager but received only from the local queue manager, with shared
queues and backup queues providing the resilience. To support this cluster, at least two
copies of the full repository containing the cluster configuration, and a persistent message
store (such as our NAS tier) are required for persistent messages. The infrastructure for a
highly available and high volume WebSphere MQ cluster is very different from that of the rest
of the WebSphere-branded products in that failover is handled at the operating system level
through High Availability Cluster Multi-Processing (HACMP™). Therefore, although this is a
core part of the Enterprise Service Bus (ESB) environment, this also not shown in Figure 1-2
on page 5, but is a key part of the online environment. We aim to keep multiple copies of the
full repository available. This part of our infrastructure supports the flight management
information system and payments system, and has extremely large volumes.
In our ESB architecture, we also have a high availability WebSphere Message Broker with
WebSphere MQ environment. This is C-based code, has similar failover requirements to the
cluster shown in Figure 1-3, and is dependent on it.
Figure 1-3 HA Environment for WebSphere Message Broker and WebSphere MQ
6
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Therefore, hosting this on the same physical machines as our WebSphere MQ cluster makes
sense, but in different partitions to allow in-memory transfer of messages using Virtual
Ethernet for performance, but suitable levels of isolation. WebSphere Message Broker also
needs a database environment for its formatters and rules storage, but can use that for our
online system.
1.5 WebSphere Portal Server and WSRP
To understand the next part of the infrastructure, you should understand a little of the
application architecture that makes use of our WebSphere Portal Server environment (see
Figure 1-4). This is an application that sits on top of a normal WAS environment to support
user customization of presentation. However, it also functions as part of the ESB. To support
customization of pages, a Portal Server must be able to front other pages. A standard exists
called Web Services for Remote Portlets (WSRP) that supports just that. In this, applications
can host pieces of user presentation as portlets that are designed to be composed with other
portlets for integration at the glass. Business applications such as those from SAP® and
Oracle Applications can present these portlets. The WSRP standard essentially makes use of
Web services to communicate presentation layout information and requirements, and in many
ways is similar to the Microsoft Object Linking and Embedding (OLE) technology that allowed
PowerPoint® presentations to be embedded in Word documents in function. To support this
level of integration, the WebSphere Portal Server uses a reduced version of the WebSphere
Process Server Business Process Execution Language (BPEL) engine.
Figure 1-4 WSRP view
Chapter 1. The Application Infrastructure
7
1.6 Partitioning
Discussion in the previous sections leads us to the partition layout, which we also described
previously. Note the benefits of hosting all of the software that sits on WAS on the same
physical System p machine as shown in Figure 1-5, although the packages are in logically
different tiers of the environment. This gives us improved throughput using in-memory
transfers through Virtual Ethernet, which is controlled by the POWER6 Hypervisor to improve
the performance and ease of management and maintenance. Thus, we get a partition layout
similar to the previous one, with all of the WAS-based applications hosted on it. As the
products develop and mature, this pattern will likely reap further benefits.
Figure 1-5 Partition layout
1.6.1 Using Workload Partitions
With the introduction of AIX 6.1 Workload Partitions (WPARs), you now have a means to use
approximately 12 MB of memory to create a software-based partition within a logical partition
and that maps down to the LPAR operating system image. A WPAR-based partitioning layout
is shown in Figure 1-6 on page 9. The native operating system image is the global
environment. WPARs are essentially AIX machines in their own right because each has its
own host name, process list, and so on. All of this, however, is mapped into the global
environment, from where it is controllable and visible.
8
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 1-6 WPAR partition layout
If we combine our partition layout infrastructure pattern with WPARs on AIX 6.1, we have
isolation for security reasons and the ability to create a number of developer environments
quickly and easily. However, with the JVM™ shipped with WAS 6.1, the shared classes
feature does not work, which affects memory and various aspects of performance.
If we combine a Java6 environment with AIX 6.1, things are different, as memory mapped
files are used for the shared classes implementation. We can then put a copy of our common
code in the global environment, which all WPARs point to. For shared classes, we have many
levels of security, ease of management for test environments and developers, and a reduction
in memory usage. WAS does not support Java6 today, but could support it in a future release.
Today, we use WAS 6.1. By giving J2EE developers their own isolated and clustered
environment, they can develop on the cluster and identify clustering issues in their designs or
code before late testing or production. No sharing exists in this scenario because the WAS
Class Sharing mechanism is shared memory-based. There is no visibility across WPAR
boundaries. Thus, with WAS 6.1, no benefit exists to using WPARs beyond software isolation
(which the JVM gives to some extent anyway), and there is no benefit to having any WAS
instances in the global environment.
Chapter 1. The Application Infrastructure
9
1.7 Design for expected load
When we set up any of our WAS-based environments, we calculate how many instances of a
WAS are necessary to support our load. If we have two physical data center environments,
we must be able to handle the loss of a data center, so we use vertical and horizontal
clustering to make sure we can accommodate all of the loading in a single data center.
If we know the arrival rate of Web requests and the duration of processing of those requests,
we can use the 50-thread limit for the Web container to calculate the number of instances we
need. In practice, most applications do not hog the processor, but do wait for I/O—some
applications perform complex calculations and we must consider a worst case. For an arrival
rate of 100 requests per second, with each request taking two seconds from the point of entry
into the WAS Web container until it leaves WAS, then 200 requests are in flight at any one
time. Therefore, 200 instances divided by 50, which equals four instances that are required to
support the load. Because this must be accommodated in a single data center, in total we
require eight instances, or four instances in each data center.
We can now map this to physical hardware. A modern POWER™ processor supports
Symmetric Multiprocessing, with two threads per processor core. Although limitations exist for
instruction scheduling, we can assume that the threads behave the same across both thread
instruction streams. Each thread on a POWER5™ or later has its own run queue, which is the
number of threads that have their resources and are ready and waiting to run. It is normally
desirable to keep this queue depth number less than 2 for steady state throughput on the
processor, giving six threads per core as one is actually running. Therefore, each of our four
instances can support 50 threads; the next integer larger than 50 divided by six is the number
of processor cores required to support our load (for example, nine processor cores per WAS
instance). Do not forget that additional asynchronous threads are in use within WAS and the
operating system, so we always go above the calculated number to the next highest integer.
Because we have to accommodate the complete load in each data center, we need four times
this value to accommodate the four instances, (for example, 36 processor cores). This is a
large value and does not recognize the amount of time an application must wait for I/O.
In practice, the previous calculation is an upper bound. Because applications typically spend
the majority of their time waiting for I/O, test the application in a representative environment
and tune the processors required to keep the thread-run queue below two.
In this case study, we decided to have two cells for security isolation reasons:
򐂰 One cell for Internet-facing traffic
򐂰 One cell for intranet-facing traffic
We apportion the loads to clusters and cells accordingly.
So far we have placed all of the key components of our environment without discussing
security in detail, and without considering Cluster Systems Management (CSM), Network
Installation Manager (NIM), or Hardware Management Console (HMC) environments.
In this case study, we combine management applications, such as CSM and NIM, on a single
physical system, and we use HACMP to fail-over between our data centers (choosing one to
be active and another passive), which is acceptable given that these do not affect the running
of the environment. (See Running IBM WebSphere Application Server on System p and AIX,
SG24-7347, for general considerations and technical guidance in using CSM and NIM.)
For the HMC, we use dual HMCs for every environment. The command line interface is fast
so this is preferred for management of the CEC and partitions.
We discuss security in the next chapter.
10
Case Study: AIX and WebSphere in an Enterprise Infrastructure
2
Chapter 2.
Active Directory Integration
In this chapter, we discuss the integration details for Active Directory security.
© Copyright IBM Corp. 2008. All rights reserved.
11
2.1 Integrating WAS 6.1 and AIX with Windows 2003 R2 Active
Directory security
AIX has supported Kerberos and LDAP for many years. Our objective is to have
administrators, who are likely to have Windows desktops that are integrated into a common
Active Directory forest for the organization:
򐂰 Log in as normal to the AIX environment .
򐂰 Have their credentials checked using the RFC 1510 Kerberos and RFC 2307 LDAP
POSIX User information provided by Active Directory.
This saves money for many organizations because the security and passwords for the
enterprise can be managed in one place, and the operations of a user can be tied together
across the enterprise for traceability, which is a compliance requirement for many industries.
Additionally, if the organization has a human resources (HR) application such as Oracle
HRMS or SAP HR, then when a new user joins the organization and the user role is set up,
the user accounts and permissions across the enterprise can automatically be provisioned.
A number of user provisioning and identity management tools exist, such as the Tivoli Identity
Manager. However, because this is a Microsoft environment, we assume the Microsoft
Identity Information Server (MIIS) is being used with its SQL Server® database acting as a
repository, and a Microsoft Active Directory Application Mode (ADAM) LDAP server as its
target repository.
When a new user joins our RnREnterprise company, the Oracle HRMS system generates
entries in its tables, including role information. From this, we can identify roles, our application
users, and our AIX administrators. We also can use the Microsoft Identity Information Server
to massage the data and populate our MS ADAM environment with a configured set of rules.
We use ADAM with the same user ID that we use to populate the full Active Directory
environment for Windows login. We do however, separate the two to allow for additional
directory objects required for the applications we are using so that we do not pollute the main
Active Directory forest and slow down replication and login. Because the core schema is the
same for Active Directory and ADAM, we can use the two together, with Active Directory
acting as the primary location of authentication data and ADAM as the primary location of
authorization data.
For our Internet users, we have a separate IBM Tivoli Directory Server environment to act as
an LDAP server for login, so the information that follows in the next sections applies only to
the internal administrators and users.
Key infrastructure requirements are:
򐂰 AIX 5.3 TL05, although TL06 is preferred for synchronized password changes.
򐂰 Windows 2003 Server R2 Active Directory is used.
򐂰 WebSphere Application Server Network Deployment v6.1 is used.
򐂰 Authentication uses Kerberos to the RFC1510 standard.
򐂰 Authorization and user role identity management (such as group, OU membership, and
others) uses Kerberos authentication and LDAP over SSL.
򐂰 Trust relationships between multiple domains in a forest must be fully implemented on the
Windows side in Active Directory rather than locally on the AIX environment.
򐂰 Across multiple domains a user ID must exist only once to avoid subsequent issues with
Kerberos authentication and LDAP applications running on AIX.
12
Case Study: AIX and WebSphere in an Enterprise Infrastructure
We consider the key points of the security mechanisms we are implementing in the following
sections.
2.1.1 RFC 1510 Kerberos authentication
Kerberos is a trusted third party ticket granting service, originally developed by MIT, and is
currently at release 5. Its names is from the mythological three-headed dog that guarded the
gates of Hades. It is a robust, standard authentication mechanism that is implemented on
many environments and is now available as part of the Windows Active Directory.
The main Kerberos Server is a Key Distribution Center (KDC) and consists of an
Authentication Service (AS) and a Ticket Granting Service (TGS). The environment it
manages is called a realm, which is essentially a security domain consisting of principals of
users, servers, and services.
Authentication is to the KDC Authentication Service and not to individual servers or services.
This is a trusted third-party authentication mechanism in which clients and servers both trust
the KDC AS. During login to a client, the user name gets sent to the KDC, which replies with
a nonce (a one-time integer challenge value), a session key encrypted through the user
password, and a ticket for presentation to the KDC TGS. The password does not cross the
network. The client uses the locally-held password to obtain access to the session key, and
the nonce that it can later present to the TGS with the ticket to obtain access to services.
To access services, the TGS of the KDC is used. When a client wants to use a service, the
client contacts the TGS with its ticket and session key to obtain a ticket for the service. The
request "authenticator" is encrypted with the TGS Session Key. The TGS responds with a
session key for the specific service, encrypted with the original session key, and a ticket for
the service encrypted with the service private key. The client sends the service ticket to the
service, which checks the validity of its private key and the authenticator encrypted with the
session key. See Figure 2-1.
Figure 2-1 Kerberos authentication and ticket granting services
Chapter 2. Active Directory Integration
13
2.1.2 RFC 2307 POSIX user and group mappings for LDAP based directories
Based on UNIX, a standard way to represent users and roles is an LDAP directory. It consists
of a standard set of attribute names for the user, group membership, and more, which can all
be used by a POSIX or UNIX system. Microsoft uses a nonstandard storage mechanism with
Microsoft attribute names. But, the addition of the schema change to support RFC 2307
rectifies this, allowing interoperability between Windows and UNIX accounts without any
Microsoft-proprietary extensions on the UNIX environments.
The representation for users is shown in Table 2-1; representation for groups is in Table 2-2.
Table 2-1 POSIX representation: users
posixaccount
Object
Class
username
CHAR
uid
id
INT
uidnumber
pgrp
CHAR
gidnumber
home
CHAR
homedirectory
shell
CHAR
loginshell
gecos
CHAR
gecos
spassword
CHAR
userpassword
lastupdate
INT
shadowlastchange
Table 2-2 POSIX representation: groups
posixaccount
Object
Class
groupname
CHAR
cn
id
INT
gidnumber
users
LIST
memberuid
Although AIX can be configured to support the Microsoft extensions, changes on the
Windows directory side are required. A standard RFC 2307 User and RFC 2307 Group
mapping file has been included with AIX. The WebSphere registry and directory support
recognizes a number of standard LDAP environments including RFC 2307, although more
specifically, both Active Directory 2003 Application Mode and Active Directory 2003 R2.
2.1.3 RFC 2478 SPNEGO
The Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) is used for a
configured browser to transparently pass an access token for a pre-authenticated user
through HTTP. The first request from a browser configured to support SPNEGO is rejected by
the Web server through an HTTP 401 Authenticate: Negotiate message indicating the
mechanisms that are supported (including SPNEGO). The browser invisibly gets a ticket from
the Kerberos Ticket Granting Service and converts it to a SPNEGO access token. The
browser then invisibly retries the original request but this time includes the SPNEGO access
token. The WebSphere Application Server SPNEGO Trust Association Interceptor (TAI)
decodes the user ID from the token, checks against the WebSphere Application Server
14
Case Study: AIX and WebSphere in an Enterprise Infrastructure
(WAS) registry (AD), and sets the J2EE User Principal. Finally, a LTPA token is returned to
the client for use for the rest of the session.
2.2 System configuration
To set up our end-to-end security:
1. Ensure that the Windows 2003 Server Active Directory meets the R2 standard and has
the appropriate trusts in place with other directories in the forest. Ensure the RFC 2307
POSIX schema extensions are installed.
2. Add user accounts to the Active Directory for each System p system that is to be secured
across the enterprise. Add user accounts to the Active Directory for each System p
system software package we want to run under a shared account across the enterprise.
This includes the WAS. Set the appropriate account attributes for the role.
3. Export a keytab file from each system to be used by the system and the system software
when obtaining permission to access the Active Directory for authentication purposes.
4. Prepare the AIX environment for Kerberos support by copying the key tab file to the AIX
machine and configuring its contents for use by the Kerberos v 5 (krb5) components to
make use of Active Directory.
5. Configure AIX administrative users and groups to use Kerberos authentication.
6. Configure the LDAP environment on AIX to use Kerberos authentication to get access to
the data in Active Directory.
7. Configure the enterprise Internet Explorer® settings to support our single sign-on security.
This might already be in place if Windows authentication is in use with Microsoft Windows
Server® IIS Web servers.
8. Configure WAS to make use of the SPNEGO TAI for Kerberos authentication against
Active Directory with the information in the AIX keytab file.
9. Configure the WAS Federated Directory support to access a local file for certain admin
accounts, and Active Directory for the system accounts, admin accounts, and user
accounts.
Each step is described in more detail in the next sections.
2.2.1 Ensure Windows 2003 Server R2 Active Directory is configured
First, use the Active Directory Domains and Trusts tool to ensure that the appropriate trusts
are in place for all AD domain environments against which the users can be authenticated
within the forests.
For full integration with Active Directory, without using proprietary extensions, requires the
Windows 2003 Server Active Directory schema to be at R2 level to support the RFC 2307
LDAP extensions for UNIX account management. Windows 2003 Server fully supports the
Kerberos RFC 1510 standard without this, but the schema is required to enable additional
features such as group management through LDAP.
To upgrade to the RFC 2307 schema, the Windows 2003 Server must first be upgraded to
Service Pack 1 and then the R2 schema update is applied from the R2 CD. To find details for
the schema update, search the Microsoft Web site by searching for the file named
R2SchemaUpdate.doc. Essentially, a command prompt is opened on the Schema Master
Windows 2003 Server Active Directory and you run the following command from the
Chapter 2. Active Directory Integration
15
\CMPNENTS\R2\ADPREP directory of CD2 of the Windows 2003 Server SP1 R2 installation
set:
adprep /forestprep
This and subsequent operations must be performed by Windows domain administrators.
For the test environment, the schema master Windows 2003 Active Directory domain
controller server is called MICHAEL in the Windows domain and RNRENTERPRISE in the Kerberos
realm. The DNS domain for this environment is RnREnterprise.dyndns.org. Note that the
Kerberos realm name is very important and must be upper case for the security to work
end-to-end. Figure 2-2 and Figure 2-3 show the process to import an LDAP LDIF file
(sch31.ldf). This import process upgrades our schema to support the RFC 2307 POSIX
standard for user names, passwords, directory names, and data that are accessible by LDAP.
Figure 2-2 LDIF import to upgrade schema
Figure 2-3 LDIF import to upgrade schema
16
Case Study: AIX and WebSphere in an Enterprise Infrastructure
2.2.2 Add user accounts for the AIX system and WAS
To enable the AIX environment and WAS system software to use Active Directory for
authentication they must have permission. To do this, they require user accounts in the Active
Directory and a keytab file, which contains a key that authenticates them against the Kerberos
Key Distribution Center (KDC) that is part of the Active Directory environment. Note that these
are Users accounts and not Computers accounts in Active Directory, because the Computers
accounts have an incomplete setup for use with Kerberos.
The machine we set up for this environment is an AIX POWER3™ 44P machine called
spock44p in the DNS domain RnREnterprise.dyndns.org. Note that DES encryption is used
for the accounts because this is the only common encryption mechanism between the
environments.
We used Active Directory Users and Computers tool as shown in Figure 2-4.
Figure 2-4 Active Directory Users and Computers tool
Add a user account by right-clicking the Users folder, then selecting New and then User.
As shown in Figure 2-5 on page 18, enter the host name of the target AIX machine or
partition, without the domain name, in the First name and User logon name fields. Click
Next.
Chapter 2. Active Directory Integration
17
Figure 2-5 Enter user account information
Check the User must change password at next logon box (Figure 2-6), enter a password
that meets both the AIX and Windows password complexity requirements, and click Next.
Figure 2-6 Enter password information
As shown in Figure 2-7 on page 19, click Finish.
18
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-7 Finish adding a user account
Repeat the process for adding a new user for a WebSphere Application Server system
software account called wasuser and a controlling wasadmin account. The wasadmin account
will be the AIX account under which the WebSphere Application Server runs.
2.2.3 Export the Keytab file from Active Directory
The keytab file that authenticates the AIX environment to the Windows 2003 Server Active
Directory environment must be generated by using the ktpass utility from the command line
on the Active Directory domain controller. The provided keytab file must be transmitted to the
AIX environment. Figure 2-8 on page 20 shows that the entry is for host machine
name@Kerberos realm name and that the user account in Active Directory must be mapped to
the keytab file.
Chapter 2. Active Directory Integration
19
Figure 2-8 Export the Keytab file
For subsequent use with the LDAP tools, the Service Principal Name (SPN) associated with
the machine user account is also needed, so use the setspn command to verify, as follows:
C:\Documents and Settings\Administrator>setspn -L spock44p
Registered ServicePrincipalNames for
CN=spock44p,CN=Users,DC=RnREnterprise,DC=dyndns,DC=org:
host/spock44p.RnREnterprise.dyndns.org
For the WAS wasadmin account, the SPN should identify the account as being for an HTTP
service, as follows:
C:\Documents and Settings\Administrator>setspn -a
http/HTTPALIAS.RnREnterprise.dyndns.org wasadmin
The HTTPALIAS is the canonical alias for the WebSphere cluster and wasadmin is the
WAS-owning user.
Finally, use FTP to put the keytab file on the AIX environment. Place it in an AIX user home
directory for the AIX administrator to merge into an existing keytab file with the ktutil utility.
Note: The file transmission must be binary rather than ASCII.
2.2.4 Prepare the AIX environment for Kerberos support
To configure AIX to use Active Directory for its authentication, use the KRB5A authentication
module rather than the KRB5 module. The KRB5 module expects the kadmin interface to be
supported for Kerberos principal management, which the KRB5A module leaves to Windows
tools on the Windows platform.
As shown in Figure 2-9 on page 21, use lslpp to check whether the KRB5A client is installed.
20
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-9 Checking for KRB5A authentication client application
If the client application is not installed, then install krb5.client.rte from the AIX CDs.
To ensure that the appropriate Kerberos support is in the path, given that the JDK™ also
contains its own utilities with the same name, edit /etc/environment and put /usr/krb5/bin and
/usr/krb5/sbin before the JDK in the system PATH variable.
Important: If you do not ensure that the appropriate Kerberos support is in the path, there
might be LDAP, rather than Kerberos, issues later on and some Kerberos tracing could
show errors.
Next, enure the full domain name is entered in /etc/hosts as the first entry. Thus, for a
machine called spock44p with ip address 192.168.200.5, the /etc/hosts entry should be:
192.168.200.5spock44p.RnREnterprise.dyndns.org spock44p
Make sure that the hostname command returns exactly the same text as this first entry:
# hostname
spock44p.RnREnterprise.dyndns.org
If it does not contain the correct information, set the hostname using uname -S and hostname.
For example:
uname -S spock44p and hostname spock44p.RnREnterprise.dyndns.org
Both are necessary to ensure that the hostname is not lost on the reboot by the ODM.
Because Kerberos is very time-sensitive, the AIX environment should use the same Network
Time Protocol (NTP) server source as the Windows Active Directory environments. Verify this
by looking at the ntp.conf file and start the NTP (xntpd) daemon to maintain this
synchronization.
Chapter 2. Active Directory Integration
21
To support full Kerberos integration, the keytab file generated previously by Active Directory
must be integrated with the AIX Kerberos keytab file. The keytab file is located in
/etc/krb5/krb5.keytab. Use the ktutil utility, found in /usr/krb5/sbin, to perform the merging,
as follows:
# /usr/krb5/sbin/ktutil
ktutil: rkt /home/root/spock44p.keytab
ktutil: wkt /etc/krb5/krb5.keytab
ktutil: q
#
In Windows 2003 Active Directory, the Kerberos realm is usually the name of the domain in
uppercase letters. For the test environment, the Kerberos realm is
RNRENTERPRISE.DYNDNS.ORG. However, AIX might not use this value because it is used for the
kadmin interface, which Active Directory does not support.
In addition, Windows 2003 Active Directory sets up a service record similar to the canonical
alias for all Active Directory servers to give clients resilience. This is known as
_kerberos._tcp._dc._msdcs.domainname. Because AIX cannot use these DNS service
records, set up a separate DNS canonical alias to point to all servers that are listed with these
service records in DNS, for example kdcs. Similarly, set up an entry for LDAP access, such as
ldap.
For our test environment, the KDC would be accessed as:
“kdcs.RnREnterprise.dyndns.org”
And the LDAP services would be accessed as:
“ldap.RnREnterprise.dyndns.org”
These must be used as the identifier for the KDC for the setup of the Kerberos client and the
identifier for the setup of the LDAP client respectively.
The DNS domain name is also necessary for the configuration; we are configuring client
options only. To configure the client environment on AIX to use Windows 2003 Active
Directory Kerberos for authentication, use the config.krb5 utility as follows:
# cd /usr/krb5/sbin
# config.krb5 -C -r RNRENTERPRISE.DYNDNS.ORG -d RnREnterprise.dyndns.org -c
kdcs.RnREnterprise.dyndns.org -s kdcs.RnREnterprise.dyndns.org
Initializing configuration...
Creating /etc/krb5/krb5_cfg_type...
Creating /etc/krb5/krb5.conf...
The command completed successfully.
Because Windows does not support all of the same encryption types as set up by default, the
krb5.conf file in the /etc/krb5 directory must be amended to support encryption modes
des-cbc-crc and des-cbs-md5 respectively for the encryption types default-tkt-enctypes and
default-tgs-enctypes under the libdefaults section. This is shown in Example 2-1.
Example 2-1 Amending the krb5.conf file to support encryption types
[libdefaults]
default_realm = RNRENTERPRISE.DYNDNS.ORG
default_keytab_name = FILE:/etc/krb5/krb5.keytab
default_tkt_enctypes = des-cbc-crc des-cbc-md5
default_tgs_enctypes = des-cbc-crc des-cbc-md5
22
Case Study: AIX and WebSphere in an Enterprise Infrastructure
[realms]
RNRENTERPRISE.DYNDNS.ORG = {
kdc = kdcs.RnREnterprise.dyndns.org:88
admin_server = kdcs.RnREnterprise.dyndns.org:749
default_domain = RnREnterprise.dyndns.org
}
[domain_realm]
.RnREnterprise.dyndns.org = RNRENTERPRISE.DYNDNS.ORG
kdcs.RnREnterprise.dyndns.org = RNRENTERPRISE.DYNDNS.ORG
[logging]
kdc = FILE:/var/krb5/log/krb5kdc.log
admin_server = FILE:/var/krb5/log/kadmin.log
default = FILE:/var/krb5/log/krb5lib.log
Next, amend the /usr/lib/security/methods.cfg file to make use of the new configuration for
authentication. This is accomplished by adding the entries, shown in Example 2-2, to the
methods.cfg file.
Example 2-2 Amending the methods.cfg file
KRB5A:
program = /usr/lib/security/KRB5A
program_64 = /usr/lib/security/KRB5A_64
options = authonly
KRB5Afiles:
options = db=BUILTIN,auth=KRB5A
Change /etc/netsvc.conf to check DNS before local information to make sure the machine
names are found in their fully qualified state, although the hosts entry at the beginning of the
instructions should negate the need for this.
2.2.5 Configure AIX Administrative users and groups
Use the mkuser command to add users of the new Kerberos environment. The usage must
point to authentication through the Active Directory.
mkuser registry=KRB5Afiles SYSTEM=KRB5Afiles 1000000
As you set up the user, if an error message indicates the name is too long, the reason might
be that the user was not added correctly on the Active Directory side. Otherwise, a mapping
between a local name and an Active Directory name can be set up by using a variant of the
mkuser command with the auth_name parameter, which identifies the user name as it is listed
in the Active Directory. For example:
mkuser registry=KRB5Afiles SYSTEM=KRB5Afiles auth_name=mgr2222222 2222222
As Figure 2-10 on page 24 shows, the login for a mapped account looks like any other,
although the names in Active Directory and on the AIX platform differ.
Chapter 2. Active Directory Integration
23
Figure 2-10 Mapped account login
2.2.6 Configure the AIX Environment for LDAP support
The goal of using Active Directory as an LDAP server is to enable the centralized storage of
user account information, such as group membership. As Active Directory in Windows 2003
Server R2 fully supports UNIX integration through the RFC 2307 schema extension, the goal
of this step is to offload the information, allowing it to be handled by Active Directory.
To be able to access the Active Directory through LDAP, the LDAP client must be installed. To
integrate through SSL, the LDAP Max Crypto Client and Certificate and SSL support in the
Global Secure Toolkit (GSKit) is required. To verify that these are installed, use lslpp as in
section 2.2.4, “Prepare the AIX environment for Kerberos support” on page 20. If not installed,
the LDAP Client (ldap.client) is on the original AIX CDs, and the other files (gskta.rte and
ldap.max_crypto_client) are on the AIX Expansion Pack CDs.
Normally, for RFC 2307 integration with AIX, the mksecldap utility is used. However, in AIX 5.3
TL05, this utility detects that the LDAP environment is Active Directory and assumes that it is
not RFC 2307-compliant, which is not the case for Windows 2003 Server R2 Active Directory.
This has improved with TL06. Configuring LDAP for this environment is a manual process.
First, the methods.cfg file in /usr/lib/security must be amended to use LDAP to back up
Kerberos. The entry we previously added to use KRB5A files, must now be commented out
when you add the LDAP entries. Keep it in the file, however, to allow testing of Kerberos
independently of LDAP, if required. The entries shown in Example 2-3 should be added to the
end of the file (the asterisks indicate commented lines).
Example 2-3 Amending methods.cfg to configure LDAP as backup to Kerberos
*KRB5Afiles:
*
options = db=BUILTIN,auth=KRB5A
KRB5ALDAP:
options = db=LDAP,auth=KRB5A
LDAP:
program = /usr/lib/security/LDAP
program_64 = /usr/lib/security/LDAP64
24
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Next, manually configure the LDAP client daemon by adding the Active Directory information
into the ldap.cfg file in the /etc/security/ldap directory. Because we are using both standard
RFC1510 Kerberos and RFC 2307 LDAP together, we set them up together. Add the
information shown Example 2-4 to the end of the file.
Example 2-4 manual configuration of LDAP client daemon in ldap.cfg
# First add the list of LDAP servers for this to talk to, in this case
# the canonical alias for Active Directory
ldapservers:ldap.RnREnterprise.dyndns.org
# Add the LDAP server bind distinguished name (DN) and password, i.e.
# that we set up for this machine earlier.
binddn:cn=spock44p,cn=Users,dc=RnREnterprise,dc=dyndns,dc=org
bindpwd:Passw0rd
# Add the AIX LDAP attribute map, in this case for RFC2307 since we are
# using Windows 2003 Server R2 Active Directory which supports RFC 2307
userattrmappath:/etc/security/ldap/2307user.map
groupattrmappath:/etc/security/ldap/2307group.map
# Add the Base DN where the user and group data are stored in the
# Active Directory LDAP Server
userbasedn:cn=Users,dc=RnREnterprise,dc=dyndns,dc=org
groupbasedn:cn=Users,dc=RnREnterprise,dc=dyndns,dc=org
# LDAP class definitions
userclasses:User
groupclasses:Group
useKRB5:yes
krbprincipal:cn=spock44p,cn=Users,dc=RnREnterprise,dc=dyndns,dc=org
krbkeypath:/etc/krb5/krb5.keytab
krbcmddir:/usr/krb5/bin/
Next, start the LDAP client daemon and test the environment. Use the start-secldapclntd
script to start the client daemon, as follows:
# start-secldapclntd
Starting the secldapclntd daemon.
The secldapclntd daemon started successfully.
Upon success, add the client daemon startup to the inittab file:
mkitab "ldapclntd:2:once:/usr/sbin/secldapclntd > /dev/console 2>&1"
To test LDAP, use the following command. You must be logged on as the user who is
configured (check AUTHSTATE) in Active Directory, not as root.
ldapsearch -b cn=Users,dc=RnREnterprise,dc=dyndns,dc=org -h
ldap.RnREnterprise.dyndns.org -m GSSAPI -s one objectclass=* dn
Before users can actually log in using LDAP credentials, the security configuration must
enable both users and groups to be checked against the LDAP directory. This requires
modification of the /etc/security/user file, with the default entry being changed to support an
LDAP registry and authentication using either the system configuration for LDAP or the
existing files mechanism (for example, for users such as root).
Chapter 2. Active Directory Integration
25
To make this amendment use the chsec command as follows:
# chsec -f /etc/security/user -s default -a "SYSTEM=LDAP or files"
Note that it is the default user that must change because the details for specific users are held
in the LDAP directory rather than locally.
Finally, to allow later authentication of users who were not added manually to the user
configuration on the local AIX machine, add the ability to authenticate based on Active
Directory configured POSIX Group membership. For this, the +@admingrp entry was added to
the bottom of /etc/passwd. Users that are not configured locally are then created in Active
Directory.
AIX results summary
So far we have configured AIX to make use of Active Directory for user authentication, and for
authorization using Kerberos and LDAP. Administrators configured locally can log in, and
administrators configured in the admingrp in Active Directory should also be able to log in.
Note that the keytab file must be secured because it contains authentication information for
the system. The contents are time-dependent. If they are out-of-date, a message similar to
the the following message can appear in syslog.out (if configured by the syslog daemon):
Jan 16 14:08:27 spock44p daemon:err|error secldapclntd: 3001-740 Kerberos init
failed using command /usr/krb5/bin/kinit, key table file /etc/krb5/krb5.keytab,
on principal host/spock44p.RnREnterprise.dyndns.org.
Our next step is to support all users who make use of our WAS applications by allowing those
users to be authenticated against Active Directory for single sign-on.
2.2.7 Configure Windows Internet Explorer clients
Windows and Kerberos SPNEGO authentication only work with Internet Explorer 5.5 and
later in a native mode Active Directory domain, although Firefox can be configured to use it
also.
To configure the clients:
1. Refer to Figure 2-11 on page 27.
2. In Internet Explorer, select:
Tools → Internet Options → Security
3. Select the Local intranet icon and click Sites.
4. Click Advanced.
5. In the Local Intranet window add the canonical alias for the WAS environment to the Add
this Web site to the zone and click OK.
6. In the Internet Options window click the Advanced tab and scroll down to the Security
settings.
7. Ensure that the Enable Integrated Windows Authentication box is checked, and then
click OK.
26
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-11 Configuring Windows Internet Explorer clients
2.2.8 Set up the WebSphere Application Server 6.1 for SPNEGO
A number of steps is involved in setting up of the SPNEGO Trust Association Interceptor
within the WebSphere Application Server (WAS). This only works with version 6.1 and later.
For earlier versions, products such as the IBM Tivoli Access Manager or BMC Open
Networks UiDP Enforcement Agen and TAI are required.
We use the WAS 6.1 Integrated Solutions Console or adminconsole for the initial
configuration of the SPNEGO TAI, but use wsadmin.sh for later configuration and fine tuning.
Configure the SPNEGO TAI
To set up WAS for SPNEGO:
1. Select Security → Secure administration, applications and infrastructure. See
Figure 2-12 on page 28.
2. In the Authentication panel, select Web security → Trust association.
Chapter 2. Active Directory Integration
27
Figure 2-12 Initial configuration of the SPNEGO TAI
3. In the Configure tab, under General Properties, select the Enable trust association
box to enable the feature (see Figure 2-13 on page 29).
28
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-13 Enable trust association
4. Click Interceptors, and select the SPNEGO TAI and Custom Properties for setting
parameters
5. Add the following information:
com.ibm.ws.security.spnego.SPN<X>.hostName=Fully Qualified Domain Name of Host
In this example X=1 and hostname=spock44p.RnREnterprise.dyndns.org.
6. Optionally, add com.ibm.ws.security.spnego.SPN<X>.trimUserName=true.
7. After defining any custom properties click Save (see Figure 2-14 on page 30).
Chapter 2. Active Directory Integration
29
Figure 2-14 Completing SPNEGO TAI configuration
Set up JVM, WAS Kerberos support, and WAS LTPA
Although the SPNEGO TAI is now configured, we now have to set up the Java Virtual
Machine (JVM) to use SPNEGO, the WAS Kerberos support, and the WAS Lightweight Third
Party Authentication (LTPA) configuration:
1. Use the WAS 6.1 Integrated Solutions Console adminconsole to set up Lightweight Third
Party Authentication (LTPA).
2. Select Security → Secure administration, applications and infrastructure →
Authentication mechanisms and expiration (as shown in Figure 2-15 on page 31).
30
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-15 Configuring authentication mechanisms
3. Update the Kerberos configuration for the platform to include the keytab for WAS to use:
# /usr/krb5/sbin/ktutil
ktutil: rkt /home/root/wasadmin.keytab
ktutil: wkt /etc/krb5/krb5.keytab
ktutil: q
4. Use the WAS 6.1 adminconsole to configure the JVM for the SPNEGO TAI.
5. Select Servers → Application servers (see Figure 2-16 on page 32).
6. Select a server and select Java and Process Management → Process Definition.
Chapter 2. Active Directory Integration
31
Figure 2-16 Configure the JVM for the SPNEGO TAI
7. Click Java Virtual Machine (see Figure 2-17 on page 33).
32
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-17 Configure the JVM for the SPNEGO TAI
8. As shown in Figure 2-18, add the following information to Generic JVM arguments:
-Dcom.ibm.ws.security.spnego.isEnabled=true
Figure 2-18 Generic JVM Arguments
Chapter 2. Active Directory Integration
33
Ensure LDAP registry is configured
We ensure our LDAP registry is configured. Initially we point at the Active Directory and
ensure we get the same information as Kerberos does (for example, that the IDs match).
1. Select Security → Secure administration, applications and infrastructure, as shown
in Figure 2-19.
Figure 2-19 Configuring LDAP registry
2. In the Available realm definitions, as shown in Figure 2-20 on page 35, select LDAP
Standalone Registry and click Configure.
This allows the LDAP environment to be tested correctly after configuration. Note that the
options here for directories are quite simple. More options are available when the
Federated Repositories are selected.
34
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-20 Configuring LDAP registry
3. Configure the Active Directory, the IP address and ports, and set up a user who has
permission to access it in the keytab file. See Figure 2-21.
Figure 2-21 Configuring LDAP registry
Chapter 2. Active Directory Integration
35
2.2.9 Set up the directories
This section descrcibes WAS administrative security and application-specific authorization.
What we have set up so far is very basic. In reality, the administrative users should be kept
separate from the general users. Similarly, if application roles and configurations are to be
stored in the Active Directory, the Windows login performance is affected. Thus, having
proven our login environment, we move to a more complex environment that can support
administrative users with WebSphere file-based security, and a move from Active Directory to
its smaller sibling Active Directory Application Mode (ADAM). We can add application-specific
user information to ADAM and attach it to the core schema details we have from Active
Directory. For this, the Federated Repository option is necessary; control of the joint security
within WAS is through the WebSphere Identity Manager (WIM).
Note: The same user ID cannot exist in more than one place.
To set up the WebSphere file-based security:
1. Select Security → Secure administration, applications and infrastructure, as shown
in Figure 2-22 on page 37.
2. Select Federated Repositories.
3. Click Configure.
36
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-22 Setting up the WebSphere file-based security
4. Enter a Realm name and a primary administrative user name, as shown in Figure 2-23
on page 38.
When using a Federated Repository the primary administrative user must be configured in
the file-based security file for the WIM rather than the directory.
5. Select the Ignore case for authorization option to allow the different repositories to map
appropriately.
Chapter 2. Active Directory Integration
37
Figure 2-23 Setting up the WebSphere file-based security
6. Click Add Base entry to Realm, which allows the setup of a new repository.
At this point, we should explain that we originally configured access to the full Windows
2003 Server Active Directory so we could ensure that the Kerberos and LDAP information
matched. This makes step-by-step problem determination easier. However, for production
we want to use the Active Directory Application Mode LDAP environment with a copy of
the core schema from Active Directory, mapped using Tivoli Identity Manager or Microsoft
Identity Information Server, to which additional attributes are added to support the
application requirements.
7. Click Add Repository, as shown in Figure 2-24 on page 39.
38
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-24 Setting up the WebSphere File Based Security
8. For our repository we select Microsoft Active Directory Application Mode, as shown in
Figure 2-25 on page 40.
9. Set up the appropriate parameters such as bind parameters and TCP/IP connectivity
information.
Chapter 2. Active Directory Integration
39
Figure 2-25 Setting up for production
10.Administer the users from the repositories and map them to the appropriate roles. This is a
function best reviewed in the WebSphere documentation.
2.2.10 Results for WebSphere Application Server single sign-on users
A user should now be able to transparently log in to the WAS environment and access
applications. A good test application to try is that of snoop, if it is configured. The key to
knowing whether things have been successfully set up is when the value for the Remote
User field matches the Windows login user ID. For all other applications, the successful result
is a transparent login rather than a login form or an Unauthorized page returned. The Remote
User maps to the value populated in the J2EE Servlet Web getRemoteUser() call. If this
returns a null, as shown in Figure 2-26 on page 41, then the value is not being correctly
passed through to the J2EE application.
40
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Figure 2-26 Testing the setup
2.3 Summary
What we have done in this paper is simplified compared to the work required for a real
enterprise, although this paper does discuss all of the major steps. The benefits are the
reduced cost of user administration so that user security details are maintained in one place.
The costs are further reduced if the addition of a user to the organization can result in the
provisioning of a user setup automatically. For non-administrative users, authentication to
different systems is now transparent and uses the Windows login to their machine. This
process can provide real customer benefit in a branch office environment that is
customer-facing.
We have only used WebSphere Application Server in this paper, but the configuration is the
same for most IBM WAS-based products, and many other application environments offer
similar configuration features. Because we now have a single representation of a user,
compliance is more easily achived.
Chapter 2. Active Directory Integration
41
42
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Related publications
The publications listed in this section are considered particularly suitable for a more detailed
discussion of the topics covered in this paper.
IBM Redbooks
For information about ordering these publications, see “How to get Redbooks” on page 43.
Note that some of the documents referenced here may be available in softcopy only.
򐂰 WebSphere Application Server V6 Scalability and Performance Handbook, SG24-6392
򐂰 Effective System Management Using the IBM Hardware Management Console for
pSeries, SG24-7038
򐂰 Hardware Management Console V7 Handbook, SG24-7491
򐂰 WebSphere Application Server Network Deployment V6: High Availability Solutions,
SG24-6688
򐂰 PowerVM Virtualization on IBM System p: Introduction and Configuration Fourth Edition,
SG24-7940
򐂰 Implementing High Availability Cluster Multi-Processing (HACMP) Cookbook, SG24-6769
򐂰 Using WebSphere Extended Deployment V6.0 To Build an On Demand Production
Environment, SG24-7153
Online resources
These publications are also relevant as further information sources:
򐂰 The WebSphere Application Server, Version 6.1 Information Center:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp
򐂰 The IBM Systems Information Center:
http://publib.boulder.ibm.com/infocenter/systems/index.jsp
How to get Redbooks
You can search for, view, or download Redbooks, Redpapers, Technotes, draft publications
and Additional materials, as well as order hardcopy Redbooks, at this Web site:
ibm.com/redbooks
© Copyright IBM Corp. 2008. All rights reserved.
43
Help from IBM
IBM Support and downloads
ibm.com/support
IBM Global Services
ibm.com/services
44
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Index
Symbols
/etc/security/ldap 25
/usr/lib/security 24
G
gecos 14
gidnumber 14
groupname 14
GSS-API 2, 14
A
Active Directory 13
Integration 11
Users and Computers tool 17
Active Directory Application Mode 12, 36
Active Directory Configuration 15
ADAM 12, 36
admingrp 26
application-specific authorization 36
Ascential 5
Authentication Service 13
authentication, KRB5A 20
B
BMC Open Networks 27
BPEL 7
broker-in-a-box 3
C
chsec 26
commands
chsec 26
config.krb5 22
ktutil 22, 31
ldapsearch 25
mkitab 25
mkuser 23
setspn 20
start-secldapclntd 25
uname 21
config.krb5 22
context, enterprise 2
CSM 10
D
DataPowerXI50 3
DataStage 5
DB2 3
DNS 22
E
Enterprise Service Bus (ESB) 3, 5
ESB 3, 5
Extraction 5
F
H
HACMP 6
High Availability Cluster Multi-Processing (HACMP) 6
HMC 10
homedirectory 14
hosts 21
Hypervisor 8
I
IBM DataStage 5
IBM Tivoli Access Manager 27
IBM Tivoli Directory Server 3, 12
IBM WebSphere Data Power XI50 3
Identity Information Server 12
Interceptors 29
Internet Explorer clients 26
J
J2EE 2, 40
JVM 30
K
KDC 4, 13
Kerberos 12
Kerberos Authentication 13
Kerberos RFC 1510 2
Key Distribution Center 4, 13
Keytab file 19
krb5.client.rte 21
krb5.conf, encryption types 22
krb5.keytab 22
KRB5A 20
ktpass 19
ktutil 22, 31
L
lastupdate 14
LDAP client daemon 25
LDAP registry 34
LDAP Standalone Registry 34
LDAP Support, preparing AIX 24
ldap.client 24
ldap.max_crypto_client 24
ldapsearch 25
LDIF 16
FileNet 3
© Copyright IBM Corp. 2008. All rights reserved.
45
LDIF import 16
Lightweight Third Party Authentication 30
load 10
loginshell 14
LTPA 30
M
Max Crypto Client 24
memberuid 14
methods.cfg 23
Microsoft Active Directory Application Mode 12
Microsoft Identity Information Server 12
Microsoft Object Linking and Embedding (OLE) 7
MIIS 12
MIT 13
mkitab 25
mkuser 23
MQ 6
N
netsvc.conf 23
NIM 10
O
OLE 7
Oracle 3, 12
overview 1
P
Partitioning 8
pgrp 14
POSIX 12
PowerPoint 7
ProfileStage 5
Q
QualityStage 5
T
TAI 2, 4, 14
technical overview 1
TGS 13
Ticket Granting Service 13
ticket granting ticket 4
Tivoli Access Manager 27
Tivoli Directory Server 3, 12
Transformation 5
Trust Association Interceptor (TAI) 2, 4, 14
U
uid 14
uidnumber 14
UiDP Enforcement Agent/TAI 27
uname 21
user accounts, adding 17
username 14
userpassword 14
Users and Computers tool 17
W
WAS Administrative Security 36
WebSphere Application Server
setting up for SPNEGO 27
WebSphere Data Power XI50 3
WebSphere Identity Manager 36
WebSphere MQ 6
WebSphere Process Server 7
WIM 36
Windows 2003 Server 12, 15
Windows Active Directory 13
Windows Internet Explorer 26
Windows Vista 2
Windows XP 2
Workload Partitions 8
WPAR 8
WSRP 7
R
Redbooks Web site 43
Contact us vii
RFC 1510 2, 12, 15
RFC 2307 2, 12, 14
S
SAP 12
setspn 20
shadowlastchange 14
shell 14
single sign-on 40
spassword 14
SPNEGO 2, 4, 14, 26
start-secldapclntd 25
Symmetric Multiprocessing 10
46
Case Study: AIX and WebSphere in an Enterprise Infrastructure
Back cover
Case Study: AIX and
WebSphere in an
Enterprise Infrastructure
Integrate AIX with
Microsoft Active
Directory-based
authentication and
directory services
Use Microsoft Identity
Information Server and
Active Directory
Application Mode LDAP
®
Redpaper
™
This IBM Redpaper presents a technical case study describing, in
detail, what a realistic enterprise-level application and system
architecture would look like for an environment that provides AIX and
Websphere-hosted applications that are integrated with Microsoft
Active Directory-based authentication and directory services.
INTERNATIONAL
TECHNICAL
SUPPORT
ORGANIZATION
We recommend that readers of this paper also become familiar with
the following IBM Redbooks publication: Running IBM WebSphere
Application Server on System p and AIX Optimization and Best
Practices, SG24-7347. In addition to the topics covered in that book,
this paper provides a reference architecture and technical guide for the
design and integration of highly available WebSphere applications
hosted on AIX with Active Directory-based services.
BUILDING TECHNICAL
INFORMATION BASED ON
PRACTICAL EXPERIENCE
Integration details from
an actual enterprise
scenario
IBM Redbooks are developed
by the IBM International
Technical Support
Organization. Experts from
IBM, Customers and Partners
from around the world create
timely technical information
based on realistic scenarios.
Specific recommendations
are provided to help you
implement IT solutions more
effectively in your
environment.
For more information:
ibm.com/redbooks
REDP-4436-00