Mixing It Up: Mixing It Up: Windows, UNIX, And Active Directory

Article
09/07/2016

Cross-Platform Security

Mixing It Up: Windows, UNIX, And Active Directory

Peter Larsen and Jason Zions

At a Glance:

Overview of Kerberos 4 and 5
Transitioning from X.500 to LDAP
The LDAP model
Vintela Authentication Services for UNIX and Linux

UNIX

Windows

Active Directory

LDAP

Kerberos

As the world becomes more and more connected, a problem has emerged. How do organizations and partners store sensitive data in heterogeneous environments, and how do they verify the identity of users requesting the information on any platform?

Both end users and organizations look for three elements in their security solutions: confidentiality, integrity, and availability. When a user is authenticated, the process can employ any number of methods from passwords (informational) to smartcards (object-based) to biometrics, or ideally, some combination of these techniques. When you are supporting a site that employs a mixture of Windows®, UNIX, and Linux servers, you can support all of these elements and methods by choosing Kerberos and LDAP as your protocols of choice.

Directory Services and Identity Management

Active Directory® in Windows Server™ 2003 provides a foundation for identity management, which covers information relating to individuals. Identity management includes the management of computer user accounts, the contact details of those user accounts, door entry system user accounts, application user accounts, e-mail system user addresses and accounts, and more.

Identity management solves the problems of maintaining this information. Information on individuals is stored in one place and administered in a consistent manner. The LDAP standard discussed later defines a directory service that can be used as the basis for identity management solutions.

Overview of Kerberos 4

The Kerberos protocol is a standard designed to provide strong authentication within a client/server network environment. Kerberos network messages are encrypted and decrypted using algorithms that translate the Kerberos data into a form that is very difficult to decode into its original form. A secret encryption key is used to encrypt and decrypt the data. Kerberos also uses mathematical techniques called hashes to ensure the integrity of any data that is not encrypted.

Kerberos 4 contains a number of terms and ideas that are important to know.

Principals All entities within Kerberos, including users, computers, and services, are known as principals. Principal names are unique; a hierarchical naming structure ensures their uniqueness.

Realms The principal is a member of a realm. By convention, a realm name is the DNS name converted to uppercase, so that the example.com domain becomes the EXAMPLE.COM realm. Although uppercase realms are not obligatory, using a different case simplifies differentiating between domain names and realms.

Ticket A ticket is the fundamental unit of Kerberos authentication. It is a carefully constructed message containing the authentication information which is passed between computers.

Key Distribution Center The Key Distribution Center (KDC) is made up of three components: a database of principals containing users, computers, and services; an authentication server that issues Ticket Granting Tickets (TGT); and a Ticket Granting Service (TGS) that issues service tickets granting clients access to specific services.

Each realm requires at least one KDC to operate. Kerberos authentication relies on the use of tickets passed between the client, the KDC, and the required server to confirm authentication and authorization.

Figure 1 shows the exchanges that take place during authentication using the Kerberos protocol.

Figure 1 Authentication with Kerberos

Figure 1** Authentication with Kerberos **

Initially, a client contacts the authentication server component of the KDC, sending a request that contains the principal name, a timestamp, the lifetime of the ticket requested by the client, and the name of the TGS.

References

The full detailed guide "Microsoft Solution Guide for Windows Security and Directory Services for Unix" can be found on the TechNet Web site.

More information regarding object identifier trees (OIDs) can be found on the Internet Assigned Numbers Authority's Web site.

Look for the enterprise numbers entry under "E."

The following Requests for Comments (RFCs) describe the Lightweight Directory Access Protocol (LDAP), the representation of standard attributes within LDAP, and the relationship between LDAP and X.500, an international standard for providing online directory services:

