Se connecter et se déconnecter à nouveau en tant qu’utilisateur différent déverrouille un PC précédemment verrouillé - comment ça marche?

12

J'ai observé un comportement plutôt curieux de Windows 7 sur certains de nos ordinateurs de bureau:

  1. L'utilisateur A se connecte à son compte comme d'habitude.
  2. L'utilisateur A verrouille le PC (via Win + L ou similaire).
  3. L'utilisateur B (peu importe qui, il doit simplement s'agir d'une personne ayant un compte d'utilisateur différent) se connecte ensuite au même PC avec ses informations d'identification (directement sur le PC ou à distance).
  4. L'utilisateur B se déconnecte à nouveau.
  5. Immédiatement après avoir vu l'écran de "déconnexion", la session de l'utilisateur A est déverrouillée, sans nécessiter de mot de passe.

Ce modèle exact fonctionne comme présenté sur tous les PC affectés avec des combinaisons arbitraires de comptes d'utilisateurs. J'ai entendu notre administrateur nous dire qu'il fonctionnait même pour déverrouiller des comptes d'administrateur, s'ils devaient rester connectés au bon PC. Cependant, cela ne fonctionne pas sur un lot de PC récents que nous avons récemment achetés pour notre équipe.

Ce "phénomène" est-il connu? Je n'ai pas pu trouver de rapports sur un comportement similaire via Google. Je suppose donc qu'il doit s'agir de quelque chose de spécifique à notre environnement de bureau. Quelle faille dans la configuration de Windows 7 pourrait conduire à un tel comportement?


Quelques antécédents:

  • Nos ordinateurs fonctionnent sous Windows 7 Professional, 64 bits. Le SP1 est installé. Les mises à jour de sécurité semblent être appliquées régulièrement.
  • Tous les comptes d'utilisateurs sont des comptes de domaine.
  • J'ai informé l'un de nos administrateurs de cette particularité il y a quelques mois, mais comme le comportement persiste, je vais essayer de présenter le problème de manière plus urgente (et de veiller à inclure également le responsable de la sécurité informatique).
  • Je suis conscient que cela a des implications en matière de sécurité de l'information. (Cela permet l'emprunt d'identité, l'accès à des lecteurs réseau restreints, etc.). Mais au moins, sur mon PC, les agencements de fenêtres sont sérieusement perturbés. Il est donc peu probable que quelqu'un l'exploite sans que je m'en rende compte par la suite. Je suis sûr que la seule raison pour laquelle il n'a pas encore été traité est qu'il n'y a pas eu de cas d'abus (connu). En outre, un accès physique au PC correspondant est nécessaire pour être exploitable.
  • Je ne suis qu'un utilisateur sans privilèges élevés. J'essaierai de fournir toutes les informations nécessaires (le cas échéant), mais susceptibles de rencontrer certaines restrictions tôt ou tard.
  • De plus, je voudrais m'excuser si ma terminologie concernant l'administration du système est incorrecte - je ne suis pas un professionnel. S'il vous plaît laissez-moi savoir si je peux améliorer ma formulation n'importe où.

Onglet Ouverture de session Autoruns (les entrées Microsoft sont masquées): la Onglet Ouverture de session Autoruns (les entrées Microsoft sont masquées) section en noir est un script qui mappe les lecteurs réseau en fonction de celui qui se connecte. Onglet Winlogon d'Autoruns (il n'y a que des entrées Windows): Onglet Winlogon d'Autoruns (il n'y a que des entrées Windows)

