Resetting the krbtgt account password

Explanation of the concept and differences between Microsoft-AD and Samba-AD

The krbtgt account is a security-critical account in the Active Directory domain. The hash of this account is used to sign Kerberos tickets exchanged with domain joined clients.

The compromise of the authentication secrets of the krbtgt account allows you to have control over all the resources of the domain. This account must be changed if the Active Directory account base is compromised.

It is recommended to change it regularly (e.g. every month or every two months). The ANSSI recommendation is currently every 40 days.

When changing the password of the krbtgt account, Microsoft-AD caches the old hash to ensure that the password change can be replicated to all domain controllers.

On a Microsoft-AD, it is therefore necessary to change the password of the krbtgt account twice to ensure security if the account has been compromised. The delay between the two password changes is important, because if it is too short, it can cause replication problems, if it is too long, it can give enough time to an attacker who has compromised the AD in the past to recover the new krbtgt account again.

Samba-AD does not currently implement N-1 hash retention for the krbtgt account (N-1 hash retention is only applied to machine accounts). This is not blocking in practice because if it is validated that replication has spread to all DCs immediately after the change, the domain controller accounts are still valid and therefore the replication tickets still work.

The fact that Samba-AD does not store N-1 hash means that Kerberos clients will be forced to negotiate a new TGT when they next request a ST. This is not a problem on Windows machines that keep the login credentials in memory in the lsass.exe process, so they can renew their TGT without any worries. The same is true for the Winbind processes on file servers. User accounts that are members of the Protected Users group will need to renew their TGT manually.

Warning

It is necessary to pay attention to the appliances which can behave differently from Windows workstations and servers with regard to the renewal of their TGT (longer renewal time, not automatic renewal, etc.). It can then be interesting to make a test beforehand.

In conclusion, in the case of Samba-AD, it is necessary to change the password of the krbtgt account only once to guarantee its confidentiality. On the other hand, when changing the password krbtgt, it is necessary to ensure that all the DCs are reachable and well replicated to guarantee a fast replication of the changes to all these DCs.

Getting the KRBTGT password change script

Samba provides a script in the source code to perform the password change. This one is currently not packaged in the RPM distributed by Tranquil IT. It can be retrieved in the tar.gz of the source code or in the git (take the version corresponding to your Samba release):

# Samba 4.18
wget https://gitlab.com/samba-team/samba/raw/v4-17-stable/source4/scripting/devel/chgkrbtgtpass
# Samba 4.19
wget https://gitlab.com/samba-team/samba/raw/v4-18-stable/source4/scripting/devel/chgkrbtgtpass
# Samba 4.19
wget https://gitlab.com/samba-team/samba/raw/v4-19-stable/source4/scripting/devel/chgkrbtgtpass

This file must be retrieved and copied to the domain controller with the PDC role.

Changing the KRBTGT password on a Samba-AD

It is preferable to do the password change on the machine that has the PDC role.

Before changing the password, check that the replication works with all DCs:
```
samba-tool drs replicate <remote_dc> <pdc_dc> dc=mydomain,dc=lan
```
Then run the script that was previously retrieved:
```
python3 chgkrbtgtpass
```
Ensure that the password has been updated by checking the last modification date:
```
pdbedit -Lv krbtgt
```
Then force replication across all DCs. In practice Samba-AD will send out notifications of changes to all DCs very quickly, and replication will probably have already taken place:
```
samba-tool drs replicate <remote_dc> <pdc_dc> dc=mydomain,dc=lan
```
Finally, check on the different DCs that the account replication went well:
```
pdbedit -Lv krbtgt
```