Bug 7893 - CIFS tickets vs. <host>$ tickets
Summary: CIFS tickets vs. <host>$ tickets
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: libsmbclient (show other bugs)
Version: 3.5.4
Hardware: x64 Linux
: P3 normal
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2010-12-29 12:23 UTC by Nigel Benns
Modified: 2011-05-13 19:38 UTC (History)
1 user (show)

See Also:

patch for 3.5 (6.87 KB, patch)
2011-05-11 10:03 UTC, Guenther Deschner
metze: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Nigel Benns 2010-12-29 12:23:11 UTC
I found a behaviour difference between Windows and Samba.
I was actually having this problem:

I see that it is fixed with this patch:

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.

Comment 1 Stefan Metzmacher 2010-12-29 13:52:47 UTC
I guess this is already fixed in v3-6-test and master, see
Comment 2 Stefan Metzmacher 2010-12-29 13:55:45 UTC
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}

That's why cifs/* principal doesn't need to be specified explicitly.
Comment 3 Nigel Benns 2011-03-24 18:23:28 UTC
Can this get backported to 3.5.x series or will 3.6 be out soon?
Comment 4 Guenther Deschner 2011-05-11 10:03:55 UTC
Created attachment 6442 [details]
patch for 3.5

Yes, I think we should have this in 3.5 as well.
Comment 5 Stefan Metzmacher 2011-05-11 10:18:42 UTC
Comment on attachment 6442 [details]
patch for 3.5

Looks good...
Comment 6 Guenther Deschner 2011-05-11 10:19:48 UTC
Karolin, please add to 3.5
Comment 7 Karolin Seeger 2011-05-13 19:38:57 UTC
Pushed to v3-5-test.
Closing out bug report.