No LM Hash - no really

[Miha Pihler]

Can you try few things.

Try to create local user on Windows XP. Is password stored as LM "Hash" or
NTLM?
What if you try to reset user's password in AD Users and Computers? How is
password stored?

Mike

 

[Ian Boyd]

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

3.. On the Edit menu, click Add Key, type NoLMHash, and then press

ENTER.

Add a "Key" *ugh*

The group policy editor creates "nolmhash=0" or "nolmhash=1" in the
registry. But it doesn't create a "NoLMHash" key. Creating the key and
rebooting makes it work!

Oh for the love of god.


Thank you very much, Steve.


Now i just need my other question answered

http://groups.google.com/[email protected]&rnum=1

 

[Ian Boyd]

i have set the group policy on the domain controller (Windows 2000), and

added to the domain controller's registry the NoLMHash = 1 DWORD.

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

environment?

The answer is, neither of the above work.

Create a NoLMHash key, not a NoLMHash=1 DWORD


That's 7 hours of my life i'm not getting back.

 

[Ian Boyd]

Try to create local user on Windows XP. Is password stored as LM "Hash" or

NTLM?
What if you try to reset user's password in AD Users and Computers? How is
password stored?

Steve found it.

Create a NoLMHash key.

The NoLMHash dword or group policy don't do it.

 

[Miha Pihler]

Cool. I just read his post. I am glad you got a solution to your problem

Mike

 

[Ian Boyd]

Cool. I just read his post. I am glad you got a solution to your problem


Me to.

About a year ago we thought we dealt with the security issue. Yesterday i
discovered that the DC was ignoring the group policy and registry value.

Now that i have a solution, i can tell everyone that they might want to
change their passwords.

 

[Paul Adare - MVP - Microsoft Virtual PC]

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

Now i just need my other question answered

http://groups.google.com/[email protected]&rnum=1

You need to reread the KB article again:

"Method 1: Implement the NoLMHash Policy by Using Group Policy
To disable the storage of LM hashes of a user's passwords in the local
computer's SAM database by using Local Group Policy (Windows XP or
Windows Server 2003) or in a Windows Server 2003 Active Directory
environment by using Group Policy in Active Directory (Windows Server
2003), follow these steps:"

Since this setting is only available to Windows XP and Windows Server
2003 computers, using the Group Policy editor on a Windows 2000 computer
is not going to do you any good (the setting in question didn't exist
when Windows 2000 was released).

Either run the Group Policy editor from an XP computer or, update the
ADM files on your domain controller.

Have a search through the KB for updating the ADM templates from an XP
computer.

 

[Ian Boyd]

"Method 1: Implement the NoLMHash Policy by Using Group Policy

To disable the storage of LM hashes of a user's passwords in the local
computer's SAM database by using Local Group Policy (Windows XP or
Windows Server 2003) or in a Windows Server 2003 Active Directory
environment by using Group Policy in Active Directory (Windows Server
2003), follow these steps:"

Since this setting is only available to Windows XP and Windows Server
2003 computers, using the Group Policy editor on a Windows 2000 computer
is not going to do you any good (the setting in question didn't exist
when Windows 2000 was released).

Either run the Group Policy editor from an XP computer or, update the
ADM files on your domain controller.

There is a combination of things working against me here.

First is that you cannot set the 'No store lm hash' group policy option from
an Windows 2000 server machine itself. You need to configure it instead from
an XP or 2003 machine.

The other problem is that even if you administer the 2000 DC from an XP or
2003 machine - it won't help you. All it will do is create a registry value
on the 2000 DC NoLMHash= (DWORD)1.

And it turns out that a Windows 2000 DC machine ignores the NoLMHash value.

Instead it has to be a NoLMHash key - which no group policy editor will
create.


I wish the KB article specifically detailed that fact that the Group Policy
editor cannot be used to disable the storage of LM Hashes on a Windows 2000
machine.

Otherwise, i am led to believe that i CAN use the group policy editor, as
long as i use it FROM an XP or 2003 machine.


Well, hopefully the next person looking for a solution to the problem i was
having, they will find the solution hours before it took me.

 

[Steven L Umbach]

OK. Glad it worked. Sometimes we all miss the fine print. --- Steve

 

[Steven L Umbach]

For your other question, that security option is not available in Windows 2000 which
is why we have to use a registry key. As you know you can manage XP Group Policy
additional settings for XP Pro computers in a Windows 2000 domain from a XP Pro
domain computer. Those settings as far as I know only apply to XP Pro computers which
is usually stated in the settings for administrative templates for user and computer.
For computer security settings I would assume those items new to XP Pro or W2003 are
not compatible with W2K unless I have proof that they do. For the most part, user
rights are just about the same but there are quite a bit more security options
compared to W2K. -- Steve

 

