Handling Kerberos principals that don't match hostnames

In trying to troubleshoot why Kerberos authentication is not working
with our particular setup, I came across some interesting things.  CIFS
currently assumes the principal is either cifs/hostname or host/hostname
(a feature of cifs.upcall).  Not a problem there, per-se, but this
doesn't seem to be a 100% reliable method for determining the principal,
either.  In our case, two circumstances seem to foul up everything:

1) Load balancing, where the client connects to a virtual IP and gets
handed off to a real server.
2) CNAMEs.

smbclient got around these issues by using some data returned by Windows
2003 servers that revealed the SPN clients should use, it seems.
However, 2008 Server has removed this, and the CIFS kernel module
doesn't even try.  So, I started digging for the way Windows does it to
see if the SPN can be determined in a somewhat reasonable fashion.

I've found that the servers return a bevy of information, including the
NetBIOS domain, NetBIOS hostname, DNS domain, and DNS hostname as a part
of the NTLMSSP response... specifically, the NTLMSSP_CHALLENGE packet.
This reveals the real hostname of the machine that you are connecting
to.

So, getting to the point, is it feasible to use the NTLMSSP
process--just so far as to get the challenge packet back--and parse for
the real information?  Granted, it's not the cleanest option, but I've
been trying to think of any way to determine the hostname to connect to
cleanly, and this is the best I can think of.  If the actual hostname is
determined, the upcall program shouldn't even need to be changed.

Thanks!

--Doug Kelly