docs/textdocs/NT-Guest-Access.txt

   1 !==
   2 !== NT-Guest-Access.txt for Samba release 2.0.4 18 May 1999
   3 !==
   4 > Hi folks ... I don't know if you have seen this, have corrected this yet
   5 > or it is my configuration.
   6 > I am using our company PDC for passwd authentication and it works OK
   7 > except for one snag.
   8 > The authentication process between the our Samba server & the PDC always
   9 > includes one unsuccessful pass thru attempt.
  10 >    This initial pass thru validation has an incorrect user password
  11 > (1F1F1F1F......). A SMB reject from the PDC forces the Samba Svr to
  12 > immediately send a second validation with the correct
  13 > encrypted Bell Master Domain user password.
  14 >    It would be nice to get rid of the first bad validation attempt.
  15
  16 What you are seeing is being done deliberately.
  17
  18 The problem is that some versions of MS Windows NT have a bug when
  19 used as a password server when Samba is set up to use "security=server"
  20 (Note that this is *NOT* a problem when using "security=domain").
  21
  22 The NT server accepts a user logon request with a bad password as
  23 a "guest" login attempt, and logs the user on as the guest user.
  24
  25 The bug is that the NT server doesn't tell the Samba server
  26 that this is what it has done (it doesn't set the guest bit
  27 that is designed for this use in the protocol). Thus the
  28 Samba server cannot tell if a user entered a bad password
  29 and was logged on as guest, or entered a correct user name
  30 and password and was logged on as the correct user.
  31
  32 The severity of this bug may be imagined if a user attempts
  33 to access the Samba server as user "root" with a bad password,
  34 and the Samba server trusted the NT server to authenticate
  35 this.....
  36
  37 Thus, Samba performs a logon request with a deliberately
  38 bad password and checks to see if that request succeeded.
  39 If it did, then the NT server suffers from the bug and cannot
  40 be used for "security=server" authentication. If it fails
  41 then we know this server is correct.
  42
  43 It is this first deliberate invalid connection request that
  44 people are seeing in the NT event log, but currently there
  45 seems no way around this so long as there are NT servers
  46 out there that have this bug.