The KRBTGT account is a user account which resides inside the domain users container in every Active Directory domain. This service account is critical and is required by the Kerberos Key Distribution Centre (KDC).
This account must never be deleted.
This account must never be renamed.
Before reading this post, I hope you have an understanding of how the Kerberos authentication protocol works. If not I encourage you to watch the following video entitled "How Kerberos Works" by Don Jones, a CBT Nuggets instructor. This can be found on the following link:
https://www.youtube.com/watch?v=kp5d8Yv3-0c
From watching this video you will understand that all users and devices on a network must be assigned a Ticket Granting Ticket (TGT) from the KDC which then enables them the ability to access resources on the network.
The KRBTGT account is critical to this process as the KDC uses the password derived from the KRBTGT account to encrypt each TGT assigned to users and devices on the network. All KDC servers on the network have the KRBTGT account password because all domain controllers have this account. The KRBTGT account is created upon the promotion of the first domain controller in a new Active Directory domain.
If you haven't already guessed, KRBTGT stands for "Kerberos Ticket Generating Ticket Account".
Read Only Domain Controllers
There are a few things to be aware of with the KRBTGT account when dealing with Read Only Domain Controllers. RODC's also act as a KDC for branch offices and as a result require a KRBTGT account. However, RODC's do not contain the passwords of all accounts in an Active Directory domain, only passwords specified by an administrator defined in the Password Replication Policy (PRP) - for more information see http://technet.microsoft.com/en-us/library/cc730883.aspx
Now because the password associated with the KRBTGT account is so sensitive, we do not want this residing at branch sites as the whole point of an RODC is to implement it when physical security to the server is low. To ensure that the KRBTGT of a compromised RODC can't be leveraged to request tickets to other domain controllers, each RODC has a special local KRBTGT account. This account has the format KRBTGTXXX, where "XXX" is a string of random numbers. This random string uniquely identifies the RODC and is generated when an RODC is installed.
The accounts generated for each RODC appear in the users container on all Active Directory domain controllers in the domain. As a result all writeable domain controllers also keep a copy of the KRBTGT password hash.
Lastly, if an RODC receives a session ticket request based on a TGT that isn't valid, a Kerberos error will occur asking the client computer to request a new TGT. If the RODC does not have a copy of the users password hash, the RODC will forward the TGT request to a writable domain controller.
This account must never be deleted.
This account must never be renamed.
Before reading this post, I hope you have an understanding of how the Kerberos authentication protocol works. If not I encourage you to watch the following video entitled "How Kerberos Works" by Don Jones, a CBT Nuggets instructor. This can be found on the following link:
https://www.youtube.com/watch?v=kp5d8Yv3-0c
From watching this video you will understand that all users and devices on a network must be assigned a Ticket Granting Ticket (TGT) from the KDC which then enables them the ability to access resources on the network.
The KRBTGT account is critical to this process as the KDC uses the password derived from the KRBTGT account to encrypt each TGT assigned to users and devices on the network. All KDC servers on the network have the KRBTGT account password because all domain controllers have this account. The KRBTGT account is created upon the promotion of the first domain controller in a new Active Directory domain.
If you haven't already guessed, KRBTGT stands for "Kerberos Ticket Generating Ticket Account".
Read Only Domain Controllers
There are a few things to be aware of with the KRBTGT account when dealing with Read Only Domain Controllers. RODC's also act as a KDC for branch offices and as a result require a KRBTGT account. However, RODC's do not contain the passwords of all accounts in an Active Directory domain, only passwords specified by an administrator defined in the Password Replication Policy (PRP) - for more information see http://technet.microsoft.com/en-us/library/cc730883.aspx
Now because the password associated with the KRBTGT account is so sensitive, we do not want this residing at branch sites as the whole point of an RODC is to implement it when physical security to the server is low. To ensure that the KRBTGT of a compromised RODC can't be leveraged to request tickets to other domain controllers, each RODC has a special local KRBTGT account. This account has the format KRBTGTXXX, where "XXX" is a string of random numbers. This random string uniquely identifies the RODC and is generated when an RODC is installed.
The accounts generated for each RODC appear in the users container on all Active Directory domain controllers in the domain. As a result all writeable domain controllers also keep a copy of the KRBTGT password hash.
Lastly, if an RODC receives a session ticket request based on a TGT that isn't valid, a Kerberos error will occur asking the client computer to request a new TGT. If the RODC does not have a copy of the users password hash, the RODC will forward the TGT request to a writable domain controller.
We are the fastest growing organization in the present market and providing the technical support for the customers’ computers across the globe.
ReplyDeleteSystem performance is very slow/freezing/not responding Windows 7