Microsoft Identity and Access Management - Intranet Access Management

Chapter 1: Introduction to the Intranet Access Management Paper

Executive Summary

A common intranet access management infrastructure that integrates applications and platforms can produce significant benefits for organizations trying to improve the use and management of digital identities. For example, the use of a standard set of security protocols and the elimination of redundant identity stores can simplify infrastructure, reduce management efforts, enable single sign on (SSO), and make security auditing easier.

These benefits are primarily financial, including lower administration expenses, licensing fees, and application development costs. Additional benefits include greater security (because the attack surface is reduced) and better options for protecting access to sensitive organizational data.

Improving intranet access management through tight integration with common directory and security services is often very challenging in its technical aspects. A large portion of the challenge stems from the fact there is currently little straightforward guidance on how to configure platforms and applications for interoperability. This paper was written to address this problem, and discusses the business challenges, security issues, tools, and protocols involved.

The Business Challenge

Organizations have made significant investments in technology infrastructure over the last decade, but in many cases the infrastructure is not being used to its fullest capabilities. Almost every organization has inadvertently deployed competing and overlapping technology solutions to solve common intranet access management problems.

Most organizations have the following common business challenges related to intranet access management:

• No SSO capability exists between applications, which results in user confusion, reduced productivity, and increased Helpdesk and administration costs.
• The existence of multiple identity stores results in a high number of password reset requests.
• Multiple, inconsistent approaches to security services (such as authentication and authorization) make it difficult to comprehensively protect valuable business data.

Employees at many organizations spend over a quarter of an hour per day signing in to different operating systems, directory services, and applications. This means that multiple authentication mechanisms in an organization with 10,000 computer users consume up to 2,666 hours every day. (Source: META Group research conducted on behalf of PricewaterhouseCoopers, June 2002.)

Multiple applications with different identity stores typically require different user names and passwords, which leads directly to increased Helpdesk costs to satisfy password reset requests.

Data protection is a central concern of today's organizations. Data about products, customers, and financials represents a significant amount of capital for many companies, and it is essential that this data is protected as it is accessed and acted on by knowledge workers. In addition to competitive threats that are caused by compromised data, many business sectors have also seen a significant increase in regulatory requirements for data protection. Failure to meet such requirements can cause organizations to incur financial penalties, a loss in customer confidence, or both.

The Business Benefits

The implementation of effective intranet access management within an organization can result in a number of business benefits, including:

• Improved user productivity. If the amount of time that computer users spend on authentication could be reduced from 16 minutes to 2 minutes per day, an organization of 10,000 users could reclaim more than 2,300 hours each day, which is roughly the number of hours worked by one full-time employee in a year. SSO can facilitate this, as it improves knowledge worker productivity by 15 percent and logon efficiency by 18 percent.
• Reduced Helpdesk costs. Fewer logon credentials for users to remember increases their ability to follow security policy and reduces Helpdesk calls from users for password resets.
• Improved network security. Fewer logon credentials also helps improve the security of the network, because it reduces the likelihood that users will use unsuitable techniques to manage multiple passwords—such as writing them down.
• Increased data protection. The security capabilities of the best infrastructure products can increase data protection and allow organizations to meet regulatory requirements.
• Infrastructure consolidation. The creation of an environment for platform and application integration allows organizations to consolidate identity stores, which reduces both administrative and licensing costs.
• Reduced administration. Cross-platform access management for a majority of an organization's applications helps it to realize an even greater return on the investment made to consolidate the identity stores. This opportunity exists because related cost savings will result through reduced administrative overhead.

Who Should Read This Paper

The intended audience for this paper includes architects, IT professionals and managers, technical decision makers, and consultants involved in identity and access management efforts.

Reader Prerequisites

This paper assumes the reader has a moderate knowledge of identity and access management concepts and technologies, which are described in the "Fundamental Concepts" paper in this series.

To implement the two solutions outlined in this paper, readers should have an understanding of the infrastructure described in the "Platform and Infrastructure" paper in this series and how to implement such an infrastructure. The different solution scenarios have the following additional requirements:

• The first solution scenario requires a familiarity with UNIX administration and configuration.
• The second solution scenario requires a familiarity with SAP administration and configuration.

Paper Overview

This paper discusses the business challenges, security issues, tools, and protocols for improving intranet access management through integration with Windows Server 2003 directory and security services.

The paper consists of the following seven chapters:

Chapter 1: Introduction

This chapter introduces the paper and describes the two main scenarios that the material in the paper covers.

Chapter 2: Approaches to Intranet Access Management

This chapter discusses different methods for improving intranet access management that include:

• Direct integration with Microsoft Windows®-based server and client operating systems.
• Custom integration with Windows-based directory and security services.
• Integration through the Lightweight Directory Access Protocol (LDAP).
• Credential mapping techniques that use enterprise single sign on (ESSO) products.
• Synchronized user accounts and passwords across multiple systems.

The chapter lists the advantages and disadvantages of each method, and highlights situations in which each is most appropriate.

Chapter 3: Issues and Requirements

This chapter considers the Contoso Pharmaceuticals scenario, and highlights the technical issues and requirements for improving intranet access management in the Contoso environment.

Chapter 4: Designing the Solution

This chapter explains the design of two Contoso solution scenarios. It uses the information in the previous chapter to describe the intranet access management components for each scenario and how they interoperate.

Chapter 5: Implementing the Solution

This chapter provides step-by-step prescriptive guidance on how to implement each of the designs from the previous chapter. The chapter uses the Contoso identity and access management infrastructure as its foundation, and demonstrates how you can set up each intranet access management scenario in a secure and functional fashion.

Chapter 6: Testing the Solution

This chapter provides guidance on how to troubleshoot and validate the Contoso solution scenarios implemented in the previous chapter.

Chapter 7: Operational Considerations

The final chapter of the paper provides an overview of some core operational procedures required for day-to-day management of the two intranet access management solutions.

Solution Scenarios

Chapters 3 to 7 provide design and implementation details for the following two solution scenarios:

• Integrating UNIX workstations with Active Directory.
• Integrating SAP R/3 Application Server authentication by using Kerberos.

These scenarios were compiled to embody the typical challenges faced by organizations that wish to provide intranet access management services. Detailed prescriptive guidance is provided on how Microsoft technologies can address such challenges.

The fictitious company Contoso Pharmaceuticals (discussed previously in more detail in the "Platform and Infrastructure" paper in this series) serves as the organization for the prescriptive guidance examples.

Integrating UNIX Workstations with Active Directory

Integration of UNIX workstations with Active Directory can provide organizations with the following important benefits:

• Users can log on to Active Directory from any workstation, regardless of whether it is running a Windows or UNIX operating system, with a single set of credentials.
• Accounts used for UNIX workstations can benefit from the same user account security policy that is applied to Windows-based workstation users.
• The Active Directory-integrated Kerberos version 5 protocol Key Distribution Center (KDC) can provide Kerberos-based credentials to UNIX workstation users that will provide them with seamless access to network resources in a secure manner.
• IT administrators can focus their efforts on managing a single set of workstation users in Active Directory.

This solution scenario demonstrates how to configure UNIX workstations that run the Sun Solaris version 9 operating system as part of a Microsoft Windows Server™ 2003 domain, and then authenticate users to Active Directory by using the Kerberos version 5 protocol.

For more information about guidance and scenarios on how to integrate UNIX servers and UNIX server-based applications with Active Directory, see the Microsoft Solution Guide for Windows Directory and Security Services for UNIX.

Integrating SAP R/3 Application Server Authentication By Using the Kerberos Protocol

Mission-critical applications, including Enterprise Resource Planning (ERP) applications such as SAP, are typically deployed in enterprise environments with their own identity store and authentication mechanisms. The implementation of an application-specific identity store presents management, usability, and often security issues that your organization should address.

One way to address these problems is to integrate the application with a standards-based identity store such as Active Directory. SAP R/3 Application Server is an example of a third party, platform-neutral product that integrates with Active Directory by means of the Kerberos version 5 protocol.

Using the Kerberos version 5 protocol to integrate applications with Active Directory provides the following benefits.

• Users gain the benefit of SSO from using their desktop logon credentials to access applications.
• You can use the Kerberos version 5 protocol to provide a secure client/server application data channel.
• Requirements to manage application-specific identity stores can be reduced and sometimes eliminated.

In this scenario, the SAP R/3 Application Server maps Active Directory principals to an account in the SAP identity store. Although this does not completely eliminate the need to provision and manage the entitlements of users within SAP (they are still required for SAP authorization purposes), the administrative burden is reduced because a different user password is no longer needed. Also, removing user access to multiple resources, including SAP, is easier because disabling user accounts in Active Directory also prevents users from authenticating to SAP.

For other alternatives that provide integration between SAP R/3 Application Server and Active Directory, download the "SAP and Active Directory Identity Management" white paper.

For more general information about SAP integration with Active Directory, SAP customers can log on to the Microsoft section of the SAP Service Marketplace by using their SAP extranet credentials.

Chapter 2: Approaches to Intranet Access Management

There are a number of ways to improve intranet access management within an organization that uses Microsoft technologies. An approach that migrates platforms and applications to use common authentication and authorization security services can enable single sign on (SSO) for users, improve security auditing, take advantage of existing trust relationships, consolidate your infrastructure, reduce management overhead, and improve network security.

However, not all approaches are equal in terms of efficiency, ease of implementation, or security. The approaches, in order of preference, include:

• Application integration with Windows security services. This approach develops and migrates applications to use the security services of the Microsoft® Windows® platform, including authentication and authorization. Integration with Windows security services reduces application development costs and allows applications to easily use the SSO, trust, and security auditing capabilities of the Windows operating system.
• Platform integration with Windows directory and security services. This approach configures other platforms to use the directory and security services supported by the Microsoft Active Directory® directory service and enables cross-platform interoperability and reduced administration.
• Application integration with Windows directory services. The development and migration of applications to use the standard directory protocols supported by Active Directory for authentication and authorization enables identity store consolidation.
• Indirect integration through credential mapping. When direct integration of an application or platform is not feasible, credential mapping (also known as enterprise single sign on or ESSO) can provide an SSO experience for users.
• Synchronized accounts and passwords. When none of the other options are available and the security risks have been considered, the use of common credentials between different applications and platforms can reduce user confusion.

A less-preferred approach may be selected because of the capabilities of a host system, the ability to change an application, or the expected return on investment (ROI) to implement the solution.

Application Integration with Windows Security Services

Integrating applications with Windows security services (also called Windows integrated applications) provides the following benefits:

• SSO for Windows-based clients.
• Greater security for application data transmitted over the network.
• More efficient management of digital identities in Active Directory.
• The ability to establish enterprise-level security groups and role-based access control across multiple applications.
• An extended range of authentication and authorization services through trust relationships with limited management overhead.
• Integrated security event logging.

This section describes many of the benefits of Windows integrated applications through a discussion of the following topics:

• Windows SSO and Access Management.
• Examples of Windows integrated applications.

Note For more information about developing Microsoft ASP.NET applications that integrate with Windows security services, see the "Developing Identity-Aware ASP.NET Applications" paper in this series.

Windows Single Sign On and Access Management

Client computers running Microsoft Windows-based operating systems, such as Microsoft® Windows® XP Professional and Windows® 2000 Professional (as well as any server product such as Windows Server™ 2003 acting as a client) include built-in features that allow SSO when the client and server are joined to a Windows domain or forest. Cross-domain SSO is enabled by establishing trust between domains or forests as described in the "Fundamental Concepts" paper in this series.

The following features that are implemented with Windows security services provide the capability for SSO:

• A credential cache managed by the Local Security Authority (LSA).
• A set of authentication packages that are integrated with the LSA.

Understanding the Windows logon process is a requirement for understanding how Windows security services provide SSO. The following sections provide an overview of how this process is done to achieve SSO.

The Logon Process

In the Windows operating system, the user logon mechanism is integral to both the client computer and the network. The user only has to authenticate once to the network with their domain credentials. This single logon allows the user to log on to the workstation and access any local or remote resources to which they have been granted access. The logon process is described in Figure 2.1.

Figure 2.1. The Windows-integrated authentication process for desktop logon

As part of the logon process, the user invokes the Graphical Identification and Authentication DLL (GINA) by pressing CTRL+ALT+DEL. This is the secure authentication sequence (SAS), which presents the Windows logon dialog box (step 1) to the user. The user then enters their credentials into the logon dialog box.

The Local Security Authority (LSA) then makes a Ticket Granting Ticket (TGT) request, or TGT-REQ (step 2) to a domain controller running Active Directory. The Kerberos version 5 protocol Key Distribution Center (KDC) running in the LSA service on the domain controller authenticates the username and password by calling the Service Accounts Manager (SAM) (step 3) on the domain controller. If the credentials are correct and no other policy elements (such as time or workstation restrictions) prevent the user from logging on, the LSA on the domain controller either passes Kerberos version 5 authentication protocol tickets (step 4) or NT LAN Manager (NTLM) authorization data (not shown) back to the LSA on the client.