[Paul Adare - MVP - Microsoft Virtual PC]

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

There is a combination of things working against me here.

First is that you cannot set the 'No store lm hash' group policy option from
an Windows 2000 server machine itself. You need to configure it instead from
an XP or 2003 machine.

You can, you just need to update the ADM templates.

The other problem is that even if you administer the 2000 DC from an XP or
2003 machine - it won't help you. All it will do is create a registry value
on the 2000 DC NoLMHash= (DWORD)1.

And it turns out that a Windows 2000 DC machine ignores the NoLMHash value.

Instead it has to be a NoLMHash key - which no group policy editor will
create.


I wish the KB article specifically detailed that fact that the Group Policy
editor cannot be used to disable the storage of LM Hashes on a Windows 2000
machine.

It does:

Method makes no mention of Windows 2000, and Method 2 makes no mention
of XP or 2003. Seems pretty obvious to me.

Otherwise, i am led to believe that i CAN use the group policy editor, as
long as i use it FROM an XP or 2003 machine.

As above.

 

[Ian Boyd]

There is a combination of things working against me here.

You can, you just need to update the ADM templates.

What does the template update get you? Will the group policy editor then do
what no other version does: create a registry key called NoLMHash? Every
other version of GPE creates a NoLMHash value.

I wish the KB article specifically detailed that fact that the Group Policy

It does:

Method makes no mention of Windows 2000, and Method 2 makes no mention
of XP or 2003. Seems pretty obvious to me.

| To disable the storage of LM hashes of a user's passwords
| in the local computer's SAM database
| by using Local Group Policy (Windows XP or Windows Server 2003)
| or
| in a Windows Server 2003 Active Directory environment
| by using Group Policy in Active Directory (Windows Server 2003), follow
these steps:

i was doing the former.

Using the local group policy from Windows XP or Windows Server 2003 (Windows
XP in my case) to change the policy on my target machine.

Turns out the modifier was dangling, and the "Windows XP or Windows Server
2003" adjective applies to "the local computer", not to "using Local Group
Policy"

Once it was expained to me that the modifier was dangling, i see what step
#1 was trying to say.

 

[Karl Levinson [x y] mvp]

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

I think you are mistaken. You should try it and see if you are
misinterpreting what you are seeing in your results. In other words, see
what it looks like when there can't possibly be an LM hash.

section

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.

I'm confused. Unless the password is blank, then whatever is being stored
in the "blank" LM hash is garbage and won't allow anyone to log on.

I want to make sure you're not assuming that LM hashes are there just
because your password cracker is cracking the passwords. NTLM passwords can
be easily cracked too, especially if they are 7 characters or shorter.

When I pointed out that the LM hashes from your print out were in all lower
case letters, I was doubting that what you were seeing there were really
passwords cracked from the LM hash, because I would normally expect
passwords cracked from LM hashes to be in all UPPER CASE. I asked a few
questions and made a few suggestions in my last post, did you try any of
them, and if so, what happened? Are you assuming they won't help you?

 

[Karl Levinson [x y] mvp]

Hi,
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...

.... but only if the NTLM hash was cracked. If theLMHash was cracked,
L0phtcrack shows that in all upper case as well. Since we're not seeing
that in the reports being pasted here, my recommendation that a different
tool be used would be valid here.

 

[Karl Levinson [x y] mvp]

as
a DC

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.

It's easier to change one registry value than to restore a single DC from
tape backup.

registry?

i have both.

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

So then that setting is not so hard to push out.

When you change the correct setting on the DC, it doesn't cascade down to
the workstation. What setting is on the workstation is as you may know
irrelevant.

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.

How do you know that was the LM hash being cracked? What you posted was in
lower case, which was from the NTLM hash being cracked.

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.

Unless you see the password in all upper case letters at some point, you're
not proving that you've cracking the LMHash. IIRC L0phtcrack displays both
passwords, the LM hash crack with the password in in all uppercase, and then
the NTLM hash crack in mixed case.

 

[Karl Levinson [x y] mvp]

environment?

The answer is, neither of the above work.

Create a NoLMHash key, not a NoLMHash=1 DWORD


That's 7 hours of my life i'm not getting back.

A lot of problems are caused by using WinXP or 2003 security templates on
Windows 2000. This is because different versions of Windows use different
registry keys and values to enable certain settings, and a GP template is
just a static text file that can only pick one or the other method. It
sounds like that's the case here, since your GP is creating the Win 2003
version of this setting. Make sure there aren't mixed versions of the GP
templates in your environment. You're not the only one that's been bitten
by this kind of problem with mixed GP templates. GP templates should really
clearly specify in the GUI, if not also in the text file itself, what OS
they're intended for.

 

