A: The Kerberos authentication protocol uses session
tickets that are encrypted with a symmetric key derived from the
password of the server or service to which a Windows user requests
access. To request a session ticket, the user must present a special
ticket, called the ticket-granting ticket (TGT) to the Kerberos Key
Distribution Center (KDC) service on a domain controller (DC). All
Windows users get a TGT from the KDC at the start of their Windows login
session after they successfully authenticate to the KDC by using their
password.
The KDC encrypts a user's TGT with a key it derives from the password
of the krbtgt AD domain account. The krbtgt account and its password
are shared between the KDC services of all DCs in a domain. The krbtgt
account is automatically created as part of the dcpromo AD installation
process on the first DC in a domain. It shows up in the Users container
of the Microsoft Management Console (MMC) Active Directory Users and
Computers snap-in and is disabled by default. Unlike other AD user
accounts, the krbtgt account can't be used to log on interactively to
the domain. Because it's a built-in account, krbtgt also can't be
renamed.
A read-only domain controller (RODC) is a new type of DC that
Microsoft introduced in Windows Server 2008. An RODC hosts read-only
partitions of the AD database. It doesn't store the password hashes of
all user accounts in a Windows domain; instead, an RODC stores only the
password hashes of the accounts that are defined in the RODC's Password
Replication Policy (PRP). This method means that the compromise of an
RODC represents much less risk than the compromise of a classic
read/write DC (RWDC) that holds copies of the password hashes of all
user accounts in a domain. That's why an RODC can be deployed in a way
that might be considered less secure. Organizations typically deploy
them in branch offices or in their demilitarized zones (DMZs).
An RODC acts as a Kerberos KDC for a branch office or DMZ, and as
such it also requires a krbtgt account. To ensure that the krbtgt of a
compromised RODC can't be leveraged to request tickets to other RODCs or
RWDCs, each RODC has a special local krbtgt account. This account has
the format krbtgt123, where "123" is a string of random numbers. This
random string uniquely identifies the RODC and is generated when an RODC
is installed.
The different local krbtgt accounts of the RODCs in a domain are
stored in AD and show up in Active Directory Users and Computers under
the Users container. All RWDCs in the domain also keep a copy of the
password hashes of the krbtgt accounts of the RODCs in the domain.
Therefore, a TGT that's issued by an RODC is valid for requesting
session tickets against the same RODC and also against any other RWDC in
the domain.
If an RODC receives a session ticket request that's based on a TGT
that isn't valid -- meaning that the TGT wasn't issued by the RODC
itself -- it returns a Kerberos error asking the client computer to
request a new TGT request against the RODC itself. If the RODC doesn't
have a copy of the user's password hash, the RODC forwards the TGT
request to a RWDC. In this case, the RODC acts as a proxy, whereby it
forwards the answer from the RWDC directly to the client computer. At
the same time, the RODC triggers the process of caching the user
password hash so that the RODC will be able to create a TGT for that
particular user in the future. The caching succeeds if the RODC's PRP
allows the user account's password hash to be cached on the RODC.
Original Post:
