Had some fun with PDQ deploy/inventory credential decryption and wrote about it here: unsigned-sh0rt.net/posts/pdq_cr... thanks to
@dru1d.bsky.social for writing a BOF out of the POC

tl;dr get admin on PDQ box, decrypt privileged creds

#SCCM forest discovery accounts can be decrypted—even those for untrusted forests. If the site server is a managed client, all creds can be decrypted via Administration Service API.

Check out our latest blog post from @unsignedsh0rt.bsky.social to learn more. ghst.ly/4buoISp

Awesome new addition to krbrelayx by Hugow from Synacktiv: www.synacktiv.com/publications...

Claude.ai is so sick. I might actually fool people into believing I know how to code with this

It's not limited to just ADCLI either...ManageEngine is probably the most familiar or recognizable tool that does this. It's true microsoft fixed creating them in ADUC but hardly fixed things where third party tools are involved.

So what's happening? The tool before would create the computer object without a password and then set it to a default after the fact. Now, that password setting is blocked and the object persists...with no password.

But now, you get a failure as you cannot change the accounts password. However, it STILL creates the object.

I had a hunch though that behavior might not be true for third party tools and third-party tools were arguably the biggest cause of their existence across all the enviroments I've tested over the years. An example of this is the adcli command line tool. Before it would set with a default password.

Was doing some digging "What's New" in Server2025 learn.microsoft.com/en-us/window... specifically the changes to pre-2k machines. Oddvar and I had spoken previously about the changes being solid and demonstrated pre-created machines in ADUC could no longer be set with a default password.

Guess this is the place to be then