Bug 815 - NT4.0 client can not map drives on a 3.0 (cleartext) standalone server
NT4.0 client can not map drives on a 3.0 (cleartext) standalone server
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.0
All Solaris
: P2 major
: none
Assigned To: Gerald (Jerry) Carter
:
: 718 (view as bug list)
Depends on:
Blocks: 807
  Show dependency treegraph
 
Reported: 2003-11-25 12:54 UTC by Qing Chang
Modified: 2005-08-24 10:16 UTC (History)
2 users (show)

See Also:


Attachments
Here is the patch. (1.18 KB, patch)
2003-12-12 14:55 UTC, Jeremy Allison
no flags Details
Level 10 logs of an NT client trying to map a drive (101.06 KB, text/plain)
2003-12-16 12:39 UTC, Dana Chee
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Qing Chang 2003-11-25 12:54:12 UTC
mapping a share on a 3.0 standalone server will cause following error:
"Logon failure: unknown user name or bad password." 
There is no problem when client is W2K and XP. No tests done
on machine below NT4.0.

Below is the conf file:
======== begin =========
# Global parameters
[global]
        workgroup = RESEARCH
        netbios name = samba
        server string = samba test (Samba %v)
        invalid users = root, bin, deamon, adm, sys, lp, uucp
        local master = No
        encrypt passwords = No
        pid directory = /global/admin/samba/var/locks
        smb ports = 139

[admin]
        path = /global/admin
        writeable = yes
        browseable = yes
========== end ===========

"smb ports = 139" was added in hope of taking away port 445
as a possible factor for NT not working, but did not make any difference.
W2k and XP are still happy with this setting.

We are using plain text password. NT clients can map to a 2.2.8a
server using plain text password no problem.
Comment 1 Gerald (Jerry) Carter 2003-11-25 13:59:05 UTC
please send me a level 10 debug log.  You may mail it 
to me directly if you wish.  Thanks.
Comment 2 Gerald (Jerry) Carter 2003-12-10 13:32:17 UTC
confirmed and easily reproducible with encrypt passwords = no.
Comment 3 Gerald (Jerry) Carter 2003-12-10 13:34:59 UTC
did you compile --with-pam ?
Comment 4 Gerald (Jerry) Carter 2003-12-10 13:48:52 UTC
This is an NT4 bug when talking to unicode enabled servers.
Notice the password length values and how the string 'test'
is stored.  

The workaround is to set 'unicode = no' in smb.conf.  If 
you need extended character support you will have to 

    (a) move to encrypted passwords, or 
    (b) upgrade from Windows NT 4.0

SMB (Server Message Block Protocol)
    SMB Header
    Session Setup AndX Request (0x73)
        Word Count (WCT): 13
        AndXCommand: Tree Connect AndX (0x75)
        Reserved: 00
        AndXOffset: 162
        Max Buffer: 16644
        Max Mpx Count: 50
        VC Number: 1
        Session Key: 0x0000406e
        ANSI Password Length: 10
        Unicode Password Length: 18255
        Reserved: 00000000
        Capabilities: 0x000000d4
        Byte Count (BCC): 101
        ANSI Password: 45740065007300740000
    Tree Connect AndX Request (0x75)
        Word Count (WCT): 4
        AndXCommand: No further commands (0xff)
        Reserved: 00
        AndXOffset: 0
        Flags: 0x0000
        Password Length: 1
        Byte Count (BCC): 48
        Password: 00
        Path: \\192.168.1.41\PUBLIC
        Service: A:

