[Samba] Linux server, Win2k client: Almost works, what am I missing?

Kris Kelley skunk at simdesk.com
Thu May 16 16:12:03 GMT 2002


I wrote:
> > Once I fired up Samba, I tried to access it from a Win2k box, on which
> > I'm logged in as DEVGROUP/skunk (user "skunk" also exists on the linux
> > box, and the passwords are the same in both environments).  This failed
> > with the usual "account is not authorized to log in from this station"
> > error (clear text passwords are enabled on the Win2K box)...
> > 
> > However, when I used the "net use" CLI command to log in with user
> > "nobody", supplying "nobody"'s password, it worked!  The share was
> > successfully mounted...
> > 
> > I then tried putting "skunk" into Samba's user database [but] 
> > I still couldn't access the share as user "skunk"; I got the
> > same error message on the Win2K side and the same Samba log entries on
> > the linux side.
> > 
> > I should note that when I use smbclient, I can access the test share
> > just fine as user "skunk" on the linux box.
> >
> > There is no Win2k user "nobody" within the DEVGROUP domain, if that
> > provides any clue.

Joel Hammer wrote:
> ...this sounds like you are failing Test #10 in
> DIAGNOSIS.txt in the source documents.
> It suggests you enable encrypted passwords on the samba server.
> Maybe you didn't do the hack properly.

The hack consists of changing a single value.  A value named
"enableplaintextpasswords" is changed from 0 (not enabled) to 1
(enabled).

At any rate, I am becoming convinced that this is not an encryption
issue.  Why would encryption, or a lack of encryption, allow one user
("nobody") to access the share, but not another user ("skunk")?
 
But just to be sure, I re-enabled encrypted passwords on the Win2k box
and then also enabled encrypted passwords in Samba.  Using smbpasswd, I
set up passwords for both "skunk" and "nobody".  The very same thing
happened:  If I used user "nobody", I could access the share from the
Win2K box, but I could not with user "skunk"!  I know the password file
is being utilized, because if I disable user "nobody" (smbpasswd -d), I
am no longer to access the share as that user.

I wonder if this is something specific to the DEVGROUP/skunk account
that is being instigated by the Windows domain, somehow.  For another
test, I logged into WIN2KBOX as a DEVGROUP user besides "skunk", and
tried accessing the share with "skunk" ("net use /user:skunk
\\skunkworx\test").  At first it would let me in if the Samba password
for "skunk" was *different* than his Windows domain password, but after
several more attempts I could access the share even when they were the
same!  But then suddenly the DEVGROUP/skunk was locked out of all
Windows boxes!  When the sysadmin unlocked the account and
DEVGROUP/skunk was again able to log inot WIN2KBOX, again I could not
access the share as "skunk" (the passwords were again the same at this
point).

Confused?  I am!

I guess I'm going to try all this with an account that's hopefully less
volatile.  DEVGROUP/skunk is a domain admin and handles several
automated tasks on various machines within DEVGROUP, so I shouldn't be
playing with that account anyway.  But does this sound plausible?  Could
something within DEVGROUP be throwing a monkey wrench into the works
that makes Samba (sometimes) refuse access to the account, even though
tbe Windows boxex have no trouble?  I'm more than willing to believe
that, but I don't want to sweep this under the rug if there's still an
issue that's going to bite me later.

This is now my smb.conf file:

   [global]
      workgroup = DEVGROUP
      security = user
      netbios name = skunkworx
      encrypt passwords = yes
   [test] 
      comment = test share
      path = /export/samba/test
      read only = no

Thanks for all the help!

---Kris Kelley





More information about the samba mailing list