Exportar (0) Imprimir
Expandir Todos
EN
Este conteúdo não está disponível no seu idioma mas aqui tem a versão em inglês.
Este tópico ainda não foi classificado - Classificar este tópico

Chapter 8: Evolving a Custom Solution

Published: June 27, 2006
On This Page

Introduction and Goals Introduction and Goals
Determining Your Next Steps Determining Your Next Steps
Expanding Active Directory Kerberos and LDAP Functionality Expanding Active Directory Kerberos and LDAP Functionality

Introduction and Goals

Now that you have deployed your custom solution for establishing interoperability between computers running the UNIX or Linux and Microsoft® Windows® operating systems, you might want to explore expanding your solution. You can take advantage of the services provided by the Active Directory® directory service beyond authenticated logon and authorization. You might also want to extend the solution to include additional operating systems or versions.

The solution that is now in place in your organization is one of several possible custom solutions for implementing interoperability between Windows Active Directory and UNIX or Linux clients. Each of these solutions is described in detail in Volume 2: Chapter 4, "Developing a Custom Solution" of this guide.

Depending on which solution your organization deploys, interoperability between UNIX hosts and an Active Directory domain is established as follows:

  • Authentication only. An End State 1 solution, as defined in this guide, enables UNIX or Linux clients to use Kerberos to authenticate to Active Directory. If your solution is an End State 1 solution, UNIX or Linux clients continue to use the existing UNIX-based authorization method.

  • Authentication and authorization. An End State 2 solution, as defined in this guide, uses both Active Directory–based Kerberos authentication and Active Directory–based lightweight directory access protocol (LDAP) authorization to support UNIX or Linux clients.

Some custom End State 1 or End State 2 solutions described in this volume use native operating system (native OS) components available by default in UNIX or Linux; others add the use of open source components and free software downloads to the native OS components. Both native OS and open source custom solutions described in this guide include solutions designed for Red Hat 9 Linux and for Solaris 9 UNIX.

CAUTION   We do not recommend deploying the native OS Red Hat 9 solution in your production environment because of the security risks inherent in this solution. For more information, see the discussion in the section "Use Red Hat 9 with Native OS Components for End States 1 and 2" in Volume 2: Chapter 4, "Developing a Custom Solution."

This chapter provides a number of approaches to evolving your interoperability solution beyond the End State 1 or End State 2 solution your organization chooses to deploy in your production environment. In addition to the approaches suggested here, you might identify other approaches appropriate for your organization.

Intended Audience

The audience for this chapter includes:

  • Any business decision maker or technical decision maker who is investigating whether to develop and deploy one of the custom solutions included in this volume or, alternatively, whether to buy one of the commercial solutions. Some of the limitations or challenges for evolving an End State 2 solution described in this chapter for the custom solutions are addressed in one or both of the commercial solutions:

    • Volume 2: Chapter 2, "Using Quest Software VAS to Develop, Stabilize, Deploy, Operate, and Evolve End State 2."

    • Volume 2: Chapter 3, "Using Centrify DirectControl to Develop, Stabilize, Deploy, Operate, and Evolve End State 2."

  • All teams who are investigating or who have already participated in developing, testing, releasing, or operating any of the custom solutions described in this volume.

This chapter is especially appropriate for developers of a custom solution who want to take advantage of Kerberos authentication and Lightweight Directory Access Protocol (LDAP) directory capabilities in their applications.

Determining Your Next Steps

Review your deployment to identify additional areas of your environment that can be considered for integration with Active Directory. You can then evaluate the areas that you identify for potential ways to extend the capabilities of your new solution, whether that solution currently includes only authentication or includes both authentication and authorization.

Review Your Deployment

You can start by asking the following questions:

  • Did we achieve our desired goals?

  • Are we realizing the expected benefits?

  • Are there secondary objectives or nice-to-haves that we did not achieve?

  • What areas did we exclude from the scope of the previous project that might be included in the scope in the future?

  • If we were unable to retire some of the existing infrastructure components in the previous project, what do we need to do to retire them in the next project?

  • Did we encounter any significant problems in using our new system, such as problems in usability, performance, features, or stability?

