This is a discussion on [Samba] Windows sometimes authenticates with wrong user - Samba ; Sorry in advance for the long post. But this is a bit of a detective story. We are having an authentication issue with a small number of Windows XP (SP2) machines. The Windows machines are set up to have only ...
Sorry in advance for the long post. But this is a bit of a detective story.
We are having an authentication issue with a small number of Windows XP
(SP2) machines. The Windows machines are set up to have only a single user --
let's say the user is called "Writer". There is no password set up for this user
called "Writer". User1 logs on to the machine and connects to our Linux Samba
Server (3.0.13). None of the shares on the server allow guests (guest ok =
no) -- so when connecting to a "public" share on the server, User1 is prompted
for a username and password. User1 supplies his Linux/samba username and
password -- the server authenticates him -- and now he can access the "public"
shares. His own private shares also now become visible (home directory, and
shares defined with a %u variable in the path).
All is fine. This is how things are supposed to work
But now, User1 logs off (literally logs off Windows -- back to the Windows
user log on screen -- fast user switching is NOT enabled) and a couple of
minutes later User2 logs on. When User2 clicks on a public share, on these
Windows machines she is NOT asked for a username and password. Instead, she
immediately gets access to the "public" share and can also see and use all of
User1's private shares!
For some reason, it seems Windows is still telling the Samba Server that it
is User1 who is connecting -- Windows has not forgotten that User1 logged out
-- and Samba just obliges and serves up User1's shares.
We see the same behavior if we disconnect shares via "net use * /d". The
shares disconnect, but when we connect again we're not asked to authenticate
This behavior is extremely rare. We have thousands of Windows clients
accessing hundreds of Samba Servers. In many of the cases, users log on and log off
just as I described above without any problem. But we have a few machines
out in the field that just keep behaving in this unexpected way (Note:
Unfortunately, it's not always feasible for users to log in on every Windows client
where they might work with usernames and passwords that match their
Linux/samba names and passwords. We encourage organizations that have users moving
around a lot to set up a PDC, but many can't do that so they use our "on the
My question is: is there a way to force Windows to clear all knowledge of
what user was previously using a machine?
I kind of doubt this is a Samba issue. But COULD IT BE POSSIBLE that Samba
is matching up a Username to a Mac address or IP address and therefore not
recognizing that one user has logged out (disconnecting all network shares) and
another logged on? Is there something that can make Samba hold on to thinking
User1 is still connected when it's acutally User2? If so, what can we do to
Can a switch that's in between the client and server be a culprit?
As a related issue -- we produce servers that are deployed in isolated and
totally separate environments. The servers ALL go out with the exact same
NetBios names. They are essentially clones of one another -- and all have the
same set of "public" shares. We always test the servers in our office before
they go out. Over time, a couple of our Windows clients in the office just
won't connect to certain "public" shares on the Samba Machines. We get an error
message to the effect of "Windows can't find this resource requested or you
don't have authority to access this resource. Please consult with your network
administrator" We don't get a username and password prompt. If we click on a
DIFFERENT public share, we get the username and password prompt. After
authenticating, we can THEN access the first share that gave us the error.
My question is, can Windows machines get stuck thinking that a share called
\\Server\ShareA that it ONCE connected to on a "Server Serial # 131" is
still supposed to be the same share that when we try to connect to
\\Server\ShareA on "Server Serial # 133 -- and because it's not exactly the same share (how
could windows figure that out -- by the Mac Address of the Server?), it
throws the error?
Again, we cycle many "server clones" into and out of our place and this is a
rare event. But we have a two Windows clients that sometimes seem to resist
the switch from one server to another. The Windows clients can be shut down
for days, but when we boot them up again and try to connect to a completely
different server, we can have this issue. Is there some sort of cache on the
Windows clients that we can clear out?
By the way, we use Samba 3.0.13 on our systems because of a couple of
specific Samba issues that appeared in 3.0.14 and 3.0.20 that affect our software
and that haven't yet been resolved.
We also do NOT tell Windows to "reconnect at logon".
Hope somebody can shed some light here.
To unsubscribe from this list go to the following URL and read the