0000  00 30 f1 11 bf 72 00 50 56 40 00 44 08 00 45 00   .0...r.PV@.D..E.
0010  01 09 ed 00 40 00 80 06 88 db c0 a8 01 99 c0 a8   ....@...........
0020  01 29 04 1d 00 8b 00 00 54 d4 d2 96 b1 1c 50 18   .)......T.....P.
0030  21 dd 0d 21 00 00 00 00 00 dd ff 53 4d 42 73 00   !..!.......SMBs.
0040  00 00 00 18 03 80 00 00 34 48 dc ca cc f7 c9 b7   ........4H......
0050  00 00 00 00 fe ca 00 00 00 00 0d 75 00 a2 00 04   ...........u....
0060  41 32 00 01 00 6e 40 00 00 0a 00 4f 47 00 00 00   A2...n@....OG...
0070  00 d4 00 00 00 65 00 45 74 00 65 00 73 00 74 00   .....e.Et.e.s.t.
0080  00 00 6c 00 69 00 7a 00 61 00 72 00 64 00 00 00   ..l.i.z.a.r.d...
0090  56 00 41 00 4c 00 45 00 00 00 57 00 69 00 6e 00   V.A.L.E...W.i.n.
00a0  64 00 6f 00 77 00 73 00 20 00 4e 00 54 00 20 00   d.o.w.s. .N.T. .
00b0  31 00 33 00 38 00 31 00 00 00 00 00 57 00 69 00   1.3.8.1.....W.i.
00c0  6e 00 64 00 6f 00 77 00 73 00 20 00 4e 00 54 00   n.d.o.w.s. .N.T.
00d0  20 00 34 00 2e 00 30 00 00 00 00 00 04 ff 00 00    .4...0.........
00e0  00 00 00 01 00 30 00 00 5c 00 5c 00 31 00 39 00   .....0..\.\.1.9.
00f0  32 00 2e 00 31 00 36 00 38 00 2e 00 31 00 2e 00   2...1.6.8...1...
0100  34 00 31 00 5c 00 50 00 55 00 42 00 4c 00 49 00   4.1.\.P.U.B.L.I.
0110  43 00 00 00 41 3a 00                              C...A:.
~
Comment 5 Jeremy Allison 2003-12-12 14:55:19 UTC
Created attachment 324 [details]
Here is the patch.
Comment 6 Jeremy Allison 2003-12-12 14:55:53 UTC
I have fixed this with the given patch in CVS.
Jeremy.
Comment 7 Dana Chee 2003-12-16 12:39:11 UTC
Created attachment 329 [details]
Level 10 logs of an NT client trying to map a drive
Comment 8 Dana Chee 2003-12-16 12:43:52 UTC
Patch did not actually fix the bug for NT client machines.  Attached is a level 
10 log after the patch was applied.  Notice that when NT sends the cleartext 
password, the system doesn't seem to pick out the username, and says that the 
username is blank (lines after:

[2003/12/16 15:25:37, 10] lib/util.c:dump_data(1825)

Thanks for your attention to this.
Comment 9 Gerald (Jerry) Carter 2003-12-16 20:27:54 UTC
the patch works for me. What is interesting is that before
the patch was posted, I tried Jerry's suggestion of using
unicode = no in smb.conf, it enabled the mapping of the
drive but the drive was not accessible with an error like
unexpected connetction error.

After applied the patch, NT was happy without unicode line
in smb.conf.

Qing 
Comment 10 Andrew Bartlett 2003-12-25 02:55:06 UTC
*** Bug 718 has been marked as a duplicate of this bug. ***
Comment 11 Gerald (Jerry) Carter 2004-01-06 10:30:56 UTC
patch works for both pam and non pam enabled builds.

Dana, I looked at your log and don't think the 
anonymous login is the problem.  It is more likely a 
local configuration issues (e.g. if you are not using PAM, 
smbd must be able to retrieve the UNIX des password hashes
which may not be possible if you are using nss_ldap or 
another NSS module).
Comment 12 Tony DeJoie 2004-01-06 15:19:11 UTC
Can you suggest what 'local configuration' may have a problem (Samba or Solaris
8)?  Samba v2.28 was previously running on the same system which had no problems
with Windows NT clients.
Comment 13 Gerald (Jerry) Carter 2004-01-06 16:12:43 UTC
2.2 didn't support unicode.  You can just set 'unicode = no' in 3.0 and
you should be ok.

However, I already didn't suggest possible local issues like 
PAM, nss_ldap, etc....
Comment 14 prudhomme 2004-07-08 01:28:18 UTC
I have the same problem :

smb.conf (server IP = 10.202.57.117)
********************************************************************************

[global]
        ...
        security = SHARE
        encrypt passwords = No
        ...

[admarche]
        path = ...
        valid users = arche    (Linux account with password "noe")
        read only = No
        create mask = 0777

log file with a nt4 client (just the part after i enter name/password to connect
to the share)
********************************************************************************

[2004/07/07 10:01:18, 10] lib/util_sock.c:read_smb_length_return_keepalive(488)
  got smb length of 114
[2004/07/07 10:01:18, 6] smbd/process.c:process_smb(890)
  got message type 0x0 of len 0x72
[2004/07/07 10:01:18, 3] smbd/process.c:process_smb(891)
  Transaction 39 of length 118
[2004/07/07 10:01:18, 5] lib/util.c:show_msg(465)
[2004/07/07 10:01:18, 5] lib/util.c:show_msg(475)
  size=114
  smb_com=0x75
  smb_rcls=0
  smb_reh=0
  smb_err=0
  smb_flg=24
  smb_flg2=32771
  smb_tid=0
  smb_pid=51966
  smb_uid=0
  smb_mid=2368
  smt_wct=4
  smb_vwv[ 0]=  255 (0xFF)
  smb_vwv[ 1]=    0 (0x0)
  smb_vwv[ 2]=    0 (0x0)
  smb_vwv[ 3]=    7 (0x7)
  smb_bcc=71
[2004/07/07 10:01:18, 10] lib/util.c:dump_data(1858)
  [000] 20 6E 00 6F 00 65 00 00  00 30 00 2E 00 00 00 5C   n.o.e.. .0.....\
  [010] 00 5C 00 31 00 30 00 2E  00 32 00 30 00 32 00 2E  .\.1.0.. .2.0.2..
  [020] 00 35 00 37 00 2E 00 31  00 31 00 35 00 5C 00 41  .5.7...1 .1.5.\.A
  [030] 00 44 00 4D 00 41 00 52  00 43 00 48 00 45 00 00  .D.M.A.R .C.H.E..
  [040] 00 3F 3F 3F 3F 3F 00                              .?????. 
[2004/07/07 10:01:18, 3] smbd/process.c:switch_message(686)
  switch message SMBtconX (pid 12159) conn 0x0
[2004/07/07 10:01:18, 3] smbd/sec_ctx.c:set_sec_ctx(288)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2004/07/07 10:01:18, 5] auth/auth_util.c:debug_nt_user_token(486)
  NT user token: (NULL)