Identify Areas for Evolving the Solution

A further set of questions can complement your review process and help identify the next steps for evolving your UNIX-to-Windows interoperability solution. These include:

  • What other operating systems or versions can be incorporated into the Active Directory–based solution?

  • What other applications can use Active Directory for authentication, authorization, or directory services?

  • What other authentication, authorization, or directory services can be integrated with Active Directory?

  • What other major systems in the enterprise can be integrated with Active Directory? For example, provisioning, identity management, or enterprise system management systems might be candidates for integration.

When you evaluate other systems to integrate into your Active Directory–based environment, examine closely their authentication, authorization, and directory service mechanisms to determine which of them are good candidates for integration with your new solution.

Extend the Capabilities of Your Solution

Many options are potentially available for extending the capabilities of your interoperability solution for UNIX and Windows. The following subsections describe some of these options.

Extending from End State 1 to End State 2

If the solution you deployed is an End State 1 solution, that is, if it provides Active Directory–based authentication for UNIX clients but continues to use UNIX-based authorization, you can extend the solution to End State 2 by enabling UNIX clients to retrieve authorization information from the Active Directory LDAP store.

Factors to consider when you prepare to migrate authorization data to Active Directory might include migrating user authorization data from multiple authorization stores and planning migration of user authorization data and computers.

For more information about these factors, see "End State 1 or End State 2" in the overview of Volume 2: Chapter 4, "Developing a Custom Solution" in this guide.

Extending the Solution to Other Systems

You might want to extend Active Directory–based Kerberos authentication to other systems that already exist in your environment. You might also want to add commercial Kerberized (Kerberos-enabled) products to your environment. For a list of companies that provide Kerberized products, see "Commercial Kerberized Applications" later in this chapter.

You can modify existing custom applications to support Kerberos capabilities only or to support both Kerberos and LDAP capabilities. You can also require that new custom applications support Kerberos and LDAP. For commercial applications that you already use or are considering acquiring, contact the vendor to see what support their applications offer for Kerberos and LDAP.

Extending Certificate Services

The native OS Solaris End State 2 solution described in Volume 2: Chapter 4, "Developing a Custom Solution" uses public key certificates to implement Secure Sockets Layer (SSL). If your deployment currently uses certificates purchased from an outside provider, you might consider using Microsoft Windows Server™ 2003 Certificate Services to deploy your own public key infrastructure (PKI) in order to generate the certificates required by this solution.

Extending the Solution to Additional Operating Systems and Versions

You can extend your interoperability solution to other operating systems and operating system versions. Ideal first candidates for a native OS solution include Solaris 10, Fedora, Red Hat Enterprise, or HP-UX 11i. Most versions of native IBM AIX (versions 5.2 and earlier) do not interoperate well with Active Directory and are, therefore, not appropriate candidates for extending a native OS solution.

You can expand open source solutions to support older operating system versions (such as Solaris 8 or HP-UX 11.0) or operating systems such as most versions of IBM AIX that do not support the solution natively.

For a detailed description of native OS solutions and open source solutions that use Red Hat 9 or Solaris 9 to implement either End State 1 or End State 2, see Volume 2: Chapter 4, "Developing a Custom Solution."

Implementing Stronger Encryption Types for Kerberos Authentication

Kerberos authentication supports a number of authentication types. The authentication types supported depend on the particular implementation. The custom solutions described in this volume support DES-CRC, DES-MD5, and, for open source solutions only, RC4-HMAC. These three encryption types are among the most commonly used. The best practice is to use the strongest and, therefore, most secure encryption type supported by the solution that you select.

The following encryption types are listed in increasing order of strength:

  • DES-CRC. This encryption type, also known as des-cbc-crc, is the weakest encryption type supported. However, it is supported by almost all implementations, including the native OS solutions described in this volume because it was one of the original encryption types defined.

    Note   Microsoft does not recommend the use DES-CRC because it provides weaker security than DES-MD5 or RC4-HMAC. Use DES-CRC only if no other option is available.

  • DES-MD5. This encryption type, also known as des-cbc-md5, is somewhat stronger than DES-CRC. Because this encryption type is one of the earliest encryption types defined, it is supported by almost all implementations, including the native OS solutions described in this volume.

  • RC4-HMAC. This encryption type was developed by Microsoft and is stronger than both DES-CRC and DES-MD5. RC4-HMAC is relatively new and is therefore not supported by all implementations. The open source solutions described in this volume do support RC4-HMAC, but the native OS solutions do not.

