Résolution des erreurs de code d'authentification de message de l'état d'affichage

Traductions disponibles Traductions disponibles
Numéro d'article: 2915218 - Voir les produits auxquels s'applique cet article
Agrandir tout | Réduire tout

Qu'est-ce qu'un état d'affichage ?

Un état d'affichage correspond à une information qui est échangée entre les pages Web Forms (.aspx) dans une application ASP.NET. Le balisage HTML pour le champ __VIEWSTATE est semblable à ce qui suit :

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />

Le texte d'un contrôle bouton constitue un exemple d'un élément susceptible d'être stocké dans le champ __VIEWSTATE. Si un utilisateur clique sur le bouton, le gestionnaire d'événements Button_Click pourra extraire le texte du contrôle bouton du champ d'état d'affichage. Consultez la rubrique Vue d'ensemble de l'état d'affichage ASP.NET sur le site web MSDN (Microsoft Developer Network) pour une présentation beaucoup plus détaillée de l'état d'affichage ASP.NET.

Le champ __VIEWSTATE contenant des informations importantes permettant de reconstruire la page en vue de sa publication, veillez à ce qu'un utilisateur malveillant ne falsifie pas ce champ. Si un utilisateur malveillant a envoyé une charge utile __VIEWSTATE malintentionnée, celui-ci pourrait tromper l'application en exécutant une action qu'il n'aurait sinon pas effectuée.

Pour éviter le risque de falsification, le champ __VIEWSTATE est protégé par un code d'authentification de message. ASP.NET valide le code d'authentification de message qui est envoyé avec la charge utile __VIEWSTATE lors d'une publication. La clé utilisée pour calculer le code d'authentification de message est spécifiée dans l'élément <machineKey> de l'application du fichier Web.config. L'utilisateur malveillant ne pouvant pas déterminer le contenu de l'élément <machineKey>, il ne peut, par conséquent, fournir un code d'authentification de message valide si celui-ci tente de falsifier la charge utile __VIEWSTATE. ASP.NET détecte l'absence de code d'authentification de message valide et rejette alors la demande malintentionnée.

Pourquoi des erreurs de validation de code d'authentification de message se produisent-elles ?

Une erreur de validation de code d'authentification de message se présente comme suit :

Erreur de serveur dans l'application '/'.

Échec de la validation du code d'authentification de message de l'état d'affichage. Si cette application est hébergée par une batterie de serveurs web ou un cluster, veillez à ce que la configuration <machineKey> indique la même clé et le même algorithme de validation. La valeur AutoGenerate ne peut pas être utilisée dans un cluster.

Description : une exception non gérée s'est produite au moment de l'exécution de la demande web actuelle. Contrôlez la trace de la pile pour plus d'informations sur l'erreur et son origine dans le code.

Détails concernant l'exception : System.Web.HttpException: Échec de la validation du code d'authentification de message de l'état d'affichage. Si cette application est hébergée par une batterie de serveurs web ou un cluster, veillez à ce que la configuration <machineKey> indique la même clé et le même algorithme de validation. La valeur AutoGenerate ne peut pas être utilisée dans un cluster.

Source de l'erreur : [Aucune ligne source appropriée]

Fichier source : ... Ligne : 0

Trace de pile :

