Why Negotiate choose NTLM instead of Kerberos?

[Speedo]

Hi All

I'm trying SSPI calls on a Windows Server 2008, using
InitializeSecurityContext() to generate the first token sent to a peer
with SPN like http/host.local.domain. When the package name is given
as "Kerberos", it creates a nice Kerberos token. When package name be
"Negotiate", it creates an NTLM token.

My question is, how can I let Negotiate choose Kerberos as the
underlying mechanism. It should be safer than NTLM, right?

On the other hand, if the peer is a normal user (say, Administrator).
Both Negotiate and Kerberos emit a token using Kerberos, the user2user
TGT-REQUEST token.

Thanks
Goo

[DaveMo]

Post by Speedo
Hi All
I'm trying SSPI calls on a Windows Server 2008, using
InitializeSecurityContext() to generate the first token sent to a peer
with SPN like http/host.local.domain. When the package name is given
as "Kerberos", it creates a nice Kerberos token. When package name be
"Negotiate", it creates an NTLM token.
My question is, how can I let Negotiate choose Kerberos as the
underlying mechanism. It should be safer than NTLM, right?
On the other hand, if the peer is a normal user (say, Administrator).
Both Negotiate and Kerberos emit a token using Kerberos, the user2user
TGT-REQUEST token.
Thanks
Goo

If ISC works correctly using Kerberos explicitly, it should work using
Negotiate. The code path for Nego simply tries Kerb first and only
falls back to NTLM if the SPN or account is not found. Since the SPN
worked using Kerb, this should not be the case. Recheck everything
including the SPN. Try registering a new SPN like HTTP/TEST and assign
it to the account that you are running the SSPI peer with.

HTH,
Dave

[Speedo]

Thanks Dave, I do more experiments and find this pattern:

Now I have two Windows Server 2008 (say, host1 and host2) joining the
same domain. When I'm on host1, I can get a Nego token using Kerberos
for http/host2, but NTLM for http/host1. When I'm on host2, http/host2
NTLM and http/host1 Kerberos. So, it seems you cannot get a Nego token
using Kerberos for the machine you're running on. Is this a designed
bahavior?

I have a Wireshark running on the AD server (host1). When I run ISC
targetting http/host1 on host2, TGS-REQ/REP packets can be observed.
When targetting http/host2, no TGS-REQ is ever tried.

Post by DaveMo
worked using Kerb, this should not be the case. Recheck everything
including the SPN. Try registering a new SPN like HTTP/TEST and assign
it to the account that you are running the SSPI peer with.

I have no SSPI peer running. In fact, my program is not communicating
with any program at the moment -- I'm not happy with the first token
from ISC.

Thanks
Goo

[DaveMo]

Post by Speedo
Now I have two Windows Server 2008 (say, host1 and host2) joining the
same domain. When I'm on host1, I can get a Nego token using Kerberos
for http/host2, but NTLM for http/host1. When I'm on host2, http/host2
NTLM and http/host1 Kerberos. So, it seems you cannot get a Nego token
using Kerberos for the machine you're running on. Is this a designed
bahavior?
I have a Wireshark running on the AD server (host1). When I run ISC
targetting http/host1 on host2, TGS-REQ/REP packets can be observed.
When targetting http/host2, no TGS-REQ is ever tried.

Post by DaveMo
worked using Kerb, this should not be the case. Recheck everything
including the SPN. Try registering a new SPN like HTTP/TEST and assign
it to the account that you are running the SSPI peer with.

I have no SSPI peer running. In fact, my program is not communicating
with any program at the moment -- I'm not happy with the first token
from ISC.
Thanks
Goo

Ahh. You are observing NTLM loopback behavior. The LSA will shortcut
the authentication process if it sees that there is already a token on
the box for the account you are trying to authenticate as. The LSA is
faily single-minded about these kinds of things. It knows that the end
result of authentication is generating the logon token so if it sees a
way to shortcut the process that is usually what happens. There are
real benefits to this, of course, as avoiding unneccessary round trips
to the KDC is normally a good thing.

In the case where you are targetting the host account for the computer
where you are running the process, then of course the token already
exists and the logon credentials can be verified using information
that is already cached locally. The NTLM provider handles this
scenario. If you were to create a service account (a domain user
account) and run the SSPI peer (AcceptSecurityContext) under that
account then you would see Kerberos as you might expect.

HTH,
Dave

[Speedo]

Post by DaveMo
Ahh. You are observing NTLM loopback behavior.

Ahhh, thanks!

Well, I'm playing with the wfetch tool from MS's IIS6 Resource Kit.
When domain/username/password given, the tool performs a real Kerberos-
based Negotiate. I guess it simply does not use the local cached
credentials and manage the logon/authentication process all by its
own.

Do you know if MS provides the source code for wfetch?

Thanks again
Goo

[DaveMo]

Post by Speedo

Post by DaveMo
Ahh. You are observing NTLM loopback behavior.

Ahhh, thanks!
Well, I'm playing with the wfetch tool from MS's IIS6 Resource Kit.
When domain/username/password given, the tool performs a real Kerberos-
based Negotiate. I guess it simply does not use the local cached
credentials and manage the logon/authentication process all by its
own.
Do you know if MS provides the source code for wfetch?
Thanks again
Goo

I've never seen the source for wfetch, so no I'm not aware if it is
available.

I'm not sure I understand your description of your use case using
wfetch. If you would like additional input let me know what
differences you are seeing between using wfetch and your original
observations.

Dave

[Speedo]

I mean when I use wfetch to target http/my.local.machine, when domain/
user/pass is left empty, the authentication token is NTLM; with those
fields filled, token is Kerberos.

Goo

[DaveMo]

Post by Speedo
I mean when I use wfetch to target http/my.local.machine, when domain/
user/pass is left empty, the authentication token is NTLM; with those
fields filled, token is Kerberos.
Goo

Depending on how you set up your cred structures, with no username/pwd
the authentication attempt is likely "anonymous" and anonymous logon
is always NTLM. There's no key for "anonymous" in the KDC.

Dave