If you extend a native OS solution to support newer operating system versions, you might be able to implement stronger encryption types supported by these later versions. Similarly, if you have implemented an open source solution with the weaker DES encryption types to support legacy Kerberos applications, you might be able to implement stronger encryption as these applications are modified or retired.

For information about Windows Server 2003 support for these encryption types, see "How the Kerberos Version 5 Authentication Protocol Works" at http://technet2.microsoft.com/WindowsServer/en/Library/4a1daa3e-b45c-44ea-a0b6-fe8910f92f281033.mspx.

For more information about Kerberos encryption types in general, see RFC 3961, "Encryption and Checksum Specifications for Kerberos 5," at http://tools.ietf.org/wg/krb-wg/draft-ietf-krb-wg-crypto/rfc3961.txt.

Integrating Other Services into Active Directory

If you extend your interoperability solution by integrating other operating systems or other operating system versions into an enterprise-wide authentication system based on Active Directory, you might find that additional services can benefit from integration with Active Directory. You can take advantage of Kerberos features—such as strong authentication, single sign-on (sometimes referred to as SSO), delegation, and encryption—for a variety of services, including the following:

  • Services that distribute software or data to computers

  • Services that automate tasks

  • Printing services

  • File sharing services

  • Authentication services for Web applications and Web services

  • Services that perform backups and consolidate backups

  • Services that automate distribution and renewal of X500 certificates (or other entities)

  • Patch management services

  • System or health management services

  • Identity management services

Migrating NSS Services to Active Directory LDAP

If you implemented one of the End State 2 solutions described in this volume, you have already migrated the UNIX passwd and group Name Service Switch (NSS) services to the Active Directory LDAP server. NSS is a service that Solaris and Red Hat clients can use to obtain identity and authorization information about users, groups, or computers from a variety of sources, including an LDAP directory such as Active Directory. As you evolve your solution, you might want to migrate additional NSS services to Active Directory.

NSS services are configured in the UNIX /etc/nsswitch.conf file to obtain information for their services from one or more sources, including:

  • Local files (such as /etc/hosts or /etc/passwd)

  • Network Information Service (NIS)

  • Network Information Service Plus (NIS+ or NISPLUS)

  • Domain Name System (DNS)

  • LDAP

Because NSS evolved alongside NIS, these data sources are often generically referred to as NIS maps although a NIS map is technically the data source for NIS only.

NSS services that you might choose to migrate include hosts, ethers, networks, rpc, services, protocols, netgroup, bootparams, aliases, publickey, netid, netmasks, and automount.

Redirecting Authentication and Authorization of Kerberos and LDAP-enabled Applications to Active Directory

You can configure existing commercial applications in your environment that use Kerberos for authentication or LDAP for authentication or authorization—either against private data stores (such as are provided in applications such as Oracle and Sybase) or against existing shared data stores (such as UNIX Kerberos key distribution centers, NIS, the Sun Microsystems iPlanet Directory Server, or IBM Tivoli Directory Server)—to direct authentication and authorization requests to Active Directory. For Kerberized applications, this can provide for single sign-on for your UNIX users. Kerberos single sign-on makes multiple applications and services available to the user over the network without the user having to provide credentials (typically, user name and password) more than once.

Applications in your environment that are good candidates for replacing their current authentication and authorization methods with Active Directory Kerberos and LDAP include:

  • Commercial database products, such as Sybase and Oracle.

  • Commercial and open source Web servers (such as Microsoft Internet Information Services [IIS], and Apache), browsers, and applications.

  • Commercial and open source remote-access tools, such as Secure Shell (SSH) and Hummingbird Exceed.

