Samba currently hands out at least HOST and CIFS tickets for all domain members, even if they are not in the machine account's servicePrincipalName attribute. I'm guessing the genesis of this is the Windows DC behavior of handing out CIFS tickets, even though its not listed as a valid SPN typically. This behavior differs from Windows DCs and breaks older servers. 

Testing against a Windows 2008 DC, I observed that it will only issue HOST and CIFS tickets if the HOST SPN entry is present. If the HOST entry is not present, the DC will return KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. This ensures that TGS-REQs against the DC for NT4 client machines will fail.

This behavior is required to allow modern Windows clients (2000+) to connect to ancient SMB servers which do not have extended security support. Under a Samba DC, extended security capable Windows clients are unable to connect to servers which do not support extended security (ex NT4). 

i. The notes on http://msdn.microsoft.com/en-us/library/cc246806.aspx describe the observed behavior when Samba returns an SPN for a non-extended capable server:
<94> Section 3.2.5.2: When the server completes negotiation and returns the CAP_EXTENDED_SECURITY flag as not set, Windows-based SMB clients query the Key Distribution Center (KDC) to verify whether a service ticket is registered for the given security principal name (SPN). If the query indicates that the SPN is registered with the KDC, then the SMB client terminates the connection and returns an implementation-specific security downgrade error to the caller.

In short, Samba needs to stop fulfilling requests for CIFS and HOST SPN tickets if the HOST entry is not in the directory. If HOST is present, we should allow either HOST or CIFS.