iTechNote

Active Directory uses the Kerberos protocol and LDAP as follows:

• Active Directory uses the Kerberos protocol for authentication (by default).
• Active Directory uses LDAP for authorization (by default).
• Active Directory can use LDAP for authentication (optionally).

Because Active Directory, by default, uses the Kerberos v5 protocol for authentication and LDAP v3 for authorization, Active Directory is compatible with Kerberos v5 clients and LDAP v3 clients across all platforms, including UNIX and Linux. Together, Active Directory authentication and authorization can provide a strong, easy-to-administer security system for a mixed network.

The first key step in a comprehensive identity and access management strategy is to consolidate— to the greatest extent possible—divergent identity stores into a single, centralized store. Ideally, UNIX-based computers can use the same identity store as Windows—namely, Active Directory—for both authentication and authorization. Alternatively, UNIX-based computers can use Active Directory for authentication only.

There are five possible options for enabling interoperability between UNIX and Windows computers in a mixed network environment.

End State 1

End State 1 introduces the use of Active Directory as a Kerberos KDC to store authentication data for users on both UNIX and Windows computers. However, an End State 1 solution continues to rely on your existing UNIX-based source, such as the local /etc/passwd and /etc/group files, iPlanet, or NIS, to store authorization data for UNIX users.

Using Active Directory Kerberos authentication for both Windows and UNIX clients lets users log on securely to either UNIX or Windows hosts with a single user name and password. An authenticated UNIX user, like an authenticated Windows user, can access Kerberized applications (applications that use Kerberos for authentication) without being prompted again to provide a user name or password.

Consolidating Windows and UNIX authentication data storage in Active Directory eliminates the need for separate administration of authentication data on the UNIX side. However, typically, in an End State 1 solution, you cannot retire UNIX-based computers currently used for storing authentication data because in most cases these computers also store authorization data. LDAP, NIS, and /etc/passwd stores typically store not only passwords (authentication data) but also store UIDs and GIDs (authorization data). In addition, these computers might also be used for authentication by UNIX-based computers not included in the End State 1 solution.

End State 2

End State 2 introduces the use of Active Directory to store both authentication and authorization data for UNIX users, replacing existing UNIX-based authentication and authorization storage methods. With an End State 2 solution, authentication data for UNIX users is migrated to the Active Directory Kerberos KDC so that UNIX clients can authenticate to the Active Directory KDC. Authorization data for UNIX users is migrated to the Active Directory LDAP data store so that UNIX clients can use Active Directory LDAP for authorization. Using both Active Directory Kerberos and Active Directory LDAP enables UNIX clients to take full advantage of Windows authentication and authorization security mechanisms.

Storing UNIX authentication data in Active Directory allows users to log on securely to either UNIX or Windows hosts with a single user name and password. An authenticated UNIX user, like an authenticated Windows user, can access Kerberized applications without being prompted again to provide a user name or password.

Consolidating Windows and UNIX authentication and authorization data in Active Directory eliminates the need for separate administration of authentication and authorization data on the UNIX side. You can retire UNIX-based computers currently used for storing authentication and authorization data or reallocate them for other use.

End State 3

In End State 3, Windows clients continue to use the Kerberos KDC on Active Directory, which is the default Windows method for storing authentication data. However, in an End State 3 solution, UNIX clients do not use Active Directory Kerberos for authentication. Although Kerberos v5 is the default method used for authentication in an Active Directory–based network, it is also possible to use Active Directory LDAP for authentication, and End State 3 introduces the use of Active Directory LDAP to store authentication data for UNIX clients. End State 3 continues to rely on your existing UNIX-based source, such as the local etc/passwd and /etc/group files, iPlanet, or NIS, to store authorization data for UNIX clients.

Centralizing Windows and UNIX authentication data storage in Active Directory allows users to log on to either UNIX or Windows hosts with a single user name and password. However, with End State 3, users do not get the single sign-on benefits provided by Kerberos authentication for applications: Users logged on to UNIX clients must provide their user name and password each time they want to access a Kerberized application (or any application that requires authentication) because End State 3 uses LDAP instead of Kerberos for authentication.

Consolidating Windows and UNIX authentication data storage in Active Directory eliminates the need for separate administration of authentication data on the UNIX side. Typically, in an End State 3 solution, you cannot retire or reallocate UNIX-based computers currently used for authentication data storage for other use because, in most cases, these computers also store authorization data or are used for authentication by UNIX-based computers not included in the End State 3 solution.

End State 4

End State 4 introduces the use of Active Directory LDAP to store both authentication and authorization data for UNIX clients. End State 4 is similar to End State 2 in that both end states replace UNIX-based authentication and authorization methods with the use of Active Directory to provide both authentication and authorization for UNIX users. However, unlike End State 2, which uses Active Directory as a Kerberos KDC for authentication and Active Directory LDAP to handle authorization, End State 4 uses Active Directory LDAP for both authentication and authorization.

Centralizing Windows and UNIX authentication data storage in Active Directory allows users to log on to either UNIX or Windows hosts with a single user name and password. However, with End State 4, users do not get the single sign-on benefits provided by Kerberos authentication for applications: Users logged on to UNIX clients must provide their user name and password each time they want to access a Kerberized application (or any application that requires authentication) because End State 4 uses LDAP instead of Kerberos for authentication.
Consolidating Windows and UNIX authentication and authorization data in Active Directory eliminates the need for separate administration of authentication and authorization data on the UNIX side. You can retire UNIX-based computers currently used for storing authentication and authorization data or reallocate them for other use.

End State 5

End State 5, unlike End States 1–4, continues to use your existing UNIX and Windows infrastructures but establishes interoperability between UNIX-based Kerberos (such as MIT Kerberos) and Active Directory–based Kerberos by deploying a cross-realm trust. Windows clients and UNIX clients each authenticate to their own KDC and, if the trust is a two-way trust, are then trusted by workstations and servers hosting network resources on the other side.

UNIX users, when authenticated to the UNIX KDC, can access services (applications) in the Windows environment without having to reauthenticate. The Windows KDC trusts the UNIX KDC’s authentication credentials and so grants access to Windows services to UNIX users without reprompting the user for authentication. You can configure the trust to be one-way (the Windows KDC trusts the UNIX KDC but the UNIX KDC does not trust the Windows KDC, or vice versa) or two-way (each KDC trusts the other).

End State 5 requires minimal infrastructure modification yet enables both Windows users and UNIX users to access Kerberized applications in either environment without being prompted repeatedly for user name and password. With End State 5, authorization is not a factor, so you continue to use your existing UNIX-based authorization method for UNIX users.
End State 5 is appropriate for an organization with an existing UNIX-based Kerberos infrastructure where it is impractical or not possible to make extensive changes to that infrastructure.

via Microsoft TechNet