[ViewStateException : État d'affichage non valide.
IP client : ::1
Port : 40653
Référant : http://localhost:40643/MyPage.aspx
Chemin d'accès : /MyPage.aspx
Agent utilisateur : Mozilla/5.0 (compatible ; MSIE 10.0 ; Windows NT 6.2 ; WOW64 ; Trident/6.0)
État d'affichage : ...]

[HttpException (0x80004005) : Échec de la validation du code d'authentification de message de l'état d'affichage. Si cette application est hébergée par une batterie de serveurs web ou un cluster, veillez à ce que la configuration <machineKey> indique la même clé et le même algorithme de validation. La valeur AutoGenerate ne peut pas être utilisée dans un cluster.

Voir http://go.microsoft.com/fwlink/?LinkID=314055 pour plus d'informations.]
System.Web.UI.ViewStateException.ThrowError(Exception inner, String persistedState, String errorPageMessage, Boolean macValidationError) +190
System.Web.UI.ViewStateException.ThrowMacValidationError(Exception inner, String persistedState) +46
System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Purpose purpose) +861
System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Purpose purpose) +51
System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Purpose purpose) +67
System.Web.UI.HiddenFieldPageStatePersister.Load() +444
System.Web.UI.Page.LoadPageStateFromPersistenceMedium() +368
System.Web.UI.Page.LoadAllState() +109
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +7959
System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +429
System.Web.UI.Page.ProcessRequest() +125
System.Web.UI.Page.ProcessRequestWithNoAssert(HttpContext context) +48
System.Web.UI.Page.ProcessRequest(HttpContext context) +234
ASP.mypage_aspx.ProcessRequest(HttpContext context) in ...:0
System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +1300
System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +140

Cause 1 : L'application web s'exécute dans une batterie de serveurs (environnement multiserveur)

ASP.NET génère automatiquement une clé de chiffrement pour chaque application et stocke la clé dans la ruche de Registre HKCU. Cette clé générée automatiquement est utilisée s'il n'existe aucun élément <machineKey> explicite dans la configuration de l'application. Toutefois, l'ordinateur ayant créé une clé locale, ce scénario génère un problème pour les applications qui s'exécutent dans une batterie de serveurs. Chaque serveur dans la batterie va créer sa propre clé locale et aucun de ces serveurs ne s'accordera sur la clé à utiliser. De ce fait, si un serveur génère une charge utile __VIEWSTATE qu'un autre serveur utilise, celui-ci ne parviendra pas à valider le code d'authentification de message.
  • Résolution 1a : Création d'un élément <machineKey> explicite

    Si vous ajoutez un élément <machineKey> explicite au fichier Web.config de l'application, le développeur indique à ASP.NET de ne pas utiliser la clé de chiffrement générée automatiquement. Voir l'Annexe A pour obtenir des instructions sur la procédure de création d'un élément <machineKey>. Une fois cet élément ajouté au fichier Web.config, redéployez l'application sur chaque serveur de la batterie de serveurs.

    Remarque Certains services d'hébergement web, tels que les sites web de Microsoft Azure, prennent des mesures pour synchroniser la clé générée automatiquement de chaque application sur leurs serveurs principaux. Cela permet aux applications qui n'ont pas spécifié un élément <machineKey> explicite de continuer à travailler dans ces environnements, même si l'application s'exécute dans une batterie de serveurs. Si votre application s'exécute sur un service d'hébergement tiers, contactez votre fournisseur d'hébergement afin de déterminer si vous êtes concerné par cette situation.

  • Résolution 1b : Activation de l'affinité du système d'équilibrage de charge

    Si vos sites fonctionnent derrière un système d'équilibrage de charge, vous pouvez activer l'affinité des serveurs afin de résoudre provisoirement le problème. Cela permet de vérifier que les clients concernés interagissent uniquement avec un seul serveur physique situé derrière le système d'équilibrage de charge de manière à ce que toutes les charges utiles de chiffrement soient générées et utilisées par le même serveur.

    Il ne s'agit pas d'une solution à long terme. Même si l'affinité des serveurs est activée, la plupart des systèmes d'équilibrage de charge redirigent le client vers un autre serveur physique si le serveur d'origine sur lequel l'affinité des systèmes d'équilibrage de charge a été activée passe en mode hors connexion. Le nouveau serveur va alors refuser les charges utiles de chiffrement (telles que __VIEWSTATE, des tickets d'authentification par formulaires, des jetons anti-contrefaçon MVC et d'autres services) dont le client dispose actuellement.

    L'utilisation d'un élément <machineKey> explicite et le redéploiement de l'application doivent être prioritaires sur l'activation de l'affinité des serveurs.

