No LM Hash - no really

[Ian Boyd]

How do you REALLY disable the generation of Lan Manager password hashes.

i have set the group policy on the domain controller (Windows 2000), and
added to the domain controller's registry the NoLMHash = 1 DWORD.

Then i go to a workstation and reset the password of my domain account.

i can then go back to the domain controller, dump the AD password hashes. i
then crack it and confirm that the LM Hash exists, and contains my new
password.


So how does one REALLY disable LM Hashes in an Active Directory environment?

 

[Ian Boyd]

The machine has been rebooted - several times.

 

[Miha Pihler]

Hi Ian,

I have dumped some information on this URL... Can you check this and compare
to your results.

http://freeweb.siol.net/mpihler/hashes.jpg

One way to also test your environment is to create password that is longer
then 14 characters (15 will be fine). In this case password can not be
stored as LM "Hash" due to LM design.

Next thing to check would be did your client get new policy. At what level
did you set it? Domain, OU, ... ?

I have few passwords to reset now

Mike

 

[Ian Boyd]

Both your shows Guest and Admistrator accounts there have no LM password.
The others do.

One way to also test your environment is to create password that is longer
then 14 characters (15 will be fine). In this case password can not be
stored as LM "Hash" due to LM design.

That doesn't test the domain controller not storing the LM hash in the first
place.

Next thing to check would be did your client get new policy. At what level
did you set it? Domain, OU, ... ?

It is set on the Domain (Default domain group policy)

My workstation has the policy inherited ( i can see it in the workstation's
own group policy).

Yet i change my password to some uber shocking non-sense, and in 2 minutes i
can have it cracked because the LM Hash is still being stored.

****

I have few passwords to reset now

i guess.

I have dumped some information on this URL... Can you check this and compare
to your results.

a:91c7ae7122196b5eaad3b435b51404eeasswd
c:8b0ea5a7df135b03aad3b435b51404ee
f:3b61b03f29f1c479818d2672d8e13550:.......tugmsee
g:8c6f5d02deb21501aad3b435b51404ee:abc
h:89a8d8845f8d04f8aad3b435b51404ee:geslo_
i:91c7ae7122196b5eaad3b435b51404eeasswd

Administrator and Guest:aad3b435b51404eeaad3b435b51404ee:<empty>

 

[Karl Levinson [x y] mvp]

Both your shows Guest and Admistrator accounts there have no LM password.
The others do.

You sure? The way I read those results, the accounts in the NTLM section in
that image don't have LM hashes. This is what I would expect, passwords
changed after LM hashes are disabled shouldn't have LM hashes, those changed
before should have LM hashes.

Not that this really helps the original poster, unless maybe I'm reading the
results correctly and you're reading your results wrong?

 

[Karl Levinson [x y] mvp]

How do you REALLY disable the generation of Lan Manager password hashes.

i have set the group policy on the domain controller (Windows 2000), and
added to the domain controller's registry the NoLMHash = 1 DWORD.

Is there only one DC? If not, can you try making the change to all DCs? If
there is, would it be wise to have a second server configured to act as a DC
for fault tolerance?

How about making the change in the Group Policy MMC instead of the registry?
Also, is there any chance you could have a Group policy setting that is
changing the registry value back to the default?

Then i go to a workstation and reset the password of my domain account.

i can then go back to the domain controller, dump the AD password hashes. i
then crack it and confirm that the LM Hash exists, and contains my new
password.

Maybe run a second cracking tool to confirm there really is an LMHash? I
notice the cracked LMHashes you posted are all in lower case. This is
strange, because I believe LMHashes convert all the characters to uppercase.

I would prefer to use a tool that shows you whether there is an LMHash
*before* you run a crack, just to be sure. L0phtCrack is one tool that does
this.

 

[Miha Pihler]

Hi,

This is strange, because I believe LMHashes convert all the characters to

uppercase.

That is true, but the passwords are written correct. While L0pht Crack will
use all upper cases to attach the hash once it has the correct hash it will
also write the correct password that was used (lower case letter and
capitals if they were used) etc...

Mike

 

[Ian Boyd]

Both your shows Guest and Admistrator accounts there have no LM
password.