You might also have custom applications in your environment that you want to modify so that they direct authentication and authorization requests to Active Directory. These applications might already use Kerberos, or might use both Kerberos and LDAP, which you could retire and use Active Directory instead. Alternatively, you could introduce Kerberos and LDAP capabilities to these applications by enabling them to use Active Directory.

Note   For information about adding or modifying applications that do not already support Kerberos and LDAP, see "Expanding Active Directory Kerberos and LDAP Functionality" later in this chapter.

Replacing Standard Tools Such as Telnet and FTP with Kerberized Versions

You can significantly increase security for remote access by implementing standard Kerberized versions of applications such as telnet, ftp, rlogin, rsh, and rcp. Kerberized versions of these tools are more secure than non-Kerberized versions, all of which transmit data over the network in clear text.

When you use a standard, non-Kerberized version of one of these tools in combination with one of the custom solutions in this volume that uses Kerberos with pluggable authentication modules (PAM) (which enables UNIX-based computers to authenticate against Active Directory), you are using Kerberos for authentication. However, with this method, you use the standard tool to open a non-Kerberized channel from the local client computer to the UNIX client computer (the destination computer) and then initiate the Kerberos session on the UNIX client computer. In this scenario, when a user logs on to a UNIX client computer remotely using one of these tools, the user's user name and password are sent from the user's initiating computer (that is, the local computer, which might be a Windows computer) to the UNIX client computer, and then the UNIX client computer uses this user name and password to make a request (via PAM) to the Kerberos Key Distribution Center (KDC) on the Active Directory server to request a Kerberos ticket-granting ticket (TGT) from the KDC.

If the user name and password are correct, a TGT is returned to the UNIX client and stored in the credentials cache on the UNIX client. Establishing this connection is transparent to the user.

Because the Kerberos authentication attempt is not initiated until the request reaches the UNIX client computer, the user name and password, and any data, might be sent in clear text from the initiating computer to the UNIX client computer.

For this reason, we recommend using SSH (which provides an encrypted channel for communication with or without the use of Kerberos) or using Kerberized versions of these tools in a production environment. By replacing the standard tools with Kerberized versions, you prevent the user’s password from being sent over the network and you allow for encryption of the data channel using Kerberos.

For more information about Kerberized versions of remote access tools, see:

  • "Kerberized Tools" later in this chapter.

  • The descriptions of non-Kerberized versus Kerberized tools in "Use Non-Kerberized UNIX Tools for Base Functionality Testing" and "Switching to Kerberized Remote Access Tools for Extended Testing" in Volume 2: Chapter 5, "Stabilizing a Custom Solution."

Implementing DNS for Kerberos KDC Lookups

The instructions provided for developing the custom solutions described in this volume do not cover implementing Domain Name System (DNS) lookups for Kerberos. Instead, Active Directory servers that handle authentication are specified in the Kerberos configuration file, krb5.conf, that is used to configure Kerberos client functionality on a UNIX client. You can provide for automatic Kerberos load balancing similar to that used by Windows by implementing DNS lookups. This will eliminate the need to specify KDCs in the krb5.conf file.

Note   It is not currently possible to configure DNS lookups for LDAP. Therefore, the custom End State 2 solutions will continue to require that you manually provide for load balancing by specifying individual Active Directory servers in the LDAP configuration files.

Adding or Modifying Password Change Tools

Users can use the standard UNIX Kerberos password change tool, kpasswd, to change their passwords. In a large enterprise, managing password changes through the use of this tool individually on each UNIX-based computer can be difficult. If you have an existing enterprise password management tool, consider integrating password changes for UNIX users into it or redirecting it to Active Directory.

If you do not have an enterprise password management tool or the existing tool is not appropriate for your UNIX-to-Windows interoperability solution, implementation options include:

  • Commercial password management or identity management solutions that support Active Directory.

  • A custom application that uses the MIT Kerberos libraries for password change against Active Directory.

  • A custom tool or script that uses kpasswd for Active Directory password changes. Such a tool could be designed to also use the native passwd tool for local password changes as well. This would allow both local and Active Directory users to change their passwords using the same tool.

Adding or Modifying User-Provisioning Tools