Cause 2 : Le processus de travail utilise l'identité du pool d'applications des services IIS 7.0

Les services IIS 7.0 (Windows Vista, Windows Server 2008) ont lancé l'identité du pool d'applications, un nouveau mécanisme d'isolation permettant de renforcer la sécurité des serveurs qui exécutent des applications ASP.NET. Toutefois, les sites qui s'exécutent sous l'identité du pool d'applications n'ont pas accès au Registre HKCU. Il s'agit de l'endroit où l'exécution ASP.NET stocke ses clés <machineKey> générées automatiquement. De ce fait, ASP.NET ne peut pas rendre permanente la clé générée automatiquement lorsque le pool d'applications est réinitialisé. Par conséquent, à chaque réinitialisation de w3wp.exe, une nouvelle clé temporaire est générée.

Remarque Cela ne pose aucun problème dans IIS 7.5 (Windows 7, Windows Server 2008 R2) et versions ultérieures. Dans ces versions, ASP.NET peut rendre permanentes les clés générées automatiquement dans un emplacement différent qui conserve les réinitialisations du pool d'applications.
  • Résolution 2a : Utilisation de l'utilitaire aspnet_regiis

    Les installations ASP.NET contiennent un utilitaire, aspnet_regiis.exe. Celui-ci permet à l'interface ASP.NET avec IIS d'effectuer les configurations nécessaires à l'exécution d'une application gérée. L'une de ces configurations crée les clés nécessaires dans la ruche de Registre afin d'activer la permanence des clés d'ordinateur générées automatiquement.

    Vous devez tout d'abord déterminer le pool d'applications utilisé par votre site. Cette opération peut être effectuée à l'aide de l'utilitaire inetmgr, fourni avec les services IIS. Sélectionnez votre site dans l'arborescence à gauche, cliquez avec le bouton droit sur Gérer le site web, puis cliquez sur Paramètres avancés. La boîte de dialogue qui apparaît affiche le nom du pool d'applications.

    Réduire cette imageAgrandir cette image
    Paramètres avancés


    Pour structurer les clés de Registre appropriées pour un pool d'applications ASP.NET 4.0, procédez comme suit :
    1. Ouvrez une invite de commandes d'administration.
    2. Recherchez le répertoire approprié, selon que vous utilisez un pool d'applications de 32 bits ou de 64 bits :
      • pool d'applications de 32 bits : cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • pool d'applications de 64 bits : cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. Accédez au répertoire, tapez la commande suivante, puis appuyez sur Entrée :

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

    Si le pool d'applications est ASP.NET 2.0 ou 3.5, procédez comme suit :
    1. Ouvrez une invite de commandes d'administration.
    2. Recherchez le répertoire approprié, selon que vous utilisez un pool d'applications de 32 bits ou de 64 bits :
      • pool d'applications de 32 bits : cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • pool d'applications de 64 bits : cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Accédez au répertoire, tapez la commande suivante, puis appuyez sur Entrée :

      aspnet_regiis -ga "IIS APPPOOL\app-pool-name"

    Par exemple, si votre pool d'applications se nomme Mon pool d'applications (comme dans l'image précédente), exécutez la commande suivante :
     
    aspnet_regiis -ga "IIS APPPOOL\My App Pool"


    Remarque Vous devrez peut-être exécuter les services système APPHOSTSVC et WAS pour l'utilitaire aspnet_regiis afin de résoudre de manière approprié les noms APPPOOL\* des services IIS.

  • Résolution 2b : Création d'un élément <machineKey> explicite

    Si vous ajoutez un élément <machineKey> explicite au fichier Web.config de l'application, le développeur indique à ASP.NET de ne pas utiliser la clé de chiffrement générée automatiquement. Voir l'Annexe A pour obtenir des instructions sur la procédure de création d'un élément <machineKey>.


Cause 3 : Le pool d'applications est configuré à l'aide de LoadUserProfile=false

Si le pool d'applications s'exécute avec une identité personnalisé, il se peut que les services IIS n'aient pas chargé le profil utilisateur pour l'identité th. Le Registre HKCU ne sera alors plus disponible pour ASP.NET pour rendre permanent l'élément <machineKey> généré automatiquement. Par conséquent, une nouvelle clé générée automatiquement sera créée à chaque redémarrage de l'application. Pour plus d'informations, consultez la section Profil utilisateur sur le site web de Microsoft.
  • Résolution 3a : Utilisation de l'utilitaire aspnet_regiis

    Les instructions sont identiques à celles indiquées dans la Résolution 2a. Consultez cette section pour plus d'informations.

  • Résolution 3b : Utilisation d'un élément <machineKey> explicite

    Si vous ajoutez un élément <machineKey> explicite au fichier Web.config de l'application, le développeur indique à ASP.NET de ne pas utiliser la clé de chiffrement générée automatiquement. Voir l'Annexe A pour obtenir des instructions sur la procédure de création d'un élément <machineKey>.

  • Résolution 3c : Configuration manuelle des clés de Registre HKCU requises

    Si vous ne parvenez pas à exécuter l'utilitaire aspnet_regiis, vous pouvez utiliser un script Windows PowerShell pour configurer les clés de Registre appropriées dans HKCU. Voir l'Annexe B pour plus d'informations.

  • Résolution 3d : Définition de LoadUserProfile=true pour ce pool d'applications

    Vous pouvez également activer le chargement du profil utilisateur à l'intérieur de ce pool d'applications. La ruche de Registre HKCU, le dossier temporaire et d'autres emplacements de stockage spécifiques de l'utilisateur seront alors disponibles pour l'application. Toutefois, cela peut entraîner une utilisation accrue du disque ou de la mémoire pour le processus de travail. Consultez l'élément <processModel > pour plus d'informations sur la procédure d'activation de ce paramètre.

Cause 4 : La propriété Page.ViewStateUserKey a une valeur incorrecte

Les développeurs de logiciels peuvent décider d'utiliser la propriété Page.ViewStateUserKey pour ajouter la protection contre la falsification de requête intersites au champ __VIEWSTATE. Si vous utilisez la propriété Page.ViewStateUserKey, elle est généralement définie sur une valeur telle que le nom de l'utilisateur actuel ou l'identificateur de session de l'utilisateur. Les modèles de projet des applications Web Forms dans Microsoft Visual Studio 2012 et les versions ultérieures contiennent des exemples qui utilisent cette propriété. Consultez la rubrique Page.ViewStateUserKey Property sur le site web de MSDN (Microsoft Developer Network) pour plus d'informations.

Si la propriété ViewStateUserKey est spécifiée, sa valeur est gravée sur __VIEWSTATE au moment de la génération. Lorsque le champ __VIEWSTATE est utilisé, le serveur vérifie la propriété ViewStateUserKey de la page actuelle et la valide en fonction de la valeur utilisée pour générer le champ __VIEWSTATE. Si les valeurs ne correspondent pas, la demande est rejetée comme potentiellement malintentionnée.

Exemple d'une défaillance liée à ViewStateUserKey : un client pour lequel deux onglets sont ouverts dans le navigateur. Le client est connecté en tant qu'utilisateur A et, dans le premier onglet, une page s'affiche avec un champ __VIEWSTATE dont la propriété ViewStateUserKey contient « Utilisateur A ». Dans le second onglet, le client se déconnecte, puis se reconnecte en tant qu'utilisateur B. Le client revient au premier onglet et envoie le formulaire. La propriété ViewStateUserKey peut contenir « Utilisateur B » (comme l'indique le cookie d'authentification du client). Toutefois, le champ __VIEWSTATE que le client a envoyé contient « Utilisateur A ». Cette différence provoque l'échec.
  • Résolution 4a : Vérifiez que ViewStateUserKey est correctement défini.

    Si votre application utilise la propriété ViewStateUserKey, vérifiez que sa valeur est identique lors de la génération de l'état d'affichage et lors de son utilisation. Si vous utilisez le nom de l'utilisateur actuellement connecté, veillez à ce que l'utilisateur reste connecté et que son identité n'a pas été modifiée au moment de la publication. Si vous utilisez l'identificateur de session de l'utilisateur actuel, vérifiez que la session n'a pas encore expiré.

    Si vous procédez à l'exécution dans un environnement de batterie de serveurs, vérifiez que les éléments <machineKey> correspondent. Voir l'Annexe A pour obtenir des instructions sur la procédure de création de ces éléments.

Annexe A : Procédure de création d'un élément <machineKey>

Avertissement de sécurité

Il existe de nombreux sites web qui génèreront un élément <machineKey> pour vous via un simple clic sur un bouton. N'utilisez jamais un élément <machineKey> que vous avez obtenu à partir d'un de ces sites. Il est impossible de savoir si ces clés ont été créées en toute sécurité ou si elles sont enregistrées dans une base de données confidentielle. Vous ne devez utiliser que les éléments de configuration <machineKey> que vous avez créés vous-même.


Pour générer un élément <machineKey> vous-même, vous pouvez utiliser le script Windows PowerShell suivant :

# Génère un élément <machineKey> qui peut être copié-collé dans un fichier Web.config.
function Generate-MachineKey {
  [CmdletBinding()]
  param (
    [ValidateSet("AES", "DES", "3DES")]
    [string]$decryptionAlgorithm = 'AES',
    [ValidateSet("MD5", "SHA1", "HMACSHA256", "HMACSHA384", "HMACSHA512")]
    [string]$validationAlgorithm = 'HMACSHA256'
  )
  process {
    function BinaryToHex {
        [CmdLetBinding()]
        param($bytes)
        process {
            $builder = new-object System.Text.StringBuilder
            foreach ($b in $bytes) {
              $builder = $builder.AppendFormat([System.Globalization.CultureInfo]::InvariantCulture, "{0:X2}", $b)
            }
            $builder
        }
    }
    switch ($decryptionAlgorithm) {
      "AES" { $decryptionObject = new-object System.Security.Cryptography.AesCryptoServiceProvider }
      "DES" { $decryptionObject = new-object System.Security.Cryptography.DESCryptoServiceProvider }
      "3DES" { $decryptionObject = new-object System.Security.Cryptography.TripleDESCryptoServiceProvider }
    }
    $decryptionObject.GenerateKey()
    $decryptionKey = BinaryToHex($decryptionObject.Key)
    $decryptionObject.Dispose()
    switch ($validationAlgorithm) {
      "MD5" { $validationObject = new-object System.Security.Cryptography.HMACMD5 }
      "SHA1" { $validationObject = new-object System.Security.Cryptography.HMACSHA1 }
      "HMACSHA256" { $validationObject = new-object System.Security.Cryptography.HMACSHA256 }
      "HMACSHA385" { $validationObject = new-object System.Security.Cryptography.HMACSHA384 }
      "HMACSHA512" { $validationObject = new-object System.Security.Cryptography.HMACSHA512 }
    }
    $validationKey = BinaryToHex($validationObject.Key)
    $validationObject.Dispose()
    [string]::Format([System.Globalization.CultureInfo]::InvariantCulture,
      "<machineKey decryption=`"{0}`" decryptionKey=`"{1}`" validation=`"{2}`" validationKey=`"{3}`" />",
      $decryptionAlgorithm.ToUpperInvariant(), $decryptionKey,
      $validationAlgorithm.ToUpperInvariant(), $validationKey)
  }
}

Pour les applications ASP.NET 4.0, vous pouvez simplement appeler Generate-MachineKey sans paramètres pour générer un élément <machineKey>, comme suit :

PS> Generate-MachineKey
<machineKey decryption="AES" decryptionKey="..." validation="HMACSHA256" validationKey="..." />

Les applications ASP.NET 2.0 et 3.5 ne prennent pas en charge HMACSHA256. Au lieu de cela, vous pouvez spécifier SHA1 pour générer un élément <machineKey> compatible, comme suit :

PS> Generate-MachineKey -validation sha1
<machineKey decryption="AES" decryptionKey="..." validation="SHA1" validationKey="..." />

Dès que vous avez généré un élément <machineKey>, vous pouvez le placer dans le fichier Web.config. L'élément <machineKey> n'est valide que dans le fichier Web.config à la racine de votre application et n'est pas valide au niveau du sous-dossier.

<configuration>
  <system.web>
    <machineKey ... />
  </system.web>
</configuration>

Pour obtenir une liste complète des algorithmes pris en charge, exécutez help Generate-MachineKey à l'invite de Windows PowerShell.

Annexe B : Configuration du Registre en vue de rendre permanentes les clés générées automatiquement

Par défaut, les clés générées automatiquement ASP.NET étant permanentes dans le Registre HKCU, celles-ci peuvent être perdues si le profil utilisateur n'a pas été chargé dans le processus de travail des services IIS et que le pool d'applications est recyclé. Ce scénario peut affecter les fournisseurs d'hébergement partagés qui exécutent les pools d'applications en tant que comptes d'utilisateur Windows standard.

Pour résoudre cette situation, ASP.NET permet de rendre permanentes les clés générées automatiquement dans le Registre HKLM au lieu du Registre HKCU. Cette opération est généralement effectuée à l'aide de l'utilitaire aspnet_regiis (voir les instructions indiquées dans la section « Résolution 2 : Utilisation de l'utilitaire aspnet_regiis »). Toutefois, les administrateurs ne souhaitant pas exécuter cet utilitaire peuvent utiliser le script suivant Windows PowerShell à la place :

# Configure le Registre HKLM afin que le compte d'utilisateur spécifié puisse rendre permanentes les clés d'ordinateur générées automatiquement.
function Provision-AutoGenKeys {
  [CmdletBinding()]
  param (
    [ValidateSet("2.0", "4.0")]
    [Parameter(Mandatory = $True)]
    [string] $frameworkVersion,
    [ValidateSet("32", "64")]
    [Parameter(Mandatory = $True)]
    [string] $architecture,
    [Parameter(Mandatory = $True)]
    [string] $upn
  )
  process {
    # Les autorisations administratives sont requises pour pouvoir continuer.
    if (-Not (new-object System.Security.Principal.WindowsPrincipal([System.Security.Principal.WindowsIdentity]::GetCurrent())).IsInRole([System.Security.Principal.WindowsBuiltInRole]::Administrator)) {
        Write-Error "This cmdlet requires Administrator permissions."
        return
    }
    # Ouvrir HKLM dans le Registre avec un affichage approprié
    if ($architecture -eq "32") {
        $regView = [Microsoft.Win32.RegistryView]::Registry32;
    } else {
        $regView = [Microsoft.Win32.RegistryView]::Registry64;
    }
    $baseRegKey = [Microsoft.Win32.RegistryKey]::OpenBaseKey([Microsoft.Win32.RegistryHive]::LocalMachine, $regView)
    # Ouvrir la clé de base ASP.NET
    if ($frameworkVersion -eq "2.0") {
        $expandedVersion = "2.0.50727.0"
    } else {
        $expandedVersion = "4.0.30319.0"
    }
    $aspNetBaseKey = $baseRegKey.OpenSubKey("SOFTWARE\Microsoft\ASP.NET\$expandedVersion", $True)
    # Créer la sous-clé AutoGenKeys si elle n'existe pas
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Obtenir l'identificateur de sécurité de l'utilisateur concerné, ce qui permet également d'accéder à sa sous-clé AutoGenKeys
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # Le SYSTÈME, les ADMINISTRATEURS et l'identificateur de sécurité cible disposent d'un accès complet
    $regSec = New-Object System.Security.AccessControl.RegistrySecurity
    $regSec.SetSecurityDescriptorSddlForm("D:P(A;OICI;GA;;;SY)(A;OICI;GA;;;BA)(A;OICI;GA;;;$sid)")
    $userAutoGenKey = $autoGenBaseKey.OpenSubKey($sid, $True)
    if ($userAutoGenKey -eq $null) {
        # La sous-clé n'existait pas ; créer une liste de contrôle d'accès de manière appropriée
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # La sous-clé existait ; vérifier que les listes de contrôle d'accès sont correctes
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

L'exemple suivant montre comment configurer les entrées de Registre HKLM appropriées pour un pool d'applications qui s'exécute en tant qu'utilisateur, exemple@contoso.com (il s'agit du nom d'utilisateur principal du compte d'utilisateur Windows). Ce pool d'applications de 32 bits exécute la version CLR v2.0 (ASP.NET 2.0 ou 3.5).

PS> Provision-AutoGenKeys -FrameworkVersion 2.0 -Architecture 32 -UPN "example@contoso.com"

Si le pool d'applications est un pool d'applications de 64 bits qui exécute la version CLR v4.0 (ASP.NET 4.0 ou 4.5), la commande est la suivante :

PS> Provision-AutoGenKeys -FrameworkVersion 4,0 -Architecture 64 -UPN "example@contoso.com"

Même si les clés générées automatiquement sont stockées dans HKLM, la sous-clé de Registre, qui conserve les données de chiffrement confidentielles de chaque compte d'utilisateur, est ajoutée à une liste de contrôle d'accès de façon à ce que les données de chiffrement ne puissent pas être lues par d'autres comptes d'utilisateur.

Annexe C : Chiffrement de l'élément <machineKey> dans les fichiers de configuration

Les administrateurs du serveur peuvent ne pas vouloir d'informations hautement confidentielles, telles que l'élément de clé <machineKey>, en texte brut dans les fichiers de configuration. Dans ce cas, les administrateurs peuvent décider de profiter d'une fonction de .NET Framework connue comme « configuration protégée ». Cette fonctionnalité vous permet de chiffrer certaines sections des fichiers .config. Si le contenu de ces fichiers de configuration n'est jamais divulgué, le contenu de ces sections restera toujours confidentiel.

Vous trouverez une brève présentation de la configuration protégée sur le site web MSDN. Elle contient également un didacticiel relatif à la protection des éléments <connectionStrings> et <machineKey> du fichier Web.config.
Remarque Il s'agit d'un article de « PUBLICATION RAPIDE » rédigé directement au sein du service de support technique Microsoft. Les informations qui y sont contenues sont fournies en l'état, en réponse à des problèmes émergents. En raison du délai rapide de mise à disposition, les informations peuvent contenir des erreurs typographiques et, à tout moment et sans préavis, faire l'objet de révisions. Pour d'autres considérations, consultez les Conditions d'utilisation.

Propriétés

Numéro d'article: 2915218 - Dernière mise à jour: vendredi 20 juin 2014 - Version: 2.0
Les informations contenues dans cet article s'appliquent au(x) produit(s) suivant(s):
  • Microsoft .NET Framework 4.5.1 Release Candidate
  • Microsoft .NET Framework 4.5.1
  • Microsoft .NET Framework 4.5
  • Microsoft .NET Framework 4.0
  • Microsoft .NET Framework 3.5.1
  • Microsoft .NET Framework 3.5
  • Microsoft .NET Framework 2.0 Service Pack 2
  • Microsoft .NET Framework 1.1 Service Pack 1
Mots-clés : 
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218
L'INFORMATION CONTENUE DANS CE DOCUMENT EST FOURNIE PAR MICROSOFT SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. L'UTILISATEUR ASSUME LE RISQUE DE L'UTILISATION DU CONTENU DE CE DOCUMENT. CE DOCUMENT NE PEUT ETRE REVENDU OU CEDE EN ECHANGE D'UN QUELCONQUE PROFIT.

Envoyer des commentaires

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com