RFC 1777, "Lightweight Directory Access Protocol"
RFC 1778, "The String Representation of Standard Attribute Syntaxes"
RFC 1779, "A String Representation of Distinguished Names"
RFC 2247, "Using Domains in LDAP/X.500 Distinguished Names"
RFC 2251, "Lightweight Directory Access Protocol (v3)"
RFC 2252, "Attribute Syntax Definitions"
RFC 2253, "UTF-8 String Representation of Distinguished Names"
RFC 2254, "A String Representation of LDAP Search Filters"
RFC 2255, "The LDAP URL Format"
RFC 2256, "A Summary of the X.500(96) User Schema for use with LDAPv3"

These RFCs describe the Kerberos protocol and the methods of using Kerberos through the Generic Security Service Application Programming Interface (GSS-API):

RFC 1510, "The Kerberos Network Authentication Service (Version 5)"
RFC 1964, "The Kerberos Version 5 GSS-API Mechanism"

All of these RFCs can be found at www.ietf.org/rfc.html.

In response, the authentication server generates a session key, and makes two copies of it: one for the client, the other for the TGS. The authentication server sends a TGT back to the client; this TGT contains a copy of the session key, the identity of the client, a timestamp, details of the IP address of the client, and of the ticket lifetime.

When returning the TGT to the client, the authentication server also returns a copy of the session key, the principal name of the TGS, and the lifetime of the ticket. This whole response to the client is encrypted using the client key.

The client receives the information in this encrypted reply, and is able to decrypt it because it was encrypted with the client's key. This gives the client its session key, as well as a TGT that is still encrypted by the key of the TGS.

The client now forwards the TGT to the ticket-granting server, along with a request for the service to be accessed and a timestamp encrypted with the session key obtained from the authentication server. This timestamp serves to prevent replay attacks, which occur when a request for a service from the client is captured by a hacker and resent at a later date. The TGS processes this request and responds with a new set of session keys, the principal name of the service requested, the lifetime of the ticket, and a service ticket encrypted with the service key.

The service ticket is similar to the TGT and contains a new session key, the principle name of the client, the ticket lifetime, a timestamp, and the client's IP address. All of this is then encrypted with the key of the client and sent.

The final stage of the authentication procedure differs depending on the service and server being requested. This is because each application defines its own methods for the exchange of the service ticket.

An example of a service is the Network File System (NFS). NFS allows for a host to access ("mount") directories that are held on a remote server. This access can be controlled by Kerberos.

Kerberos 5 is an extension of Kerberos 4. It contains all of the functionality of the earlier version, plus many enhancements. These include support for credential forwarding, multiple encryption types, renewable tickets, and preauthentication. Kerberos 5 is the default method of network authentication for services and applications in Windows Server 2003.

A large number of distributions of the Kerberos protocol are available, both commercial and open source. Most major UNIX distributions contain an implementation of Kerberos as part of a standard installation. There are two open source Kerberos 5 distributions, MIT and Heimdal; information about the Heimdal version is available at Heimdal.

MIT Kerberos is simple to compile across all platforms and works well with all other implementations. While precompiled versions are available for download from other sources, it is recommended that you download and verify the integrity of the source yourself to ensure the best security. MIT Kerberos is available for download from Kerberos: The Network Authentication Protocol.

Some countries have restrictions on the use of cryptography, so confirm that Kerberos is acceptable under your country's laws before implementing a Kerberos solution.

Transition from X.500 to LDAP

The LDAP standard is used for authentication and directory services, and has also evolved into a simple method of accessing X.500. The X.500 standard is designed to have one worldwide distributed directory with a standard access interface. It is extremely complex, as are the Open System Interconnection (OSI) network protocols over which it was designed to operate. In fact, OSI network protocols are far more complex than the more commonly used TCP/IP suite.

LDAPv3 is widely implemented as a part of operating systems, network operating systems, directory services, applications such as e-mail servers, and client applications. LDAPv3 is a core component of Windows Server 2003 Active Directory. The implementation of LDAPv3 found in Active Directory is fully integrated with a standards-compliant security system based on Kerberos and Microsoft® Windows.

Overview of the LDAP Directory Service