[Paul Adare - MVP - Microsoft Virtual PC]

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

What does the template update get you? Will the group policy editor then do
what no other version does: create a registry key called NoLMHash? Every
other version of GPE creates a NoLMHash value.

No, it won't. However, if you update the ADM files on your 2000 domain
controllers, you can use the Group Policy Editor on your DCs to create
the registry entry that will disable LMHash on XP and 2003 computers
affected by the policy.

The _only_ was to do this for a 2000 computer is to create the registry
key indicated in the KB article. You could, if you wanted to, create a
custom ADM template to push the registry key to your 2000 based
computers.

<snip>

 

[Ian Boyd]

One way to also test your environment is to create password that is

longer

I think you are mistaken. You should try it and see if you are
misinterpreting what you are seeing in your results. In other words, see
what it looks like when there can't possibly be an LM hash.

i didn't try it. Microsoft says that one way to avoid storing an LM Hash is
to create a password longer than 14 characters. Well that's just not good
enough that i won't even bother.

I'm confused. Unless the password is blank, then whatever is being stored
in the "blank" LM hash is garbage and won't allow anyone to log on.

If you use the LM Hash algorithm to hash <nothing>, then you get

AAD3B435B51404EEAAD3B435B51404EE

which is the hash for nothing

The NTLM hash for <nothing> is

31D6CFE0D16AE931B73C59D7E0C089C0

So when i see a password that has an "empty" LM hash, but an "non-empty"
NTLM hash, then i know it is not storing the LM Hash, even though it is
storing the NTLM hash, and hence has a real password.

So whenever i see the "AAD3.." i know there is no LM hash being stored.

When I pointed out that the LM hashes from your print out were in all lower
case letters, I was doubting that what you were seeing there were really
passwords cracked from the LM hash, because I would normally expect
passwords cracked from LM hashes to be in all UPPER CASE.

Yes, i understand that the LM hash algorithm converts the password to
UPPERCASE and hashes the first and last 7 characters as two separate hashes.
i converted them to lowercase in my post, and they were almost CERTAINLY not
entered as uppercase into Windows, and so really would be a lowercase
password.


i see your confusion in a couple of posts regarding the lowercase passwords.
i wasn't posting the results of a password cracker; i was trying to post the
actual passwords. Windows NT,2000,XP,2003 is case sensitive, and it is
almost a guarantee that nobody has uppercase passwords. So i implicitly
convert them to lowercase.

The idea was to post the password for a given account. i accomplished that
by cracking the LMHash, but the crack of the LM Hash doesn't give you the
actual password.

I asked a few
questions and made a few suggestions in my last post, did you try any of
them, and if so, what happened? Are you assuming they won't help you?

i have already found the fix, and posted it in this thread. (Create a
NoLMHash key, verses trying to use a group policy editor or create a
NoLMHash value).

 

[Ian Boyd]

You could, if you wanted to, create a

custom ADM template to push the registry key to your 2000 based
computers.

Custom ADM template? i didn't know you could to that.

Interesting...

i also could force a registry key creation in the group policy that would
apply to everyone in the domain, controllers and workstations.

i'm sure the NoLMHash registry key has no effect on XP/2003 machines - so it
wouldn't hurt to put it in - and it would protect windows 2000 machines (of
which we have a lot).

 

[Ian Boyd]

A lot of problems are caused by using WinXP or 2003 security templates on

Windows 2000. This is because different versions of Windows use different
registry keys and values to enable certain settings, and a GP template is
just a static text file that can only pick one or the other method. It
sounds like that's the case here, since your GP is creating the Win 2003

and Windows XP

version of this setting. Make sure there aren't mixed versions of the GP
templates in your environment. You're not the only one that's been bitten
by this kind of problem with mixed GP templates. GP templates should really
clearly specify in the GUI,

i guess. i didn't appreciate that the GP editor doesn't make magical changes
to something special in the guts of the computer - but is a centralized way
to managing all kinds of disprate registry key, values, combinations.

if not also in the text file itself, what OS they're intended for.

i've never seen these text files.

i've always read that for BackOffice logo certification, you should use
group policies. But they never explained how to integrate into the group
policy editor.

i'm gonna have to find these text files now.


p.s. If you haven't found it elsewhere in the thread. The cracker didn't
come back with lowercase passwords: i did. i was posting the password for a
given LM Hash. Nobody has uppercase passwords.