70-240 in 15 minutes a week: Kerberos and Active Directory Replication

Welcome to article number 18 in my 70-240 in 15 minutes a week series.
This week’s article covers Kerberos, as well as Active Directory
replication. This includes a look at how Kerberos functions in a
single and multiple domain environments, and how replication
occurs both within and between sites. Next week’s article will
be the final article in the Active Directory portion of the
series, with a deeper look at maintaining the AD database,
managing operations masters, and Remote Installation Services.
The following week will begin the first of approximately eight
articles to cover the Networking Services material. 

The material to be covered in this article includes:

Kerberos v.5
Active Directory Replication
This week’s article covers Kerberos, as well as Active Directory replication. This includes a look at how Kerberos functions in a single and multiple domain environments, and how replication occurs both within and between sites.

A quick note for those who don’t yet know
– the Win2000Trainer.com website no longer exists. It has been
replaced by my new partnership, 2000Trainers.com.
Be sure to check out the expanded content, which now includes
SQL and Exchange 2000 content as well. Thanks to everyone who
supported Win2000Trainer.com.

Kerberos v.5

Windows 2000 Active Directory relies on a different
authentication protocol than Windows NT 4. Where NT 4 used the
NT Lan Manager (NTLM) protocol for authentication, Windows 2000
utilizes Kerberos. The Kerberos protocol was developed at MIT,
and is named after Cerebus, the three-headed fire-breathing dog
that guards the gate to Hades. Why do I bother telling you this?
Because it makes it easier to remember that Kerberos is a
3-pronged authentication scheme. The three parts of Kerberos
are:

1.Client – the system/user making the request
2.Server – the system that offers a service to systems whose
identity can be confirmed
3.Key Distribution Center (KDC) – the third-party intermediary
between the client and the server, who vouches for the identity
of a client. In a Windows 2000 environment, the KDC in a domain
controller running Active Directory (It could be a UNIX-based
KDC also)

The way that Kerberos works can seem a little intimidating if
you get into all of the tiny little details, but I’ll spare them
for an overview of how things work. It is more important that
you understand the process to begin with. If you want every
behind-the-scenes detail, I’ve provided a link at the end of the
section.

In a Kerberos environment a user provides a username, password,
and domain name (often referred to as a Realm in Kerberos lingo)
that they wish to log on to. This information is sent to a KDC,
who authenticate the user. If the user is valid, they are
presented with something called a ticket-granting ticket, or TGT.
I like to consider the TGT to be like a hand-stamp admission to
a country fair – it proves that you have paid admission and
have proof. The TGT is helpful in that it does not require you
to constantly re-authenticate every time you need to access a
server.

However, if you do want to access a server, you still require a
ticket for that server or you will not be able to create a
session with that machine. Think of a ticket as being like the
ticket you need to purchase to get on rides at the country fair
– even though you’ve paid admission (proved by the hand-stamp
or TGT), you still need a ticket to get into the haunted house.
When you wish to access a server, you first need to go to the
KDC, present your TGT as proof of identity, and then request a
session ticket for the server you wish to contact. This ticket
simply acts as authentication between the client and the server
you wish to contact. If you are authenticated, whether or not
you will be able to actually access anything on the server will
depend on your permissions. The TGT and session tickets that you
are presented with actually expire after a period of time that
is configurable via group policy. The default value for a TGT
(also referred to as a user ticket) is 7 days, while the default
value for a session ticket (sometimes called a service ticket)
is 10 hours. 

In a single-domain environment, Kerberos authentication is
pretty straightforward. However in a multiple domain environment
Kerberos has more steps involved. The reason for this is that
when you are attempting to obtain a session ticket for a server,
it must be obtained from a KDC in the domain where the server
exists. Also, you must obtain session tickets in order to
traverse the trust-path to the KDC you need to contact. The
example below outlines the steps necessary for a client in
west.win2000trainer.com to access a server in
east.win2000trainer.com.

1.The client logs on to the network as a user in
east.win2000trainer.com, and is presented with a TGT.
2.The client wants to communicate with a server in
west.win2000trainer.com. It contacts the KDC in
east.win2000trainer.com, asking for a session ticket for a KDC
in the win2000trainer.com domain. 
3.After it receives this ticket, it contacts the KDC in
win2000trainer.com, requesting a session ticket for the KDC in
west.win2000trainer.com. 
4.After it receives this ticket, it contacts the KDC in
west.win2000trainer.com, and requests a session ticket for the
server in west.win2000trainer.com whom it originally wanted to
contact. 
5.Once granted the session ticket for the server, the client
contacts that server directly and can access resources according
to the permissions in place.

If this seems like a great deal of steps, that is indeed true.
This is one of the reasons that you might consider implementing
shortcut trusts, as outlined in my last article. If shortcut
trusts exist, the shorter available path would be used. Kerberos
is a wonderful protocol in that is makes the network much more
secure, due to the necessity of authentication between clients
and servers before a session can be established. It is actually
much faster than you might think. For a good hands-on
experiment, you might consider setting up multiple domains and
then running network monitor while accessing resources between
domains. Though the packets contents are encrypted, it will
still give you a great idea of what is happening behind the
scenes. Three utilities that you should be aware of for
troubleshooting Kerberos problems are Netdom (discussed in a
previous article), as well as the resource kit utilities
KerbTray.exe and Llist.exe.

For a great piece of reading on Kerberos, click
here 
For the Kerberos V5 RFC, click
here