As a standard for a directory access protocol, LDAP defines the operations used to communicate with a directory service, how to refer to an entity in the directory, how to describe the attributes of an entity and, finally, the security features that can be used to authenticate to the directory and control access to the entities within the directory. LDAP is characterized by the following:

The protocol is carried directly over TCP for connection-oriented transport (receipt of data is acknowledged) and User Datagram Protocol (UDP) for connectionless transport (no acknowledgment upon sending or receiving data).
Most protocol data elements, such as distinguished names, can be encoded as ordinary strings.
Referrals to other servers can be returned to the client.
Simple Authentication and Security Layer (SASL) mechanisms can be used with LDAP in order to provide associated security services.
Attribute values and distinguished names can be internationalized through the use of the International Organization for Standardization (ISO) 10646 character set.
The protocol can be extended to support new operations, and controls can be used to extend existing operations.
The schema is then published through an attribute on the root object for use by the clients.

The component models defined in LDAP are the same as those defined in X.500, and are explained in the following sections.

The Information Model

The attributes and characteristics associated with an entry are defined in the entry's object classes. The definition of object classes and attributes, in turn, is held in the schema. The following are the three types of object class definitions that are used in LDAP directory servers:

Structural object class A structural object class represents a real-world object, such as a person. An entity must belong to one and only one structural object class.

Auxiliary object class An auxiliary object class is used to extend a structural object class. It has no meaning on its own.

Abstract object class The abstract object class is used only when it is an ancestor of a derived class.

The Naming Model

The naming model defines how each entry can be referenced. In an LDAP directory, entries are organized in a hierarchical tree called a Directory Information Tree (DIT). Each node in the tree is an entry that can store information, and also serve as a container for other entries. An entry in the tree can be referenced by using either its relative distinguished name (RDN) or its distinguished name (DN). An RDN is unique only within a particular directory; a DN is globally unique.

An RDN for an attribute might be the common name (cn) of an object, as you can see in this attribute:

cn="Michael Allen"

An RDN could also be made up of more than one attribute value when uniqueness cannot be ensured by simply using a single attribute. For example:

cn="Michael Allen"+ou="Engineering"

The plus (+) symbol in this example makes it clear that the RDN is multi-valued. The practicality of multi-valued RDNs is clear when your organization has two employees named Michael Allen. If they are in two different departments, they can have RDNs which are uniquely qualified by department, as defined in the example by the organization unit (ou) attribute. The DN for Michael Allen's entry might be:

cn="Michael Allen",dc="example",dc="com"

In this case, the object is uniquely defined in the local directory as well as globally. The domain component (dc) attribute values are used to uniquely define the DNS domain name of the directory server.

In LDAP, the naming context for a directory can be defined in either a geographical or a domain name format. The geographical format was the primary method of locating a directory in X.500, and is still used with LDAP servers. However, it is common to use the domain name of an LDAP server as its naming context because domain names are globally unique on the Internet.

Figure 2 Naming

Figure 2** Naming **

In Figure 2, the naming context of the directory server is the domain name example.com, or the DN dc=example, dc=com. The DN uses ou="Users" instead of cn="Users". In this case cn and ou are interchangeable because the common name of an organizational unit is identical to the name of the organizational unit.

The Functional Model

The functional model is the method by which a directory client can communicate with the directory; this role is filled by the LDAP protocol itself. LDAP provides the following operations:

Interrogation: searching the directory
Modification: updating, adding, or deleting entries in the directory
Authentication and control: authenticating to the directory (also known as the bind operation)

The Security Model

The security model provides methods for authenticating against the directory and for authorizing client access control to the directory. There are two components to the security model: authentication using LDAP binds and the control of any access to objects in the directory.

We'll cover the details of authentication to LDAP a little later in the article, but once the client is authenticated, it can use the LDAP directory only as defined by the directory's Access Control Lists (ACLs). The use of ACLs in an LDAP directory is implementation-dependent.

The LDAP Interchange Format

LDAP directories can exchange data and schema definitions using a standard notation called the LDAP Interchange Format (LDIF). LDIF has a simple text file format that consists of the following:

