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:
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:
No comments:
Post a Comment