I found a behaviour difference between Windows and Samba. I was actually having this problem: https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=622790 I see that it is fixed with this patch: https://bugzilla.samba.org/show_bug.cgi?id=7890 But I still have a question about the difference I came across. First some background: I have been able to browse windows shares from Linux/Gnome/Nautilus no problem, except that sometimes I was able to see the shares on the host, but was prompted for a password when I tried to go into the folders. So I could access \\<host> and it would get a Kerberos ticket of <host>$@REALM, but when I tried to access \\<host>\<share> the authentication would fail and I would get prompted via NTLM. It turned out this was only happening on EMC Celerra hosts. I was looking at the differences between how Windows was requesting tickets and how Linux/Samba was doing it. In Windows if I access a share on our server, we get a ticket for cifs/<host>@REALM, but in Samba, we get <host>$@REALM. In order to tell this, I have been using kerbtray.exe in the Windows support tools pack. I am running Windows XP and the servers are 2003/2008. If I take a look at AD, I get spns of: servicePrincipalName: cifs/<hostFQDN> servicePrincipalName: cifs/<host> servicePrincipalName: host/<hostFQDN> servicePrincipalName: host/<host> no userPrincipalName for this account. The cifs service principal is ONLY on EMC Celerra hosts, nothing else, though I get tickets of cifs/ for hosts that DO NOT have the cifs/ SPN assigned to them as well (for a domain controller or a member server hosting shares). I don't know if the cifs principal is "there by default" so that any host can implement sharing, or if its some other spooky thing, but it seems 'proper' to be using a service principal instead of the user principal to access the shares as they are a service. Something as crazy as this could only be from Microsoft. I don't know if you want to do anything about this per se, but it is a difference between your implementation and Microsoft's, so I though I would bring it to your attention. Thanks!
I guess this is already fixed in v3-6-test and master, see http://gitweb.samba.org/?p=samba.git;a=commit;h=f13404e27b00f826a11684e69cff82ae0023fc91
AD has this sPNMappings: host=alerter,appmgmt,cisvc,clipsrv,browser,dhcp,dnscache,replicator,eventlog,eventsystem,policyagent,oakley,dmserver,dns,mcsvc,fax,msiserver,ias,messenger,netlogon,netman,netdde,netddedsm,nmagent,plugplay,protectedstorage,rasman,rpclocator,rpc,rpcss,remoteaccess,rsvp,samss,scardsvr,scesrv,seclogon,scm,dcom,cifs,spooler,snmp,schedule,tapisrv,trksvr,trkwks,ups,time,wins,www,http,w3svc,iisadmin,msdtc on the CN=Directory Service,CN=Windows NT,CN=Services,${CONFIGDN} object. That's why cifs/* principal doesn't need to be specified explicitly.
Can this get backported to 3.5.x series or will 3.6 be out soon?
Created attachment 6442 [details] patch for 3.5 Yes, I think we should have this in 3.5 as well.
Comment on attachment 6442 [details] patch for 3.5 Looks good...
Karolin, please add to 3.5
Pushed to v3-5-test. Closing out bug report. Thanks!