Entries separated by blank lines representing a single entity
Comments beginning with the pound character (#)
Assignments of values to attributes
Directives that instruct the LDIF parser on how to interpret the entries

An LDIF file showing the definition of a person entity is shown in the following example. This LDIF file could be used to create the entity in an LDAP directory:

# This is a comment
dn: cn=Michael Allen,cn=Users,dc=example,dc=com
objectClass: person
cn: Michael Allen
sn: Reid
telephoneNumber: 555-0100

The last line is a blank line. This file defines an entity with the DN:

cn=Michael Allen,cn=Users,dc=example,dc=com

The entry is a member of object class person, which contains attributes such as the common name (cn) of a person, a person's surname (sn), and a person's telephone number (telephoneNumber).

Using LDAP for Network Authentication

LDAP authentication involves an entity binding to the LDAP server. The success of the bind operation is determined by the acceptance or rejection of the entity's credentials. If the bind is successful, the entity is authenticated; if it is unsuccessful, the entity is not authenticated.

In order for LDAP to be used for UNIX and Linux login or service authentication, it needs to be coupled with the LDAP Pluggable Authentication Module (PAM).

Unlike Kerberos, which is designed as an authentication mechanism, LDAP authentication is designed specifically for securing directory transactions. Using LDAP authentication for purposes other than LDAP directory access can lead to performance problems. This is because LDAP directory services are not designed to handle large numbers of authentication requests, but are instead tuned to perform well when handling directory transactions.

Microsoft Active Directory

Active Directory is an essential and inseparable part of the network architecture that improves on the domain architecture of the Windows NT® 4.0 operating system to provide a directory service designed for distributed networking environments. Introduced in Windows 2000, Active Directory is an integral part of Windows Server 2003.

Active Directory is built around the Kerberos 5 and LDAPv3 protocols and, as such, is compatible with Kerberos 5 clients and LDAPv3 clients across all platforms. This allows Windows Active Directory servers to provide security and directory services in a heterogeneous network.

Figure 3 Active Directory

Figure 3** Active Directory **

Combined, these technologies enable organizations to apply standardized business rules to distributed applications and network resources without requiring administrators to maintain a variety of specialized directories. An overview of Active Directory is shown in Figure 3.

Vintela Authentication Services

As with Active Directory, UNIX and Linux systems typically include their own implementations of both Kerberos and LDAP. Although these implementations can interoperate with Active Directory, they are typically done without considering the way that Microsoft has integrated the two standards in Active Directory.

Vintela Authentication Services (VAS) implements Kerberos and LDAP functionality on UNIX and Linux systems, and can fully integrate with Active Directory. The benefits of using VAS include the following:

You have the ability to manage UNIX and Linux users and computers are managed through the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in.
Kerberos is the protocol used to secure LDAP traffic.
Performance is tuned to work effectively with Active Directory.

The VAS product allows UNIX and Linux clients to operate within an Active Directory domain in a manner equivalent to Windows clients.

Summary

In this article, we've discussed the basic technologies necessary to achieve single sign-on between networked computers with a variety of operating systems. The detailed instructions on how to configure single sign-on between, say, Linux and Windows is detailed in the online guide listed in the references. The guide describes two methods of achieving single sign-on, one using open source code and the other using the commercially available Vintela product. With these new technologies in hand, you'll finally be able to deliver on the promise of information access any time, on any device and on any platform.

Peter Larsen is a software development engineer at Microsoft. Before joining Microsoft, Peter was involved in architecture and development of telecom operational software systems and standardization and development of wireless services.

Jason Zions is an architect at Microsoft. Previously he was the chief scientist for Softway Systems, where he led the development of Interix, which later became a part of Microsoft Services For UNIX. Jason has also been heavily involved in POSIX standardization.

This article is adapted from Microsoft Solution Guide for Windows Security and Directory Services for UNIX, available on the TechNet Web site.

Additional resources