Hi all,
So, in a long running battle with samba service provisioning, I've run
up against an authentication problem. It was outlined in an email to
the list a few days ago. After coming to the conclusion that it is not
a kerberos issue (the kerberos MIT list helped me work through this),
I can now be fairly assured me issues are related to my samba config.
A global definitions list:
[global]
use sendfile = yes
interfaces = lo0 nge1
bind interfaces only = yes
unix extensions = no
password server = SOMEHOST.SOMEWHERE.NOWHERE.ORG
workgroup = STAFF
realm = SOMEHOST.SOMEWHERE.NOWHERE.ORG
netbios name = SOMEHOST.SOMEWHERE.NOWHERE.ORG
netbios aliases = SUN SAM-FS HSM
security = SERVER
use kerberos keytab = yes
encrypt passwords = yes
server string = HSM Fileserver
preferred master = no
domain master = no
local master = no
password level = 4
username level = 2
getwd cache = yes
guest account = nobody
log level = 1
debug pid = yes
log file = /var/samba/log.%m.%U
lock directory = /var/samba/locks
preserve case = yes
default case = lower
short preserve case = yes
case sensitive = no
printing = lprng
load printers = no
printcap name = /dev/null
client use spnego = yes
OK. So, the problem. My users can authenticate to this just fine. They
get a krb ticket perfectly and can happily r/w/x to things they are
allowed to do so with. The problem comes in when the user unmounts the
share, then tries to remount it with the same krb ticket.
Essentially, the client then tries to auth as "nobody". The only way
to fix this is to do a kdestroy on the client and get a fresh ticket.
Being told VERY strenuously that this wasn't a krb problem, I started
digging in the samba HOW-TO docs and found this, in a section talking
about the differences between "security = share, user, domain,
server" ...etc:
“ Why does server_validate() simply give up rather than re-establish
its connection to the password server? Though I am not fluent in the
SMB protocol, perhaps the cluster server process passes along to its
client workstation the session key it receives from the password
server, which means the password hashes submitted by the client would
not work on a subsequent connection whose session key would be
different. So server_validate() must give up. ”
I then read a very serious section saying that "security = server" was
bad, bad bad. I thought. OK - I will swap it to "security = domain". I
could then no longer connect to the service and kept getting (from /
var/samba/ logs):
[2008/08/13 10:34:45, 1, pid=21114] libsmb/clispnego.c:(265)
Failed to parse negTokenTarg at offset 54
Started to wonder why this was happening, then read more about
"security = domain" and found:
"In order for this method to work, the Samba server needs to join the
MS Windows NT security domain"
Well, of course I don't have this. I have a kerberised samba solaris
host using an OpenLDAP system as a PDC/KDC. How does one achieve
"security = domain" in this circumstance? How does my samba server
join the OpenLDAP "domain" per se?
Thanks.
JC--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
