[PATCH] Add support for using server supplied principal (mic option)

simo idra at samba.org
Mon Aug 25 03:58:36 GMT 2008

On Sun, 2008-08-24 at 23:49 -0400, simo wrote:
> On Mon, 2008-08-25 at 02:38 +0100, Love Hörnquist Åstrand wrote:
> > 25 aug 2008 kl. 02.25 skrev Jeff Layton:
> > 
> > > Everything I've read does say that windows clients don't use the
> > > contents of the MIC field. The idea was that this would be useful for
> > > allowing kerberos auth in situations where clients and servers have
> > > differing ideas about the hostname of the server (either broken DNS or
> > > maybe trying to mount a CNAME).
> > 
> > Semi modern windows servers doesn't put a hostname there, so it wont  
> > be much use either.
> > 
> > Windows just assume if you can look up the name, the same name will be  
> > in the SPN in the ldap.
> > 
> > > I'll confess though that I haven't thought through the security
> > > implications fully here. Obviously, we don't want to do this if it's
> > > dangerous...
> > >
> > > So that I understand correctly, what exactly is the risk of using the
> > > server-provided principal?
> > 
> > You try to connect to host/my.secrets.com at GOOD.COM, but since the host  
> > announces
> > host/will.fake.your.data.secrets.com at GOOD.COM you'll use that instead  
> > and never notice that you talk to wrong host.
> Love,
> this would be true if we used the name returned to connect to a
> different host.
> But we only do use it to get a ticket, we do not use the name to resolve
> an IP to which to connect as we are already connected to the host.
> Now, assuming the connection is already established, what would be the
> risk if the server is telling us the wrong name? The ticket we get from
> the KDC (after the connection is established) will work only if the
> server we are connected to actually has the corresponding keytab.
> Is there an attack vector that could be used here if the ticket we try
> to use is not in fact the one we should use ?

Uhmm, I should have thought a bit more, what you are saying is that a
user may be fooled (for example through DNS poisoning) to connect to
will.fake.your.data.secrets.com instead of my.secrets.com, because we
use the returned name to fetch the ticket, we will not "know" as users
that the server we are actually connected to is not the right one,
although it must obviously have been a trusted (by the KDC) one at some

This could be used by a compromised host to get access to data that we
think should be stored only on my.secrets.com

Given this reasoning, I agree this is indeed a security issue. If we
want to enable this behavior it must be optional and the users must be
warned in the documentation of the risks that activating such behavior
would imply.

Now assuming we cannot use this mechanism, what would you suggest as the
recommended way to get the right ticket in the case the SPN is not
immediately evident ?


Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>

More information about the samba-technical mailing list