Inarion
la source
Je soupçonne vraiment que cela est dû à une modification locale que votre nouveau lot de PC n'a pas encore subi. (Je ne me souviens d'aucun article de presse critiquant Microsoft pour ce problème particulier ...)
grawity
1
Ceci est très certainement causé par un programme tiers. Cela se produit-il avec des comptes d'utilisateurs locaux? En mode sans échec? Utilisez Autoruns pour désactiver toutes les applications de démarrage non Microsoft et tester le comportement de ce dernier (soyez prudent avec les pilotes et les services, bien que ce soit probablement ce qui pourrait en être la cause).
Twisty Impersonator
De plus, 1) dans Autoruns, que trouve-t-on dans l' Winlogononglet? S'il vous plaît poster une capture d'écran de cet onglet si possible. 2) Après le problème, quelles sont les données de la valeur LastLoggedOnProvider dans la clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData\#? (Où #est le numéro de session dont il peut y avoir plus d'un.)
Twisty Impersonator
@ TwistyImpersonator Autoruns semble vouloir utiliser cela aussi sur mon PC privé - très chouette! 1) Il y a un tas d'entrées sur l'onglet d'ouverture de session, aucune d'entre elles ne me semble suspecte. Ajoutera une capture d'écran à ma question. 2) Toutes les clés affichent la même valeur pour LastLoggedOnProvider , mais seule la première clé indique mon nom d'utilisateur dans LoggedOnUsername, tandis que toutes les autres ont le nom de mon collègue (celui avec lequel j'ai effectué les tests).
Inarion
@ TwistyImpersonator En ce qui concerne les comptes locaux: je dois encore tester cela. Je ne peux rien désactiver au-delà des entrées dans HKCU car il me manque les privilèges pour le faire. Devrons demander à nos informaticiens de le faire.
Inarion

Réponses:

0

C'est a conçu.

Voir Ouverture de session interactive: Exiger l’authentification du contrôleur de domaine pour déverrouiller le poste de travail.

C'est un paramètre de sécurité qui, s'il n'est pas activé, permet essentiellement à l'utilisateur de se connecter sans valider à un contrôleur de domaine.

Dans votre cas, l'utilisateur A a été validé et mis en cache. L'utilisateur B a été validé et lorsque l'utilisateur A est revenu, il a utilisé le cache. Si ce paramètre est défini, il devrait nécessiter une nouvelle authentification auprès du contrôleur de domaine afin d'éviter tout retrait. Si vous avez un ordinateur portable et que vous avez perdu votre connexion réseau, comment vous reconnectez-vous au contrôleur de domaine pour le déverrouiller. Il peut donc s'agir d'un paramètre "dangereux".

todd_placher
la source
Merci, le lien m'a été utile pour ma compréhension générale. Toutefois, ni votre lien ni les résultats Google associés n'indiquent que des informations d'identification mises en cache seraient utilisées pour authentifier automatiquement un utilisateur (inutile de saisir un mot de passe). Autant que je sache, même les informations d'identification mises en cache localement ne servent qu'à comparer les informations entrées par l'utilisateur lors de la connexion. Donc, théoriquement, il ne devrait pas exister de scénario dans lequel l'utilisateur B peut se connecter en tant qu'utilisateur A, qu'il ait ou non ses informations d'identification. mis en cache. Pourtant, cela arrive encore.
Inarion
Il est intéressant de noter que votre commentaire a suscité une émerveillement quant à la différence entre les différentes méthodes de connexion utilisées par Windows. Il a été remplacé pour Windows 10 par Microsoft Windows Credential Provider Integration. En effectuant une analyse plus approfondie, vous trouverez CREDENTIAL_PROVIDER_USAGE_SCENARIO enumeration. Voir la section remarques
toddd_placher
Remarques: À partir de Windows 10, les scénarios utilisateur CPUS_LOGON et CPUS_UNLOCK_WORKSTATION ont été combinés. Cela permet au système de prendre en charge plusieurs utilisateurs se connectant à une machine sans créer ni changer de session inutilement. N'importe quel utilisateur de la machine peut s'y connecter une fois qu'elle a été verrouillée sans avoir besoin de quitter une session en cours et d'en créer une nouvelle. De ce fait, CPUS_LOGON peut être utilisé à la fois pour se connecter à un système ou lorsqu'un poste de travail est déverrouillé.
todd_placher
C'est faux. L'OP rencontre un cas dans lequel un compte précédemment connecté mais verrouillé est déverrouillé sans que l'utilisateur ne fournisse ses informations d'identification . Le paramètre de stratégie de groupe que vous référencez contrôle le comportement de Windows lorsque des informations d'identification sont fournies ... mais ces informations d'identification doivent toujours être fournies pour que la session d'ouverture de session soit déverrouillée.
Twisty Impersonator
0

Il semble donc que nos informaticiens ont trouvé le problème. HP Remote Graphics Sender est installé sur tous nos ordinateurs, qu’ils soient de marque Dell ou HP (version 6.0.3 dans le cas de mon ordinateur). La désactivation du service correspondant arrête immédiatement le comportement incriminé.

Pourquoi ce service spécifique a-t-il permis ce type de comportement inouï dans Windows: Nous ne le savons pas. Nous sommes complètement désemparés.
Il est fort probable que nous n'allouons plus de ressources pour résoudre ce problème car nous n'avons pas besoin du service Sender (nous utilisons uniquement le récepteur). Je ne peux donc que supposer que le problème pourrait être causé par une sorte d'incompatibilité entre le logiciel HP et nos PC de la marque Dell. (La plupart des ordinateurs concernés provenaient de Dell, bien que quelques ordinateurs - plus anciens? - se soient également mal comportés, de sorte que cela ne peut pas en dire autant.)

Tout compte fait, l'affaire reste mystérieuse de manière insatisfaisante, mais malheureusement, je ne suis pas en mesure d'enquêter davantage sur cette affaire, tant du point de vue du financement que du point de vue des privilèges.

Inarion
la source