Note Other authentication protocols are implemented in authentication packages (also known as authentication providers) in Windows clients and servers, but this paper concentrates mainly on the Kerberos version 5 authentication protocol, and mentions NTLM only if appropriate.

Building the Authorization Context

The Kerberos ticket contains, among other things, the Privilege Attribute Certificate (PAC), which contains the Security Identifier (SID) information for the user and the groups of which that user is a member. Figure 2.2 shows this structure.

From the Kerberos ticket (step 5 in Figure 2.1) or NTLM authorization data, the workstation constructs an access token. (This is sometimes referred to as a security context, but access token is more correct when discussing local authorization as opposed to network authentication.)

A Windows access token contains:

• The user's primary SID.
• Global and Universal group SIDs from the user's account, domain or forest.
• Domain local SIDs from the domain of the workstation (if they are different from the domain of the user).
• Privileges that are explicitly assigned to the user or derived from group membership.

The logon sequence on the client computer starts an instance of the shell (normally the Explorer.exe file) and attaches the user's access token to the shell (step 6 in the Figure 2.1).

Figure 2.2. The Kerberos ticket contains the PAC, which in turn contains user and group SIDs

Accessing Local Resources

All applications that are launched on the workstation from the shell will inherit the access token from the shell process. Therefore, after the user has logged on, any attempt to access a local resource, such as open a file or print a document from the shell or any shell-launched process, causes the workstation to compare the user's access token to the security access control list (ACL) on the object being accessed.

Accessing Remote Resources

Any attempt by the user to carry out an operation on a remote resource, such as open a file on a network file share, or print a document to a network printer, causes the client and server to carry out an authentication sequence. The authentication sequence is performed, by default, with the same credentials that were used to log on to the workstation. The integration of the Kerberos and NTLM authentication protocol providers with the LSA on the workstation is what creates an SSO experience for the Windows-based user. Figure 2.3 describes this process.

Figure 2.3. The authentication process for remote resource logon

In this example, it is assumed that the workstation logon was accomplished by using the Kerberos protocol, which is the default authentication mechanism in Microsoft Windows® 2000 and Windows Server 2003. If the initial logon was through the NTLM protocol, the sequence would be somewhat different.

The user attempts to access a file on a remote computer running Windows Server 2003 (step 1). The server requires authentication and issues a "challenge" to the user (step 2). The LSA on the client then invokes the Kerberos authentication package to request the necessary authentication credentials (step 3).The Kerberos authentication package satisfies the request by retrieving a previously issued and valid ticket from the ticket cache (step 4) on the client or by requesting a new ticket (TKT) for the server (not shown) from the KDC, Finally, the client answers the server challenge by sending the ticket to the server (step 5).

After the ticket is validated (step 6), the Kerberos authentication provider builds an access token as already described (step 7). Through this token, the server can impersonate (step 8) the client user. Impersonation allows the server to rely on the operating system to enforce correct authorization by comparing the entitlements of the user — captured in the access token — against the ACL on the resource (step 9). The operating system then either allows (as shown in Figure 2.3) or denies the operation, as appropriate.

Security Auditing

Security auditing can be configured for both authentication (including workstation logon) and authorization. Security auditing should be tuned to meet the organization's written security policy. You can configure authentication auditing to audit logon success, logon failure or both.

Authorization auditing is configurable at an object level and is detailed to the level that operations on the object are defined. For example, either failed or successful read, write or edit operations on a file can be audited.

Extending Access By Using Trust Relationships

You can extend the effect of Windows Integrated Authentication by using Windows trust relationships. A trust relationship between two Windows domains, or between forests in Windows Server 2003, enables user accounts in one trusted domain to be granted rights and permissions in the other trusting domain.

Trust relationships extend SSO because the user does not need to sign on again to access resources in the trusting domain. When they attempt to connect to a resource in the trusting domain, the trusting domain connects to the trusted domain through the trust relationship and verifies the user credentials. The resource in the trusting domain then grants access depending on the entitlements of the user from the trusted domain.

Inter-domain trusts are set up by default within Windows 2000 domains in the same forest. In Windows Server 2003 domains, cross forest trusts allow all domains in one forest to trust domains in the other forest.

When trust relationships cannot be established then you can use Windows Credential Manager to provide a SSO experience for the user through an application that uses Windows Integrated Authentication. Windows Credential Manager is discussed in more detail later in this chapter.

For more information about Windows trust mechanisms, see the What Are Domain and Forest Trusts? page.

For more information about planning and implementing cross-forest trust in Windows Server 2003, see the Planning and Implementing Federated Forests in Windows Server 2003 page.

Improving Access By Using Windows Credential Manager

As described previously, application and platform services integrated with the Windows Security services provide a user SSO experience by using the user's logon credentials to authenticate the user to network resources. However, this approach might not always be sufficient — or even desirable. Examples of cases in which the Windows security services will not provide a SSO experience include:

• When there is a need to authenticate to a resource in a non-trusted domain.
• When there is a need to authenticate to a resource on a stand-alone server.
• When there is a need to use alternate credentials to access a network resource.

Microsoft Windows® XP and Windows Server 2003 address these scenarios through a component integrated with the LSA known as Stored User Names and Passwords — usually referred to as Windows Credential Manager — which provides client-side credential management functionality.

You can configure this component in one of two ways: to require a user to manually enter credentials once before accessing the resource, or to save the user's credentials automatically and use them for future access.

Windows Credential Manager provides the user with a secure roaming store for credentials. You implement this in the domain user's roaming profile, which allows users to access their credential store anywhere they can log on and access their profile.

Some applications and developer interfaces are written to use Windows Credential Manager when appropriate. The user experience that occurs for this is that on the first attempt to access a resource that requires authentication, the application will prompt the user to supply a credential. If the application used to access the resource allows it, the user can save the credential. The credential is then associated with the requesting resource. When the user accesses the resource in the future, the authentication package will reuse the saved credential without prompting the user. However, if the application does not allow the user to save credentials, the user must manually set up a credential for that resource by going into the Stored User Names and Passwords component of Windows Credential Manager. You can configure Windows Credential Manager to supply credentials for the Kerberos and NTLM protocols, Secure Sockets Layer (SSL), TLS protocols, Microsoft Passport, and Basic authentication.

For more information about how applications can use the Stored User Names and Passwords component, see Using Credential Management in Windows XP and Windows Server 2003 on Microsoft MSDN®.

Examples of Windows Integrated Applications

Client/server applications can use the mechanisms described previously to provide user SSO, integrated security auditing, and utilize the benefits of trust relationships. Although many Microsoft and third-party applications — both client and server — use the integrated Windows security features to accomplish SSO, the following client/server applications are of particular interest:

• Microsoft Internet Explorer and Internet Information Services (IIS).
• Microsoft Office Outlook® and Exchange Server 5.5 or later.
• Microsoft SQL Server™ 7.0 or later and SQL Server for clients.

The following sections provide examples of how Windows Integrated Authentication works in these applications.

Internet Explorer and IIS

Providing Web SSO to intranet browsers is an important user experience for Web applications. Internet Explorer is a Windows integrated application, enabling intranet Web SSO with IIS 5.0 (included with Windows 2000 Server), IIS 6.0 (included with Windows Server 2003). Figure 2.4 shows how Windows Integrated authentication works between Internet Explorer and IIS.

Figure 2.4. IIS authentication using the Kerberos protocol

An IIS administrator who wants to allow only authenticated users to access an intranet Web application will typically configure a site or virtual directory to use Windows Integrated Authentication. With this security setting enabled, the Internet Explorer-based client application must first authenticate the user to the IIS 6.0 Web server by using either the Kerberos or NTLM authentication protocol. The Kerberos version 5 protocol is preferred in most cases, but there are network and security configurations at the domain controller, the server running IIS 6.0, and Internet Explorer-based client level that an administrator can use to force the use of NTLM authentication.

An example of how Kerberos authentication works between Internet Explorer and IIS follows. First, the client running Internet Explorer makes a page request (step 1). The server running IIS 6.0 forces authentication over the Hypertext Transfer Protocol (HTTP) protocol by sending back a 401 challenge (step 2) to the browser. The challenge includes a list of WWW-Authenticate HTTP headers that specify the authentication protocols that the server running IIS 6.0 is configured to accept for that URL.

When Internet Explorer receives the 401 challenge, it will examine the list of headers and choose an appropriate authentication protocol based on browser configuration. Internet Explorer calls the authentication package through the LSA (step 3). Based on user credentials present in the workstation's LSA credential cache, and the ability to get a Kerberos ticket for the IIS resource (step 4), the ticket is then returned to Internet Explorer from the LSA (step 5). After Internet Explorer has the ticket, it is sent back to the server running IIS in a 401 response, which includes a WWW-Authenticate HTTP header (step 6).

After the client resends the request, the server running IIS 6.0 will extract the authentication information from the HTTP header, and present the data to the authentication provider that the client specifies (step 7). If the authentication succeeds, the authentication provider creates an access token that represents the user, and IIS 6.0 associates impersonation this token with the client request (step 8) by using impersonation. Figure 2.4 shows this process in operation.

It is important to understand that the IIS 6.0 application is not authenticating the user during this process. The server application is entrusting this task to the operating system through the authentication provider interface. The server application benefits from this arrangement by not having to implement authentication code itself.

If the following conditions are met, then authentication and authorization will succeed without the user having to enter additional credentials:

• The server running IIS is a member of a Windows-based domain.
• The client Windows-based workstation is a member of a domain with a trust relationship to the domain in which the server running IIS resides.
• The user logged on to the workstation by using their domain credentials.
• The user is granted access to the requested resource because one of the following conditions is met.
  • The IIS 6.0 administrator configured ACLs for static content (files with .htm and .asp extensions) that allow the user access.
  • A Microsoft ASP.NET application defines Microsoft .NET roles or Authorization Manager that allow the user access.

For more information about this authentication and authorization process, see:

• Kerberos Authentication in Windows Server 2003.
• Microsoft Knowledge Base article How IIS Authenticates Browser Clients.
• The Kerberos Authentication for Load Balanced Web Sites article.
• The Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication page on MSDN.

Microsoft Office Outlook and Exchange Server

In this example, a user logs on to a Windows-based workstation with her user account. The user then starts the Outlook e-mail client which attempts to connect to the Exchange Server application running on Windows Server 2003 by using Remote Procedure Call (RPC) interfaces. The Exchange Server application requires clients to authenticate before a connection will be established, so both the client and server negotiate authentication messages during the establishment of the RPC session.

In the case of Outlook and Exchange, Kerberos authentication is first attempted (Kerberos is the preferred authentication protocol over NTLM). If the attempt succeeds, an access token is generated for the Exchange Server application to impersonate the operating system to enforce correct authorization. The Outlook client application attempts to open the user's mailbox, but this operation will only succeed if the ACLs on the mailbox are configured to grant access for the user that is attempting to connect. If the authentication process succeeds, and the authorization rules described by the mailbox ACL are met, the user is granted access to the mailbox in Outlook without needing to log on again.

SQL Server and SQL Clients

A similar process happens with databases hosted on SQL Server that are configured to use either Windows Authentication Mode or Mixed Mode. Windows Authentication Mode in SQL Server is equivalent to Windows Integrated Authentication as described previously for IIS 6.0, while Mixed Mode allows a combination of Windows-based authentication and SQL Server authentication.

The SQL Server database administrator can define access for Active Directory users or groups at the database or table level. When a client application such as SQL Query Analyzer, or a custom application that uses Open Database Connectivity (ODBC) or Microsoft ADO.NET, connects to the database, SQL Server authenticates the user, and then determines whether the requested data should be returned to the client. The access check compares the user's permissions relative to the entire database, or more precisely at the table level, based on the ACLs stored by the SQL Server operating system, and the user's access token. If the authentication and access check succeeds, then access to the SQL Server data is securely obtained without causing the user to log on separately to the SQL Server application.

For more information about how to configure and use Windows Integrated Authentication with SQL Server, see the Administering SQL Server: Authentication Modes page.

Platform Integration with Windows Directory and Security Services

There are a number of services for integrating Windows with other platforms. These services provide organizations with options for integrating — at a certain level — with Windows security and directory services. Integration through these services typically does not involve changing applications or reconfiguring workstations and servers. They do, however, introduce additional "moving parts" to the network and have separate manageability requirements. Typically these services do not offer all of the capabilities and functionality that can be achieved through direct integration with Windows security services.

UNIX and Linux Integration

Platform integration with Windows security services uses the Kerberos version 5 protocol. The Kerberos protocol is an excellent choice for integrating UNIX and Linux with the Windows operating system because they all support (sometimes through the use of third-party products) the protocol.

The advantages of using the Kerberos version 5 protocol for integration include:

• The Kerberos protocol is a standards-based protocol (Internet Engineering Task Force (IETF) RFC 1510) implemented in Microsoft Windows-based client and server products, Active Directory, and nearly all versions of UNIX and Linux.
• The Kerberos protocol supports secure logon.
• Logging on by using the Kerberos protocol can provide an authorization context (containing groups) and profile information through the following mechanisms.
  • Processing the Windows PAC information in Kerberos tickets issued by Windows domain controllers: Not all vendors have modified their Kerberos version 5 protocol implementations to request the Windows PAC when making ticket requests. This restriction includes the current version of the Kerberos protocol libraries supplied with the SUN Solaris 9 operating system.

