Enabling LAN Manager hash value store on next password change

2

I am talking about this
group policy
Can I somehow set this setting to "Disabled" from registry or using any sort of command? I do know that it's unsafe, but when compatibility (with DOS) is at stake I don't care. The result of my research was Method 2 from this support article, however it speaks of opposite from what I want to achieve, and the way to "invert" the registry key addition is unobvious for me. If it was about setting the (freshly created) NoLMHash value to 1 for example, I would guess setting it to 0. But in this case I'm puzzled

P.S. Bonus question: do you think resetting the pass with net user login pass will trigger the hash storage?

mekkanizer

Posted 2016-08-20T00:15:14.913

Reputation: 159

Answers

2

Yes, if you set that value to zero in the Registry, LM hash storage will be enabled. In fact, changing that security setting via the UI modifies that Registry value on the back end. For the convenience of future readers, here's the key where you should set NoLMHash to 0 if you want this behavior:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

Forcible password resets should have the same behavior as normal password changes with respect to hash storage, since the LSA has to update the Security Accounts Manager database either way.

Note that the Registry change may require a reboot before taking effect. Also, if a password is too long (>14 characters) to be LM-hashed, no LM hash will be stored for it no matter what your Registry says.

Ben N

Posted 2016-08-20T00:15:14.913

Reputation: 32 973

I created a .reg file from your answer, which also contained a change of LmCompatibilityLevel to 1, in the same key. I have applied it, confirmed that everything has been successfully added to registry, ran gpupdate /force and that net user commands to update policies & change password, rebooted, and guess what :(
The policies are both still undefined, even though the regedit tells me that changes have been made. Could it be some sort of lag? How do I become sure that it worked fine and will work in future?
– mekkanizer – 2016-08-22T22:27:26.850

@mekkanizer Are you on a domain? If so, the GUI might be looking at and editing the policy object (which is applied to the Registry as part of Group Policy processing) rather than the Registry itself. The LSA system only cares about the Registry value. – Ben N – 2016-08-22T22:32:43.080

Currently not. I'm tuning Windows in Virtualbox to prepare a disk image that will be deployed to POS systems which ARE in domain. Those settings' purpose is to make DOS machines in that domain accessible. So you're saying that I can disregard what GUI says while I have proper values in registry? – mekkanizer – 2016-08-22T22:58:12.913

1@mekkanizer On a domain, you can ignore the UI/policy object (as long as it's not set to the opposite). On non-domain-joined Windows 10 Pro for me, updating the Registry causes the UI to change. Make sure the entry is created as a REG_DWORD, not a string. Also, could you double-check that everything is in the right place and spelled correctly? – Ben N – 2016-08-22T23:01:57.690

You got it! It was REG_SZ, not REG_DWORD! So now I just remove those wrong keys and change "NoLMHash"="0" line to "NoLMHash"="dword:0" in my .reg file, run it again, run the commands, reboot and it's done? – mekkanizer – 2016-08-22T23:16:18.763

1@mekkanizer I can't recall the .reg syntax right now, but once the Registry value type is fixed, you should be good to go! – Ben N – 2016-08-22T23:16:56.717