This is very frustrating, because it worked once, and now doesn't.

I have built Samba 3.0.1 on Red Hat 8 and am attempting to share
files for users with accounts on a Windows 2000 server that is
the master for a tiny Active Directory Domain. The smb.conf file
for the Samba server (named Tripoli) follows. The WIndows server
is 137.xx.yy.zz:


[global]
realm = TEST.OURCOMPANY
security = ADS
encrypt passwords = yes
password server = 137.xx.yy.zz
dos charset = CP850
unix charset = UTF8
display charset = UTF8
workgroup = TEST
local master = no
hosts allow = 137.xx. 198.xx.xx. 128.xx.
username map = /usr/local/samba/lib/usermap
idmap uid = 20000-30000
idmap gid = 20000-30000
winbind separator = +
winbind enum users = yes
winbind enum groups = yes
[data]
path = /data
writable = yes
[software]
path = /export/software
writable = yes


The krb5.conf file:

[libdefaults]
default_realm = TEST.OURCOMPANY
[realms]
TEST.OURCOMPANY = {
kdc = 137.xx.yy.zz:88
}
[domain_realms]
.our.domain.com = TEST.OURCOMPANY


I have successfully done the "net ads join" thing, and Tripoli
is listed in "Active Directory Users and Computers" on the Windows server.
Kerberos appears to work fine: I can kinit to get a ticket from
the Windows server, and use smbclient to see shares on that server
using passwordless Kerberos authentication. Winbind also appears
to be running properly and lists the "TEST+" users and groups as
expected. But when I attempt to list the Tripoli shares from smbclient,
I see:

[2004/01/08 08:05:56, 1] smbd/sesssetup.c:reply_spnego_kerberos(172)
Failed to verify incoming ticket!
[2004/01/08 08:05:56, 1] smbd/service.c:make_connection(792)
make_connection: refusing to connect with no session setup

in the smbd log, and

tree connect failed: NT_STATUS_ACCESS_DENIED

is output by smbclient. Similar results occur when attempting to map
shares, or browse Tripoli, from the W2K system. A curious thing
is that after doing this, a 'klist' shows that I was granted a ticket
for the principal "tripoli$@TEST.OURCOMPANY"...so why are things
still unhappy.

The very frustrating thing about this is that, experimentally, I set
things up identically on a Solaris 8 system back in September with
Samba 3.0.0beta3. That Samba server is still running, and works
just fine in its limited way. I cannot see what I am doing differently.
Searching the message archives suggests that winbindd has to be running
(although it is not, on the Solaris system), but setting winbindd up
did not change the situation.

Another curious thing is that while I was experimenting with this yesterday
(with no winbindd set up), a user on a workstation in a different domain
was accidentally able to successfully map one of these shares to his
workstation, using his Kerberos password.

Any suggestions?

Mike