For more information about the Windows PAC see the white paper, "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources" on MSDN.

• Configuring the UNIX workstation name service switch (NSS) to use LDAP with the nss_ldap module: The nss_ldap module provides the means for UNIX workstations to retrieve authorization information from an LDAP directory based on the principal name in the Kerberos tickets issued by the Windows Key Distribution Center (KDC). This approach to authorization typically requires a schema extension to Active Directory that adds UNIX-style group and authorization data. Microsoft Services for UNIX (SFU) provides a schema extension that meets this requirement.
• Configuring the UNIX workstation NSS to use NIS with the nss_nis module: You can install SFU to provide a NIS "head" for Active Directory. With SFU, Active Directory will appear as a NIS server, as well as implement a schema extension in Active Directory to provide common UNIX profile and authorization information, user identification (UID), group identification (GID), and shell information.

• The Kerberos protocol in Active Directory is fully integrated with a strong security policy that is enforced by domain controllers running Windows Server 2003. Before processing a Kerberos logon request, the domain controller compares all relevant policy settings against the current account status. If any policy requirement is not met, the domain controller denies the request.
• The Kerberos protocol specifies that the Ticket Granting Ticket (TGT) acquired during logon can be presented to the KDC to generate a service ticket. The service ticket is then used to authenticate to network resources and applications, such as the SAP R/3 Application Server. This process is transparent to the user, allowing for an SSO experience.
• The Kerberos authentication protocol includes the creation and sharing of client/server session keys that allow for strong encryption of subsequent application data transmitted between client and server.

Conventional UNIX and Linux users log on to their computers by supplying a unique username and password. The username and password are compared with those stored in /etc/password and /etc/shadow files. The Pluggable Authentication Module (PAM) service extends the authentication and authorization capabilities of UNIX and Linux by allowing credentials to be stored in different places. PAM also allows for different mechanisms to be used to verify user credentials.

On systems that use PAM, the logon process and all utilities that require user authentication must be compiled to use PAM for authentication and authorization.

Most versions of UNIX and many distributions of Linux include support for the Kerberos version 5 protocol through the PAM configuration file called pam.conf. Many of these operating system version also provide libraries that implement the client/server portions of the Kerberos protocol. Support for the Kerberos protocol in UNIX and Linux provides the opportunity for seamless integration of applications with Windows security services on computers running UNIX and Linux.

Chapters 3 through 7 of this paper include a detailed scenario that configures Kerberos authentication on a Sun Solaris UNIX workstation in order to integrate with Active Directory for authentication and authorization.

Services for UNIX 3.5

Microsoft Windows Services for UNIX (SFU) enables Windows and UNIX clients and servers to share network resources, integrates account management, simplifies cross-platform management, and provides a full UNIX scripting and application execution environment that runs natively on the Windows operating system. For more information about SFU, see the Windows Services for UNIX Web site.

Windows Server 2003 R2 UNIX Interoperability

Windows Server 2003 R2 includes UNIX interoperability components as part of the operating system. These interoperability components consist of:

• Subsystem for UNIX-based Applications, which enables UNIX-based applications to compile and run on Windows Server 2003 R2.
• Identity Management for UNIX (IDMU), which provides the capacity to integrate UNIX security and directory services. IDMU includes an optional Active Directory schema update that imports the NIS and Kerberos schema extensions.
• Microsoft Services for Network File System, which includes a number of components to share files, enforce file security and manage file and print sharing between UNIX and Windows systems.

For more information, see the white paper, "UNIX Interoperability in Microsoft Windows Server 2003 R2".

Vintela Authentication Services

Vintela Inc. (now part of Quest Software) is a Microsoft partner and independent software vendor that focuses on UNIX integration with the Microsoft platform. Vintela Authentication Services (VAS) integrates versions of the UNIX Linux operating systems with Active Directory, integrating the native UNIX interfaces with Active Directory by using the Kerberos protocol and LDAP.

For more information about VAS, see the Vintela Web site.

Novell NetWare Integration

Microsoft Windows Services for NetWare (SFN) 5.02 provides a set of interoperability utilities that help to simplify the introduction of Windows Server 2003 and Active Directory in a Novell NetWare network environment with Novell Directory Service (NDS).

For more information about SFN, see the Microsoft Windows Services for Netware 5.03.

Apple Macintosh Integration

Microsoft Windows Server 2003 Services For Macintosh (SFM) is a thoroughly integrated component of Windows Server 2003, making it possible for computers running Windows and Macintosh operating systems to share files and printers. After SFM is set up, these computers can perform the functions of a file server, remote access server, and print server for computers running the Macintosh operating system. In addition, Windows Server 2003 with SFM can perform the functions of an AppleTalk router.

For more information about SFM, see the Windows 2000 SFM page on the Mactopia Web.

Mainframe Integration

Integration with mainframe operating systems such as OS/390 and z/OS from IBM with Windows directory and security services can be done in a few ways, including:

• Credential mapping through Microsoft Host Integration Server.
• Platform integration through the Kerberos protocol.
• Application integration approaches that use LDAP and GSS-API.

HIS provides a credential mapping (or ESSO) approach to indirectly integrating Active Directory with mainframe directory stores. For more information about this subject, see the "Indirect Integration Through Credential Mapping" section later in this paper.

IBM mainframes with updated versions of IBM SecureWay Security Server (which includes Resource Access Control Facility (RACF)) support the Kerberos protocol, LDAP, SSL, GSS-API, and other access management-related standards described in the "Fundamental Concepts" paper in this series. The use of standards like the Kerberos protocol makes it theoretically possible to configure RACF on a mainframe to cooperate with the Microsoft implementation of a Kerberos KDC.

Alternatively, you can theoretically configure or migrate applications on mainframes that use standards such as LDAP and GSS-API to use Windows directory and security services.

For more information about how to use RACF standards that support integration with Windows directory and security services, see the following resources.

• Security on z/OS: Comprehensive, current, and flexible on IBM.com.
• SecureWay Security Server for z/OS and OS/390 on IBM.com.
• The OS/390 Security Server (RACF) Interoperability with Windows 2000 Case Studies PDF document download on IBM.com.

J2EE Integration

J2EE is an application development platform choice that many customers consider instead of, or in addition to, using the Microsoft .NET Framework for application development. Integrating J2EE applications with Windows directory and security services is possible by using one or more of the following technologies:

• Browser to Web Server. J2EE application servers such as Apache and BEA WebLogic support the Kerberos protocol through pluggable authentication modules available from the vendor, as open source, or from independent software vendors (ISV).
• LDAP. Any J2EE application that performs BASIC or Forms-based authentication can validate user credentials against Active Directory by using LDAP bind.
• Web Services – Security. WS-Security defines several token types, including those for the Kerberos protocol and X.509 that allow integration between J2EE applications and Windows security services.

Vintela

Vintela (now part of Quest Software) integrated JCSI Kerberos from Wedgetail into Vintela Single Sign-on for Java (VSJ). VSJ is a server side solution that allows Windows Integrated Authentication to Java application servers. For more information about Vintela products, see the Vintela Web site.

Application Integration with Windows Directory Services

When native integration between applications and Windows Security Services is not possible, you may be able to integrate applications in the Windows environment through Windows directory services, or through a product that extends the functionality of Active Directory. This solution may not be as elegant as the fully integrated approach described previously, but it may be necessary for different platforms and applications that do not support direct Windows integration.

Directory services integration may simply require configuring applications, servers, or workstations to use an Active Directory service such as LDAP. In some cases, applications might need to be modified to completely integrate with Windows directory services, or an application directory such as Active Directory Application Mode (ADAM) may be required.

The following sections provide examples of how to integrate applications with Windows directory services by using LDAP and ADAM.

Integration with LDAP

Active Directory is compliant with LDAP 3.0, which is defined by RFC 3377 and other RFCs. Because many other commercially available directory services support LDAP — and many applications use LDAP to access those directory services — a standardized protocol such as LDAP can provide access management interoperability between existing third-party and in-house developed applications and Active Directory.

For more information about Active Directory support for LDAP, see the Active Directory LDAP Compliance paper.

LDAP can enable authentication and authorization integration between Active Directory and applications hosted on any client or server operating system that supports LDAP. In this role, Active Directory becomes the identity store for the application. In general, applications can use LDAP directly, through RFC 1823 compliant application programming interfaces (API) provided by the operating system hosting the application, or by add-ons such as Open LDAP, which is an open source LDAP library for the UNIX and Linux operating systems.

Developing for LDAP

Application development is not the focus of this paper, but it is important to point out that integration with Active Directory through LDAP might require some changes to existing applications. Some of these changes may be required because of:

• Subtle differences in LDAP implementations.
• A more complex directory structure based on Active Directory domains and forests.
• Requirements to take advantage of the LDAP security features in the Windows platform.

For applications on Windows-based clients and servers that do not integrate with Windows Security Services, there is a choice of APIs to use for integration with Windows directory services. Active Directory supports the following interfaces.

• RFC 1823-compliant LDAP Win32 API set for C and C++ applications.
• Active Directory Service Interfaces (ADSI) for Microsoft Visual Basic® applications and VB scripts.
• System.DirectoryServices for managed-code applications written by using Microsoft Visual Studio .NET.

For more information about how to use these programming interfaces to Active Directory, see the Using Active Directory page of the Platform SDK: Active Directory on MSDN.

Authentication Through LDAP

LDAP sessions typically begin with a "bind" operation. The bind operation can either be anonymous or can optionally include credentials of the user wishing to connect to the directory service. Because the focus of this section is authenticating users, we will focus on the authenticated bind.

There are two types of authenticated bind operations, "simple" binds, and non-simple binds that use an authentication protocol supported by the directory service. Simple binds use plaintext credentials to authenticate the bind, and, for this reason, should be used with care. LDAP supports SSL which should be considered mandatory for applications that use simple bind. The LDAP function that enables SSL is ldap_set_option() with the LDAP_OPT_SSL flag.

For more information about how to use SSL to protect LDAP sessions, see the Example Code for Establishing a Session over SSL page of the Platform SDK: Lightweight Directory Access Protocol on MSDN.

There are certain cases in which LDAP simple binds are the best option. Examples of this are server applications that prompt for the user's name and password for authentication, such as a Web application that uses forms-based authentication, which need to validate the plaintext password of the user. If the application requires it to be as platform and directory neutral as possible, then LDAP simple binds are the correct approach.

For server applications that need to bind to Active Directory by using their own credentials to retrieve some information from the directory service, Microsoft recommends configuring the server to use one of the authentication mechanism options listed in the documentation for the ldap_bind_s() API.

Note LDAP APIs that end with an 's', such as ldap_bind_s are synchronous APIs. The 's' does not imply any type of security for the session. This can cause confusion because only synchronous bind, or ldap_bind_s, supports other authentication mechanisms beside simple bind.

LDAP non-simple binds are accomplished through a mechanism known as the Simple Authentication and Security Layer (SASL). The SASL mechanisms supported by Active Directory include the same authentication protocols documented elsewhere in this series; the Kerberos version 5 and NTLM protocols (through the Negotiate security package), and Digest authentication. LDAP binds that use these mechanisms use the default credentials of the server applications and eliminate the need to keep a plaintext version of the applications password in memory. In order to use these mechanisms, the application should call ldap_bind_s() with the LDAP_AUTH_NEGOTIATE or LDAP_AUTH_DIGEST flag.

When an application uses any of the SASL mechanisms to establish a session to Active Directory, it can also specify that all data exchanged between the LDAP client and server will be digitally signed or encrypted. The application uses the ldap_set_option() API with either the LDAP_OPT_SIGN or LDAP_OPT_ENCRYPT option. Microsoft recommends that all sessions over which sensitive directory data, or any data that will be used for authorization, should be protected by session encryption.

Authorization Through LDAP

Beyond authentication, applications often query directory services to retrieve data about users that will be used for authorization. Attributes and directory information that are commonly used for authorization include:

• Security groups.
• User attributes such as location, title, or manager.
• Hierarchical information such as organizational unit (OU) or department.
• Custom attributes stored in the directory that might be application specific such as "Platinum Customer."

Applications that use directory services for authorization have many choices on how they access directory information and occasionally developers make poor implementation choices. A common problem is that applications fail to cache query results with the result that a single application can generate a considerable amount of the load for a directory. Developers should take special care to cache directory query results if it is likely that this information will be needed again.

Note One of the biggest advantages of application integration with Windows Security Services is that Windows authentication mechanisms retrieve and cache authorization information, such as security groups, during the authentication sequence. Windows Authorization Manager also caches other role-based authorization information when the authorization context is first created. After cached, authorization information is available locally for the duration of the authenticated session. Built-in cache mechanisms make it significantly easier to develop efficient applications.

Another common problem is that developers may not understand how to implement effective searches. Poor searches that are repeated frequently can unnecessarily impact directory performance and availability. For more information, see the Creating More Efficient Microsoft Active Directory-Enabled Applications page on MSDN.

