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.
please send me a level 10 debug log. You may mail it to me directly if you wish. Thanks.
confirmed and easily reproducible with encrypt passwords = no.
did you compile --with-pam ?
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:. ~
Created attachment 324 [details] Here is the patch.
I have fixed this with the given patch in CVS. Jeremy.
Created attachment 329 [details] Level 10 logs of an NT client trying to map a drive
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.
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
*** Bug 718 has been marked as a duplicate of this bug. ***
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).
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.
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....
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...
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.