Description de l'utilisation de AMA dans les scénarios d'ouverture de session interactive dans Windows

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3101129
Résumé
Cet article explique comment utiliser l'Assurance de mécanisme d'authentification (AMA) dans les scénarios d'ouverture de session interactive.
Introduction
AMA ajoute une appartenance au groupe universel, désignés par l'administrateur au jeton d'accès d'un utilisateur lorsque les informations d'identification de l'utilisateur sont authentifiées lors de l'ouverture de session à l'aide d'une méthode d'ouverture de session basée sur le certificat. Cela rend possible de ressources aux administrateurs réseau de contrôler l'accès aux ressources, telles que des fichiers, des dossiers et des imprimantes. Cet accès dépend de si l'utilisateur ouvre une session à l'aide d'une méthode d'ouverture de session basée sur le certificat et le type de certificat qui est utilisé pour ouvrir une session.
Dans cet article
Cet article se concentre sur deux scénarios de problème : ouverture de session/fermeture de session et de verrouiller/déverrouiller. Le comportement de AMA dans ces scénarios est « normal » et peut être résumé comme suit :

  • AMA est destiné à protéger les ressources réseau.
  • AMA peut identifier ni appliquer le type d'ouverture de session interactive (carte à puce ou nom d'utilisateur/mot de passe) pour l'ordinateur local de l'utilisateur. C'est parce que les ressources qui sont accessibles après une ouverture de session d'utilisateur interactive ne peuvent pas être protégées de manière fiable à l'aide de AMA.
Symptômes

Problème de scénario 1 (ouverture/fermeture de session)

Considérez le scénario suivant :
  • Un administrateur souhaite mettre en œuvre l'authentification d'ouverture de session de carte à puce (SC) lorsque les utilisateurs accèdent à certaines ressources sensibles à la sécurité. Pour ce faire, l'administrateur déploie AMA en fonction de la Assurance du mécanisme d'authentification pour les services AD DS dans le Guide pas à pas de Windows Server 2008 R2 pour l'identificateur d'objet de stratégie d'émission qui est utilisé dans tous les certificats de carte à puce.

    Remarque Dans cet article, nous faisons référence à ce nouveau groupe mappé en tant que « groupe de sécurité universel de carte à puce. »
  • Le « ouverture de session Interactive : carte à puce nécessaire » stratégie n'est pas activé sur les stations de travail. Par conséquent, les utilisateurs peuvent vous connecter à l'aide d'autres informations d'identification, nom d'utilisateur et mot de passe.
  • Local et le groupe de sécurité universel de carte à puce requiert l'accès aux ressources réseau.
Dans ce scénario, vous vous attendez que seul l'utilisateur qui se connecte l'à l'aide de cartes à puce peut accéder aux locaux et ressources réseau. Toutefois, comme la station de travail autorise optimisé/mise en cache d'ouverture de session, le vérificateur de mise en cache est utilisé lors de l'ouverture de session pour créer le jeton d'accès NT pour le bureau de l'utilisateur. Par conséquent, les groupes de sécurité et les revendications de l'ouverture de session précédente sont utilisées au lieu de celle en cours.

Exemples de scénarios

Remarque Dans cet article, l'appartenance au groupe est récupéré pour les sessions d'ouverture de session interactive à l'aide de « whoami/groupes ». Cette commande extrait les groupes et les revendications du jeton d'accès du bureau.

  • Exemple 1

    Si l'ouverture de session précédente a été effectuée à l'aide d'une carte à puce, le jeton d'accès pour le bureau possède le groupe de sécurité universel de carte à puce fournie par AMA. Un des résultats suivants se produit :

    • L'utilisateur ouvre une session à l'aide de la carte à puce : l'utilisateur peut toujours accéder à des ressources sensibles sécurité locale. L'utilisateur essaie d'accéder aux ressources réseau qui requièrent le groupe de sécurité universel de carte à puce. Ces tentatives échoue.
    • L'utilisateur ouvre une session en utilisant le nom d'utilisateur et le mot de passe : l'utilisateur peut toujours accéder à des ressources sensibles sécurité locale. Ce résultat n'est pas attendu. L'utilisateur essaie d'accéder aux ressources réseau qui requièrent le groupe de sécurité universel de carte à puce. Ces tentatives échouent comme prévu.
  • Exemple 2

    Si l'ouverture de session précédente a été effectuée à l'aide d'un mot de passe, le jeton d'accès pour le bureau n'a pas le groupe de sécurité universel de carte à puce fournie par AMA. Un des résultats suivants se produit :

    • L'utilisateur ouvre une session à l'aide d'un nom d'utilisateur et le mot de passe : l'utilisateur ne peut pas accéder aux ressources sensibles de sécurité locale. L'utilisateur essaie d'accéder aux ressources réseau qui requièrent le groupe de sécurité universel de carte à puce. Ces tentatives échouent.
    • L'utilisateur ouvre une session à l'aide de la carte à puce : l'utilisateur ne peut pas accéder aux ressources sensibles de sécurité locale. L'utilisateur essaie d'accéder aux ressources réseau. Ces tentatives échoue. Cette outcomeisn't attendu par les clients. Par conséquent, il entraîne l'accès des problèmes de contrôle.

