it-admin

As most of you are aware, Windows 2000 includes a new authentication package, which is Microsoft's implementation of MIT's Kerberos protocol. This protocol is much more secure than NTLM and NTLMv2. And with that, I'm going to show you how a client logon happens with Kerberos.

Bob comes into work in the morning, grabs his coffee, and sits down at his workstation. He looks at the Windows 2000 professional logon at the logon screen, hits ctrl+alt+del, and proceeds to type his username, password, and after being authenticated by a Windows 2000 domain controller, logs onto his domain. He starts Microsoft Outlook, to take a look at this morning's pile of email. This seems like a simple process, but that's far from the truth.

Let's take a look at what happened in the past few seconds. Domain Logon Authentication When Bob pressed "Enter" after typing his password, the Kerberos client on his workstation converted his password to an encryption key. Kerberos is based on the concept of symmetric encryption keys, which means that the same key is used to encrypt and decrypt a message. This is also referred to as a shared private key. After the Kerberos client converted Bob's password to an encryption key, it's saved in the workstation's credential cache.

The workstation then sent an authentication request to the Domain Controller, or KDC (Key Distribution Center is a Kerberos term, used to describe the service that distributes the "keys to the kingdom"). The authentication request identifies Bob, and names the service that he's requesting access to, and some pre-authentication data, that proves that Bob knows the password.

The first portion of the authentication request identifies Bob, and asks for access to the TGS(Ticket Granting Service). The TGS is the service on the KDC that issues tickets for access to other services. All of the services within the Kerberos domain trust the TGS, so they know if a ticket was issued by the TGS, that the user successfully authenticated (him/her) self, and is really who he claims to be.

The second part of the authentication request contains the pre-authentication data, and is a generic timestamp, encrypted with Bob's long-term key (or password in this case) When the KDC receives the authentication request, it checks the local AD database for Bob's password. Decrypts the pre-authentication info that was sent in the package, and if the timestamp is within the permissible guidelines (allowable clock difference, usually of 5 minutes or so), sends Bob a TGT (Ticket Granting Ticket) that he's going to use to access the TGS in the future.

But even this process isn't so simple (Kerberos is much more complicated than NTLM). To accomplish this task, the KDC creates a session key for itself and Bob to use in their future communications, then it encrypts that session key with Bob's password, and embeds another copy of the session key and some authorization info about Bob (This authorization info is the list of Bob's SID's (SID history, group membership, and Bob's own SID) which is used where ACL's are applied.). It encrypts all of this with it's own long-term key. (The portion that was encrypted with the KDC's long-term key is the actual TGT) The Kerberos implementation in Windows 2000 places the SIDS in the TGT in a field that is defined as optional in the RFC's, which Win2k uses for access control information, which extends Kerberos from not only authentication, but a piece of the access control puzzle as well. When Bob's workstation receives a reply from the KDC, it decrypts the session ticket with Bob's password, and stores this in the credentials cache. This is the authentication info that Bob's workstation will use to communicate with the KDC from now on, the next time Bob logs on, the session ticket will be completely different, as the KDC doesn't reuse it's session keys. The workstation also extracts the TGT, which will still be encrypted with the KDC's long-term key, (which Bob's workstation doesn't know) and stores the encrypted TGT in it's credentials cache.

"What does all of this have to do with the way I access resources?" you might ask. I'm going to give you a bonus, here's how resource access works in the same domain, with the user being authenticated by Kerberos. Authentication works a bit differently when you are traversing trusts. I will show you that process in an upcoming article.

Resource Access Authentication Since Bob was authenticated by the KDC, he received a TGT, which allows him to request access to other resources. Since Bob needs to access the word doc reports.doc on the FILESERV1 fileserver, he's going to request access to FILESERV1. Bob might be opening the document from the recent documents menu, or browsing for it in Windows Explorer, however Bob is opening the file, is irrelevant. The Kerberos client performs all authentication in the background, without any user intervention. Below is a detailed process of the entire negotiation.