You sure? The way I read those results, the accounts in the NTLM section in
that image don't have LM hashes. This is what I would expect, passwords
changed after LM hashes are disabled shouldn't have LM hashes, those changed
before should have LM hashes.

Let me clarify, i'm ignoring the ones after "Administrator" and "Guest".

Yes, the first 6 have an LM password. All the rest have an <Empty> LM
password.

His idea what to be sure that i recognize the difference between _any_ LM
hash and _empty_ LM hash.

Not that this really helps the original poster, unless maybe I'm reading the
results correctly and you're reading your results wrong?

i'm the original poster, and it doesn't really help me.

i have NoLMHash turned on, but it keeps storing LM Hashes.

 

[Ian Boyd]

There is only one DC.

Is there only one DC?

If there is, would it be wise to have a second server configured to act as a DC
for fault tolerance?

But on the down side, if you have two DC's, then if someone wants to disable
LM hash storing, it is harder to implement.

How about making the change in the Group Policy MMC instead of the

registry?

i have both.

i can see the policy cascaded down to my workstation, in it's local security
policy.

Also, is there any chance you could have a Group policy setting that is
changing the registry value back to the default?
Nope.

Maybe run a second cracking tool to confirm there really is an LMHash? I
notice the cracked LMHashes you posted are all in lower case. This is
strange, because I believe LMHashes convert all the characters to

uppercase.

There really is an LM Hash. i change my password to something i would never
say out loud.

i.e. Something DIFFERENT than it was before.

i then walk to the DC, dump the hashes, and can crack out my NEW DIFFERENT
password.

I would prefer to use a tool that shows you whether there is an LMHash
*before* you run a crack, just to be sure. L0phtCrack is one tool that does
this.

The hash is in there. No matter what tool i'm using, i change my pass
phrase, and then that new pass phrase is instantly recoverable from the
domain controller.


So, how do i STOP the domain controller from setting that value? Why is it
setting it? Even if the workstation calculates both hashes, and sends them
to the DC, why is the DC saving it?

 

[Miha Pihler]

Ian,

Both your shows Guest and Administrator accounts there have no LM password.
The others do.

Administrator does not have an empty password. Empty password would have
hash value

aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

but it has LM "Hash" and not NTLM hash.

91c7ae7122196b5eaad3b435b51404ee:22315d6ed1a7d5f8a7c98c40e9fa2dec:::

Yet i change my password to some uber shocking non-sense, and in 2 minutes i
can have it cracked because the LM Hash is still being stored.

It is a poor design of LM "Hash". When L0pht Crack will attack it it will
actually attack first 7 characters separately from second 7 characters (LH
"passwords" are always 14 characters long. If users will create a password
that is 8 characters long computer will add 6 NULL characters) . This makes
things much easier and faster. As Karl pointed out the characters that it
has to attack are quite limited since password is converted to all capital
letters before "hash" is created.

Even with NTLM hash you will still need password complexity -- NTLM does no
magic. If your users will use simple passwords L0pht Crack will have no
problem figuring out what the password is. It can still use dictionary
attach and pre-computed NTLM Hashes that you can buy on the internet.

You mentioned that you have the policy set at Default Domain Policy. Set
this policy also in Default Domain Controller Policy since passwords are
stored there. Yes also your clients need the same policy since they use it
to locally store the passwords. Use GUI to make the change.

Note, by default Windows will cache passwords (in LM "Hash"). If you want to
get read of old cache you will have to disable it first (set the policy
"Interactive logon: Number of previous logons to cache" to 0) and make users
change their passwords. After they change it you can set this policy back
(you really should) to e.g. default value (10) or some other value... Even
locally cached passwords will now be stored as NTLM...

Mike

 

[Paul Adare - MVP - Microsoft Virtual PC]

microsoft.public.win2000.security news group, Ian Boyd

But on the down side, if you have two DC's, then if someone wants to disable
LM hash storing, it is harder to implement.

How do you figure? If you use Group Policy to set this (which is all you
need to do, you do _not_ need to set this with both Group Policy and a
reg setting) you only need to set this once.

 

[Ian Boyd]

Administrator does not have an empty password. Empty password would have

hash value

Yeah, i wasn't paying enough attention. i see "Built-In Administrator
Account" and think the next entry is the admin account

Point is, i realize that my account on my DC is storing a LM Hash of my
passwords, still.