Problème de scénario 2 (verrouillage)

Considérez le scénario suivant :

  • Un administrateur souhaite mettre en œuvre l'authentification d'ouverture de session de carte à puce (SC) lorsque les utilisateurs accèdent à certaines ressources sensibles à la sécurité. Pour ce faire, l'administrateur déploie AMA en fonction de Assurance du mécanisme d'authentification pour les services AD DS dans le Guide pas à pas de Windows Server 2008 R2 pour l'identificateur d'objet de stratégie d'émission qui est utilisé dans tous les certificats de carte à puce.
  • Le « ouverture de session Interactive : carte à puce nécessaire » stratégie n'est pas activé sur les stations de travail. Par conséquent, les utilisateurs peuvent vous connecter à l'aide d'autres informations d'identification, nom d'utilisateur et mot de passe.
  • Local et le groupe de sécurité universel de carte à puce requiert l'accès aux ressources réseau.
Dans ce scénario, vous pensez que seul un utilisateur qui se connecte l'à l'aide de cartes à puce peut accéder aux local et ressources réseau. Toutefois, parce que le jeton d'accès pour le bureau de l'utilisateur est créé lors de l'ouverture de session, il n'est pas modifié.

Exemples de scénarios

  • Exemple 1

    Si le jeton d'accès pour le bureau possède le groupe de sécurité universel de carte à puce fourni par AMA, un des résultats suivants se produit :

    • L'utilisateur déverrouille à l'aide de la carte à puce : l'utilisateur peut toujours accéder à des ressources sensibles sécurité locale. L'utilisateur essaie d'accéder aux ressources réseau qui requièrent le groupe de sécurité universel de carte à puce. Ces tentatives échoue.
    • L'utilisateur déverrouille en utilisant le nom d'utilisateur et le mot de passe : l'utilisateur peut toujours accéder à des ressources sensibles sécurité locale. Ce outcomeisn't est attendu. L'utilisateur essaie d'accéder aux ressources réseau qui requièrent le groupe de sécurité universel de carte à puce. Ces tentatives échouent.
  • Exemple 2

    Si le jeton d'accès pour le bureau n'a pas le groupe de sécurité universel de carte à puce fourni par AMA, un des résultats suivants se produit :

    • L'utilisateur déverrouille en utilisant le nom d'utilisateur et le mot de passe : l'utilisateur ne peut pas accéder aux ressources sensibles de sécurité locale. L'utilisateur essaie d'accéder aux ressources réseau nécessitant le groupe de sécurité universel de carte à puce. Ces tentatives échouent.
    • L'utilisateur déverrouille à l'aide de la carte à puce : l'utilisateur ne peut pas accéder aux ressources sensibles de sécurité locale. Ce outcomeisn't est attendu. L'utilisateur essaie d'accéder aux ressources réseau. Ces tentatives échoue comme prévu.
Plus d'informations
En raison de la conception AMA et le sous-système de sécurité qui est décrite dans la section « Symptômes », les utilisateurs rencontrent les scénarios suivants dans lesquels les AMA ne peut pas identifier fiable le type d'ouverture de session interactive.

Ouverture de session/fermeture de session

Si l'optimisation d'ouverture de session rapide est active, le sous-système de sécurité locale (lsass) utilise le cache local pour générer l'appartenance aux groupes dans le jeton d'ouverture de session. En procédant ainsi, la communication avec le contrôleur de domaine (DC) n'est pas obligatoire. Par conséquent, l'ouverture de session est réduite. Il s'agit d'une fonctionnalité très intéressante.

Toutefois, cette situation provoque le problème suivant : après l'ouverture de session SC et SC de fermeture de session, le groupe AMA mis en cache localement est incorrecte, toujours présent dans le jeton de l'utilisateur après l'ouverture de session interactive d'utilisateur nom/mot de passe.

Remarques

  • Cette situation s'applique uniquement aux ouvertures de session interactives.
  • Un groupe AMA est mise en cache de la même manière et en utilisant la même logique que les autres groupes.

Dans ce cas, si l'utilisateur tente ensuite d'accéder aux ressources du réseau, l'appartenance au groupe mis en cache sur le sideisn'tused de ressources et ouverture de session de l'utilisateur sur le côté de la ressource ne contient pas un groupe AMA.

