Case Study: AIX and WebSphere in an Enterprise … in an Enterprise Infrastructure ... Integrate AIX with Microsoft Active Directory ... 2.2.1 Ensure Windows 2003 Server R2 Active

ibm.com/redbooks Redpaper

Front cover

Case Study: AIX and WebSphere in an Enterprise Infrastructure

Colin Renouf

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 anactual enterprise scenario

http://www.redbooks.ibm.com/


International Technical Support Organization


September 2008

REDP-4436-00

© 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 ScheduleContract with IBM Corp.

First Edition (September 2008)

This edition applies to IBM AIX v5.3 and IBM WebSphere Application Server v6.1

Note: Before using this information and the product it supports, read the information in “Notices” on page v.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .vTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiAuthor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiYou can become a published author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiComments welcome. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Chapter 1. The Application Infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Overall infrastructure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Enterprise Service Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 The middle tier: WebSphere MQ and high availability . . . . . . . . . . . . . . . . . . . . . . . . . . 61.5 WebSphere Portal Server and WSRP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.6 Partitioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.6.1 Using Workload Partitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.7 Design for expected load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Chapter 2. Active Directory Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1 Integrating WAS 6.1 and AIX with Windows 2003 R2 Active Directory security . . . . . . 12

2.1.1 RFC 1510 Kerberos authentication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.2 RFC 2307 POSIX user and group mappings for LDAP based directories . . . . . . 142.1.3 RFC 2478 SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 System configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.1 Ensure Windows 2003 Server R2 Active Directory is configured . . . . . . . . . . . . . 152.2.2 Add user accounts for the AIX system and WAS . . . . . . . . . . . . . . . . . . . . . . . . . 172.2.3 Export the Keytab file from Active Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.4 Prepare the AIX environment for Kerberos support . . . . . . . . . . . . . . . . . . . . . . . 202.2.5 Configure AIX Administrative users and groups . . . . . . . . . . . . . . . . . . . . . . . . . . 232.2.6 Configure the AIX Environment for LDAP support . . . . . . . . . . . . . . . . . . . . . . . . 242.2.7 Configure Windows Internet Explorer clients . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2.8 Set up the WebSphere Application Server 6.1 for SPNEGO . . . . . . . . . . . . . . . . 272.2.9 Set up the directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.2.10 Results for WebSphere Application Server single sign-on users . . . . . . . . . . . . 40

2.3 Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Related publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43IBM Redbooks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Online resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43How to get Redbooks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Help from IBM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

http://www.ibm.com/legal/copytrade.shtml

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

http://www.redbooks.ibm.com/residencies.html

http://www.redbooks.ibm.com/residencies.html



� Send your comments in an e-mail to:

[email protected]

� Mail your comments to:

IBM Corporation, International Technical Support OrganizationDept. HYTD Mail Station P0992455 South RoadPoughkeepsie, NY 12601-5400

viii Case Study: AIX and WebSphere in an Enterprise Infrastructure

http://www.redbooks.ibm.com/contacts.html

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.

1

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

http://www.redbooks.ibm.com/abstracts/sg247347.html

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.


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.


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


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


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.


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.


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.


Chapter 2. Active Directory Integration

In this chapter, we discuss the integration details for Active Directory security.

2


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.


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

Table 2-2 POSIX representation: groups

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

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

posixaccount Object Class

groupname CHAR cn

id INT gidnumber

users LIST memberuid


(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


\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


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.


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.


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.


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

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.

Note: The file transmission must be binary rather than ASCII.


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.

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:

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

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.


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/ktutilktutil: rkt /home/root/spock44p.keytabktutil: wkt /etc/krb5/krb5.keytabktutil: 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.orgInitializing 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


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


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=KRB5AKRB5ALDAP: options = db=LDAP,auth=KRB5ALDAP: program = /usr/lib/security/LDAP program_64 = /usr/lib/security/LDAP64


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 Directoryldapservers: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=orgbindpwd: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 2307userattrmappath:/etc/security/ldap/2307user.mapgroupattrmappath:/etc/security/ldap/2307group.map

# Add the Base DN where the user and group data are stored in the# Active Directory LDAP Serveruserbasedn:cn=Users,dc=RnREnterprise,dc=dyndns,dc=orggroupbasedn:cn=Users,dc=RnREnterprise,dc=dyndns,dc=org

# LDAP class definitionsuserclasses:Usergroupclasses:Group

useKRB5:yeskrbprincipal:cn=spock44p,cn=Users,dc=RnREnterprise,dc=dyndns,dc=orgkrbkeypath:/etc/krb5/krb5.keytabkrbcmddir:/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-secldapclntdStarting 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).


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


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


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


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


Figure 2-14 Completing SPNEGO TAI configuration