First Bob's workstation sends a message to the domain controller that granted it's TGT. The message is a Ticket Granting Service Request, that includes Bob's username, the authenticator, the TGT that was sent back to Bob's workstation during the logon, and the name of the service that Bob is requesting access to. (In this case it's FILESERV1) When the KDC receives the message from Bob's workstation, it decrypts the TGT portion of the message, with it's own private long-term key, and pulls out the session key that it embedded during the logon session. It uses the session key to decrypt the authenticator section of the message. If everything checks out OK, it creates a session key for Bob to utilize when talking to FILESERV1.

The KDC now constructs a message to Bob in 2 parts.

The first part is the actual session key for Bob to use when talking to the FILESERV1 file server, which is then encrypted in Bob's logon session key.

The second part is the session key that Bob is going to use to talk to the FILESERV1 server, but it's encrypted in FILESERV1's long-term key. This message is sent to Bob's workstation. When Bob's machine gets this message, it decrypts the first part of the message and saves the session key for FILESERV1 in it's credentials cache. Then, it pulls the second portion of the message out (which is encrypted in FILESERV1's long term key, which by the way, Bob's workstation does not know the key by which it was encrypted) and also stores it in it's credentials cache.

Now Bob's workstation is going to access the FILESERV1 server. Bob's machine sends FILESERV1 a Kerberos App Request, which sends the has in it an authenticator encrypted in the session key that the KDC gave to Bob to use when talking to FILESERV1, and the encrypted ticket that the KDC gave to Bob, which is the Bob-FILESERV1 session key, encrypted in FILESERV1's long-term key, that the KDC stores in the Database.
When FILESERV1 receives this message, FILESERV1 decrypts the ticket with it's own long-term key, and is able to read the session key that the KDC gave to Bob for use with FILESERV1. It then decrypts the rest of Bob's message with the session key, viola', an authenticated session is established.

I know this seems extremely complicated, but in relative terms of authentication, it's a simple, and secure process. I'm more than satisfied with Microsoft's implementation of Kerberos in Windows 2000, I think it's a long needed building block for a secure OS. We won't see full benefit of Kerberos, until all of our clients are Win2k, since AD servers still support the old NTLM, and NTLM2 authentication protocols, but I think that day is coming soon.... There is another set of events that occurs after this exchange, that set of events refers to access control, I'll also explain that in another article.

The SASL/GSS mechanism supported by the LDAP server is used to securely access the directory. Using SASL/GSS and LDAP does not help authenticate a user so he/she can use an application which then presents the users identity to another application components in a secure manner - this is one of the many requirements for application security which Kerberos is idealy suited.I think we need to compare the LDAP directory and Kerberos protocol in order to answer the original question asked. Admitedly, if SASL/GSS is used to securely access a directory so that a password can be read and compared, then LDAP can be used to authenticate a user.I have provided a short list of some differences, not necessarily a complete list so maybe others on this email discussion can add comments and think of other important differences ?LDAP server for user authentication- can be used to store password + other information about users.- useful for simple user authentication requirements where checking of password is all that is required.Kerberos for user authentication- uses security credentials which have a lifetime - LDAP does not have this capability- built in prevention from network replay attacks and protect against other network security concerns - LDAP does not protect against these issues- removes the need to pass any form of password across a network - LDAP requires password transmission- A protocol that alows support for userid/password, token card, smart card authentication and other forms of user authentication - LDAP is only suited to userid/password- works well in a client/server and multi-tier environment especially when using credential delegation or impersonation- can be used to setup a security context between application components on the network - LDAP cannot be used for this.- provide mutual authentication, integrity, confidentiality services - LDAP does not do any of these- makes single signon easy, especially since Microsoft Active Directory does the Kerberos authentication when a user logs onto a MS network- works well in a heterogeneous environment- supported and utilised by a growing number of application vendors and standards- a strategic protocol in many ways because of having many uses - it can even be used very effectively to allow an unattended application to authenticate itself to another application (e.g. ftp -> ftpd).

One of the big benefits of Active Directory over the "flat" domain structure of Windows NT 4 (and earlier) domains is that objects can be stored in a hierarchical folder-like structure. In earlier domains, however, at least you knew where all of the objects were - they were in one big long list - no searching for them, just scrolling (and scrolling, and scrolling). In Active Directory, objects can be stored down in several layers of Organizational Units (OUs). So how does Active Directory keep track of where these objects are? It uses LDAP (Lightweight Directory Access Protocol) naming paths. These naming paths can take three forms: Distinguished Names, Relative Distinguished Names and Canonical Names.
Distinguished NamesEach AD object has a distinguished name - and no, that doesn't mean they are called "Sir" or "Madam." By distinguished, we mean that the name itself distinguishes the exact location of the object in the directory. There are several notations that are used in the distinguished name:

DC
Domain Component
Part of the DNS name of the domain such as COM or EDU
OU
Organizational Unit
One of the containers in AD that holds other objects
CN
Common Name
Objects in AD, such as users, computers, printers, etc.
These components can be used more than once in a distinguished name, if necessary, to accurately name the path to the object. For instance, the user Fred Jones in Accounts Receivable, in Accounting at My Company might have a distinguished name like this:
CN=Fred Jones,OU=AR,OU=Accounting,DC=mycompany,DC=com
In this example, you can see that there are two OU components, and to DC components.

Relative Distinguished NamesThe Relative Distinguished Name is simply the portion of the Distinguished Name that uniquely identifies an object within the object's parent container. For instance, Fred's Relative Distinguished Name from the example above, would be:
CD=Fred Jones
Keep in mind that the user Fred Jones in the Shipping department might also have the exact same Relative Distinguished Name, though his Distinguished name would, of course, indicate that his account was in a different OU.

Canonical NamesThere is a third naming path that Microsoft sometimes refers to. This is just a different way of displaying the distinguished name (that is easier to read), and looks like this:
mycompany.com/Accounting/AR/Fred Jones
It not only removes the notation for the Distinguished Name (e.g.: DC=) it is also the reverse order of the Distinguished Name.

Understanding that all resources in Active Directory are represented by objects, and that all objects have attributes, we can now understand that the schema contains the definitions for all these objects and attributes. Put another way, the schema is the rules that govern what objects can be in the directory, and what attributes those objects can have.
An Active Directory forest can have only one schema, and all domains in that forest share the same schema. This ensures that all objects in the forest conform to the same set of rules. The schema can be changed, or extended, to include new definitions. The schema is protected from unauthorized changes by permissions, similar to other Active Directory objects.
The schema is made up of two things: object classes, and attributes.
Object Classes:We know that there are objects represented in Active Directory, such as the user "Bob," or the printer "Accounting." These objects are examples of the object classes "User" or "Printer." Every object that can be created in AD is an example of a object class. So one of the things that the schema is made up of is a list of all of the possible object classes. Every new object that is created must belong to an object class in this list.
Attributes:A list of all of the possible attributes for object classes is the second part of the schema. These attributes are defined just once in this list, but can be used in multiple object classes. For instance, the attribute "Location" may be used for the object classes of both printers and computers, but it is defined only once in the schema. By defined, we mean that it is given a unique name, as well as a syntax. The syntax tells what data type the attribute is. The schema keeps track of which attributes are used with each object class, so that when a new object of the class "User" is created, it will have all of the same attributes as all the other user objects (full name, telephone, etc.).
The schema itself is actually stored inside Active Directory, as opposed to being read in from a text file, as is common with some databases or directories. According to Microsoft, this has three advantages:
The schema is dynamically available to user applications, so they can read it and discover what object classes and attributes are available for use.
The schema is dynamically updateable, so that an application can extend the schema (add object classes and attributes) "on the fly."
The schema can be protected using DACLs (discretionary access control lists), enabling only authorized users to make schema changes.
The schema can be a challenging concept to understand. Fortunately, it is rarely necessary for changes to be made, and users must have the appropriate permissions to make those changes. For more in-depth information on the schema, particularly regarding extending the schema, look to the Windows 2000 Server Resource Kit books (specifically the Distributed Systems Guide).

So far we've briefly touched on Active Directory in general, and the benefits of using it, but what does it really do? In simplest terms, Active Directory is really just a database of information about Objects. In Active Directory, every resource is represented as an object. This includes real physical objects, such as printers, computers, servers, etc., as well as logical, or virtual (cyber?) objects, such as users, groups, sites, domains, etc. No matter what it is, if it goes in Active Directory, it is pretty much an object.
Furthermore, each object that resides in AD has properties, or attributes. These attributes are different depending on the type of object. For instance, user objects have such attributes as "First Name" or "Zip Code" or "Title" to name only a few. Computer objects, on the other hand, have such attributes as "Role" or "Description" or "Location." Objects can and do have hundreds of attributes, some of which can be manipulated or changed, and some of which are assigned by the system. One of the handy things about an object's attributes is that you can search on them. For instance, if you are looking for a nearby printer, you can search on the location attribute for printer objects.
The tool used most commonly for working with AD objects is the Active Directory Users and Computers tool. You can view or modify the attributes of many objects in this tool by simply right-clicking an object and choosing Properties (or by simply double-clicking the object in most cases). Of course, what you can do with an object, including simply viewing its attributes, depends on the permissions that you have to the object.
Since all resources in the network are represented in AD as objects in a centralized database, these resources can easily be administered from a central location (or locations), and by a single or multiple administrators

So far we've pointed out that Active Directory is a complex networking technology that requires planning in intimate detail in order to work properly when implemented. So why bother? What benefit does AD bring that would make it worth the trouble? The answer, of course, is that "it depends." However, even in a small and simple network, the benefits can outweigh the costs of design and implementation.
ScalabilityOne of the most apparent advantages to using Active Directory over using either NT4 Domains or a Workgroup model is that Active Directory can accommodate size. In a workgroup environment, a user account with password has to exist on each computer with shared resources. If you have three servers and ten users, that means creating thirty user accounts total, and each user would have to remember or synchronize three passwords each. AD also overcomes the limitations and work-arounds for large enterprises using NT4 domains. Active Directory domains can contain many more groups and users, rendering the Account domains, and Resource domains from NT4 obsolete.
Organization - MacroActive Directory is tied tightly to the DNS structure, and follows the DNS hierarchy for domains. In this way a large company can organize its domains similar to the business structure. If a business has operations in several different regions of the world, it can organize the domain along those lines: europe.domain.com, australia.domain.com, asia.domain.com, etc. Active Directory introduces the concept of the "forest" of domain trees, which share certain things in common, but remain separate domains for administrative purposes.
Organization - MicroActive Directory is created hierarchically, allowing for better organization and ease of use at the resource level, too. No longer are all of the users and groups organized in a single list, as in User Manager for NT4 Domains. Sub-containers, called Organizational Units (OUs) can be created, so that, for instance, all of the user, groups, printers, etc., for a single geographic location can be placed together, making them easier to find and administer.
Centralized Management/ControlWith a single set of management tools, the entire Directory can be managed from a single location. AD also allows for much more granular delegation of rights, so that certain administrative tasks can be delegated, while still retaining a secure environment.
Single Sign-onActive Directory brings us that much closer to the administrator's dream of single sign-on for users. This means only one login name to remember, one password to remember and change, and so on. As more applications become AD-enabled, this dream becomes a reality. Imagine, for instance, when an accountant leaves the company, disabling a single AD account, rather than disabling the NT domain account, the AP/AR software account, the Payroll software account, etc.
Ultimately, you and/or your company will have to evaluate the risks versus the rewards of implementing Active Directory in your computing environment, but in most cases, I believe it will be a step forward.

Active Directory: you can't buy it, you can't touch or hold it, and yet most Windows 2000-based networks rely on it to function properly. So what exactly is Active Directory? It's a simple question, but the answer becomes more complex the more you discuss it. In simplest terms, Active Directory is a service (or group of services) that runs on Windows 2000 servers. More specifically, you could say that Active Directory is a "directory service" for Windows 2000. This service is used to store and organize information about the network and the resources that are available on the network. More importantly, Active Directory can be used to control access to network resources.
Microsoft refers to Active Directory as the way to "provide a consistent way to name, describe, locate, access, manage, and secure information about resources" on a Windows 2000 network.
Directory services are not a new concept: Novell's NDS instantly comes to mind when thinking about directories, as well as DNS, and even Microsoft Exchange has had its own directory for years.
If you are familiar with Windows NT (3.x & 4.x) domains, you will be able to appreciate the features that Active Directory brings to a Windows network. Active Directory brings a hierarchical structure to the domain concept of earlier versions of NT. In comparison, it's like using a single pile of lose papers on your desk as a way of organizing your work (NT domains), compared to placing those loose papers in labeled hanging folders in a filing cabinet (Active Directory).
As much as Active Directory adds in functionality, organization and user experience, it also adds much more complexity in design, implementation and support. Planning was important when implementing an NT 4 domain; it is imperative when implementing Active Directory.
Over the next few features, we will begin looking at some of the benefits of using Active Directory, as well as some of the properties of Active Directory, best practices for implementing it, technologies that it depends on (e.g.: DNS), and technologies that depend on it (e.g.: Group Policy).