The solutions described in this volume use the Active Directory Users and Computers snap-in tool to manage UNIX user data. For End State 2, the solutions use a tool such as Active Directory Service Interfaces Edit (ADSI Edit) to manage UNIX group membership. In an enterprise environment, use of these tools—especially ADSI Edit—does not scale well. You will probably find it necessary to modify an existing user-provisioning tool or implement a new one to support management of UNIX users and, for End State 2, UNIX user attribute data in Active Directory.

If you do not have an enterprise user-provisioning tool or the existing tool is not appropriate for your UNIX-to-Windows interoperability solution, implementation options include:

  • Commercial user provisioning solutions that support Active Directory. You might need to customize some of these solutions to include the UNIX attributes.

  • A custom application that uses the MIT Kerberos libraries for password management and LDAP libraries for user attribute management (for both End States 1 and 2).

Expanding Active Directory Kerberos and LDAP Functionality

Implementing one of the custom UNIX-to-Windows interoperability solutions described in this volume opens the door to extending the strong security and simplified and centralized directory storage offered by Kerberos and LDAP throughout your enterprise. For example:

  • Kerberos. Kerberos includes a number of technical capabilities that enable you to use your solution in new ways. One important example is single sign-on—the capability that lets a user log on once and then access network resources without being repeatedly prompted for user name and password.

  • LDAP. An LDAP directory store contains a very large number of discrete items of information about users, groups, computers, and other network entities. Using the Active Directory LDAP store to store this information lets you use Active Directory to support a wide variety of applications.

The following subsections describe some of the ways that you can extend your solution to include Kerberos single sign-on and to expand your use of the Active Directory LDAP store.

Implement or Expand Kerberos Single Sign-on Functionality

Single sign-on and credential delegation (also known as credential or ticket forwarding) allow you to access Kerberized applications not only on the computer on which a user acquires the Kerberos credentials by logging on but also on other computers in the enterprise or through multitiered applications. When an authenticated user attempts to access a network resource (and if the user is authorized to access that resource), the user can connect to the network resource without being prompted again for user name and password.

Credential delegation can be helpful, for instance, with database applications. For example, in recent years the need for sophisticated auditing has increased as a result of regulations such as those in the Sarbanes-Oxley (SOX) Act in the United States or the EU Data Protection Directive in the European Union. One way to achieve such a sophisticated level of auditing with a database application is to use Kerberos to authenticate users to the database. By using Kerberos credential delegation, the user can authenticate to a Web application, which then delegates the user’s authentication to the back-end database.

Using Kerberized Tools

Using Kerberized versions of standard remote access tools, such as telnet, ftp, rlogin, rsh, rcp, and ssh, greatly increases security for remote access in your environment and allows you to use single sign-on for this access.

Examples of Kerberized versions of these tools include:

  • PuTTY. The extensions to the PuTTY SSH product by Certified Security Solutions (CSS) allow for the use of Kerberized ssh from a Windows desktop to a UNIX-based computer. For more information, see the Certified Security Solutions page at http://www.css-security.com, click Downloads, and then click PuTTY with GSSAPI and Kerberos v0.56b2.

  • OpenSSH. The open source Open SSH package is included in many Linux distributions or can be installed separately on most UNIX platforms. For more information, see http://www.openssh.org.

    OpenSSH is also available with the cygwin tools that let you port UNIX applications to Windows without extensive changes to the source code. In addition to enabling porting, the cygwin environment and tools are useful without porting any software or compiling any code. For more information, see http://cygwin.com.

    OpenSSH tools are available for Windows Services for UNIX from Interop Systems. For more information, see the Interop Systems page "UNIX Tools for Windows" at http://www.interopsystems.com. Interop Systems also offers a commercial secure shell product for Windows.

  • FileZilla. The ftp tool FileZilla supports Kerberos. For more information, see http://sourceforge.net/projects/filezilla.

  • Native telnet , ftp , and r’utils. Almost all UNIX and Linux platforms have native versions of telnet, ftp, and the remote tools rlogin, rsh, and rcp. These tools are collectively known as the r'utils. In most cases, the UNIX and Linux platforms also include versions of the r'utils that support Kerberos. Many of these tools will interoperate successfully with Active Directory using Kerberos. For more information, see the man (manual) pages of the UNIX or Linux platform.

    Older versions of these platforms might not offer such tools or the tools might not be fully compatible with Active Directory.

  • Open source telnet , ftp , and r’utils. Open source MIT Kerberos includes Kerberized versions of telnet, ftp, and r’utils. Information about MIT Kerberos is available at http://web.mit.edu/Kerberos.

  • Open source telnet , ftp , and r’utils for Windows. Open source MIT Kerberos for Windows (a separate package from the standard MIT Kerberos package) includes Kerberized versions of telnet, ftp, and r’utils. Information about MIT Kerberos for Windows is available at http://web.mit.edu/kerberos/kfw-3.0/kfw-3.0/relnotes.html.

