RE: Basic question

From: Laura A. Robinson (
Date: 03/14/05

  • Next message: Maxime Ducharme: "Re: Question on IIS servers and reverse lookup ... found answer"
    Date: Sun, 13 Mar 2005 18:51:52 -0500
    To: "'dave kleiman'" <>, "'Roman L. Daszczyszak II'" <>, <>


    > -----Original Message-----
    > From: dave kleiman []
    > Sent: Friday, March 11, 2005 5:04 AM
    > To: 'Roman L. Daszczyszak II';
    > Subject: RE: Basic question
    > Roman,
    > An excellent write-up on LM-v2 is "The NTLM Authentication Protocol"
    > It does not cover
    > your Kerberos request.

    If somebody else hasn't covered it already, I'll try to send out a Kerberos
    explanation, but the Win2K reskit (Distributed Systems Guide, IIRC) has a
    decent explanation of it.

    > Although technically NT-W2K3 passwords are based on the
    > Unicode character set and can be up to 128 characters long,
    > Pre-W2K user interfaces limits do not allow passwords to
    > exceed the LanMan 16 byte long, which that write-up above
    > shows, is 14 characters.

    I believe that you are referring to *LM* hashes. NTLM-hashed passwords can
    be longer than 14 characters. (In fact, the easiest way prior to Win2K3's
    group policy to eliminate LM hashes was to require passwords of 15+
    characters. Now, however, the Win2K3 group policy gives you the option to
    disable storage of LM hashes regardless of password length.) NT4-based
    machines use NTLM hashes (NTLMv2 if you've patched them to NT4 SP4 level,
    which, of course, you need to have done in order for them to work in an AD
    environment), and SP4 also gave the ability to use up to 128 character
    passwords in NT. Win 9x machines are *also* able to use NTLMv2 if you
    install the AD extensions on them.

    Additionally, passwords themselves are not stored in AD- *hashes* are-
    unless, of course, you enable reversible encryption of passwords, which you
    reference below, albeit a bit inaccurately.
    > At this moment the source eludes me, but I remember seeing
    > several times not to use longer than 64 character passwords,
    > it may have been something to do with Kerb, or possibly
    > Inter-OS operability.

    I think you may have been referring to a glitch in the OS that has
    subsequently been fixed. Kerberos password hash algorithms produce
    fixed-length results regardless of password/salt length, BTW.

    > If I find it I will forward the source.
    > I have read several times the same thing with usernames 104
    > characters limit. "Logon names can be up to 104 characters.
    > However, it isn't practical to use logon names that are
    > longer than 64 characters". And remember it only uses the
    > first 20 characters,

    For downlevel logon names only- this doesn't mean you can't require longer
    UPNs, since UPNs and downlevel logon names do not have to be the same. UPNs
    wherein the portion of the username preceeding the @ exceeds 20 characters
    work just fine. This is very easy to test- you will, of course, have to give
    the users <= 20 character downlevel logon names.

    > which must be unique in the
    > domain/workstation for Pre-W2K compatibility, and don't
    > forget the display name is limited to 64 characters as well.
    > I sure do wish they would give us "real" off switch for
    > Pre-W2K compatibility.

    They did.

    > As far as "that authenticating to a domain-based machine from
    > a machine outside the domain"
    > If you need to use CHAP or Digest etc. authentication for
    > IIS/IAS or such, then your password would have choose that
    > "option" that says "Store password using reversible
    > encryption"

    Not quite. Digest authentication uses reversible hashes. MS-CHAP/CHAP do

    > which "is essentially the same as storing
    > plaintext versions of the passwords".

    Not quite, although it isn't a good idea to implement it if you can avoid
    doing so.



  • Next message: Maxime Ducharme: "Re: Question on IIS servers and reverse lookup ... found answer"