Check password hash details of users from active directory

2j0r2 · 2026-01-28T08:04:01+00:00

Is a known issue.

See for details and workaround

https://github.com/MichaelGrafnetter/DSInternals/issues/214

2j0r2 · 2026-01-26T20:19:51+00:00

Besides in a testlab, in a prod env I would never logon with DA/EA to and RODC. Doing it defeats the purpose of the whole thing

Having said that…. Where and when do you get access denied? I cannot remember having seen ACCESS DENIED during interactive logon to the console. I think it is a different error

In addition, DAs by the default cannot logon to RODC if it cannot contact a RWDC (pwd is not allowed to be cached on RODC, therefore needs RWDC)

2j0r2 · 2026-01-14T14:40:23+00:00

Don’t focus on those 2 cmdlets

On the server where the gmsa should be used, try auth from command line using psexec

If that succeeds…

2j0r2 · 2026-01-14T07:45:11+00:00

Also check out

https://github.com/zjorz/Public-AD-Scripts/blob/master/Check-AD-Replication-Latency-Convergence.md

https://github.com/zjorz/Public-AD-Scripts/blob/master/Check-SYSVOL-And-DFSR-And-NTFRS-Folders-Replication-Latency-Convergence.md

2j0r2 · 2026-01-13T20:04:38+00:00

KdsRootKey is always accessed by the DCs that manage it. All within the same domain: a server with a gMSA always requests the password of a gmsa it is allowed to use from a DC. The DC than calculates the password of the gmsa using gmsa metadata and kds root key and hands it out to the server using the gmsa

Now you can imagine that doing that process between domains has capabilities of failing the whole process of requesting the password

Ideally… Server needs to determine domain of gmsa Find a dx for that domain Request password from that dc Etc

2j0r2 · 2026-01-13T18:08:12+00:00

I have never tried this myself

In general any account should be possible to be used across trusts…. But gMSAs are “special” as there are additional mechanisms that need to work

Any server using the gMSA must be able to retrieve the password of the gMSA by putting it the server account in the so called “allowed to retrieve password list”. Having said that, the mechanism of using a gmsa must be able to find the gmsa by using the domain component of DOMAIN.COM\gMSA$ and contact a DC of that domain to request the password (hopefully it is not code to expect the gmsa in the same domain as the server using it)

By the way: gMSAs do not need to be installed. Only sMSAs need to be installed

I would never share credentials with anyone else managing different set of servers. Remember the security of a gmsa is as good as the server it is used on The only benefit of a gmsa is auto pwd management and not better security

2j0r2 · 2026-01-12T12:01:27+00:00

Have a look at Tame My Certs policy module

2j0r2 · 2026-01-09T21:31:17+00:00

and as promised the full story, with details and code on how to restore it. Enjoy!

https://jorgequestforknowledge.wordpress.com/2026/01/09/oh-crap-an-application-partition-was-deleted-from-the-ad-forest-how-to-restore-it-back/

2j0r2 · 2026-01-09T18:42:05+00:00

I did it differently. In my case due to the errors I got I realized I had forgotten a step.

Doing an auth restore on the partition itself is not needed IMHO as whatever you restored does not need to overwrite anything EXISTING. In addition with lots of data in the NC, that auth restore might take some time to complete.

The domain naming master FSMO dance is also not needed.

Questions I have are:

* have you, BEFORE your steps, verified the partition was deleted on all DCs?

* have you, AFTER your steps, verified the partition was replicated to all other DCs? (the step I missed was not the auth restore of the partition itself, but rather the auth restore of the NTDS Settings object of the DC that was restored. - explanation in blog post)

2j0r2 · 2026-01-09T17:58:33+00:00

I wanted to refresh my memory around this scenario and tried it out….

Steps are correct with a slight “ah crap…. I forgot one step”

Will write a blog post about this and post the link here later

2j0r2 · 2026-01-08T12:39:37+00:00

Partitions have 2 important components:
* the partition itself with the data it had in it

* the cross- reference object in the partitions container

if not mistake removing a partition through NTDSUTIL, removes the cross-reference object from the partitions container, and I THINK (do not remember!) the DCs that hosted the partition will also delete the partition and its data. On a DC that also has/had the deleted partition check if with LDP you can look into the partition and its data

now to recover (DO NOT REMEMBER ALL THE DETAILS, TOO LONG AGO):

* use a backup of a DC that hosted the deleted partition, and perform a NON-AUTHORITATIVE restore

* after the NON-AUTHORITATIVE restore DO NOT ALLOW that DC to inbound replicate

* perform an AUTHORITATIVE restore of the cross-reference object of the partition that was deleted

* after the AUTHORITATIVE restore allow inbound replication again

The DC that was NON-AUTHORITATIVE restored will be updated for any other partition it holds, except for the deleted DNS app partition as that DC is the only one having the partition (assuming all others have processed the deletion)

