[Samba] "security = server" vs "security = domain" + samba auth problems

[Jake Carroll]

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