Authentification de fichiers exécutables Windows

Question

En recherchant les méthodes et les protocoles d'authentification Windows, j'ai décidé de comprendre la différence exacte entre Negotiate, Kerberos et NTLM utilisé dans un fichier exécutable simple avant de l'utiliser avec IIS et l'authentification Web.

J'ai atteint de bons résultats, MAIS j'ai encore besoin de plus de détails sur le Negotiate et Kerberos.

Je le scénario suivant:

J'ai créé très simples fenêtres C# forme application qui affiche une boîte de message affiche la valeur:

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

Notez que je suis un utilisateur de domaine avec admin privilèges sur ma machine locale, je les résultats suivants:

1. Quand je lance le fichier exe (double clic) alors que je suis activement connecté au DC, je suis arrivé " Négocier". Lorsque j'exécute le fichier exe (exécuté en tant qu'utilisateur differnet/utilisateur local) alors que je suis connecté au DC, j'ai "NTLM". Lorsque j'ai exécuté le fichier exe en utilisant "Exécuter en tant qu'administrateur" ou "Exécuter en tant qu'utilisateur différent", j'ai obtenu "Kerberos".

2. Lorsque j'exécute le fichier exe alors que je suis connecté en utilisant un compte local, j'ai "NTLM".

Je comprends que le LSA utilisera NTLM pour les comptes locaux. Aussi je comprends que Active Directory utilise Kerberos pour authentifier les utilisateurs de domaine et les ordinateurs. Ma question est, pourquoi je reçois le Négocier Type d'authentification lorsque j'exécute l'exe en utilisant mon compte soit par (Double-clic), ou "exécuter en tant qu'utilisateur différent" en utilisant mon compte Same?

Mise à jour: J'ai remarqué ce qui suit:

- Si utilisateur local exécute le exe alors il est NTLM
- Si utilisateur de domaine exécuter l'exe alors il est Négociez (Si cet utilisateur est administrateur local) mais est Kerberos (si cet utilisateur n'est pas administrateur local)
- Si domaine admin exécutez l'exe alors il est Kerberos

Je juste une clarification sur ce comportement.

Answer 1

Tout d'abord, (que vous semblez comprendre dans la question, mais juste pour être clair) un EXE n'a aucune authentification - c'est juste un exécutable. Le système d'exploitation creates a process object qui l'exécute dans une session d'ouverture de session identifiée par un principal. C'est ce principal qui a été authentifié par NTLM ou Kerberos (ou un autre protocole).Ensuite, Négocier signifie que lorsque la session d'ouverture de session a été créée, le Negotiate authentication package a été utilisé pour décider quel package d'authentification (Kerberos ou NTLM) devait être utilisé. Lorsque vous interrogez la valeur WindowsIdentity.AuthenticationType, vous appelez une fonction dans l'autorité de sécurité locale (LSA) appelée LsaGetLogonSessionData. Ceci rapporte les détails de la session d'ouverture de session utilisée pour exécuter le processus que vous exécutez. La façon dont cette session d'ouverture de session a été créée a probablement l'effet le plus important sur le package d'authentification utilisé pour vérifier les informations d'identification.

When logging into Windows the first time, Winlogon.exe establishes an interactive logon en appelant LsaLogonUser. Il interroge les packages d'authentification dans HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Authentication Packages dans l'ordre jusqu'à ce qu'il en trouve un qui peut authentifier les informations d'identification données. Une fois qu'une connexion interactive a été établie, vous pouvez créer de nouveaux processus en utilisant des connexions non interactives sous différentes références, et dans ce cas, la fonction LogonUser est appelée. L'un des paramètres à cette fonction est dwLogonProvider qui a la valeur par défaut suivante (qui est probablement celui utilisé):

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. 

Ainsi, le paquet rapporté pour la session d'ouverture de session le processus est en cours d'exécution sous dépend de l'ouverture de session session a été créée. (Votre question ne précise pas exactement comment vous créez les sessions d'ouverture de session que vous testez ... en faisant "Exécuter en tant que" dans tous les cas? Logoff/Logon Windows pour certains cas?) Cela dépend également du package Winlogon s'authentifier avec succès en premier pour la session d'ouverture de session interactive. En fin de compte, notez cependant que les mécanismes d'authentification appellent tous un paquet d'authentification, et si Negotiate est utilisé, Kerberos est préféré, bien que Negotiate soit ce qui est rapporté.

Voici un vieux mais toujours pertinent diagramme qui montre comment tout l'authentification se imbrique dans Windows:

Source