XPe tip #34: Domain Security Key

What is the Domain Secret Key that many times was mentioned in the newsgroup and even required a special fix for EWF to make persistent the key in domain environment? Going forward quickly want to mention the EWF fix - Registry Filter that allow to make some registry keys persistent with EWF enabled and protecting system volume including registry hives.

I am actually not sure who came up with the name "Domain Secret Key". Perhaps, XPe product guys :-) Domain Secret Key is in fact nothing more but the machine's computer account password in a domain. Basically machines - PCs in the network - can be made members of groups just like users can. They log in to the domain just as users do by proving knowledge of their master key, which each machine that is a member of a domain stores in its registry.

So where does Windows store that key? That is very easy to find out (Web Search or the Registry Filter component's script) - [HKLM\Security\Policy\Secrets\$MACHINE.ACC]. If you want to explore that key, run the registry editor as LocalSystem account (the easiest way to do this is from an administrative command prompt; type "at time /interactive regedit.exe", substituting whatever time is appropriate: make it one minute in the future, or use atnow.exe tool I posted the info about in an earlier blog post). Once regedit fires up, carefully look at the subkeys under [HKLM\Security\Policy\Secrets]. In this very key Windows stores a lot of secrets that need to be kept in plaint text for further usage, including service account passwords. You're looking at the machine's password cache, aka LSA private data store, and if the machine is a domain participant, you should see a subkey called $MACHINE.ACC, where the machine's master key lives in.

Why Registry Filter was requested? Specifically to fix the Domain Secret Key issue (and one more key issue irrelevant to this post). In domain environment the default policy is to change the computer account password every 30 days. If EWF is enabled, after 30 days you may end up with the device not being able to logon to the same domain it has joined to. So the Domain Secret Key needs to be made persistent in registry to avoid password age issues in domain environment.

EWF Registry Filter creates and initializes a file-backed ramdisk used. On that ramdisk it stores files that contain the selected key contents. The secret policy protection key file is named MacAcc.rgf.

Below is just my idea on how things could be fixed if no Registry Filter was acceptable.

Using device's Local Security Policies you can change the password age:
[HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters],"MaximumPasswordAge"=dword: (default 30 days)

You can also disable the password change completely:
[HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters],"DisablePasswordChange"=dword:1
Or refuse to domain controller's change of the computer password:
[HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters],"RefusePasswordChange"=dword:1
Corresponding local security policies are:
Domain Member: Maximum machine account password age (MaximumPasswordAge)
Domain Member: Disable machine account password changes (DisablePasswordChange)
Domain Controller: Refuse machine account password changes (RefusePasswordChange)

You can see them if you launch gpedit.msc (Group Policy Editor) and go to Local Computer Policy-->Computer Configuration-->Windows Settings-->Security Settings-->Local Policies-->Security Options.

I think in domain environment those policies are getting pushed to clients from domain controller. So a domain admin can always change those on the server side before turning on the policy on multiple clients.

Some more info you can find in the following MS KB articles: KB175468 - Effects of machine account replication on a domain, KB154501 - How to disable automatic machine account password changes, TechNet article about MaximumPasswordAge.