NT/2000 password hash security

[unhappyStar]

within a week or so i will be setting up an network of 1 win2000 server machine and 4 win2000 professional clients and 8 NT service pack 6 clients. the server will be used primarily for network storage (share drives) and as PDC (primary domain controler) basically what i am trying to prevent is someone booting one of the clients into NTFSDOS or linux, copy SAM and crack it thus getting all my our passwords incuding administrator. so here's a few questions i have:

1. i know that 2000 uses a crypto while NT uses hash function of some sort (if you know the names or can clarify the whole thing, please post here) how can i make NT use the same crypto as 2000 or do i have to make my 2000 machines back-compatible w/ NT

2. is the 2000 passwod storage truly uncrackable and what is the name of it

3. what is the NT hash system name (is it lanman or is that something else)

4. if i theorize correctly, i think that the NT machines are gonna be the most vulnerable to sam/copy & crack strategy. so my question is what passwords are accually stored localy in NT and 2000 hash. is it just the local admin or every person ever logged in at the machine, or something between.

5. i would like everything to be authenticated at the PDC remotely not localy to prevent their storage on local machine ... how can i do that ?

i know a lot of you will say i have no bussiness seting up this network but it's not like i'm doing it alone and it's not like i'm getting paid

you could even point me to a good txt file about the subject

[VictorKaum]

1) & 2) two Win2000 boxes in a domain will by default use Kerberos as network authentication. All others will *not* use that default protocol for network authentication.

3) NT uses NTLM this is the NT version of the windows Lan Manager (see Win 9X). The password and accounts reside in the SAM, both NT and NTLM are vulnerable (like you said) and crackers for SAM are widely spread. NT workstations and stand alone servers (not the PDC and BDC's) have their own SAM's regulating access to resources on that computer alone. Therefor Membership in a domain group does not implies membership in a local group.

4) However Windows 2000 domain passwords and accounts are not kept in the local SAM and thus are not vulnerable to these particular programs. Keep in mind they can still be obtained by network sniffers capturing packets.

Win 2k is backwards compatible with both NTLM and LM. To make your authentication (a lot / a bit) more secure use NTLMv2 and set Win2k to only accept this authentication method. It can easily be used on NT4 and even on Win9x boxes (if you install dsclient, stands for active directory client). However Win9x is a big security no no.
There are several levels in Win2k accepting protocols. Default is NT and NTLM that's level 0,
you can set it to level 5 this accepts onlt NTLMv2. However keep in mind that when there's no protocol available security can even be worse! make sure you update all your boxes to use NTLMv2. You can set this policy in Group policy for systems using a Domain

about security (ugh!) for windows NT/2000
http://www.microsoft.com/technet/tre...e&hidetoc=true

[ammo]

I'll try to help...

1- W2k still uses hashes in the SAM, ie local accounts (unless you activate the "Use reversible encryption" group policy (needed for MS Chap 1, IAS, and others). However, for domain authentication, w2k (and winXP) clients use kerberos to authenticate to a W2k DC (they will however revert to lanman/NTLM/NTLMv2 "challenge/response" if kerberos fails or is unavailible (if auth. to a NT4 PDC for example). Kerberos indeed uses a strongly encrypted (and quite complex) mechanism for auth, which, AFAIK, hasn't been broken as of yet.

However as I said, W2k clients can be maid to revert to NTLM/Lanman challenge/response, and so you should force the use of NTLMv2 on the domain trough active directory group policies or "reg hacks" on NT4. NTLMv2 hashesisn't "un-brutforceable" (and is also vulnerable to "hash passing") but it's still faires much better than NTLM(v1) or Lanman.

2- Are you refering to storage on workstations/member servers or domain controlers? In the case of workstations/member servers, local account passwords are still stored in SAM files while on w2k domain controlers, they're in the Active Directory accounts database. However in w2k, both are encypted with syskey (128 bit encryption) making it nearly impossible to crack them BUT, there are workaround like the pwdump tool which uses dll injection to retreive usernames/passwords (hashes). So W2k still uses lanman/ntlm hashes but are 128 bit encrypted (syskey) when stored...

3- lanman / ntlm

4- In the local SAM of workstations or member servers, there are only local account credentials (user/pass).
There are however other passwords stored in the registry including service account passwords, computer account passwords and cached password hashes of the last 10 (by default) users who logged on that machine. Those are accessible with the "LSA Secrets" "hack" (tool: lsadump) but require local administrator access. You can also change the number of logons cached trough the local security settings (0 = do not cache) if you're really worried about getting domain account compromised.

5- If you are using a domain (be it NT4 domain or Active Directory domain), you just have to create the user accounts on the PDC / DC (FYI: W2k domain controlers are just called "DC" since it's a multi-master setup: there are no primaries and backup DCs, all w2k DCs are created equal, replicate the same info and offer the same services simultaniously). Those domain accounts will only be stored on the DCs (well, except for cached credentials from #4) and authentication will be done remotely trough kerberos or NTLMv2/NTLM/LM.

A good read on this is chapter 8 from "Hacking Windows 2000 Exposed".

Hope this helps...

Ammo

Heh.. took to long to type, got beat to the line

Oh yeah, you should also set the boot sequence in the bios so that your users can't boot from the floppy! Not an infalible solution, but helps quite a bit (especially for computer labs in schools!)

Ammo

[VictorKaum]

Ammo, a little addition to your edit, if you set the boot sequence not to boot from floppy, you better set a admin password on the bios config too.

[ammo]

Heh.. yeah! Meant to write it but forgot!

Ammo

[unhappyStar]

thanx ... that really clarified some of it for me but let me elaborate anyway:

1. if win2k uses kerberos for domain auth. are the passwords submited over the network in clear text? can they be sniffed. i'm not really familiar w/ the workings of kerberos (i thought it was a linux program i did try to read the MIT site for kerberos but i still don't get it. is it a protocol (like SSH) or is it some kinda wraper for other protocols, or is it a fire-wall

[ammo]

Kerberos is an authentification protocol...
It's all based on the exchange of "tickets" and uses very strong crypto; in fact, nor the password nor the hashes are sent over the network with kerberos...

The best explanation of kerberos is this paper http://www.antionline.com/attachment...tachmentid=379 (it's actually a "classic" doc from mit). It explains the why's and how's of kerberos, but formated as a dialogue between mithical greek characters! (A little long, but well worth the read...)


Ammo

[thehorse13]

You asked:
5. i would like everything to be authenticated at the PDC remotely not localy to prevent their storage on local machine ... how can i do that ?

You can set the number of cached credentials to be stored locally. This is a reghack and you can find info on it right on the Microsoft site. In your case, not storing cached credentials at all will be fine. You only have one server and if it is down, then you aren't going to do too much :-)

Disabling the floppy from the boot sequence is a decent deterrant from folks who have an NT/W2K password cracking floppy. Keep in mind that local admin accounts on NT and 2000 are certainly crackable and can be done quickly and easily this way.

Kerberos acts as a trusted authenticator where you have a client that does not trust a server and the server that does not trust a client. Careful with the nonclementure that deals with kerberos. Kerberos has realms instead of domains and the use of "client" refers to the server and such. The important thing to remember is that it is much better (security wise) than LanMan set at its defaults.