[2004/07/07 10:01:18, 5] auth/auth_util.c:debug_unix_user_token(505)
  UNIX token of user 0
  Primary group is 0 and contains 0 supplementary groups
[2004/07/07 10:01:18, 5] smbd/uid.c:change_to_root_user(288)
  change_to_root_user: now uid=(0,0) gid=(0,0)
[2004/07/07 10:01:18, 4] smbd/reply.c:reply_tcon_and_X(378)
  Client requested device type [0] for share []
[2004/07/07 10:01:18, 7] param/loadparm.c:lp_servicenumber(4034)
  lp_servicenumber: couldn't find 
[2004/07/07 10:01:18, 10] lib/username.c:Get_Pwnam(287)
  Get_Pwnam: empty username!
[2004/07/07 10:01:18, 3] smbd/service.c:find_service(130)
  checking for home directory  gave (NULL)
[2004/07/07 10:01:18, 3] smbd/service.c:find_service(142)
  checking whether  is a valid printer name...
[2004/07/07 10:01:18, 0] printing/pcap.c:pcap_printername_ok(253)
  Attempt to locate null printername! Internal error?
[2004/07/07 10:01:18, 3] smbd/service.c:find_service(153)
   is not a valid printer name
[2004/07/07 10:01:18, 3] smbd/service.c:find_service(190)
  find_service() failed to find service 
[2004/07/07 10:01:18, 0] smbd/service.c:make_connection(765)
  rmap_a_s (10.202.55.118) couldn't find service 
[2004/07/07 10:01:18, 3] smbd/error.c:error_packet(118)
  error packet at smbd/reply.c(386) cmd=117 (SMBtconX) NT_STATUS_BAD_NETWORK_NAME
[2004/07/07 10:01:18, 5] lib/util.c:show_msg(465)
[2004/07/07 10:01:18, 5] lib/util.c:show_msg(475)
  size=35
  smb_com=0x75
  smb_rcls=204
  smb_reh=0
  smb_err=49152
  smb_flg=136
  smb_flg2=51201
  smb_tid=0
  smb_pid=51966
  smb_uid=0
  smb_mid=2368
  smt_wct=0
  smb_bcc=0
[2004/07/07 10:01:18, 6] lib/util_sock.c:write_socket(432)
  write_socket(22,39)
[2004/07/07 10:01:18, 6] lib/util_sock.c:write_socket(435)
  write_socket(22,39) wrote 39

********************************************************************************

In the data dump, we can see the password and the path to the share.
Unfortunately the password seems to have a lenght of 8 bytes (unicode ?). When i
try with a Windows 2000 client, it works. The differences are :

- the Windows 2000 client send first some messages (SMBsesssetupX, etc...)
- when the Windows 2000 client send the SMBtconX message, password has a lenght
of 4 bytes (ASCII ?).

It seems that there is no patch for reply_tcon_and_X in smbd/reply.c
The consequence for the password format is, i guess, that the path to the share
is not read correctly by reply_tcon_and_X, and thus is null ( see the log
"Client requested device type [0] for share []"). That's why Samba returns a
NT_STATUS_BAD_NETWORK_NAME

If i change the protocol from NT1 to LANMAN2 in smb.conf, NT4 client to act as a
 Windows 2000 client (the client send first some messages (SMBsesssetupX,
etc...)) and it works fine. But i dont know the consequence (?) of such a change...
Comment 15 Gerald (Jerry) Carter 2005-08-24 10:16:10 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.