Note   The preceding list is not exhaustive. Some of the products and services listed previously might not work with Active Directory or they might not work in your particular environment. For a brief description of Kerberized tools versus non-Kerberized tools, see "Use Non-Kerberized UNIX Tools for Base Functionality Testing" and "Switching to Kerberized Remote Access Tools for Extended Testing" in Volume 2: Chapter 5, "Stabilizing a Custom Solution.”

Using Commercial Kerberized Applications

Commercial Kerberized applications support Kerberos authentication and thus allow single sign-on to those applications. Commercial Kerberized applications are available from many companies, including:

Open Source Kerberized Applications

Open source applications that support Kerberos authentication and Kerberos single sign-on include:

Web Applications

Several browsers, Web servers, and Web-based applications provide support for single sign-on using Kerberos. In most cases, this is accomplished through the use of the HTTP Negotiate Protocol. The HTTP Negotiate Protocol uses Simple and Protected Negotiate (SPNEGO) to negotiate the security protocol to use for the connection.

In Microsoft Internet Information Services (IIS), when you enable Integrated Windows Authentication, you are enabling the HTTP Negotiate Protocol. With Integrated Windows Authentication, the browser tries to use the current user's credentials from a domain logon, and, if the user is logged on to the local computer as a domain user, the user does not have to authenticate again when the user accesses a network computer in that domain. You must use Microsoft Internet Explorer 2.0 or later as your Web browser if you are using Integrated Windows Authentication.

Note   For more information about using the Negotiate Protocol and SPNEGO to provide Web-based integrated authentication, see HTTP-Based Cross-Platform Authentication via the Negotiate Protocol, available at http://msdn.microsoft.com/library/en-us/dnsecure/html/http-sso-1.asp.

Browsers, Web servers, and Web-based applications that support single sign-on include the following:

Operating Systems

Most recent versions of UNIX and Linux operating systems, as well as recent versions of Windows and Macintosh operating systems, contain some native support for Kerberos. Examples of operating systems that include Kerberos support include:

  • Sun Microsystems Solaris 8 or later.

  • Linux (most, if not all, current Linux distributions include support for Kerberos).

  • Hewlett-Packard HP-UX 11.0 or later.

  • IBM AIX 5.1 or later.

CAUTION   Not all operating systems that support Kerberos are fully interoperable with Active Directory. Check with the operating system vendor to determine if Active Directory interoperability is supported.

Kerberizing Your Applications

An application is considered Kerberized when it implements Kerberos for authentication. Kerberizing custom applications can offer a number of significant benefits, including:

  • Strong authentication. Applications that incorporate strong authentication allow the identities of networked users, clients, and servers to be verified without transmitting passwords over the network.

  • Mutual authentication. Mutual authentication is an optional feature in a Kerberos application and adds increased security to a Kerberos transaction by requiring both that the client (typically a user) prove its identity to the server and that the server prove its identity to the client.

  • Single sign-on. True single sign-on occurs when the user authenticates once and is then able to access all systems and applications on the network that the user is authorized to access. In a corporate setting, the user typically logs on to the computer once and is not prompted for authentication again when accessing any application.

  • Integrity and privacy. Kerberizing an application can allow it to use Kerberos credentials to implement protection of the data communications of that application. The protection is normally implemented using the Generic Security Services Application Programming Interface (GSSAPI) to provide data integrity and encryption (confidentiality).