Ce problème peut être résolu en désactivant l'optimisation d'ouverture de session rapide ("Configuration ordinateur > modèles d'administration > système > connexion > toujours attendre le réseau lors du démarrage de l'ordinateur et d'ouverture de session »).

Important Ce comportement est pertinent que dans le scénario de connexion interactive. Accès aux ressources réseau fonctionne comme prévu, car il est inutile d'optimisation d'ouverture de session. Par conséquent, mise en cache de membershipisn't groupe utilisé. Le contrôleur de domaine est contacté pour créer le nouveau ticket en utilisant les informations d'appartenance de groupe AMA plus récentes.

Verrouiller/déverrouiller

Considérez le scénario suivant :

  • Un utilisateur ouvre une session interactive en utilisant la carte à puce, puis ouvre les ressources réseau protégé par AMA.

    Remarque Réseau protégé de AMA les ressources peuvent être accessibles uniquement aux utilisateurs qui ont un groupe AMA dans leur jeton d'accès.
  • L'utilisateur verrouille l'ordinateur sans fermer au préalable la ressource réseau de protégé AMA précédemment ouverte.
  • L'utilisateur déverrouille l'ordinateur en utilisant le nom d'utilisateur et le mot de passe de l'utilisateur qui a déjà ouvert une session à l'aide d'une carte à puce).
Dans ce scénario, l'utilisateur peut toujours accéder aux ressources protégées par AMA après déverrouillage de l'ordinateur. Ce comportement est voulu par la conception. Les ordinateur exécutait sont déverrouillé, Windows ne crée pas de nouveau toutes les sessions ouvertes qui avaient des ressources réseau. Windows également ne revérifie sa l'appartenance au groupe. C'est parce que ces actions entraînerait une dégradation des performances inacceptables.

Il n'y a aucune solution prête à l'emploi pour ce scénario. Une solution consisterait à créer un filtre de fournisseur d'informations d'identification qui filtre le fournisseur de nom/mot de passe d'utilisateur après la connexion de la SC et étapes de verrouillage se produisent. Pour en savoir plus sur le fournisseur d'informations d'identification, consultez les ressources suivantes :

Remarque Nous ne pouvons pas confirmer si cette approche a été correctement implémentée.

Plus d'informations sur AMA

AMA peut identifier ni imposer le type d'ouverture de session interactive (carte à puce oruser nom/mot de passe). Ce comportement est voulu par la conception.

AMA est destinée aux scénarios dans lesquels les ressources réseau exigent une carte à puce. Il n'a pas conçu être utilisés pour l'accès local.

Toute tentative de résoudre ce problème en introduisant de nouvelles fonctionnalités, telles que la possibilité d'utiliser l'appartenance de groupe dynamique ou à des groupes de AMA de poignée sous la forme d'un groupe dynamique, peut provoquer des problèmes graves. C'est pourquoi les jetons NT ne prennent pas en charge les appartenances de groupe dynamique. Si le système autorisé à ajuster dans réel, les groupes, les utilisateurs ne pourraient peut-être pas d'interagir avec leurs propres postes de travail et les applications. Par conséquent, les appartenances aux groupes sont verrouillés au moment où la session est créée et sont conservés pendant toute la session.

Les ouvertures de session mises en cache sont également problématiques. Si une connexion optimisée est activée, lsass essaie d'abord un cache local avant d'appeler un réseau aller-retour. Si le nom d'utilisateur et le mot de passe sont identiques à ce que lsass de scie pour les ouvertures de session précédentes (cela est vrai pour la plupart des ouvertures de session), lsass crée un jeton qui a les appartenances de même que l'utilisateur possède.

Si une connexion optimisée est désactivée, un aller-retour réseau est requis. Thiswould vous assurer que les appartenances aux groupes de travail à ouverture de session comme prévu.

Dans une ouverture de session mises en cache, lsass conserve une entrée par l'utilisateur. Cette entrée inclut l'appartenance de l'utilisateur précédent. Il est protégé par deux la dernière passwordor carte à puce d'informations d'identification que lsass vu. Les deux désencapsuler la même clé de jeton et les informations d'identification. Si les utilisateurs ont été pour tenter de se connecter à l'aide d'une clé d'informations d'identification obsolètes, ils perdraient DPAPI données protégées par EFS contenu et ainsi de suite. Par conséquent, les ouvertures de session mises en cache produisent toujours les appartenances aux groupes locaux plus récentes, quel que soit le mécanisme qui est utilisé pour ouvrir une session.
L'authentification mécanisme Assurance AMA ouverture de session Interactive

Avertissement : Cet article a été traduit automatiquement.

Propriétés

ID d'article : 3101129 - Dernière mise à jour : 11/21/2015 02:09:00 - Révision : 1.0

Windows Server 2012 R2 Standard, Windows Server 2012 R2 Datacenter, Windows 8.1 Pro, Windows 8.1 Enterprise, Windows Server 2012 Standard, Windows Server 2012 Datacenter, Windows 8 Pro, Windows 8 Enterprise, Windows Server 2008 R2 Standard, Windows Server 2008 R2 Enterprise, Windows 7 Entreprise, Windows 7 Professionnel

  • kbinfo kbexpertiseadvanced kbsurveynew kbmt KB3101129 KbMtfr
Commentaires