2010-08-17 2 views
3

J'utilise C# et .Net Framework 4.Comment vérifier de manière fiable les fenêtres identifiant de domaine de l'utilisateur actuel sur un poste de travail

Je cherche une méthode à toute épreuve pour obtenir l'identifiant de connexion de l'utilisateur actuellement connecté à l'utilisateur Windows qui n'est pas susceptible d'usurpation d'identité ou de piratage. Je cherche ceci sous la forme de: DOMAINNAME \ USERNAME

par exemple. Undomaine \ JohnDoe

Actuellement, le meilleur que j'ai est:

var identity = System.Security.Principal.WindowsIdentity.GetCurrent(); 
var currentLoginId = identity.Name; 

Est-ce ouvert à l'usurpation d'identité (en dehors de quelqu'un de connaître le nom d'utilisateur et mot de passe) et si oui, est-il une meilleure façon de le faire?

+0

'non susceptible d'usurpation d'identité ou de piratage' - vous ne pouvez pas pirater l'utilisateur connecté sans connaître son mot de passe. Si vous connaissez le mot de passe, je ne pense pas que cela compte comme du piratage. –

+0

@Tim est d'accord avec vous sur ce point. S'ils connaissent le nom d'utilisateur et le mot de passe, ils peuvent se connecter à Windows en tant qu'utilisateur. – Steve

+0

Dans quel cas, pourquoi voulez-vous éviter l'usurpation d'identité? –

Répondre

4

Il peut y avoir au moins quatre identités différentes impliquées à ce stade:

  1. L'identité assignée au fil
  2. L'identité attribué au processus
  3. Le compte de l'utilisateur qui a commencé le processus
  4. le compte de l'utilisateur connecté sur le PC

Dans votre code, vous obtenez (1). C'est normalement bien, et est généralement le même que (2).

Pour récupérer (2), vous pouvez:

  1. Appel WindowsIdentity.GetCurrent pour obtenir l'identité personnifié
  2. Annuler l'usurpation d'identité en appelant la fonction Win32 RevertToSelf
  3. Regardez WindowsIdentity.GetCurrent pour obtenir l'identité de processus sous-jacent
  4. Réinitialiser l'identité de thread en usurpant l'identité de l'étape (1)

(2) et (3) seront les mêmes sauf si vous avez écrit du code non géré qui modifie l'identité du processus. Comme le souligne @Daniel, (3) et (4) pourraient légitimement être différents en présence de la commande Windows "run as".

Edit: Vous pouvez faire confiance que le WindowsIdentity actuel est celui qu'il prétend est, dans la mesure où vous pouvez faire confiance à tout élément de données dans votre application. Vous pourriez vous en fourvoyer en attachant un débogueur à votre processus et en simulant la valeur de retour de cet appel, mais si vous faites cela, vous pourriez aussi bien simuler le code dans lequel vous passez le nom d'utilisateur la base de données.

La méthode 100% sûre pour ce faire consiste à utiliser l'authentification intégrée/SSPI pour se connecter à la base de données.

1

Seule une réponse partielle:

Je crois System.Security.Principal.WindowsIdentity.GetCurrent(); renverra le compte d'utilisateur Windows associaed avec le fil en cours d'exécution. Si le thread ou l'application a été démarré sous un compte d'utilisateur différent de l'utilisateur connecté, vous n'aurez pas ce que vous recherchez après l'avoir utilisé. Si vous pouvez être sûr que votre application n'a pas été démarrée en utilisant la fonction "run-as" (ou équaliseur programmatique) et que vous ne faites rien en interne par rapport à l'identité du thread, vous pouvez être sûr que c'est le compte de l'utilisateur connecté, mais je ne suis pas à 100% à ce sujet.

Il est peut-être possible de trouver le compte d'utilisateur associé à la "session" de widows dans laquelle l'application s'exécute en utilisant ADSI (voir System.DirectoryServices).

+1

* "Je crois que' System.Security.Principal.WindowsIdentity.GetCurrent(); 'retournera le compte utilisateur Windows associé au thread en cours d'exécution." * I ne le pensez pas (voir 'Thread.CurrentPrincipal', mais il se peut qu'il ne soit pas défini). Re "RunAs", 'WindowsIdentity.GetCurrent()' vous donnera l'utilisateur "RunAs", pas l'utilisateur connecté. –

Questions connexes