Depending on the application, incorporating Kerberos authentication can be a relatively straightforward or a somewhat complex process. Kerberos can be incorporated into an application either at the library level or, more commonly, through the GSSAPI. On Windows, the GSSAPI is implemented as part of the Security Support Provider Interface (SSPI). GSSAPI toolkits are available in many UNIX operating system distributions and in open source as part of the MIT Kerberos project.

For more information, see:

Accessing Authorization Data Embedded in Kerberos Tickets

In some cases, you might also want to access the authorization data that is embedded in some Kerberos tickets obtained from Active Directory. Unlike most other Kerberos implementations, Active Directory includes authorization data in the Kerberos authorization field in a structure known as the Windows Privilege Attribute Certificate (PAC). Most UNIX applications do not understand the PAC data included in Kerberos credentials obtained from Active Directory. When you Kerberize your own application, you have the option to make use of this data.

For more information, see:

Using SPNEGO with Kerberos

Many applications that implement GSSAPI also implement the SPNEGO protocol to negotiate the use of Kerberos. This is very common with Web applications and Web services. You might find it useful to integrate SPNEGO support into your application.

For more information, see:

Expand LDAP Directory Store Usage

LDAP is the standard protocol that clients use to retrieve information from directory servers. If you have deployed an End State 2 solution that enables Active Directory LDAP to support UNIX clients, possible approaches to extending your use of Active Directory LDAP include expanding the use of directory-enabled applications and migrating application information into Active Directory.

You can now store in Active Directory information about employees, computers, printers, conference rooms, customers, or anything else typically stored in a directory. This information can now be centrally managed, and it might be possible to eliminate redundant data stores. After implementing one of the End State 2 solutions described in this volume, both your Windows-based and UNIX-based computers can securely connect to the Active Directory LDAP server and can access any information stored there to which you grant them access.

Three approaches for expanding the use of Active Directory as an enterprise LDAP directory are:

  • Expanding the use of directory-enabled applications.

  • Migrating applications from another directory to Active Directory LDAP.

  • Migrating applications from stand-alone storage to Active Directory LDAP.

Although centralizing your authorization and directory information in a central store is typically advantageous, this might not be the best approach in all cases. Some applications might require extensive schema changes to the LDAP directory, and you might not want to do extensive schema changes. In other cases, adding a large amount of application-specific information to your central directory might also be viewed as undesirable.

Expanding the Use of Directory-enabled Applications

As you deploy new applications or expand the use of your existing applications, you might investigate applications that can use LDAP as a data store. By using Active Directory LDAP as the central data store, you might be able to greatly simplify the management of data storage as well as user provisioning.

A small selection of the large number of applications that support Active Directory LDAP (as well as other forms of LDAP), include:

Migrating Applications from Another Directory to Active Directory LDAP

You might have applications that are already using a directory service other than Active Directory. In this case, you can investigate migrating the directory information into Active Directory and having the application use Active Directory as its LDAP server. This might allow you to retire the existing directory server.

Migrating Applications from Stand-alone Storage to Active Directory LDAP

This approach applies differently to applications that are developed in-house than it does to commercial applications. With applications developed in-house, you have the option of adding the capability of using an LDAP directory. Many commercial applications can be configured to either use a stand-alone data store or to use an LDAP data store.

In both instances, you can determine the feasibility of this approach by evaluating the migration effort required, potential benefits, and Active Directory compatibility.

Other Considerations

When you investigate deploying or expanding one of the End State 1 or End State 2 solutions described in this volume, you might find it useful to consider using one or more of the Microsoft products described in the following subsections.

Using MOM for Management

You might consider using Microsoft Operations Manager (MOM) to monitor and manage your systems. MOM includes an Active Directory management pack. Alternatively, you can custom-develop your own management packs. You might be able to use management packs that already exist for your other systems, including your UNIX-based computers.

Information is available at:

Using MIIS for Synchronization

