COMMAND

    rpcclient

SYSTEMS AFFECTED

    WinNT

PROBLEM

    Luke Kenneth  Casson Leighton  found following.   When an  NT  4.0
    workstation or  backup domain  controller is  joined to  a domain,
    the trust account password is  set to a well-known initial  value.
    If you are concerned about internal network security, this is  not
    really an  acceptable risk:  any captured  network traffic  can be
    decoded simply from knowing the name of the workstation, which  is
    contained in the network traffic  itself.  The initial value  _is_
    changed to a  random value... using  the initial value  as the key
    to obfuscate the new value.

    The  shared  secret  (trust  account  password)  is  stored in two
    places.  One  is on the  workstation or backup  domain controller,
    in the lsa secret named "$MACHINE.ACC".  The other location is  in
    the SAM database of the  PDC.  The workstation uses  $MACHINE.ACC,
    the PDC uses the SAM database copy.

    Recent additions to samba's  "rpcclient" and "samedit" tools  also
    allow the same  to be done  -- from a  unix command-prompt.   Once
    the  workstation  has  been  joined  to  the  domain and rebooted,
    follow these instructions _prior_ to logging in at the console:

        unix$ samedit \\ntpdc -U administrator%administratorpassword
        [administrator@ntpdc$ ] use \\ntworkstation -U localadminuser%localpwd

        [wait for the following message:]
        Net Use \\ntworksation User: localadmin: Domain: - OK

        [administrator@ntpdc$ ] createuser ntworkstation$ -j

        [you should see the followoing messages:]
        Create Workstatino Trust Account ntworkstation$: OK
        Join Worksation to Domain: OK

        [administrator@ntpdc$ ] quit
        unix$

    You _will_  need to  know --  and use  -- the  workstation's local
    admin password  _and_ the  pdc's admin  password because rpcclient
    (or  samedit)  make  two  separate  connections,  one  to   change
    $MACHINE.ACC, the  other to  store the  same password  on the PDC.
    don't  worry:  if  rpcclient  (or  samedit) cannot connect to BOTH
    machines, it will NOT attempt  to change EITHER of the  passwords.
    It is not possible,  however, to obtain the  _original_ passwords,
    for   security   reasons   (well   done   microsoft  for  removing
    LsaQuerySecret from NT 4.0 SP4 by  the way!  So if this  procedure
    fails half-way, you're going to need to rejoin the workstation  to
    the  domain.   You  will  probably  find  that there is some other
    serious problem that caused this to fail (unrelated to  rpcclient/
    samedit's use, misuse or lack of use) which will _also_ cause  the
    rejoin to fail, so fix  that first (for example, someone  switched
    off or  disconnected the  PDC whilst  rpcclient /  samedit was  in
    use!)  and  then  reissue  the  createuser  command to re-join the
    workstation, or  go back  to basics  and use  the network  control
    panel.

    The source  code to  rpcclient can  be obtained  by following  the
    instructions at

        http://samba.org/cvs.html

    and using a tag of SAMBA_TNG.  Once you have obtained the  source,
    you will need to do this:  ./configure make bin/rpcclient or  make
    bin/samedit

    Regarding  the  createuser  command,  it  issues  an LsarSetSecret
    function  and  a  SamrSetInformationUser  function with info level
    0x18 to  set the  $MACHINE.ACC and  the trust  account's password,
    respectively.  *BOTH* these functions use the User Session Key  of
    the user's connection (localadmin to the workstation,  domainadmin
    to  the  pdc).   If  you  recall  my  previous posting, when using
    NTLMv1,  this  is  MD4(NT#),  which  is  MD4(MD4(Unicode(plaintext
    password))).  You SHOULD, therefore, either:

    - add "client ntlmv2 = yes" to the smb.conf file used by rpcclient
      and samedit.  The default is /usr/local/samba/lib/smb.conf.  Set
      "LmCompatibilityLevel=0x4  or    0x5"    on   the    PDC,    and
      "LmCompatibilityLevel=0x2 or 0x3" on the workstations.
    - after ANY usage of  an administrator account to either  change a
      user's  password   or  create   account  using   SRVMGR.EXE   or
      USRMGR.EXE, ALSO change the administrator's password.  this  is,
      of  course,  totally  impractical  and  ridiculous but it is the
      only way to  ensure that new  account passwords are  secure when
      using NTLMv1 (the default for  all versions of Windows NT).  see
      previous  posting  to  NTBUGTRAQ  for  details and procedures on
      secure network alternatives to this stupid, necessary approach.

SOLUTION

    This  _has_  been  fixed  in  nt5:  the initial value is *totally*
    random.   Confirmed this  for workstations-joining-domains.   Btw,
    NT5 cannot _be_ a bdc in an nt4 domain.