Integration with Windows Directory Services By Using ADAM

Active Directory-Application Mode (ADAM) provides additional opportunity for integration with Windows directory services. ADAM is a stand-alone version of Active Directory that runs as a user service on computers running Windows XP or Windows Server 2003.

In order to satisfy requirements for reducing the number of identity stores in an environment, the general Microsoft recommendation is to use Active Directory whenever possible. Some of the advantages of Active Directory over ADAM include:

• Richer authentication features, including integration with the Kerberos version 5 protocol (including Kerberos protocol constrained delegation for n-tier servers), Public Key Infrastructure (PKI), and Microsoft Passport.
• One place for all accounts to make identity management easier.
• Connectivity with many Microsoft applications, such as Microsoft SharePoint™ Portal Server and Microsoft Exchange Server that require users to have an Active Directory account.

However, there are several valid reasons to choose ADAM, including the following considerations that are discussed below:

• Application migration. Migrating existing applications that use X.500 naming.
• Setup and management. ADAM is easy to setup and manage for developers.
• Security and identity isolation. ADAM principals cannot log on to a workstation, server, or be used to access a network resource other then a specific application that uses an ADAM instance.
• Personalization data and performance. ADAM is appropriate for low-value personalization data that is not globally interesting. Data and attributes that frequently change also could adversely affect Active Directory performance.

For more information about ADAM, see the Windows Server 2003 Active Directory Application Mode page.

Application Migration

One approach where LDAP authentication to Active Directory is particularly useful is during application migration from another directory service that supports X.500 – style naming contexts. Because Active Directory does not support X.500 – style naming, ADAM can be very useful for a no-code application migration to Microsoft directory services.

ADAM has a feature called LDAP Bind Redirection (sometimes called Bind Proxy) that is very appealing in this type of scenario. Bind Redirection allows the ADAM "shadow" account for an Active Directory user to contain any user attributes the application needs, but does not contain the user's password. The application will attempt to authenticate against ADAM by using LDAP bind, but ADAM proxies the authentication request to Active Directory. Active Directory then authenticates the user and passes the result back to ADAM. This feature allows the migration of one important aspect of the user — the account credentials — to a centralized Active Directory identity store, while leaving application-specific directory information in ADAM.

Setup and Management

During the development of directory-enabled applications, programmers may need to make modifications to the directory schema. Developers are unlikely to be members of the Active Directory Schema Admins group, and therefore cannot modify the schema. ADAM can be useful as a developer tool for prototyping the proposed schema modifications without having to change the organization's Active Directory.

Security and Identity Isolation

ADAM might also be selected as an identity store for certain types of users for security reasons. For extranet applications that expose services to customers, as well as employees and partners, the organization may require that the accounts granted to customers should not be used to access any other applications or resources in the extranet. If the accounts were created in Active Directory, this requirement might be hard to meet because Active Directory accounts typically could be used for connecting to services and resources in the external domain. Customer accounts could be very tightly controlled through a group policy object (GPO) and other policy settings, but some organizations would rather have an explicit separation of accounts. Organizations with this requirement may choose ADAM as the identity store for the customer.

Personalization Data and Performance

In certain scenarios, an organization might be concerned that migrating an application to Active Directory will have an adverse impact on the organization's central directory service. This can be due to the need to store large amounts of application-specific "personalization" data that is not relevant to any other application, because the application-specific data changes very frequently, or even because the application uses the directory services in an inefficient manner. In these cases, it may be appropriate to use ADAM for the application-specific directory data.

Indirect Integration Through Credential Mapping

When the direct integration of platforms and applications with Windows directory and security services is not feasible, ESSO can achieve indirect integration between Active Directory and other identity stores and provide authentication and SSO through credential mapping services.

Many portal and line of business (LOB) middleware applications retrieve data from back-end systems on behalf of the application users. The back-end systems typically implement their own security and have their own identity stores. Usually, the security mechanisms on the back-end systems have not been fully integrated with Windows security services, so it is not possible to delegate authentication from the portal or middleware application to the back-end system.

In a typical scenario the portal prompts the user for a credential that could be used to authenticate to the back-end system. Further prompting for user credentials when accessing a portal is generally produces a poor user experience, leading organizations to choose to adopt technology that provides SSO. The most common technology used to achieve SSO is some form of credential mapping.

For an example of how credential mapping works, assume that there is a typical middle tier application that retrieves data from a back-end system. The back-end system is not integrated with Windows security services or still maintains its own identity store. To access this back-end system without prompting for credentials, the middle-tier application requests the specific credentials for the back-end system from the ESSO service. In this example, the credentials for the local user, Mary, map to a user named M2231 on the back-end system. Mary is then granted access to the particular resource as shown in Figure 2.5.

A variation of direct mapping occurs when credentials are used to form a many-to-one mapping. This arrangement maps multiple users to a single credential that the back-end resource recognizes. In Figure 2.5, Bob maps to a generic application user on the back-end system.

Figure 2.5. An example of credential mapping

Credential Mapping Advantages and Disadvantages

The Credential Mapping Model works well if you need to deal with either of the following situations in your organization.

• Heterogeneous security models. Your application runs on the Windows operating system and IIS 6.0 on the middle tier application, and the current back-end systems use both SQL Server 2000 or later, and Exchange 5.5 or later. The Kerberos version 5 protocol works fine until you decide to implement a third back-end system, such as DB2 on OS/390. In this case, you need to map the Windows credentials to the Resource Access Control Facility (RACF) credentials in order to access the back-end resource.
• Deferred credential use. You need to defer credential use for authentication after passing asynchronously over message queues, service brokers, or integration engines.

However, you must weigh these advantages against the following disadvantages.

• The risk of storing user names and passwords. For such credential mapping systems to work, you need a database that will contain usernames and passwords that can be decrypted before they are used. You can secure such databases in many ways, but storing passwords, even encrypted ones, poses a risk. For example, using the default settings, Active Directory never stores the actual password. This risk must be evaluated and taken into consideration.
• Password synchronization. A credential mapping database means that some user credentials must either be maintained in two places or synchronized through some sort of automated process. This factor may lead to increased complexity in your systems architecture or process overhead. See the "Password Management" paper in this series for more information.

The Credential Mapping Model in Microsoft Products

Microsoft business integration products include an ESSO service that provides storage and mapping of credentials so that the applications can retrieve information from enterprise resource planning (ERP) systems, customer relationship management (CRM) systems, and mainframe-based applications.

These applications all use a secure database to hold both the user credentials and the account mapping information that link Active Directory accounts to accounts used for the back-end enterprise applications. The ESSO service also implements a secure service for issuing and exchanging tickets that is used whenever the business integration application needs to retrieve data from the back-end application. Because the user accesses the various applications by using only their Active Directory credentials, an SSO experience is provided to the users.

Applications that make use of the Microsoft ESSO service include:

• SharePoint Portal Server (SPS 2003)
• Microsoft BizTalk® Server 2004
• Host Integration Server 2004

Using SharePoint Portal Server ESSO

SharePoint Portal Server (SPS 2003) enables organizations to develop an intelligent portal that connects users, teams, and knowledge to allow people to take advantage of relevant information across business processes to help them work more efficiently.

SPS 2003 provides an enterprise business solution that integrates information from various systems into one Web-based portal solution. It does this through SSO and enterprise application integration capabilities, along with flexible deployment options and management tools. SPS 2003 also helps to secure enterprise applications by storing and mapping assigned credentials, which allow customers to interact with enterprise applications directly from the portal by using only their Active Directory credentials.

Using BizTalk Server ESSO

BizTalk Server 2004 connects systems, people, and trading partners through manageable business processes. It provides integration between ERP products, enabling organizations to integrate their business operations and bring together suppliers and consumers. It also provides a range of interoperability mechanisms, particularly Extensible Markup Language (XML) Web Services.

BizTalk Server uses a similar ESSO credential mapping database to SPS 2003. In this case, BizTalk 2004 can provide authentication details to any connection defined by the BizTalk Server orchestration engine.

A BizTalk Server 2004 SSO scenario is similar to that with SPS although it may not be portal based. The user authenticates to the Windows operating system, and BizTalk Server 2004 then links this authentication to its internal credential database. When the user needs to access information held by a business partner, such as stock levels, BizTalk Server 2004 retrieves the stored credentials and presents them to the foreign system.

Regarding SPS 2003 integration with BizTalk Server and SSO, the recommended approach is to use the SSO version from BizTalk Server rather than the one from SPS. This means that SPS Web parts call the Web services adapter in BizTalk Server, and that these Web parts need to ensure that when the BizTalk Web service adapter receives the request, it is under the context of the end-user that initiated it. For this reason, the Web service adapter needs to reside on the same computer as the Web part, or, you can set up constrained delegation for remote computer scenarios. The Web service adapter uses the IssueTicket call with Enterprise SSO, and the back-end adapter uses the ValidateAndRedeemTicket call.

Using Host Integration Server for ESSO

In customer environments, mainframe and other host-based systems almost never interoperate with the user's Active Directory credentials. Although many organizations have a long term vision of integrating host-based systems with Active Directory by using standard protocols like the Kerberos version 5 protocol, it takes time to accomplish this. As a more immediate solution, Host Integration Server 2004 provides credential management capability that provides the user with what appears to be SSO.

Host Integration Server 2004 provides the next version of the ESSO credential mapping database provided by BizTalk Server 2004. This credential mapping database provides SSO in Host Integration Server by using the 3270 and 5250 emulators, allowing authenticated Windows users to log on automatically to a mainframe or AS/400 system without having to provide further logon credentials. In addition, application and data integration features in Host Integration Server allow authenticated Windows users to access Customer Information Control System (CICS) and Information Management System (IMS) subsystems or DB2, also without requiring the user to provide further logon credentials.

A scenario using Host Integration Server might involve a broker at a merchant bank. The broker logs on, authenticates to the Windows operating system, and starts a Microsoft .NET Framework-based application for trading. In order to process a trade, he needs to know a customer's current trading balance, which the bank stores on a legacy mainframe. Host Integration Server 2004 forwards the authentication details to the mainframe by using its credential mapping database, enabling the broker to run queries on his customer.

ISV ESSO Products

ESSO is another technology area that has seen robust ISV market development. Unlike Microsoft ESSO technology, these ISV products typically provide a centralized storage mechanism based on Active Directory for credentials and mappings, and also provide an API set that applications can use to achieve ESSO functionality. ESSO vendors include (in alphabetical order):

• Passlogix
• Proginet
• ActivIdentity
• Version3

Synchronized Accounts and Passwords

Integrating platforms and applications directly with common directory and security services through a strategy of platform interoperability, application migration, and infrastructure consolidation can reap significant benefits. If direct or indirect integration as discussed previously is not feasible, integrating the underlying identity stores can achieve a subset of the benefits.

Account and password synchronization is a fallback technique for achieving reduced sign on, or for when all other approaches fail, are too difficult, or are too expensive to implement. This approach does not provide true SSO, but it reduces the number of usernames and passwords that users must remember.

Password synchronization typically implies that multiple identity stores include identical user accounts and passwords. Each user logs on to the client, other platforms, applications, and intranet Web sites by using the same username and password combination.

Note Password synchronization should only be attempted after fully considering the security characteristics and risks incurred with storing and using the same passwords in multiple systems.

The "Identity Aggregation and Synchronization" paper in this series gives more information about how to synchronize digital identities across multiple identity stores.

The "Password Management" paper in this series goes into greater detail on the approaches and issues related to using password synchronization to provide intranet access management, as well as demonstrating how to implement password propagation from one Active Directory forest to other Active Directory forests, application identity stores, and directory services for other platforms.

Chapter 3: Issues and Requirements

Many organizations have already successfully implemented the out-of-the-box intranet access management capabilities of the Microsoft platform, including file and print services, Web application services from Internet Information Services (IIS), messaging services (Microsoft® Exchange Server), and database services (Microsoft SQL Server™) that are already integrated with Windows security services.

For the purpose of discussing Contoso Pharmaceuticals, a fictitious company designed to represent a typical organization, the authors of this paper assume that an integrated infrastructure exists between desktop clients and network resources (as discussed in the "Platform and Infrastructure" paper in the series). These basic, out-of-the-box solutions are not considered any further. However, this paper discusses some of the harder, more interesting heterogeneous integration challenges.

Microsoft chose the following two common scenarios for intranet access management, as these or similar challenges regularly appear in organizations operating heterogeneous networks. The two scenarios are:

• Authenticating UNIX workstations users who use the Microsoft Active Directory® directory service and Windows® security services.
• Authenticating SAP R/3 Application Server users who use Active Directory.

These scenarios also address the two largest threats to the Contoso Pharmaceuticals environment: the potential for compromise of UNIX workstation accounts, and the potential for unauthorized access to SAP accounting data.

Integrating UNIX Workstations with Active Directory

Many organizations face difficulties in managing user accounts on UNIX workstations, including weak or unenforceable security policy and fragmented identity and access management components.

This scenario shows how to address these issues through the following approaches:

• Integrating UNIX workstations with Windows security services.
• Consolidating user accounts in Active Directory.
• Implementing the Kerberos version 5 authentication protocol to authenticate logons.

The benefits of these approaches include the following:

• Lower total cost of ownership (TCO).
• Better and more secure manageability.
• A common user experience across different workstation operating systems.
• Consistent application mechanisms for authentication and authorization.

This scenario uses Sun Solaris 9 as the desktop UNIX platform, but the concepts apply to any UNIX-based operating system that supports the Kerberos version 5 protocol.

Background

Contoso has several hundred workstations running the Sun UNIX-based Solaris 9 operating system. The results of a security risk analysis show that the user accounts for accessing these UNIX workstations are largely unmanaged, are exposed because of an unenforceable password and account security policy, and do not interoperate well with other platforms and applications.

Business Issues

In the current Contoso environment, UNIX user account management requires a significant portion of the overall administrative budget. Parallel management of user accounts in UNIX-based computers and in Active Directory is redundant. This redundancy is not cost-effective because it increases the TCO of managing digital identities.

Technical Issues

In the Contoso environment, there are no logon and authentication mechanism standards for developing in-house applications and assessing applications. In addition, Sun has officially announced an End-of-Feature (EOF) notice for Network Information Name Service Plus (NIS+), and indicates that NIS may follow a similar path in favor of using naming services based on the Lightweight Directory Access Protocol (LDAP).

For more information about the EOF notice from Sun for NIS+, see the Sun Microsystems' Solaris Operating System Technical Questions page.

Security Issues

An external security audit of Contoso found that UNIX user accounts have an inadequate account security policy, including poorly managed and infrequently changed passwords. This policy inadequacy places the accounts, and data they access, at risk. A related security issue is that the UNIX administrators at Contoso spend a significant portion of their time managing user accounts instead of securing the workstations through patch management and security configuration.

Solution Requirements

The solution for this scenario must meet the following requirements derived from the issues defined in the previous section.

• UNIX workstations must integrate with Active Directory through standards-based protocols.
• Logon authentication must take place through a secure, standards-based authentication mechanism.
• Logon authentication must result in a local authorization context and profile information.
• Logon authentication must occur through a protocol integrated with the Active Directory account security policy so that password complexity and age policies are strictly enforced.
• UNIX accounts must be managed in the intranet Active Directory.
• UNIX accounts must be subjected to the same account and password policy as user accounts in Active Directory.
• UNIX applications must have the capability to use the authentication and data protection features of the platform when possible.

Migrating UNIX user accounts to Active Directory marks a significant step toward a single management point for all user accounts in the organization.

The strong security policies in Active Directory greatly increase security for the UNIX user accounts through features that include strong password enforcement, mandatory password change intervals, and secure centralized storage of user credentials for the logon process. The combination of these features satisfies the security requirements established by Contoso.

Integrating SAP R/3 Application Server Authentication by Using the Kerberos Protocol

Many organizations suffer potential security exposure because sensitive application data is visible as plaintext on the network during transmission between client workstations and the application server. An example of this type of security issue in the Contoso environment is the enterprise resource planning (ERP) application on their SAP R/3 Application Server version 6.20 (mini-edition). Analysis of the Contoso environment indicates that this is a severe security risk.

This scenario shows how to address this issue through the following approaches.

• Configuring Secure Network Communication (SNC) to enable the Generic Security Services Application Provider Interface (GSS-API) version 2.
• Enabling GSS-API to work with Kerberos protocol encryption.
• Protecting application data by using Kerberos protocol encryption.

These approaches will enable you to achieve significantly increased security for data transmission with an ERP application.

Background

Exposure of sensitive organizational information, such as that hosted in SAP R/3 ERP applications, could result in a competitive disadvantage for the company. In addition, some of the information falls under regulatory obligations for confidentiality and privacy. Failure to protect this data could result in severe legal penalties for non-compliance.

Furthermore, users of the SAP application have to log on separately to the application by using a different set of credentials then they use to log on to their workstation.

Business Issues

SAP implements its own identity store that contains user accounts and passwords for the application. Because the SAP authentication does not integrate with the network, SAP users have to log on separately. If users forget their SAP credentials, they have to call the Helpdesk for support in resetting their passwords, leading to greater support costs for the application.

Technical Issues

The technical issues for protecting SAP application data include:

• The Kerberos protocol must be configured on each SAP UNIX host server.
• Selecting and standardizing on a specific Kerberos distribution for the SAP UNIX hosts presents an issue because each distribution of the Kerberos protocol has its own characteristics and peculiarities.

Security Issues

A number of security issues arise from the SAP implementation. However, the main issue is that of application data being visible on the network as plaintext. It is relatively easy for someone on the same network segment as the client to intercept client/server traffic and to identify financial information. The SAP implementation is also vulnerable to duplicate or altered transactions and the possibility of data corruption.

The authentication process from the workstations to the SAP server is also not secure, as it relies on weak cryptographic methods that are vulnerable to attack. This situation could lead to a compromise of user credentials. There is the further concern that if users employ the same user name and password on SAP as their enterprise logon credentials, compromise of their enterprise credentials could occur.

Solution Requirements

The Contoso identity and access management solution must provide the following:

• Secure authentication must be achieved to the SAP ERP Application Server.
• A single sign on (SSO) experience must be achieved for the user authenticating to the SAP ERP Application Server by using Windows domain credentials.
• Protection of SAP ERP Application Server data on the network must be secure between the SAP GUI client and the SAP ERP Application Server.
• Support costs and administration overhead must be reduced.

Chapter 4: Designing the Solution

The previous chapter considered the business, technology, and security issues for two intranet access management scenarios, and listed the solution requirements for each. Designing the appropriate solution is the next part of the overall process.

The following sections in this chapter present a solution concept and the solution prerequisites for each of the intranet access management scenarios. After the design is complete, subsequent chapters in the paper describe how each of the solutions work.

Integrating UNIX Workstations with Active Directory

The integration of UNIX workstations with the Microsoft identity and access management platform by means of the Kerberos version 5 authentication protocol involves transitioning from a Network Information Service (NIS+) environment to one based on the Microsoft® Active Directory® directory service. An environment based on Active Directory can provide both authentication and authorization services for the UNIX workstations, which meets the Contoso requirement for centralized management of user accounts in the intranet directory.

Solution Concept

An analysis of common security capabilities of Active Directory and the Solaris 9 workstations at Contoso identified the Kerberos version 5 protocol as the optimal technology for integrating the company's UNIX workstations with the Microsoft identity and access management platform.

The solution is implemented by:

• Modification of the pam.conf file on the UNIX workstation to specify that Kerberos should be attempted for logon and authentication that uses standard UNIX applications such as Telnet and file transfer protocol (FTP).
• Configuring the krb5.conf file so that the UNIX workstation will use the Contoso Windows®-based domain Key Distribution Center (KDC).

Figure 4.1 shows a diagram of the solution concept.

Figure 4.1. The solution concept for integrating UNIX workstations with Active Directory by using the Kerberos version 5 protocol

The solution will be implemented by configuring the Solaris workstations and Active Directory.

Solution Prerequisites

Contoso has deployed Active Directory on the intranet in accordance with the "Platform and Infrastructure" paper in this series.

This solution is enabled by changing UNIX configuration settings and does not add to or change any aspect of the existing Contoso network architecture. Accordingly, a solution architecture diagram is not provided for this scenario.

How the Solution Works

After the solution is implemented and validated as described in Chapter 5, "Implementing the Solution," and Chapter 6, "Testing the Solution," UNIX workstation users can log on to the UNIX workstation shell by using their Active Directory username and credentials. The logon request is passed from the shell to the Pluggable Authentication Module (PAM), and eventually to the Kerberos library, which begins an exchange of messages between the workstation and the Windows KDC (steps 1 to 4 in Figure 4.2). The end result of this exchange is a Kerberos service ticket which the Kerberos library on the UNIX workstation can decrypt by using its own keys. Figure 4.2 illustrates this process.

Figure 4.2. A UNIX workstation that uses the Kerberos protocol to authenticate to Active Directory