Set up JVM, WAS Kerberos support, and WAS LTPAAlthough 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).


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/ktutilktutil: rkt /home/root/wasadmin.keytabktutil: wkt /etc/krb5/krb5.keytabktutil: 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.


Figure 2-16 Configure the JVM for the SPNEGO TAI

7. Click Java Virtual Machine (see Figure 2-17 on page 33).


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


Ensure LDAP registry is configuredWe 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.



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.



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

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.

Note: The same user ID cannot exist in more than one place.


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.


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.


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.


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.


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.



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




http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp

http://publib.boulder.ibm.com/infocenter/systems/index.jsp

Help from IBM

IBM Support and downloads

ibm.com/support

IBM Global Services

ibm.com/services


http://www.ibm.com/support/

http://www.ibm.com/support/

http://www.ibm.com/services/

http://www.ibm.com/services/

Index

Symbols/etc/security/ldap 25/usr/lib/security 24

AActive Directory 13

Integration 11Users and Computers tool 17

Active Directory Application Mode 12, 36Active Directory Configuration 15ADAM 12, 36admingrp 26application-specific authorization 36Ascential 5Authentication Service 13authentication, KRB5A 20

BBMC Open Networks 27BPEL 7broker-in-a-box 3

Cchsec 26commands

chsec 26config.krb5 22ktutil 22, 31ldapsearch 25mkitab 25mkuser 23setspn 20start-secldapclntd 25uname 21

config.krb5 22context, enterprise 2CSM 10

DDataPowerXI50 3DataStage 5DB2 3DNS 22

EEnterprise Service Bus (ESB) 3, 5ESB 3, 5Extraction 5

FFileNet 3

© Copyright IBM Corp. 2008. All rights reserved.

Ggecos 14gidnumber 14groupname 14GSS-API 2, 14

HHACMP 6High Availability Cluster Multi-Processing (HACMP) 6HMC 10homedirectory 14hosts 21Hypervisor 8

IIBM DataStage 5IBM Tivoli Access Manager 27IBM Tivoli Directory Server 3, 12IBM WebSphere Data Power XI50 3Identity Information Server 12Interceptors 29Internet Explorer clients 26

JJ2EE 2, 40JVM 30

KKDC 4, 13Kerberos 12Kerberos Authentication 13Kerberos RFC 1510 2Key Distribution Center 4, 13Keytab file 19krb5.client.rte 21krb5.conf, encryption types 22krb5.keytab 22KRB5A 20ktpass 19ktutil 22, 31

Llastupdate 14LDAP client daemon 25LDAP registry 34LDAP Standalone Registry 34LDAP Support, preparing AIX 24ldap.client 24ldap.max_crypto_client 24ldapsearch 25LDIF 16

45

LDIF import 16Lightweight Third Party Authentication 30load 10loginshell 14LTPA 30

MMax Crypto Client 24memberuid 14methods.cfg 23Microsoft Active Directory Application Mode 12Microsoft Identity Information Server 12Microsoft Object Linking and Embedding (OLE) 7MIIS 12MIT 13mkitab 25mkuser 23MQ 6

Nnetsvc.conf 23NIM 10

OOLE 7Oracle 3, 12overview 1

PPartitioning 8pgrp 14POSIX 12PowerPoint 7ProfileStage 5

QQualityStage 5

RRedbooks Web site 43

Contact us viiRFC 1510 2, 12, 15RFC 2307 2, 12, 14

SSAP 12setspn 20shadowlastchange 14shell 14single sign-on 40spassword 14SPNEGO 2, 4, 14, 26start-secldapclntd 25Symmetric Multiprocessing 10

TTAI 2, 4, 14technical overview 1TGS 13Ticket Granting Service 13ticket granting ticket 4Tivoli Access Manager 27Tivoli Directory Server 3, 12Transformation 5Trust Association Interceptor (TAI) 2, 4, 14

Uuid 14uidnumber 14UiDP Enforcement Agent/TAI 27uname 21user accounts, adding 17username 14userpassword 14Users and Computers tool 17

WWAS Administrative Security 36WebSphere Application Server

setting up for SPNEGO 27WebSphere Data Power XI50 3WebSphere Identity Manager 36WebSphere MQ 6WebSphere Process Server 7WIM 36Windows 2003 Server 12, 15Windows Active Directory 13Windows Internet Explorer 26Windows Vista 2Windows XP 2Workload Partitions 8WPAR 8WSRP 7


®

REDP-4436-00

INTERNATIONAL TECHNICALSUPPORTORGANIZATION

BUILDING TECHNICAL INFORMATION BASED ON PRACTICAL EXPERIENCE

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

Redpaper™


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

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.

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.

Back cover