If you cannot consolidate all of your authentication systems, authorization systems, and directories into Active Directory, the best approach might be to synchronize the information with other systems by using Microsoft Identity Integration Server (MIIS).

Information is available at the Microsoft Identity Integration Server Web site at http://go.microsoft.com/fwlink/?LinkId=17568.

Using ADFS for Federation

In cases where you are unable or unwilling to consolidate or synchronize your authentication and authorization information in Active Directory but want to enable users to interoperate with your infrastructure, you can investigate using federation. Active Directory Federation Service (ADFS), which is available in Windows Server 2003 Release 2 (R2), enables the simplified, secure sharing of digital identities across security boundaries. ADFS implements the WS-Federation standard specification that enables environments that do not use the Windows identity model to federate with Windows environments, including allowing users from separate infrastructures to authenticate to applications.

Information is available in the white paper "Active Directory Federation Services: A Path to Federated Identity and Access Management" at http://download.microsoft.com/download/3/a/f/3af89d13-4ef4-42bb-aaa3-95e06721b062/ADFS.doc.

Potential Issues

Some or all of the options for evolving your UNIX-to-Windows interoperability solution described in this chapter might not be compatible with the solution that you deploy. In some cases, it might be possible to work around incompatibilities, or you might choose to accept a reduced level of service in exchange for the added benefits of the solution.

Problems that you might encounter while trying to extend the solution in your environment include:

  • Unsupported encryption types. Kerberized applications might support a different set of encryption types than the set of encryption types supported by Active Directory. Active Directory supports DES-CRC, DES-MD5, and RC4-HMAC. Of these, RC4-HMAC is the most secure and DES-CRC is the least secure. If the application does not include a supported encryption type, or if the application does not allow you to specify the encryption type to use, you might not be able to use Active Directory Kerberos for the application. Many applications support DES-MD5 and DES-CRC but not RC4-HMAC. If this is the case, to be able to use the application, you will need to accept the lower level of security provided by the older DES encryption types.

    Note   Microsoft does not recommend the use DES-CRC because it provides weaker security than DES-MD5 or RC4-HMAC. Use DES-CRC only if no other option is available.

  • LDAP versions. Applications might be implemented with an LDAP version that is not compatible with Active Directory. Active Directory implements LDAP version 3 (LDAP v3). To use the application, it might be necessary to acquire a new version that supports the new LDAP version or to modify the application to add support for LDAP v3.

  • LDAP referrals. LDAP referrals are used in a multidomain environment to redirect LDAP queries for data to alternative servers if the data is not found on the first server contacted. Use of referrals can lead to slow response times, which can lead to performance degradation. Information about LDAP referrals in Active Directory is available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/referrals.asp.

  • Attribute handling. Some implementations of LDAP, especially native implementations on older versions of UNIX operating systems, might include attribute types or attribute handling methods that are incompatible with the Active Directory implementation. In some cases, it might be possible to introduce a translation layer between the older LDAP implementation and Active Directory to work around this issue by using open source LDAP tools.

  • Incompatible PAM modules. Some implementations of Kerberos for PAM might include pam_krb5 libraries that are not compatible with Active Directory. For example, this might occur if the library was built with a version of Kerberos that does not interoperate with Active Directory or if the library uses encryption types that are not compatible with Active Directory.

  • Incompatible PAM implementations. The concept of PAM is a fairly new one and not all implementations of the model conform fully to the standard. For example, AIX operating system versions prior to 5.3 implemented this concept in their proprietary loadable authentication modules (LAM), which were used to make calls to PAM modules. This solution is not fully compatible with Active Directory, making native AIX interoperability with Active Directory for authentication and authorization unworkable with these older versions of AIX.

  • Kerberos versions. Active Directory uses Kerberos version 5. This is the current standard and is supported by many Kerberized applications. However, some older Kerberized applications might support only Kerberos version 4, making them incompatible with Active Directory Kerberos.

Download

Get the Windows Security and Directory Services for UNIX Guide

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions

Considera isto útil?
(1500 caracteres restantes)
Obrigado pelos seus comentários
Mostrar:
© 2014 Microsoft. Todos os direitos reservados.