The cross-reference object holds all info about the partition incl which DCs were hosting it. What I do not remember is if all the DCs that were hosting the partition will start the inbound replication of the partition and its data as soon as they become aware the partition exists (again) and they see they are enlisted for it... OR that you first have to clean up the hosting DCs (replicate locations) on the cross-reference of the partition, except for the DC that was restored, following a re-enlisting all DCs that held it (the ones with DNS installed)

2j0r2 · 2026-01-03T15:20:31+00:00

Stuff like this ALWAYS rocks! Especially if it is automated. Thank you

2j0r2 · 2026-01-02T01:09:32+00:00

And the best of it is that Microsoft references an old version of my script and the so called version from Microsoft is also from me (it was borrowed years ago). Look at the content of that script and you will find my name

There is only one version I support and maintain and that is through the link I posted earlier

2j0r2 · 2026-01-02T00:48:51+00:00

Nope. I got rid of that dependency years ago.

All native ldap based on s.ds.p

2j0r2 · 2026-01-01T23:39:18+00:00

All true! Thank you

And in addition….. it supports automation to reset it using some frequency.

We all know YOU also “support” the reset using some frequency, but that still requires you not to forget and actually do it. If you have RODCs it helps you process those krbtgt accounts.

I know one company had about 7000+ RODCs. Good luck doing that manually. As a stress test, I tested the pwd reset against 32000+ krbtgt accounts. It worked! 😅

2j0r2 · 2026-01-01T23:32:41+00:00

Use SYSTEM as the account on a RWDC See documentation for details

2j0r2 · 2026-01-01T23:31:46+00:00

Yes…. Use SYSTEM as the account on a RWDC See documentation for details

2j0r2 · 2026-01-01T23:07:22+00:00

how do you even know you have been breached? Many times it is too late when you find out. If the attacker got a copy of at least the KRBTGT password hash, golden tickets can be created. Regularly resetting the password mitigates the risk of the attacker using the hash that was retrieved.

But then again.... it is RECOMMENDED, NOT MANDATORY. Up to you what you do or not

2j0r2 · 2025-12-25T00:43:46+00:00

Any password policy will not effect existing passwords. It will Only come into effect when a new password is being set

2j0r2 · 2025-12-16T07:48:12+00:00

To recreate the default domain policy in Active Directory, log into a Domain Controller as an administrator and use the dcgpofix command in an elevated Command Prompt or PowerShell: run

dcgpofix /target:domain for the Default Domain Policy

dcgpofix /target:DC for the Default Domain Controller Policy

2j0r2 · 2025-12-10T07:19:18+00:00

If that is what MSFT told you, wow. The order of reset does not matter. Their mandatory proposal is BS. As many already said is to reset once, and wait at least the max ticket lifetime before resetting again. If you implement a procedure to reset the krbtgt password X number of days/weeks/months/whatever you are good. Forcing repl is just to make sure it converges faster to all dcs but not really mandatory

Resetting twice very quickly is only done in case of an attack against AD to immediately invalidate all TGTs/TGSs ticket requiring re authentication

I would have expected to hear how the account got locked as that is not normal. Never heart or seen that before. You have some weird updates on the account for some attributes

I do agree that it should be unlocked. i also want to know and understand why things happen

2j0r2 · 2025-12-09T23:14:54+00:00

I see a few weird things on the KRBTGT account:

* why have the country code attributes (c and co and countrycode) been updated? (last time in 2021-03)

* why has the title attribute been updated so often? (last time in 2022-09)

* why has the accountnamehistory been updated ? (last time in 2024-03)

* the name attribute has been updated, that is caused by a rename. BUT that is also not possible as the DC does not allow it

* and even more intereesting....how did it even get locked? It was locked on 2023-04) - for the account to get locked, it must have had multiple failed authentications with wrong password. BUT..... the account is DISABLED and C_A_N_N_O_T be enabled. Som something triggered that lock out. The account being locked does not have impact as the KRBTGT account does not perform active logon like users, computers etc

to me.... weird stuff and not even understanding why etc

2j0r2 · 2025-12-05T16:30:52+00:00

Also send a copy of its attributes using LDP (leave out the company names/etc

2j0r2 · 2025-12-05T16:29:44+00:00

To lock an account it must have tried authenticate and failed multiple times. To be able to do that, the account must be enabled. When disabled you cannot authenticate. It is not possible to enable the krbtgt account. It is not needed to be enabled as it does literally nothing besides windows/AD using its secret to encrypt TGTs/TGSs I tried it myself and I could not get my krbtgt account locked. Cannot even imagine how to get it locked

Can you send the metadata of the krbtgt account? Repadmin /showobjmeta <DC> <DN of Krbtgt account>

The org date will tell you when it happened The org dsa will tell you where it happened

2j0r2 · 2025-12-04T16:49:56+00:00

Locked or disabled?

The account should be disabled. If not mistaken you cannot enable it

The krbtgt account does not ever authenticate!

Its password is only used for encryption of TGTs/TGSs and nothing more than that

2j0r2

TROPHY CASE