samba - Feb 2008 - smbclient error message interpretation

Hi all,

For sure I'm dense today. I use smbclient rarely - every few years just to
test a new setup. I'm building a replacement server, and want to go from an
smbpasswd setup to an ADS member setup. The smbpasswd setup has worked just
fine for the Windows workstations, but we'd like the convenience of just
maintaining the users in one place through Windows.

So I'm going through the "rough guide" at
http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html
and have got to where the "net ads join" works. Then I'm trying to
test it
with smbclient. All that doc says is "Use smbclient as usual, but specify
the -k option." My problem obviously: I don't usually use smbclient.

Smbclient takes me straight to an error message:

"Server not using user level security and no password supplied."

This happens even when I've just been presented with a password prompt and
given it what should be a good password. And it happens if the password is
in the command line in the --user=username%password syntax. While I don't
know quite what the first part of the message points to, the "and no
password supplied" is, in common sense English, plain wrong.

Obviously there a Samba English in which it's entirely correct and
illuminating. What I'm looking for is the dictionary. Even more confusing: I
get the exact same error message from smbclient on the smbpasswd-based box:

smbclient //BLAH/BLAH --user=whit
Password: ******
Server not using user level security and no password supplied.

(The difference from the first is just the omission of "-k".)

What? On this box, there are current users from our Windows clients. So
maybe I'm using smbclient wrong, but how? In the ADS version of this,
I've
got "security = ADS" set in smb.conf. In the smbpasswd version,
security's
whatever it defaults to. Isn't ADS in the category of "user level
security"?
And on the smbpasswd-secured box, those users not specified in smb.conf have
no access to the shares, so isn't that "user level security"?
Something's
being lost in my attempt at translation into common English. That leaves me
at a loss as to what to look to fix.

Apologies again for the fog I'm in with this. Thanks for all pointers.

Whit

Less confused than when I posted yesterday. But still not golden.

The ADS stuff works if I test with nsswitch.conf containing _only_ winbind,
like:

passwd:         winbind
group:          winbind

But if I have it as "files winbind" (of course necessary to not have
the
local accounts time out and the system become unusable) then there are
problems. Trying a login with smbclient from another box with the same ADS
user which works when it's just winbind for passwd and group logs the error:

[2008/02/14 13:16:39, 2] smbd/service.c:make_connection_snum(616)   
  user 'whit' (from session setup) not permitted to access this share
(BLAH)

While smbclient shows:

tree connect failed: NT_STATUS_ACCESS_DENIED

But 'whit' is in the valid users list in smb.conf for that share, and is
working with the winbind-only configuration of nsswitch.conf, as well as
with the smbpasswd-only configuration of samba. It works if I comment out
the ADS lines from smb.conf, and run against an smbpasswd file.

When Samba's doing ADS, even with "files winbind" in the
nsswitch.conf
settings, and 'whit' in smbpasswd, running with the smbpasswd password
for
'whit' produces:

session setup failed: NT_STATUS_LOGON_FAILURE

But "files" should have had it looking to system files first, right?
So it
should have succeeded rather than fallen through to NT_STATUS at all? 

Searching through the list archives, there's a hint this may be connected to
pam issues? Have others run into this?

Best,
Whit