NT User can't access share

[John J. LeMay Jr.]

It looks as though the initial password read from the NT box may be
failing and Samba is falling back on the smbpasswd file as a backup. To
verifiy a more detailed trace would probably be necessary.



John J. LeMay Jr.		Phone (732) 785-2525
NJMC, LLC.			  Fax (732) 974-1945
http://www.njmc.com	  Text Paging 1382836 at skytel.com

On Tue, 27 Jul 1999, Jeff Newton wrote:

> 
> I've done more digging and what I can't understand is even though
> security level = server and password server identified, samba decides
> to check the smbpasswd for this user.  Again, when the user is readded
> to the DomainUsers, he auths fine.  Here is the log output from a
> rejected attempt:
> 
> 1999/07/27 11:46:14 Transaction 1 of length 174
> switch message SMBnegprot (pid 21376)
> Requested protocol [PC NETWORK PROGRAM 1.0]
> Requested protocol [XENIX CORE]
> Requested protocol [MICROSOFT NETWORKS 1.03]
> Requested protocol [LANMAN1.0]
> Requested protocol [Windows for Workgroups 3.1a]
> Requested protocol [LM1.2X002]
> Requested protocol [LANMAN2.1]
> Requested protocol [NT LM 0.12]
> resolve_name: Attempting lmhosts lookup for name myserver
> resolve_name: Attempting host lookup for name myserver
> Connecting to 134.X.X.X at port 139
> connected to password server myserver
> got session
> password server OK
> using password server validation
> Selected protocol NT LM 0.12
> 1999/07/27 11:46:14 Transaction 2 of length 195
> switch message SMBsesssetupX (pid 21376)
> Domain=[PMC_NT]  NativeOS=[Windows NT 1381] NativeLanMan=[]
> sesssetupX:name=[contractor]
> trying NetWkstaUserLogon with password server myserver
> password server myserver gave guest privilages
> get_smbpwd_entry: unable to open file 
> /home/munin/samba-1.9.18p7/private/smbpass
> wd
> Couldn't find user contractor in smb_passwd file.
> NT Password did not match ! Defaulting to Lanman
> get_smbpwd_entry: unable to open file 
> /home/munin/samba-1.9.18p7/private/smbpass
> wd
> Couldn't find user contractor in smb_passwd file.
> 
> Can anyone offer some suggestions?
> 
> Cheers,
> 
> > I'm going to say none. The IPC$ "share" is a pipe connection that as 
> far
> > as I can tell needs to be opened prior to authentication. I belive 
> the
> > authentication process then takes place across this pipe.
> > 
> > 
> > John J. LeMay Jr.		Phone (732) 785-2525
> > NJMC, LLC.			  Fax (732) 974-1945
> > http://www.njmc.com	  Text Paging 1382836 at skytel.com
> > 
> > On Wed, 28 Jul 1999, Jeff Newton wrote:
> > 
> > > 
> > > Folks,
> > > 
> > > A remote admin is trying to add a contractor account to our NT
> > > domain with limited rights.  Unfortunately, everytime the 
> contractor
> > > account is removed from the DomainUsers group, the contractor 
> > > encounters the following:
> > > 
> > > \\nt-nfs-md\IPC$
> > > 
> > > and the infamous invalid password.  Once the user is re-added to 
> the
> > > DomainUsers group, they can access the share fine.
> > > 
> > > My question is what permissions must the remote admin give this 
> user
> > > to be able to access the IPC$ share? 
> > > 
> > > Any helpful suggestions would be appreciated.
> > > 
> > > Cheers,
> > > 
> > > ----
> > > Jeff Newton
> > > Unix Systems Administrator
> > > PMC-Sierra Inc.
> > > 
> > > 
> > 
> 
> ----
> Jeff Newton
> Unix Systems Administrator
> PMC-Sierra Inc.
> 
>