You mentioned that you have the policy set at Default Domain Policy. Set
this policy also in Default Domain Controller Policy since passwords are
stored there. Yes also your clients need the same policy since they use it
to locally store the passwords. Use GUI to make the change.

Done. Done.

Local machine's don't store hashes for domain accounts on the local machine.
Setting it for the domain is useful to force workstations to not store LM
hashes when they create any local accounts. However, in a domain, there
shouldn't be any local accounts (aside from built in Admin and Guest)


These are the bugs where i can a MS guy to attach a debugger to the DC, and
figure out why it's not working.

What super-secret setting is it looking at instead?

 

[Ian Boyd]

But on the down side, if you have two DC's, then if someone wants to
disable

How do you figure?

i figure it because people say that have to set it on ALL domain
controllers. That means i have to set it more than once. Rather than setting
it on one domain controller, you have to set it on all.

If you use Group Policy to set this (which is all you need to do, you do

_not_ need to set this with both Group Policy and a reg setting) you only
need to set this once.

Yeah, that's what i would have thought. Bbut if you have been reading the
thread, IT'S NOT WORKING.

So in order to try to make it work, i'm setting everything everwhere i can.

 

[Miha Pihler]

Ian,

Can you check the steps in this article. I will this in my lab now.

How to prevent Windows from storing a LAN manager hash of your password in
Active Directory and local SAM databases
http://support.microsoft.com/default.aspx?scid=kb;en-us;299656&sd=tech

Mike

 

[Ian Boyd]

Can you check the steps in this article. I will this in my lab now.

How to prevent Windows from storing a LAN manager hash of your password in
Active Directory and local SAM databases
http://support.microsoft.com/default.aspx?scid=kb;en-us;299656&sd=tech

i know that article very well - i've been cursing it for 7 hours.

i've done all but step #3 (make a password longer than 15 characters)

Since i am not going to force users to do that - just to get around a bug in
a security hole fix.

 

[Miha Pihler]

Ian,

I tried this in my lab and for me it works without any problems.

I did the changes that are described in the KB 299656 on my DC. I tried
using regedit and GP editor. After I switched from LM to NTLM and reset the
password it created NTLM Hash. If I removed the registry key or GP setting
and I reset the password I got LM "Hash"

I did have to restart server (domain controller) between changes for new
settings to kick in...

Mike

 

[Ian Boyd]

i know nobody believes me. So i recorded it.

http://www.jet2.net/~iboyd/NoLMHash.avi

Note 1: i've cut out the screenshot of pwdump itself (can't be giving away
all my colleages passwords)

Note 2: i have to access the domain default group policy from my workstation
(Windows XP) using the Admin Tools. The policy option doesn't appear when i
do it from the domain controller (Windows 2000) itself.

I tried this in my lab and for me it works without any problems.

I did the changes that are described in the KB 299656 on my DC. I tried
using regedit and GP editor. After I switched from LM to NTLM and reset the
password it created NTLM Hash. If I removed the registry key or GP setting
and I reset the password I got LM "Hash"

I did have to restart server (domain controller) between changes for new
settings to kick in...

Outstanding!

 

[Miha Pihler]

What service pack do you have on Windows XP? What SP do you have on DC?



Mike

 

[Steven L Umbach]

According to the KB article you do not use " NoLMHash = 1 DWORD " for Windows 2000.
Try using the exact instructions below to see if it helps. I have used it before as
described and it works on my W2K domain controller.--- Steve

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q299656&
Windows 2000 SP2 and Later
WARNING: If you use Registry Editor incorrectly, you may cause serious problems that
may require you to reinstall your operating system. Microsoft cannot guarantee that
you can solve problems that result from using Registry Editor incorrectly. Use
Registry Editor at your own risk.

Important The NoLMHash registry key and its functionality were not tested or
documented and should be considered unsafe to use in production environments before
Windows 2000 SP2.

To add this key by using Registry Editor, follow these steps:
1.. Start Registry Editor (Regedt32.exe).
2.. Locate and then click the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

3.. On the Edit menu, click Add Key, type NoLMHash, and then press ENTER.
4.. Quit Registry Editor.
5.. Restart the computer, and then change your password to make the setting active.

 

[Ian Boyd]

XP SP1

2000 SP3