The Kerberos library on the UNIX system decrypts this ticket and extracts the user principal name (UPN) of the authenticated user. After authentication, the login process uses the standard UNIX application programming interfaces (API) to retrieve authorization information. These APIs are routed through the name service switch (NSS), which then uses the nss_ldap module to connect to Active Directory and retrieve the requested information (such as the user identification (UID) and the group identification (GID). Finally, the login process uses this information to establish the security context for the user and starts the logon shell by using that context.

The Kerberos library will also process error and directive messages from the KDC that relay account policy requirements, such as those that advise users to change their passwords. The logon process, through the PAM, will then take the necessary actions needed to comply with the directives.

As a result of the authentication against the KDC integrated with Active Directory, the workstation (through PAM and the Kerberos library) will cache Kerberos tickets for the user. The ticket cache is what allows the user to securely access Kerberos-enabled applications on the network, and enjoy a single sign on (SSO) experience while doing so.

If the Active Directory user previously used the UNIX workstation that used a UNIX account with the same name as the Active Directory account, then the user's UNIX account information, including a password, may still be present in the /etc/shadow file. The /etc/shadow file can be edited to remove the user's password information because it will no longer be used to logon to the UNIX workstation.

For more details on the Kerberos ticket exchange performed during user logon, see the Microsoft Systems Journal paper, "Exploring Kerberos, the Protocol for Distributed Security in Windows 2000" on MSDN.

Extending the Solution

In order fully to satisfy the functional requirements described in Chapter 3, "Issues and Requirements," UNIX user account attributes such as uid and gid should be maintained in Active Directory instead of on the UNIX workstation. To meet these requirements, Contoso will install the Active Directory schema extension that is provided with Services for UNIX.

For the UNIX workstation to retrieve these authorization attributes, the NSS on the UNIX workstation will be configured to use LDAP and Active Directory.

More information about installing the Microsoft Services for UNIX (SFU) schema extension for Active Directory and configuring NSS to use LDAP can be found in the Microsoft Solution Guide for Windows Directory and Security Services for UNIX.

Integrating SAP R/3 Application Server Authentication by Using the Kerberos Protocol

The Contoso solution for integrating SAP with the Microsoft identity and access management platform involves the reconfiguration of the SAP Application Server and the SAP client graphical user interface (GUI) to use Secure Network Communications (SNC) and the Kerberos protocol. This approach will provide both strong authentication and secure application data transmitted on the network.

For more information about the SNC capabilities of SAP R/3, see the SAP Partners Integration & Certification: Integration Scenarios page.

Solution Concept

An analysis of the common security capabilities of Active Directory and the SAP Application Server identified the Kerberos version 5 protocol as the optimal technology for achieving integration and improving security for the following reasons.

• The Kerberos protocol is a standards-based protocol implemented in Windows client and server products, Active Directory, and the SAP R/3 Application Server.
• The Kerberos protocol specifies that the TGT acquired during logon can be presented to the Windows KDC to generate a service ticket. The service ticket then authenticates to network resources and applications such as the SAP R/3 Application Server. This process is transparent to the user, allowing for an SSO experience.
• The Kerberos protocol includes the creation and sharing of client/server session keys that allow for strong encryption of subsequent application data transmitted between client and server.

Configuring the SAP R/3 Application Server, and the SAP client GUI to use SNC and the Kerberos authentication protocol provides secure user authentication while protecting SAP application data on the network.

In addition, enabling SAP to use Kerberos authentication makes it possible for SAP users to experience an SSO experience to SAP by using their Active Directory network logon. Because the solution eliminates the need for the user to present a separate SAP password, password management overhead including Helpdesk costs are reduced substantially. Figure 4.3 shows the solution concept for this scenario.

Figure 4.3. Integrating the SAP R/3 Application Server with Active Directory by using the Kerberos version 5 protocol

Solution Prerequisites

Contoso has deployed Active Directory on the intranet in accordance with the "Platform and Infrastructure" paper in this series.

This solution is enabled by changing UNIX configuration settings and does not add to or change any aspect of the existing Contoso network architecture; accordingly, a solution architecture diagram is not provided for this scenario.

How the Solution Works

After implementing and validating the solution as described in Chapter 5, Implementing the Solution," and Chapter 6, "Testing the Solution," the SAP R/3 Application Server user logs on to his Windows workstation by using his Active Directory credentials. The user then launches the SAP GUI from the desktop, and selects the Kerberos protocol logon option. The SAP GUI, through the Generic Security Service API (GSS-API) wrapper for the Kerberos authentication package, requests a Kerberos service ticket (step 1) for the SAP R/3 Application Server by using the configuration information stored in SAP GUI profile. The Kerberos authentication package requests a new ticket from the domain controller if needed, or retrieves an existing ticket from the ticket cache (step 2). The SAP GUI then initiates a connection to the SAP R/3 Application Server and presents the ticket when requested (step 3). Figure 4.4 shows this step sequence in operation.

Figure 4.4. Windows client authenticating to SAP application server

The SAP R/3 Application Server receives the service ticket and validates it by invoking the Kerberos authentication package on the server through the GSS-API wrapper (step 4). If the ticket is validated, the SAP R/3 Application Server extracts the UPN of the user, and then maps this information to an account maintained by the SAP R/3 Application Server (step 5). The user is then logged on to the SAP Application Server by using the account maintained by SAP, and an encrypted session is established between the client and the server for application data (step 6).

Because the user authenticated to the SAP R/3 Application Server by using their default Kerberos credentials, an SSO experience is achieved for the user.

Extending the Solution

This solution describes how to manually configure each SAP account to use an Active Directory account for authentication by using the Kerberos protocol. This is a sufficient solution for organizations that have a limited number of direct SAP users, such as an average-sized human resources (HR) department.

For environments with large numbers of SAP users, a more automated provisioning and synchronization approach for managing SAP accounts (including Active Directory account mappings) would be preferred. Such a solution could be created by using Microsoft Identity Integration Server 2003, Enterprise Edition with Service Pack 1 (MIIS 2003 with SP1).

Note The design could also be extended to include UNIX workstations that use the Kerberos version 5 protocol to authenticate to the SAP R/3 Application Server, but there are a few issues that block immediate adoption of such a solution at Contoso. The primary reason Contoso is not implementing this solution at present is that SAP endorses only a few GSS-API library implementations for the UNIX platform. When the list of SAP-endorsed GSS-API libraries expands to include a version already deployed at Contoso, or the company deploys a different approved version, Contoso will initiate this phase of the project.

Chapter 5: Implementing the Solution

The previous chapters in this paper provide you with the information you need to understand the business requirements, and the specifications for implementing solutions that address the two Contoso scenarios (enabling UNIX workstations to authenticate to the Microsoft® Active Directory® directory service, and configuring the SAP R/3 Application Server to authenticate to Active Directory). This chapter provides prescriptive guidance on how to implement the solutions.

The prerequisites and implementation guidance in this chapter can be verified by following the guidance in Chapter 6, "Testing the Solution."

Tools and Templates

The Identity and Access Management download package includes Identity and Access Management Tools and Templates.msi, which is the Tools and Templates installer file. The Tools and Templates that are part of this download include text-based scripts, code samples, and configuration files that are related to identity and access management, but do not include any executable programs or compiled code.

Note These samples are provided as examples only. Be sure to review, customize, and test these tools and templates before you use them in a production environment.

When you run the installer file, the resulting folder structure will look similar to the one that appears in Figure 5.1, depending on where you install it.

Figure 5.1. The Tools and Templates folder structure

This guide assumes that you have installed the Tools and Templates into the default location of %UserProfile%\My Documents\Identity and Access Management Tools and Templates. If you use a different installation location, ensure that you use the same path in all the steps in this document.

Note The Tools and Templates MSI package can sometimes produce an error during the installation process. See the Identity and Access Management Series Readme.htm file for more information.

Folder: UNIX

Table 5.1. The UNIX Folder

Integrating UNIX Workstations with Active Directory

The Contoso example integrates UNIX workstations and applications with the Microsoft Identity and Access Management Platform, which requires migrating Solaris 9 workstation local user accounts to Active Directory. To do this, Contoso must first create UNIX user and workstation accounts in Active Directory, and then configure the Solaris 9 workstations to use the Kerberos protocol. This protocol allows you to use the Key Distribution Center (KDC) in Microsoft Windows Server™ 2003 to authenticate the Solaris 9 accounts you use Microsoft Windows® credentials.

The high-level tasks you will need to perform to implement this scenario are:

• Create accounts for UNIX workstations and users in Active Directory.
• Configure UNIX workstations to use the Kerberos protocol for user logon.

Implementation Prerequisites

To implement the following prescriptive guidance, you need to ensure that the following prerequisites have been met.

• Install and configure the Active Directory portion of the Contoso infrastructure as described in the "Platform and Infrastructure" paper in this series.
• Ensure that the UNIX workstations have Domain Name System (DNS) configured to resolve the Windows Server 2003 domain names. Open the /etc/resolv.conf file and verify that it contains lines similar to those in the following table.

Table 5.2. Windows Server 2003 Domain Names

• Ensure that the UNIX workstations receive IP addresses leased from the Dynamic Host Configuration Protocol (DHCP) server in your domain.
• Install the Sun Enterprise Authentication Mechanism (SEAM) 1.0.1 product (normally bundled with Solaris 9) on the UNIX workstations.
• Ensure that the UNIX workstation clocks are all in sync with the Active Directory domain controllers.

Implementation Overview

This scenario can be implemented with the following two main activities.

• UNIX Account Creation
• UNIX Workstation Configuration

UNIX Account Creation

Contoso performed the following tasks to create user accounts in Active Directory that matched the user accounts in the Solaris 9 workstations. You can tailor these tasks to the requirements of your organization.

• Task 1: Add UNIX User Accounts to Active Directory
• Task 2: Create UNIX Workstation Accounts in Active Directory
• Task 3: Generate Keytab Files for the UNIX Workstations

Caution The user accounts in Active Directory must exactly match the user account names in the UNIX workstations, which are case-sensitive.

Task 1: Add UNIX User Accounts to Active Directory

Complete the following steps to accomplish this task.

To add a UNIX user account to Active Directory

1. Open the Microsoft Management Console (MMC) for Active Directory Users and Computers with user privileges to manage user accounts.
2. In the console tree, click the Users organizational unit (OU).
3. Right-click the Users OU, point to New, and then click User.
4. In the New Object-User dialog box, type the following information (leave all other information at the default values).

First name: <Solaris_User_First name>

Last name: <Solaris_User_Last name>

User logon name: <Solaris_User_UNIX_Account_Name>

User logon name (pre-Windows 2000): <Solaris_User_UNIX_Account_Name>

1. Click Next.
2. In the New Object-User dialog box, type the following information.

Password: <Alphanumeric_Password>

Confirm password: <Alphanumeric_Password>

1. Click Next, and then click Finish.

Task 2: Create UNIX Workstation Accounts in Active Directory

Complete the following steps to create an account in Active Directory to represent a Solaris 9 workstation.

To create a UNIX workstation account in Active Directory

1. Open the Active Directory Users and Computers MMC with user privileges to manage user accounts.
2. Right-click na.corp.contoso.com, point to New, and then click Organization Unit.
3. In the New Object-Organizational Unit dialog box, type Solaris Workstations and then click OK.
4. Right-click Solaris Workstations, point to New, and then click User.
5. In the New Object-User dialog box, type the following information (leave all other information at the default values).

First name: <Solaris_Workstation_Name>

User logon name: <Solaris_Workstation_Name>

User logon name (pre-Windows 2000): <Solaris_Workstation_Name>

1. In the New Object–User dialog box, click Next, and then type the following information:

Password: <Alphanumeric_Password>

Confirm password: <Alphanumeric_Password>

1. In the same dialog box, clear the User must change password at next logon check box, and select the Password never expires check box.
2. Click Next, and then click Finish.

Task 3: Generate Keytab Files for the UNIX Workstations

Use the ktpass.exe utility to create keytab files for the UNIX workstations. The keytab file contains the key that the Kerberos version 5 protocol uses to encrypt ticket requests.

Note The ktpass.exe utility is included with the Support Tools on the Windows Server 2003 product CD.

Complete the following steps to create keytab files for the UNIX workstations.

To generate a keytab file for a UNIX workstation

1. Log on to the domain controller as Administrator.
2. Click Start, click Run, type cmd and then press ENTER to open the command prompt.
3. At the command prompt, run the ktpass utility with the command line switches specified in this step with the following modifications.

• Use the name of the Solaris workstation created in task 2, step 5 for <Solaris_Workstation_Name>.

NA.CORP.CONTOSO.COM and na.corp.contoso.com represent the domain in which the Solaris workstation computer account was created.

• Use the password created in task 2, step 6 for password as shown in the following example.

ktpass -princ host/<Solaris_Workstation_Name>.na.corp.contoso.com@

NA.CORP.CONTOSO.COM -mapuser <Solaris_Workstation_Name>

-pass password -out <Solaris_Workstation_Name>.keytab

1. Press ENTER, and the following output should appear.

   Targeting domain controller: GRNCDC01.na.corp.contoso.com

   Successfully mapped host/ Solaris_Workstation_Name.na.corp.contoso.com to Solaris_Workstation_Name.

   Key created.

   Output keytab to Solaris_Workstation_Name.keytab:

   Keytab version: 0x502

   keysize 79 host/ Solaris_Workstation_Name.na.corp.contoso.com@NA.CORP.CONTOSO.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x3 (DES-CBC-MD5) keylength 8 (0x0e9bd5da314f5bad)

   Account Solaris_Workstation_Name has been set for DES-only encryption.

UNIX Workstation Configuration

Contoso performed the following tasks to configure the Kerberos version 5 protocol on UNIX workstations. You can tailor these tasks to fit the requirements of your organization.

• Task 1: Install the keytab File on the UNIX Workstation
• Task 2: Configure the pam.conf File
• Task 3: Configure the krb5.conf File
• Task 4: Delete User Passwords on the UNIX Workstation

Task 1: Install the Keytab File on the UNIX Workstation

Complete the following steps to accomplish this task.

To install the keytab file on the UNIX Workstation

1. Use File Transfer Protocol (FTP) to send the keytab file created on the domain controller to the Solaris 9 operating system running on the UNIX workstation.

Important Because you are going to exchange data between a computer running Windows Server 2003 and a Solaris 9 host, ensure that the transfer mode is set to binary for the FTP session.

1. Log on to the UNIX workstation as root.
2. Verify that DNS is installed. The /etc/resolv.conf file should include the following information.

   domain na.corp.contoso.com

   nameserver 10.1.103.13

3. At the # prompt, type ktutil and then press ENTER.
4. At the ktutil: command prompt, type rkt Solaris_Workstation_Name.keytab and then press ENTER.
5. At the ktutil: command prompt, type list, press ENTER, and the following output should appear.

   ktutil: list

   slot KVNO Principal

   1 3 host/ffl-na-sun-01.na.corp.contoso.com@NA.CORP.CONTOSO.COM

6. At the ktutil: command prompt, type wkt /etc/krb5/krb5.keytab and then press ENTER.
7. At the ktutil: command prompt, type q and then press ENTER.

Task 2: Configure the pam.conf File

Complete the following steps to configure the pam.conf file, which is a Pluggable Authentication Module (PAM) architecture configuration file that Contoso will use to enable the Kerberos version 5 protocol authentication.

To configure the pam.conf file

1. Log on to the UNIX workstation as root
2. Make a backup by copying the default /etc/pam.conf file and renaming the backup file /etc/pam.conf.old

The Tools and Templates folder that downloads with this paper contains an example of a pam.conf file that is used on the UNIX workstation to enable authentication using the Kerberos version 5 protocol.

1. Copy the provided file to the UNIX workstation or modify the existing /etc/pam.conf file to match the following information in the configuration file.

   #

   # PAM configuration

   #

   #

   # Contoso's pam.conf to enable Kerberos

   #

   # Authentication

   #

   other auth sufficient pam_krb5.so.1

   other auth sufficient pam_unix.so.1 try_first_pass

   #

   # Password

   #

   other password sufficient pam_krb5.so.1

   other password sufficient pam_unix.so.1

   #

   # Account

   #

   other account optional pam_krb5.so.1

   other account optional pam_unix.so.1

   #

   # session

   #

   other session optional pam_krb5.so.1

   other session optional pam_unix.so.1

Task 3: Configure the krb5.conf File

The krb5.conf file is used to set the defaults for the Kerberos protocol on the UNIX workstation. Contoso modified this file to point to the KDC in Windows Server 2003 and na.corp.contoso.com in the Windows Server 2003 realm.

Complete the following steps to configure this file according to your organization's needs.

To configure the krb5.conf file

1. Log on to the UNIX workstation as root
2. Make a backup by copying the default /etc/krb5/krb5.conf file and then rename the backup file /etc/krb5/krb5.conf.old
3. Customize the krb5.conf file in the Tools and Templates folder that downloads with this paper for your environment, and then copy it to the /etc/krb5/krb5.conf file on the UNIX workstation. An example of information contained in this configuration file that Contoso used follows:

   [libdefaults]

   default_realm = NA.CORP.CONTOSO.COM

   [realms]

   NA.CORP.CONTOSO.COM = {

   kdc = ffl-na-dc-01.na.corp.contoso.com

   admin_server = ffl-na-dc-01.na.corp.contoso.com

   kpasswd_protocol = SET_CHANGE

   }

   [domain_realm]

   .na.corp.contoso.com = NA.CORP.CONTOSO.COM

   [logging]

   default = FILE:/var/krb5/kdc.log

   kdc = FILE:/var/krb5/kdc.log

   kdc_rotate = {

   # How often to rotate kdc.log. Logs will get rotated no more

   # often than the period, and less often if the KDC is not used# frequently.

   period = 1d

   # how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)

   version = 10

   }

   [appdefaults]

   kinit = {

   renewable = true

   forwardable= true

   }

   gkadmin = {

   help_url = http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195

   }

4. Confirm that the UNIX workstation system clock is synchronized with the domain controller clock. Run the date command on the UNIX system, and run the time command on the Windows domain controller. After accounting for any difference in time zone settings, adjust the time on the UNIX system to within 5 minutes of the time reported by the domain controller.

Important This is a Kerberos version 5 protocol requirement. The system clocks cannot be more than 5 minutes out of synchronization.

Task 4: Delete User Passwords on the UNIX Workstation

If there is an existing UNIX account on the workstation with the same name as the Active Directory user account, then the password information in the /etc/shadow file should be removed because it will no longer be used.

Complete the following steps to accomplish this task.

To delete Active Directory user passwords on the UNIX workstation

1. Log on to the UNIX workstation as root
2. Open the /etc/shadow file in a text editor.
3. Find the entry for the Active Directory user, and then delete the entire line for it.

The UNIX workstation is now configured to user the Kerberos protocol to authenticate users against Active Directory.

Microsoft recommends validating the implementation by running the tests described in the "Validate the Implementation Prerequisites" section for integrating the UNIX workstation with Active Directory Scenario portion of Chapter 6, "Testing the Solution."

Integrating SAP R/3 Application Server Authentication by Using the Kerberos Protocol

Contoso wants to use its investment in the Windows Server 2003 Active Directory infrastructure to implement single sign on (SSO) to the SAP R/3 Application Server. To do this, the authentication process between the SAP front-end applications and the SAP R/3 Application Server must be configured to use the Kerberos version 5 protocol.

Implementation Prerequisites

For these implementation details to work correctly, you need to have the basic Contoso infrastructure implemented as defined in the following chapters in the "Platform and Infrastructure" paper in this series, Chapter 4, "Designing the Infrastructure" and Chapter 5, "Implementing the Infrastructure," including:

• An intranet Microsoft Active Directory® directory service forest. The forest should contain the provided Contoso OUs, groups, and users.

Before performing the tasks in this section, you must also complete the following:

• Ensure that the SAP R/3 Application Server has user accounts in the SAP system.
• Ensure that an Active Directory account exists for each SAP user account in the intranet Active Directory for account mapping and SSO purposes.

Implementation Overview

This scenario can be implemented by completing the following two activities.

• SAP R/3 Server Configuration
• Configuring the SAP GUI Client on Windows XP

SAP R/3 Server Configuration

The following tasks in this section configure the SAP R/3 Application Server to use the Kerberos version 5 protocol. You can tailor these tasks to the requirements of your organization.

• Task 1: Create a SAP Service Account to Run the SAP R/3 Application Server Process
• Task 2: Establish a Service Principal Name (SPN) for the SAP User Account
• Task 3: Add a SAP User Account to the Local Administrators Group
• Task 4: Install the Kerberos version 5 Protocol
• Task 5: Configure SNC on the SAP R/3 Server to Use the Kerberos version 5 Protocol
• Task 6: Map the SAP R/3 Application Server User Accounts to Active Directory

Task 1: Create a SAP Service Account to Run the SAP R/3 Application Server Process

Complete the following steps to accomplish this task.

To create a SAP service account in Active Directory

1. Open the Active Directory Users and Computers MMC with user privileges to manage user accounts.
2. In the console tree, right-click the Users OU, point to New, and then click User.
3. In the New Object-User dialog box, type the following information.

First name: SAP

Last name: Logon

User logon name: sapacct@na.corp.contoso.com

User logon name (pre-Windows 2000): sapacct

Note Do not change any other default value information in this dialog box.

1. Click Next, and then in the New Object-User dialog box, type the following information:

Password: <Alphanumeric_Password>

Confirm password: <Alphanumeric_Password>

Task 2: Establish an SPN for the SAP User Account

Complete the following steps to accomplish this task.

To establish an SPN for the SAP user account

1. Locate the setspn.exe utility on the Windows 2003 Server Resource Kit CD or download it from the Windows 2000 Resource Kit Tool: Setspn.exe page.
2. While logged on as a domain administrator, type the following at the command prompt: SETSPN -A SAPService/<host computer name> NA\sapacct

Note This task is necessary on Windows Server 2003 because the KDC will invoke the Kerberos user2user protocol for any account that does not have an SPN. Because the SPN is not actually used by the SAP client when requesting Kerberos service tickets for the SAP R/3 Application Server, the only part of the SPN that must be correct is the principal name of the SAP service user account.

Task 3: Add a SAP Service Account to the Local Administrators Group

Complete the following steps to accomplish this task.

To add a SAP service account to the Local Administrators group

1. Open the Computer Management MMC with domain administration privileges on the SAP R/3 Application Server.
2. In the console tree, double-click System Tools, click Local Users and Groups, and then click Groups.
3. Right-click the Administrators group, and then click Add to Group.
4. In the Administrator Properties dialog box, click Add.
5. In the Select Users, Computers or Group dialog box, go to the Enter the object names to select (examples) box, and then type sapacct@na.corp.contoso.com

Task 4: Install the Kerberos Version 5 Protocol

The next task is to install the Kerberos version 5 protocol component on the SAP R/3 Application Server by completing the following steps.

Note There is a version of the gsskrb5.dll binary file included with the SAP installation media, but a newer version available from SAP must be used in Windows Server 2003 and Microsoft Windows® XP environments. SAP note number 352295 has more information about why this version of the .dll file is needed, and also attaches the newer version so that it can be downloaded. You can access SAP notes by using your SAP account and connect to OSS or directly go to the SAP Service Marketplace page of the SAP Web site.

To install the Kerberos version 5 protocol on the SAP R/3 Application Server

1. Log on to the SAP R/3 Application Server as sapacct@na.corp.contoso.com
2. Copy the Gsskrb5.dll file to %windir%\system32.
3. Click Control Panel, and then click System.
4. Click the Advanced tab, click Environment Variables, and then in the Environment Variables dialog box, under the System variables, click New.
5. In the New System Variable dialog box, type the following information.

Variable Name: SNC_LIB

Variable Value: %windir%\system32\gsskrb5.dll

Note These variable values define the location for the Gsskrb5.dll file.

Task 5: Configure SNC to Use the Kerberos Version 5 Protocol

After you complete the previous tasks you are ready to configure the Secure Network Communication (SNC) functionality in the SAP R/3 Application Server to use the Kerberos version 5 protocol for authentication. You can download the SNC User's Guide from the SAP Web site.

Complete the following steps to accomplish this task.

To configure the SNC to use the Kerberos version 5 authentication protocol

1. Log on to the SAP R/3 Application Server as sapacct@na.corp.contoso.com.

Note The SAP R/3 Application Server system is case-sensitive. For this reason, you must log on by typing the logon name of the user account in Active Directory exactly as it appears here.

1. Open the <SAP R/3 Web Server Drive:>\MBS\MBS_D00.pfl file by using Notepad.exe, and then add the following parameters to the end of the file.

   #language

   zcsa/system_language = EN

   #Kerberos

   snc/enable =1

   snc/accept_insecure_cpic =1

   snc/accept_insecure_gui =1

   snc/accept_insecure_r3int_rfc =1

   snc/accept_insecure_rfc =1

   snc/data_protection/max =1

   snc/data_protection/min =1

   snc/data_protection/use =1

   # Location of the dll used for kerberos

   snc/gssapi_lib = C:\windows\system32\gsskrb5.dll

   snc/permit_insecure_start =1

   # The Windows User Account used to run SAP Server

   snc/identity/as = p:sapacct@na.corp.contoso.com

   snc/r3int_rfc_secure = 0

Note The parameters in this file are case-sensitive. For example, the value of the parameter snc/identity/as =p:sapacct@na.corp.contoso.com is case-sensitive and must match the case of the user logon name in Active Directory.

The exact location of the Windows installation should be used in place of C:\Windows in the snc/gssapi_lib parameter.

A line feed [empty line] should be added at the end of the configuration file MBS_D00.pfl. If an empty line is not present, warnings are generated while running the MBS.

Substitute the actual directory used for the Windows installation if different from "C:\Windows."

1. Double-click <SAP R/3 Web Server Drive>\MBS\runmbs.cmd to start the SAP MBS System.

Task 6: Map the SAP R/3 User Accounts to Active Directory

After configuring the SAP R/3 Application Server to use the Kerberos protocol, you can map the SAP R/3 Web server user accounts to the user accounts in Active Directory.

Contoso has Windows accounts for all of the company's SAP R/3 Web server users. You can tailor the steps in this task to meet the needs of your organization.

To map the SAP R/3 Server user sap1 to Active Directory account sap1@NA.CORP.CONTOSO.COM

1. Log on to the SAP R/3 Application Server as Administrator
2. Type the Transaction Code SU01 to go to the User Maintenance: Initial Screen.
3. In the User box, type sap1 the name of the SAP R/3 Application Server user.
4. Click the User Names menu, click Change to make the Maintain User screen appear, and then click the SNC tab.
5. In the SNC Name text box, type p:sap1@NA.CORP.CONTOSO.COM

Note Remember, SAP R/3 Web server user information is case-sensitive. Mapping the SAP R/3 Web server to this Active Directory account name for the user logon sap1 in the domain NA.CORP.CONTOSO.COM must exactly match this logon name in Active Directory.

1. Select the Unsecure Communication permitted (user-specific) check box.
2. Click Save on the menu bar to preserve these changes.
3. To verify that the canonical name is valid, click the User Names menu, click Display, and then click the SNC tab.
4. On the SNC Data property sheet, a check mark should appear next to the message Canonical name determined.

This concludes the tasks for configuring SSO on the SAP R/3 Application Server.

Configuring the SAP GUI Client on Windows XP

Contoso wants to configure its Microsoft Windows XP clients to use the Kerberos protocol instead of the default authentication process to log on to the SAP R/3 Application Server. To do this, the SAP graphical user interface (GUI) front-end application needs to be modified to create a logon profile that will recognize the Kerberos protocol. Users in the environment will then use this profile to connect to the SAP R/3 Application Server.

Contoso performed the following tasks in this section to configure the SAP GUI front-end application to use the Kerberos protocol. You can tailor these tasks to fit the needs of your organization.

• Task 1: Install the Kerberos version 5 Protocol in the SAP GUI Front-end Application
• Task 2: Configure the Kerberos version 5 Protocol Logons for Users
• Task 3: Log On to the SAP R/3 Application Server By Using the Kerberos Protocol

Task 1: Install the Kerberos Protocol in the SAP GUI Front-End Application

Complete the following steps to accomplish this task.

Note The SAP installation media includes the gsskrb5.dll binary.

To install the Kerberos protocol in the SAP GUI front-end application

1. Log on to the Windows XP client as the Local Administrator.
2. Copy the Gsskrb5.dll file to %windir%\system32.
3. Click Control Panel, and then click System.
4. Click the Advanced tab, click Environment Variables, and then in the Environment Variables dialog box, under System variables, click New.
5. In the New System Variable dialog box, type the following information.

Variable Name: SNC_LIB

Variable Value: %windir%\system32\gsskrb5.dll

Note These variable values define the location for the Gsskrb5.dll file.

Task 2: Configure Kerberos Version 5 Protocol Logons for Users

Complete the following steps to accomplish this task.

To configure a Kerberos version 5 protocol logon for user sap1@NA.CORP.CONTOSO.COM

1. Log on to the Windows XP Client as the Local Administrator.
2. Open SAPlogon, and then click New.
3. On the New Entry screen, enter the following information.

Description: <My_Name_For_Kerberos_Connection>

Application Server: <Fully Qualified Domain Name_For SAP R/3_Application_Server>

System number: 00

Enable SAP System: R/3

1. Click Advanced, and then in the Advanced Options pane, select the Enable Secure Network Communication check box, and in the SNC Name box, type p:sapacct@na.corp.contoso.com

Note This is the Active Directory user with the logon name sapacct in the domain na.corp.contoso.com who will run the SAP System. Because the SAP R/3 Application Server is case-sensitive, the user name for this must match the user account name in Active Directory.

1. Select the Max. available option.

Task 3: Log On to the SAP R/3 Web Server by Using the Kerberos Protocol

Complete the following steps to accomplish this task.

To log on to the SAP R/3 Application Server by using the Kerberos protocol

1. Log on to the Windows XP client as sap1@na.corp.contoso.com
2. Open SAPlogon.
3. On the SAP Logon 620 screen, select <My_Name_For_Kerberos_Connection>, and then click Logon.

These steps should log you on to the SAP R/3 Application Server system without being asked for logon credentials.

This completes the configuration tasks for the Contoso SAP R/3 Application Server to use the Kerberos version 5 protocol. The Windows workstations that connect to the SAP front-end applications can also now use the Kerberos protocol. After Contoso implements the authentication component of the solution, users at Contoso will log on to Active Directory from their workstations, and then use their Active Directory credentials to access the SAP front-end applications.

Chapter 6: Testing the Solution

This chapter describes how to validate the implemented solution scenarios from the previous chapter. It also provides some troubleshooting steps to help with common implementation challenges. Comprehensive guidance for testing the end-to-end user and administrator experience is not provided.

Integrating UNIX Workstations with Active Directory

After the implementation process to integrate UNIX workstations with the Microsoft® Active Directory® directory service is complete, you are ready to validate your implementation to ensure that the intranet access management scenario works as expected and meets the Contoso requirements.

Validating the Implementation Prerequisites

Before you start the implementation guidance in this paper you should perform a few basic verification tests to ensure that you have correctly configured the required infrastructure for the solution. The following basic tests are designed to provide you with a means to quickly check that your network setup is ready to implement the Integrating UNIX Workstations with Active Directory solution scenario.

Tests to validate the prerequisites include:

• Basic Test 1: Verify DHCP Functionality
• Basic Test 2: Verify Workstation Has a DNS Entry
• Basic Test 3: Verify Name Resolution
• Basic Test 4: Verify User's Ability to Change Password

Basic Test 1: Verify DHCP Functionality

Complete the following steps to verify that the UNIX workstation registers a Dynamic Host Configuration Protocol (DHCP) address from the intranet domain's DHCP server.

To verify DHCP functionality

1. Join the UNIX workstation to the Microsoft Windows®-based domain, and then update the necessary configuration files on the UNIX workstation with the Contoso domain details.
2. Restart the workstation.
3. Log on to the workstation from a UNIX user account.

Open the DHCP Microsoft Management Console (MMC) snap-in on the intranet DHCP server and verify that the UNIX workstation has leased an IP address.

Basic Test 2: Verify That Workstation Has a DNS Entry

Complete the following steps to verify that the UNIX workstation has a Domain Name System (DNS) entry.

To verify that the workstation has a DNS entry

1. Open the DNS management MMC on the Contoso intranet DNS server.
2. In the intranet domain namespace zone, add a Host (A) record with the IP address and hostname of the UNIX workstation you are adding.

Open a command prompt on the DNS server, and use the nslookup command to verify that the UNIX workstation name resolves in the Contoso domain.

Basic Test 3: Verify Name Resolution

Complete the following steps to verify that the UNIX workstation name can be resolved locally and that other domain members can be pinged from it.

To verify name resolution

1. After adding the UNIX workstation to Windows Active Directory domain, log on to the workstation by using a local user UNIX account.
2. Open a command prompt and use the nslookup command to resolve the workstation hostname and the intranet domain name.
3. Use the ping command to test the connectivity with the Active Directory domain controllers in the domain.

The UNIX workstation's hostname should resolve and the workstation should successfully join the domain.

Basic Test 4: Verify That User Can Change Password

Complete the following steps to verify that a user on a local UNIX workstation can change the password of his or her account multiple times.

To verify a user's ability to change their password

1. Log on to the UNIX workstation with the local user's credentials.
2. Change the user's password consecutively three times by using the passwd utility.

You should be able to successfully change the password three times after logging in with the user's credentials.

After you have successfully completed these tests, you can implement the solution as prescribed in Chapter 5, "Implementing the Solution," and then perform the following implementation validation tests.

Validating the Implementation

You can use the information in the following tasks to test the scenario for integrating the UNIX workstation with Active Directory, and validate your implementation of this guidance.

Contoso used the following tests to verify the functionality of integrating UNIX workstations from the acquired company to their intranet domain. You can tailor these tests to suit the needs of your organization.

Tests to validate the implementation include:

• Test 1: Verify Users Can Log On to UNIX Workstations
• Test 2: Verify Users with Disabled Accounts Cannot Log On
• Test 3: Verify UNIX User Accounts Meet Password Expiration Policy
• Test 4: Verify UNIX Users Can Change Their Passwords
• Test 5: Verify UNIX User Accounts Meet Password Complexity Policy

Test 1: Verify That Users Can Log On to UNIX Workstations

Complete the following steps to ensure that users with accounts in Active Directory can log on to UNIX workstations.

To test logon to UNIX workstations

1. Log on to a UNIX workstation as a user with an Active Directory account, and type the Kerberos password when prompted.
2. Run the klist utility to check for a valid Kerberos ticket.

The user can log on and has valid Kerberos tickets.

Test 2: Verify That Users with Disabled Accounts Cannot Log On

Complete the following steps to verify that users whose Active Directory accounts have been disabled cannot log on UNIX workstations.

To verify that users with disabled accounts cannot log on to UNIX workstations

1. Disable a user account in Active Directory.
2. Attempt to log on to a UNIX workstation by using the disabled Active Directory account.

The workstation logon attempt should fail.

Test 3: Verify That UNIX User Accounts Meet Password Expiration Policy

Complete the following steps to verify that UNIX user accounts in Active Directory meet the Contoso intranet domain password expiration policy.

To verify compliance with password expiration policy

1. Log on to a UNIX workstation with a UNIX user account that is less than 24 hours old.
2. Request a Kerberos ticket by using the kinit command.
3. Try changing the password by using the passwd command.

If password policy is set to Minimum password age=1 in the password policy for the domain, the attempt to change the password should be rejected.

Test 4: Verify That UNIX Users Can Change Passwords

Complete the following steps to verify that UNIX users can change their Active Directory account passwords.

To verify users can change their Active Directory account passwords

1. Log on to a UNIX workstation as a UNIX user with an account in Active Directory that is more than 24 hours old.
2. Change the password by using the passwd command.

The user can change their password, provided the new password meets complexity and length requirements.

Test 5: Verify That UNIX User Accounts Meet Password Complexity Policy

Complete the following steps to verify that UNIX user accounts in Active Directory meet the Contoso intranet domain password complexity.

To verify compliance with password complexity policy

1. Log on to a UNIX workstation as a UNIX user with an account in Active Directory.
2. Try changing the password with the passwd command to a simple password (one that uses only 3 or 4 characters and does not mix alpha and numeric characters).
3. Trying doing this a few times with different simple passwords.

Simple passwords that do not meet the domain complexity requirements should be rejected.

Troubleshooting

This section of the chapter provides information about some common errors that you may encounter while testing this scenario, and then how to most likely resolve them. The information in the following table is not an exhaustive list of errors and troubleshooting procedures.

Table 6.1. Troubleshooting the Scenario for Integrating UNIX Workstations with Active Directory

Integrating SAP R/3 Application Server Authentication By Using the Kerberos Protocol

After the implementation process for authenticating the SAP R/3 Application Server to Active Directory is complete, you are ready to validate your implementation to ensure that the intranet access management scenario works as expected and meets the Contoso requirements for SAP users.

Validating the Implementation Prerequisites

Before you start the implementation guidance in this paper, you should perform a few basic verification tests to ensure that you have correctly configured the required infrastructure for the solution. These baseline tests are designed to provide you with a means to check that your network setup is ready to implement the Authenticating the SAP R/3 Application Server to Active Directory solution scenario.

Tests to validate the prerequisites include:

• Basic Test 1: Verify Functionality of the SAP R/3 Application Server
• Basic Test 2: Verify New SAP Accounts Can Log On from the SAP R/3 Server
• Basic Test 3: Verify SAP Accounts Can Log On From a Windows XP Client

Basic Test 1: Verify Functionality of the SAP R/3 Application Server

Complete the following steps to verify that the SAP R/3 Application Server starts and operates properly on the Windows server where it is installed.

To verify the functionality of the SAP R/3 Application Server

1. Log on to the Windows server that hosts the SAP R/3 Application Server by using the credentials of the intranet domain SAP administrator account.
2. Open a command prompt and navigate to the folder C:\mbs.
3. Type runmbs.cmd and press ENTER to start the SAP R/3 Application Server.

The SAP R/3 Application Server should start successfully and run without any errors.

Basic Test 2: Verify That New SAP Accounts Can Log On from the SAP R/3 Server

Complete the following steps to verify the ability to log on to the SAP R/3 Application Server with a newly created SAP account.

To verify that new SAP accounts can log on

1. On the Windows server that hosts the SAP R/3 Application Server, start the SAP GUI client.
2. Log on to the SAP Application Server with the credentials of the SAP administrator, minisap.
3. Use the Administration tool to create a local SAP user account.
4. Log off from the SAP GUI client.
5. Log on again to the SAP R/3 Application Server by using the SAP GUI client and the local user credentials created in step 3.

The local SAP user should successfully log on to the SAP R/3 Application Server from the SAP GUI client.

Basic Test 3: Verify That SAP Accounts Can Log On From a Windows XP Client

Complete the following steps to verify that SAP accounts can successfully log on to the SAP R/3 Application Server from a computer running the Microsoft Windows® XP operating system.

To verify the ability of SAP clients to log on from computers running Windows XP

1. Log on to an intranet client computer running the Microsoft Windows XP operating system that also has the SAP GUI client installed.
2. Start the SAP GUI client application, and then log on to the SAP Application Server with the credentials of a local SAP user account.

The SAP GUI client should connect to the SAP R/3 Application Server, and a local SAP user should successfully log on.

After you have validated the prerequisites you are ready to implement the solution as prescribed in Chapter 5, "Implementing the Solution." After the solution is implemented you are ready to perform the following implementation tests.

Validating the Implementation

Contoso used the following tests to verify the functionality of integrating SAP R/3 Application Server authentication to Active Directory. You can tailor these tests to suit the needs of your organization.

Tests to validate the implementation include:

• Test 1: Verify SAP R/3 Server Functions After Active Directory Integration
• Test 2: Verify Active Directory SAP User Accounts in SAP R/3 Server Resolve
• Test 3: Verify SSO for SAP Users
• Test 4: Verify SAP GUI Logon Authentication Uses the Kerberos Protocol

Test 1: Verify That SAP R/3 Server Functions After Active Directory Integration

It is important to verify that the SAP R/3 Application Server is operating properly after it has been integrated with Active Directory.

To verify SAP R/3 Server functionality after integration with Active Directory

Perform the "Verify Functionality" test described in the previous section.

The SAP R/3 Application Server should start successfully and run without any errors.

Test 2: Verify That Active Directory SAP User Accounts in SAP R/3 Server Resolve

Complete the following steps to verify that SAP user accounts created in Active Directory resolve in the SAP R/3 Application Server.

To verify resolution of SAP user accounts

1. Log on to the SAP R/3 Application Server system as SAP administrator
2. Type the transaction code SU01 to display the User Maintenance: Initial screen.
3. In the User box, type the SAP user alias (sap1).
4. Click the User Names menu, click Display, and then click the SNC tab.

On the SNC Data property sheet, a check mark should appear next to the message:

Canonical name determined

Test 3: Verify SSO for SAP Users

Complete the following steps to verify that SAP users can experience single sign on (SSO) when they log on to the SAP R/3 Application Server without providing their logon credentials again after logging on to a computer running Windows XP with their Active Directory account.

To verify seamless logon to SAP R/3 Application Server from Windows XP

1. Log on to the Windows XP client by using the credentials of a domain user with a SAP account.
2. Open the SAP GUI client and log on to SAP by using SNC.

The user should log on successfully to the SAP R/3 Application Server without being prompted for credentials.

Test 4: Verify That SAP GUI Logon Authentication Uses the Kerberos Protocol

Complete the following steps to verify that the Kerberos version 5 authentication protocol is being used for SAP GUI logon authentication on computers running Windows XP.

To verify use of the Kerberos version 5 authentication protocol

1. Start the netmon monitoring tool on the intranet domain controller.
2. Instruct a SAP user to log on to SAP by using the steps in the previous test.
3. Stop netmon, and then browse through the captured messages.

The Kerberos version 5 authentication protocol should be used for authenticating SAP user logon requests from the SAP GUI client to the SAP R/3 Application Server.

Troubleshooting

This section of the chapter provides information about some common errors that you may encounter while testing this scenario, and then how to most likely resolve them. The information in table 6.2 is not an exhaustive list of errors and troubleshooting procedures.

Table 6.2. Troubleshooting the Scenario for Authenticating the SAP R/3 Server with Active Directory

Chapter 7: Operational Considerations

After the provided solution scenarios have been implemented and validated, a number of ongoing operational activities must happen to ensure continued success. The "Platform and Infrastructure" paper in this series provides information and references for how each service in the infrastructure should be operated. This chapter introduces a few additional operational considerations for the specific solution scenarios in this paper.

Integrating UNIX Workstations with Active Directory

This scenario creates a UNIX workstation account, which should be treated as a security sensitive account. An attacker who gains access to the password for the UNIX workstation could use the account to mount anonymous attacks on Contoso resources.

Microsoft recommends that workstation accounts have strong passwords of at least 15 characters that use a combination of upper and lower case letters, numbers, and special characters. The password should never be a word that could be found in a dictionary of any type. For more information about strong passwords, see the "Password Management" paper in this series.

In addition, the workstation account password should be changed on a regular basis.

Integrating SAP R/3 Application Server Authentication by Using Kerberos

This scenario creates a SAP service account, which should be treated as a security sensitive service account. An attacker who gains access to the password for the SAP service account could spoof the SAP R/3 Application Server on the network.

Microsoft recommends that service accounts have strong passwords of at least 15 characters that use a combination of upper and lower case letters, numbers, and special characters. The password should never be a word that could be found in a dictionary of any type. For more information about strong passwords, see the "Password Management" paper in this series.

---