Silent Operation and Command Line Parameters? about new-krbtgtkeys.ps1 HOT 7 CLOSED

@aakash-shah I just looked up gMSAs and I am a little shocked... Why isn't the KrbTgt account itself a gMSA? That would solve this problem entirely. Now I'm a little more surprised that MS hasn't dealt with this problem on their own. It should not be left for admins to come up with their own solutions when existing functionality could easily be used.

from new-krbtgtkeys.ps1.

@A9G-Data-Droid and @aakash-shah -
The reason that this is not done automatically already or using a gMSA is that there are configurations that an automated change would cause system-wide disruptions. Auth Policy Silo verification and Kerberos Armoring are two examples of cases that a change could require a system reboot to reestablish connectivity as a result of the KRBTGT account password changing. It was done as an extreme level of caution to have an administrator manually doing the change rather than an automated change take place that blocks access. While it is a low risk of impact, the risk is there and with the number of deployments worldwide it has to be taken as a blocker.

from new-krbtgtkeys.ps1.

@A9G-Data-Droid -
From the script standpoint, modifying this to run in a silent mode should be able to function correctly. You should probably have it exit gracefully if the last password change is less than the ticket lifetime when running non-interactively.

From a security standpoint, this would require a service account with Domain Admin privileges to execute. Modern advice is to avoid permanent assignment to highly privileged groups. Service accounts like this are prime targets in a privilege escalation attack since they often have static passwords and there is not a "real" person using the account to notice abuse. The account creates another attack vector for PTH/PTT exploitation. As I see it, the risks associated with the creation of a DA privileged service account to run the script far outweighs the convenience of automating the process through a script.

Another concern I see is that if there is an issue with the password change, any problems that arise from the change might not be correlated to this change immediately. It is not a very likely that an issue would occur, but this is core functionality that we are dealing with.

You could make the suggestion of a GPO setting to make this change to the Windows Server team at https://windowsserver.uservoice.com/forums/295047-general-feedback.

A question for you - I have not seen the recommendation of changing the password every 40 days, do you have a reference to a website with that?

from new-krbtgtkeys.ps1.

Thanks for the guidance @cchapin-ms . I will take your advice on exiting instead of forcing the change too early.

I agree that domain admin accounts can be dangerous. Maybe the service account could be enabled only to run the script and then disabled at the end to mitigate this risk.

The guidance to change every 40 days comes from PingCastle. They cite a French government document. I think the idea is that the golden ticket could be stolen from a full backup of a domain controller.
https://www.pingcastle.com/PingCastleFiles/ad_hc_rules_list.html

from new-krbtgtkeys.ps1.

The change could potentially be made using a gMSA which could be granted Domain Admin privileges. gMSAs have automatic protections, and will change it's password frequently like a computer account. I think having the option regardless will help for environments that would like to consider this. The risks can be detailed and each environment can choose to accept the risk.

This isn't 40 days, but here is a 6 month recommendation:
https://www.stigviewer.com/stig/windows_server_20122012_r2_domain_controller/2019-01-16/finding/V-91777

from new-krbtgtkeys.ps1.

I have a branch ready for testing.

https://github.com/A9G-Data-Droid/New-KrbtgtKeys.ps1/blob/AddParameters/New-KrbtgtKeys.ps1

from new-krbtgtkeys.ps1.

@A9G-Data-Droid Regarding the guidance from Ping Castle recommending 40 day maximum age. The guidance from the French documentation is actually that the password age for the account not exceeding 1 year. The 40 day reference comes from their guide on doing the reset. One of the methods suggests waiting 40 days before doing the second password change to allow replication to occur on all domain controllers. If replication is taking 40 days to converge, there are other issues besides changing the KRBTGT password that need to be addressed first. Ping Castle evidently took the delay period for the second password change to mean that the password age should not exceed 40 days. That is just an inference based on reading the documents in the link. The NIST recommendation of not exceeding 6 months is more frequent than the French guidance and is the shortest that I can find from a government or security organization (not a security vendor).
Of course these are the maximum age recommendations and following a shorter period based on internal processes is probably a better security stance.

from new-krbtgtkeys.ps1.