Windows Executable File Authentication

Question

Searching around the windows authentication methods and protocols, i decided to understand the exact difference between Negotiate, Kerberos, and NTLM used in a simple executable file before liking it with IIS and Web Authentication.

I reached to good results, BUT I still need more details about the Negotiate and Kerberos.

I have the following scenario :

I have created very simple C# windows forms application that shows a message box displays the value for :

System.Security.Principal.WindowsIdentity.GetCurrent().AuthenticationType

Note that i'm a domain user with admin privileges on my local machine, I have the following results :

1. When i run the exe file (double click) while i'm actively connected to the DC, i got "Negotiate".

2. When i run the exe file (run as differnet user / using local user) while i'm actively connected to the DC, i got "NTLM".

3. When i run the exe file using "Run as Administrator", or "Run as Different User" i got "Kerberos".

4. When i run the exe file while i'm locally logged in using local account, i got "NTLM".

I understand that the LSA will use NTLM for local accounts. Also i understand that Active Directory uses Kerberos to authenticate domain users and computers.

My question is, why i'm getting the Negotiate Authentication Type when i run the exe using my account either by (Double Click), or "run as different user" using my Same account ?

Update : I noticed the following :

- If local user is running the exe then it is NTLM
- If domain user run the exe then it is Negotiate (If that user is local admin) but is is Kerberos (if that user is not local admin)
- If domain admin run the exe then it is Kerberos

I just a clarification about this behavior.

Takashi

The question is unclear. The authentication package used to authenticate a user is distinct from the protocol used to authenticate the user and each of the is distinct from the entity which performs the authentication. There isn't a one-to-one(-to-one) relationship. NTLM and Kerberos (and Negotiate) are relevant only when authentication to a remote computer. Authentication to a remote computer in a non-domain environment will use NTLM and authentication to a remote computer in a domain will use either Kerberos or NTLM. What exactly are you trying to find out? – Allsun

This is not true. A local machine also uses an authentication package to authenticate the logon credentials collected by Winlogon via the GINA. Winlogon calls LsaLogonUser, which uses an authentication package to create the logon session. The LSA uses NTLM (Msv1_0.dll) to look up the account in the local machine SAM in the case of a local logon; no remote computer needed. – Shih

You're not even close. The fact that some pages (such as the one you linked in your answer) incorrectly describe MSV1_0 as "NTLM" doesn't mean that the NTLM protocol - the one described in [MS-NLMP] - is being used. (The correct description is Microsoft Authentication Package v1.0, btw.) I don't know how I can be any more clear on this point. When you authenticate against the local SAM, nobody creates a challenge and nobody creates a response to that challenge based on the LM or NT hashes of the password. – Allsun

And GINA is deprecated for almost a decade and doesn't exist anymore for two years minus 5 days. – Allsun

It is close, even if details have changed in current versions of Windows. The LSA uses authentication packages to do authentication. The MSV1_0 package implements the NTLM protocol as well as uses the local SAM to lookup account info. At one time there wasn't much difference between the protocol and the implementation since it was all hidden. The challenge / response is a straw man - the LSA still delegates authentication in a provider specific way, depending on the provider, which was the point of the question and the answer. – Shih

Yes, it looks like the GINA was replaced with Credential Providers as of Vista which provide the same function - provide credentials. These get passed to the authentication package in the same way. I gather you've read Keith Brown's book. You might want to re-read it to get the overall architecture points down. – Shih

Answer 1

First off, (which you seem to understand in the question, but just to be clear) an EXE doesn't have any authentication - it is just an executable. The OS creates a process object which executes it within a logon session identified by a principal. It's this principal which has been authenticated by NTLM or Kerberos (or some other protocol).

Next, Negotiate means that when the logon session was created the Negotiate authentication package was used to decide which authentication package - Kerberos or NTLM - would be used.

When you query the WindowsIdentity.AuthenticationType value, you are ultimately calling a function in the Local Security Authority (LSA) called LsaGetLogonSessionData. This reports details of the logon session used to run the process you are executing. The way that this logon session was created probably has the largest effect on the authentication package used to verify the credentials.

When logging into Windows the first time, Winlogon.exe establishes an interactive logon by calling LsaLogonUser. It queries the authentication packages in HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages in order until it finds one that can authenticate the given credentials. Once an interactive logon has been established, you can create new processes using noninteractive logons under different credentials, and in this case, the LogonUser function is likely called. One of the parameters to this function is dwLogonProvider which has the following default (which is likely the one used):

LOGON32_PROVIDER_DEFAULT 

Use the standard logon provider for the system. 
The default security provider is negotiate, unless you pass NULL 
for the domain name and the user name is not in UPN format. 
In this case, the default provider is NTLM.

So, the package reported for the logon session the process is running under depends on how the logon session was created. (It isn't clear from your question exactly how you create the logon sessions you are testing... doing "Run As" in all cases? Logoff / Logon Windows for some cases?) It also depends on which package Winlogon was able to successfully authenticate with first for the interactive logon session. Ultimately, though, note that the authentication mechanisms all call down to some authentication package, and if Negotiate is used, Kerberos is preferred, though Negotiate is what is reported.

Here is an old but still relevant diagram which shows how all the authentication fits together in Windows:

Source

Shih

Re. your quote from the LogonUser docs - what if I want to use another authentication package? LsaLogonUser allows this? I also believe the documentation is misleading in a few aspects: I'm guessing for domain users MSV1_0 is used and it MSV1_0 which checks for cached credentials and otherwise uses Negotiate, and it certainly is MSV1_0 that is used for local users. I'm willing to bet the used-supplied password is compared to the one stored in the SAM rather than playing a silly challenge-response game within the LSA. – Allsun

Yes, you can specify any authentication package during logon (in fact this is what you can do via implementing your own GINA / authentication package). Winlogon gets an ID for the package via LsaLookupAuthenticationPackage and then passes the value returned to LsaLogonUser. For domain users, you can use MSV1_0 (though pass-through is handled specifically by that package, not the LSA), or you can use Kerberos. For a local logon, like the doc states "you pass NULL for the domain name and the user name is not in UPN format" to get NTLM, and then the NTLM package (not LSA) will use the SAM. – Shih