I sent the following to the first guy reporting the "NT server
dropping apps due to samba" problem. I haven't had any feedback so I
don't know if it helped him or not.
The synopsis is that when samba does his 'man in the middle' server
authentication the PDC thinks that the original client connection is
no longer valid and drops it. The fix is for samba to not use the
same name as the client when connecting to the PDC.
Hope it helps the other guys who reported it.
Frank Varnavas
----------------------------------------------------------------
Jeffery:
I have not experienced the *exact* problem you describe what I have
experienced may explain your situation as well. I think you are
suffering because your PDC is also your file server, and when using
samba with 'security=server' the PDC will disconnect from your NT
desktop when samba does his authentication. In my environment the
problem was triggered when
1) I was using a broken version of a windows/NT multi-user
environment like windd
2) Some service on the NT desktop is connecting to the samba server
before a user logs in
Here's the sequence for #2:
Assume NT workstation CLIENT, samba server SAMBA,
password server NTSRV, and user USER
CLIENT, with no one logged in, connects to SAMBA
SAMBA establishes a session with NTSRV but tells him he is *really* CLIENT
USER logs in on CLIENT
CLIENT establishes a session with NTSRV to authenticate USER
NTSRV closes the session he had with SAMBA because he thinks it's now
obsolete
USER tries to mount a share from SAMBA.
SAMBA tries to authenticate USER, but gets SIGPIPE because connect to NTSRV
was closed by NTSRV
SAMBA dies (if you dont have my other patch) or just says 'password server
is not connected' if you do.
In your case when samba connects to the PDC and says he is *really*
CLIENT the PDC disconnects his earlier connection. Why this
disconnects your file shares as well I don't know.
My hack for this problem is to have SAMBA connect to NTSRV but
identify himself as WINDDPID, where PID is the pid of the running
daemon. NTSRV does not seem to validate the name anyway
change goes in password.c, function server_cryptkey. Look for below,
where he uses the name of the remote machine (CLIENT) as 'my name'.
/* and my name */
p = outbuf+len;
name_mangle(remote_machine,p,' ');
len += name_len(p);
replace with:
/* and my name */
if(1){
char buf[32]; /* create name as namePID */
sprintf(buf,"%s%d", remote_machine,getpid() );
DEBUG(1,("negprot w/password server as %s\n",buf));
p = outbuf+len;
name_mangle(buf,p,' ');
len += name_len(p);
}
If you want to test w/o the patch you can probably change the security
to user mode, or connect samba to the BDC (I never tried this!).
Good Luck,
Frank Varnavas
samba@samba.anu.edu.au writes:>
> Date: Wed, 27 Aug 1997 10:36:30 -0500
> From: "Jeffery G. Smith" <smithj@pobox.com>
> To: "Samba User's List" <samba@anu.edu.au>
> Subject: Samba causing NT client app dropouts?
> Message-ID: <199708271537.KAA14146@sagan.phys.ksu.edu>
>
> We have a reasonably complicated network setup and have been suffering an
> ongoing problem for over a year. I have been working with Microsoft tech
> support on the problem and so far we have been unable to find the cause.
> I
> recently gathered some information to indicate that samba is involved.
A> ny
> help is greatly appreciated.
>
> NT: About 20 Windows NT 4.0SP3 Pentium workstations with one PDC and one
> BDC. The PDC offers file, printer and application service.
>
> UNIX: About 20 SunOS/Solaris workstations with two Sparc5 servers. One
r> uns
> SunOS and the other Solaris. Both are running Samba 1.9.16p10
>
> The Problem: When users log in, a login script mounts four drives, two
fr> om
> the NT file server and one from each of the Sun servers. Users
frequentl> y
> run applications which reside on the NT shared drives, anything from PFE
> to
> Netscape and MSOffice. Periodically, these applications will just exit
> unexpectedly. This problem has been persisting for over a year.
Through> an
> enormous amount of debugging and testing it looks as though something is
> causing the redirector to dismount and remount the NT shares causing the
> applications to think the connection was lost. Part of the catch was
tha> t
> there seemed to be nothing I could do to force an occurrence of these
> "dropouts". Recently however I was able to find such a
situation. I hav> e
> removed the Samba mounts from the login scripts and now allow them to be
> mounted as a result of the user profile. This causes all the
application> s
> in the startup group which reside on the NT app server to die immediately.
>
> I use to experience these dropouts at least once a day. Since I have
> stopped using Samba to mount the drives on my workstation, I no longer
ha> ve
> this problem although it persists for other users. I have been up and
> running now for quite some time, but if I open a command prompt and so
mu> ch
> as net view the samba server, the applications I am running on the NT
ser> ver
> will fail.
>
> I really hope not to get a lot of responses for simple things involving
N> T
> or hardware. This is not tied to any one Ethernet card or video card or
> brand of computer, for instance. I spent a week taking network usage
dat> a
> to rule out a network load problem. We are running 10Mb Ethernet over
co> ax
> and the problem is as likely to happen at 10% utilization as at 80%.
> Microsoft has looked at several miles of network trace sessions between
t> he
> NT client and the NT server and there doesn't appear to be anything
wrong
> there either. They would like to see similar network traces between the
> NT
> client and the samba server and I plan to set that up soon.
>
> I did want to post this here though to see if anyone else has experienced
> this problem. I posted this question a year ago without any response.
M> y
> hope is that with the increased usage of samba over the recent past,
some> one
> has encountered and fixed this little annoyance. It might just be
someth> ing
> simple and configurable with samba that I have overlooked and
suggestions> of
> that nature would be welcome. Until now I hadn't looked at samba as
the
> cause of the problem, so not much research has been done on that front.
>
> Again, your help is greatly appreciated as I would much prefer to
continu> e
> using Samba over an NFS solution.
>
> --
> Recuerde--nunca vuelva a utilizar el mismo perservativo
>
> /* Jeffery G. Smith, MCSE, smithj@pobox.com *
> * BS-RHIT, MS-OSU, DJ-WMHD (aka Doc. Insomnia) *
> * Physics Computer Support Team *
> * http://pobox.com/~smithj/ */
>