Risoluzione degli errori relativi allo stato di visualizzazione del codice MAC (Message Authentication Code)

Traduzione articoli Traduzione articoli
Identificativo articolo: 2915218 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

Definizione di stato di visualizzazione

Lo stato di visualizzazione corrisponde alle informazioni che viaggiano in andata e ritorno tra le pagine WebForms (.aspx) di un'applicazione ASP.NET. I commenti HTML per il campo __VIEWSTATE hanno un aspetto analogo al seguente:

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

Il testo di un pulsante rappresenta un esempio degli elementi che possono essere memorizzati nel campo __VIEWSTATE. Se un utente seleziona il pulsante, il gestore eventi Button_Click sarÓ in grado di estrarre il testo del pulsante dal campo relativo allo stato di visualizzazione. Per una panoramica pi¨ dettagliata relativa allo stato di visualizzazione in ASP.NET, consultare l'argomento Panoramica dello stato della visualizzazione di ASP.NET contenuto nel sito Web Microsoft Developer Network (MSDN).

Dal momento che il campo __VIEWSTATE comprende informazioni importanti che vengono utilizzate per ricostruire la pagina quando si effettua il postback, assicurarsi che un utente malintenzionato non riesca a manomettere il campo. Qualora un utente malintenzionato riuscisse a inviare un payload __VIEWSTATE dannoso, Ŕ possibile che possa indurre l'applicazione a eseguire un'azione che non avrebbe effettuato in una situazione differente.

Per evitare questo tipo di manomissione, il campo __VIEWSTATE viene protetto da un codice MAC (Message Authentication Code). ASP.NET convalida il codice MAC inviato insieme al payload __VIEWSTATE durante un evento di postback. La chiave utilizzata per calcolare il codice MAC viene indicata nell'elementoá<machineKey> dell'applicazioneápresente nel file Web.config. Dal momento che l'utente malintenzionato non pu˛ conoscere i contenuti dell'elemento <machineKey>, non pu˛ nemmeno fornire un codice MAC valido quando tenta di manomettere il payload __VIEWSTATE. Quando ASP.NET rileva che Ŕ stato fornito un codice MAC non valido, rifiuta tale richiesta dannosa.

Causa degli errori relativi alla convalida del codice MAC

Un errore di convalida del codice MAC ha un aspetto analogo a quello del seguente esempio:

Errore server nell'applicazione '/'.

Convalida dello stato di visualizzazione del codice MAC non riuscita. Se l'applicazione Ŕ ospitata da una Web farm o da un cluster, assicurarsi che la configurazione <machineKey> riporti lo stesso valore validationKey e lo stesso algoritmo di convalida. Il valore AutoGenerate non pu˛ essere utilizzato in un cluster.

Descrizione: Eccezione non gestita durante l'esecuzione della richiesta Web corrente. Per ulteriori informazioni sull'errore e sul suo punto di origine nel codice, vedere l'analisi dello stack.

Dettagli eccezione: System.Web.HttpException : Convalida dello stato di visualizzazione del codice MAC non riuscita. Se l'applicazione Ŕ ospitata da una Web farm o da un cluster, assicurarsi che la configurazione <machineKey> riporti lo stesso valore validationKey e lo stesso algoritmo di convalida. Il valore AutoGenerate non pu˛ essere utilizzato in un cluster.

Errore del codice sorgente: [Nessuna riga di origine rilevante]

File di origine: ... Riga: 0

Stack Trace:

[ViewStateException: stato di visualizzazione non valido.
IP client: ::1
Porta: 40653
Provenienza: http://localhost:40643/MyPage.aspx
Percorso: /MyPage.aspx
User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
ViewState: ...]

[HttpException (0x80004005): convalida dello stato di visualizzazione del codice MAC non riuscita. Se l'applicazione Ŕ ospitata da una Web farm o da un cluster, assicurarsi che la configurazione <machineKey> riporti lo stesso valore validationKey e lo stesso algoritmo di convalida. Il valore AutoGenerate non pu˛ essere utilizzato in un cluster.

Per ulteriori informazioni, visitare la pagina http://go.microsoft.com/fwlink/?LinkID=314055http://go.microsoft.com/fwlink/?LinkID=31405].
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

Causa 1: l'applicazione Web Ŕ in esecuzione in una farm (ambiente con pi¨ server)

ASP.NET genera automaticamente una chiave di crittografia per ogni applicazione e la memorizza nell'hive di registro HKCU. Questa chiave generata automaticamente viene utilizzata in mancanza di un elemento <machineKey> specifico nella configurazione dell'applicazione. Tuttavia, dal momento che tale chiave generata automaticamente si trova in locale sul computer che l'ha generata, Ŕ possibile che si verifichino dei problemi nel caso delle applicazioni che vengono eseguite in una farm. Ogni server presente nella farm genera la propria chiave locale e nessuno dei server della farm si accorda su quale chiave utilizzare. Pertanto, se un server genera un payload __VIEWSTATE utilizzato da un server differente, l'utente visualizzerÓ un errore di convalida relativo al codice MAC.
  • Soluzione 1a: creazione di un elemento <machineKey> esplicito

    Se si aggiunge un elemento <machineKey> esplicito al file Web.config dell'applicazione, lo sviluppatore comunica ad ASP.NET di non utilizzare la chiave di crittografia generata automaticamente. Consultare la sezione Appendice A per informazioni su come generare un elemento <machineKey>. Dopo aver aggiunto tale elemento al file Web.config, Ŕ necessario distribuire di nuovo l'applicazione in ogni server della farm.

    NotaáAlcuni servizi di hosting Web, ad esempio i siti Web di Microsoft Azure, sincronizzano la chiave generata automaticamente dell'applicazione nei loro server back-end. In questo modo, le applicazioni per cui non Ŕ stato indicato un elemento <machineKey> specifico potranno continuare a funzionare in tali ambienti, anche se vengono eseguite in una farm. Se l'applicazione viene eseguita su un servizio di hosting di terze parti, contattare il fornitore per stabilire se questa situazione Ŕ adatta al proprio caso.

  • Soluzione 1b: abilitazione di affinitÓ nel servizio di bilanciamento del carico

    Se i siti dell'utente sono in esecuzione in un servizio di bilanciamento del carico, Ŕ possibile abilitare l'affinitÓ server affinchÚ risolva temporaneamente il problema. In questo modo, Ŕ possibile assicurare che i client interagiscano soltanto con un server fisico nel servizio di bilanciamento del carico. Di conseguenza, tutti i payload di crittografia saranno generati e utilizzati dallo stesso server.

    Non considerare questo metodo come una soluzione definitiva del problema. Anche se l'affinitÓ server Ŕ attivata, la maggior parte dei servizi di bilanciamento del carico reindirizzeranno il client verso un server fisico differente. Ci˛ si verifica nel caso in cui il server originale su cui Ŕ stata eseguita l'affinitÓ dei servizi di bilanciamento del carico passa in modalitÓ non in linea. Pertanto, il nuovo server rifiuta i payload di crittografia (ad esempio, __VIEWSTATE, ticket dell'autenticazione basata su form, token MVC antifalsificazione e altri servizi) disponibili nel client.

    Si consiglia di utilizzare un elemento <machineKey> esplicito e distribuire di nuovo dell'applicazione, piuttosto che abilitare l'affinitÓ server.

Causa 2: utilizzo dell'identitÓ del pool di applicazioni di IIS 7.0 da parte del processo di lavoro

In Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) Ŕ stata introdotta l'identitÓ del pool di applicazioni, un nuovo meccanismo di isolamento che consente di fornire maggiore sicurezza ai server che eseguono le applicazioni ASP.NET. Tuttavia, i siti in esecuzione nell'identitÓ del pool di applicazioni non dispongono dell'accesso al registro HKCU. In tale registro il runtime di ASP.NET memorizza le chiavi <machineKey> generate automaticamente. Pertanto, ASP.NET non pu˛ mantenere la chiave generata automaticamente quando viene reimpostato il pool di applicazioni. Ogni volta che viene reimpostato il file w3wp.exe, viene generata una nuova chiave temporanea.

Nota Questo problema non riguarda IIS 7.5 (Windows 7, Windows Server 2008 R2) e le versioni successive. In queste versioni di IIS, ASP.NET Ŕ in grado di mantenere le chiavi generate automaticamente in un percorso differente che rimane intatto anche nel caso in cui vengano reimpostati i pool di applicazioni.
  • Soluzione 2a: utilizzo dell'utilitÓ aspnet_regiis

    Le installazioni di ASP.NET comprendono un'utilitÓ denominataáaspnet_regiis.exe. Tale utility permette all'interfaccia ASP.NET con IIS di effettuare le procedure di configurazione necessarie per eseguire un'applicazione gestita. Tramite una di queste procedure di configurazione vengono create nell'hive di registro le chiavi per abilitare la persistenza delle chiavi computer generate automaticamente.

    Innanzitutto, Ŕ necessario determinare quale pool di applicazioni viene utilizzato dal sito. ╚ possibile effettuare questa operazione utilizzando l'utilitÓ inetmgr inclusa in IIS. Selezionare il proprio sito dalla visualizzazione albero a sinistra, fare clic con il pulsante destro del mouse su Gestione sito Web, quindi selezionare Impostazioni avanzate. Viene visualizzata una finestra di dialogo in cui Ŕ indicato il nome del pool di applicazioni.

    Riduci l'immagineEspandi l'immagine
    Impostazioni avanzate


    Per eseguire lo scaffolding delle chiavi del Registro di sistema appropriate per un pool di applicazioni di ASP.NET, attenersi alla seguente procedura:
    1. Aprire un prompt dei comandi di amministrazione.
    2. Individuare la directory appropriata, a seconda che il pool di applicazioni sia a 32 bit o a 64 bit:
      • Pool di applicazioni a 32 bit:ácd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • Pool di applicazioni a 64 bit:ácd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. Accedere alla directory, digitare il comando seguente, quindi premere INVIO:

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

    Se il pool di applicazioni fa parte di ASP.NET 2.0 o 3.5, attenersi alla seguente procedura:
    1. Aprire un prompt dei comandi di amministrazione.
    2. Individuare la directory appropriata, a seconda che il pool di applicazioni sia a 32 bit o a 64 bit:
      • Pool di applicazioni a 32 bit:ácd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • Pool di applicazioni a 64 bit:ácd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Accedere alla directory, digitare il comando seguente, quindi premere INVIO:

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

    Ad esempio, se il pool di applicazioni Ŕ denominato My App Poolá(come nell'immagine precedente), eseguire il seguente comando:
    á
    aspnet_regiis -ga "IIS APPPOOL\My App Pool"


    Nota ╚ possibile che debbano essere in esecuzione servizi di sistema APPHOSTSVC e WAS affinchÚ l'utilitÓ aspnet_regiis riesca a risolvere in modo corretto i nomi IIS APPPOOL\*.

  • Soluzione 2b: creazione di un elemento <machineKey> esplicito

    Se si aggiunge un elemento <machineKey> esplicito al file Web.config dell'applicazione, lo sviluppatore comunica ad ASP.NET di non utilizzare la chiave di crittografia generata automaticamente. Consultare la sezione Appendice A per informazioni su come generare un elemento <machineKey>.


Causa 3: configurazione del pool di applicazioni tramite LoadUserProfile=false

Se il pool di applicazioni Ŕ in esecuzione con un'identitÓ personalizzata, Ŕ possibile che IIS non abbia caricato il profilo dell'utente per l'identitÓ. L'effetto collaterale di questa situazione Ŕ dato dal fatto che il registro HKCU non Ŕ disponibile per permettere ad ASP.NET di mantenere l'elemento <machineKey> generato automaticamente. Di conseguenza, verrÓ creata una nuova chiave generata automaticamente ad ogni riavvio dell'applicazione. Per ulteriori informazioni, vedere la sezione Profilo utente sul sito Web Microsoft.
  • Soluzione 3a: utilizzo dell'utilitÓ aspnet_regiis

    Le istruzioni relative a questa risoluzione sono le stesse della Soluzione 2a. Per ulteriori informazioni, fare riferimento a tale sezione.

  • Soluzione 3b: utilizzo di un elemento <machineKey> esplicito

    Se si aggiunge un elemento <machineKey> esplicito al file Web.config dell'applicazione, lo sviluppatore comunica ad ASP.NET di non utilizzare la chiave di crittografia generata automaticamente. Consultare la sezione Appendice A per informazioni su come generare un elemento <machineKey>.

  • Soluzione 3c: esecuzione manuale del provisioning delle chiavi del Registro di sistema HCKU necessarie

    Se non Ŕ possibile eseguire l'utilitÓ aspnet_regiis, utilizzare uno script di Windows PowerShell per eseguire il provisiong delle chiavi del Registro di sistema in HCKU. Per ulteriori informazioni, consultare la sezioneáAppendice B.

  • Soluzione 3d: configurazione di LoadUserProfile=true per il pool di applicazioni

    ╚ possibile abilitare il caricamento del profilo utente all'interno del pool di applicazioni. In questo modo, l'hive del registro HKCU, la cartella temporanea e altri percorsi di memorizzazione specifici dell'utente saranno resi disponibili per l'applicazione. Tuttavia, ci˛ potrebbe comportare un aumento relativo all'utilizzo di spazio su disco o memoria per il processo di lavoro. Per ulteriori informazioni su come attivare questa impostazione, vedere l'elemento <processModel>.

Causa 4: valore della proprietÓ Page.ViewStateUserKey errato

Gli sviluppatori di software possono decidere di utilizzare la proprietÓáPage.ViewStateUserKeyáper aggiungere protezione da una richiesta intersito falsa al campo __VIEWSTATE. Se si utilizza la proprietÓáPage.ViewStateUserKeyá, questa viene impostata su un valore corrispondente al nome utente corrente o all'identificatore di sessione. Nei modelli di progetto per le applicazioni WebFormsáin Microsoft Visual Studio 2012 e versioni successive sono inclusi alcuni esempi che utilizzando questa proprietÓ. Per ulteriori informazioni, consultare l'argomentoáProprietÓ Page.ViewStateUserKey sul sito Web Microsoft Developer Network (MSDN).

Se viene specificata la proprietÓ ViewStateUserKey, il valore viene registrato nel campo __VIEWSTATE al momento della creazione. Quando viene utilizzato il campo __VIEWSTATE, il server controlla la proprietÓ ViewStateUserKey corrente della pagina e convalida il valore utilizzato per generare il campo __VIEWSTATE. Se i valori non corrispondono, la richiesta viene rifiutata in quanto considerata come potenzialmente dannosa.

Un esempio di errore relativo a ViewStateUserKey Ŕ rappresentato da un client che dispone di due schede aperte in un browser. Il client viene registrato come Utente A e nella prima scheda viene visualizzata una pagina con un campo __VIEWSTATE, la cui proprietÓáViewStateUserKeyácontiene "Utente A." Nella seconda scheda, il client si disconnette e in seguito si riconnette come Utente B. Il client torna alla prima scheda e invia il modulo. ╚ possibile che la proprietÓ ViewStateUserKey contenga "Utente B", in base a quanto indicato dal cookie di autenticazione del client. Tuttavia, il campo __VIEWSTATE inviat dal client contiene "Utente A". Questa mancata corrispondenza causa l'errore.
  • Soluzione 4a: verifica della corretta impostazione di ViewStateUserKey

    Se l'applicazione dell'utente utilizza la proprietÓ ViewStateUserKey, verificare che il valore della proprietÓ rimanga lo stesso sia quando lo stato di visualizzazione viene generato sia quando viene utilizzato. Se si utilizza il nome utente di registrazione, assicurarsi che l'utente sia ancora registrato e che l'identitÓ non sia cambiata al momento dell'esecuzione del postback. Se si utilizza un identificatore di sessione corrente, assicurarsi che la sessione non sia scaduta.

    Se si opera in un ambiente farm, assicurarsi che gli elementi <machineKey> corrispondano. Per le procedure di creazione relative a questi elementi, consultare la sezione Appendice A.

Appendice A: creazione di un elemento <machineKey>

Avviso di sicurezza

Molti siti Web generano un elemento <machineKey> semplicemente tramite un gesto di clic su un pulsante da parte dell'utente. Non utilizzare mai un elemento <machineKey> ottenuto da uno di questi siti. Non Ŕ possibile sapere se tali chiavi siano state create in modo sicuro o se sono registrate su un database nascosto. Si consiglia di utilizzare sempre elementi di configurazione <machineKey> creati dall'utente.


Per generare un elemento <machineKey>, Ŕ possibile utilizzare il seguente script di Windows PowerShell:

# Genera un elemento <machineKey> che pu˛ essere copiato + incollato in un file 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)
  }
}

Per le applicazioni ASP.NET 4.0, Ŕ sufficiente chiamare Generate-MachineKeyásenza parametri per generare un elemento <machineKey>, come indicato di seguito:

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

Le applicazioni ASP.NET 2.0 e 3.5 non supportano HMACSHA256. ╚ possibile specificare SHA1 per generare un elemento <machineKey> compatibile, come indicato di seguito:

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

Non appena si dispone di un elemento <machineKey>, Ŕ possibile inserirlo nel file Web.config. L'elemento <machineKey> Ŕ valido soltanto nel file Web.config della directory principale dell'applicazione e non Ŕ valido a livello di sottocartella.

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

Per visualizzare un elenco completo relativo agli algoritmi supportati, eseguire help Generate-MachineKeyádal prompt di Windows PowerShell.

Appendice B: esecuzione del provisioning del Registro di sistema per mantenere le chiavi generate automaticamente

Per impostazione definita, le chiavi generate automaticamente di ASP.NET vengono mantenute nel registro HKCU e per questo motivo potrebbero andare perdute nel caso in cui il profilo utente non venga caricato nel processo di lavoro IIS e venga eseguito il riciclo successivo del pool di applicazioni. ╚ possibile che questa situazione interessi i provider di hosting che eseguono pool di applicazioni come account utente standard di Windows.

Per risolvere questa situazione, ASP.NET consente di mantenere le chiavi generate automaticamente nel registro HKLM invece che in quello HKCU. In genere, Ŕ possibile effettuare tale operazione utilizzando l'utilitÓ aspnet_regiis. Consultare la procedura riportata nella sezione "Soluzione 2a: utilizzo dell'utilitÓ aspnet_regiis. Gli amministratori che non hanno intenzione di eseguire l'utilitÓ possono utilizzare il seguente script diáWindows PowerShell:

# Esecuzione del provisioning del registro HKLM in modo che l'account utente specificato possa mantenere le chiavi generate automaticamente dal computer.
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 {
    # We require administrative permissions to continue.
    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
    }
    # Open HKLM with an appropriate view into the registry
    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)
    # Open ASP.NET base key
    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)
    # Create AutoGenKeys subkey if it doesn't already exist
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Get the SID for the user in question, which will allow us to get his AutoGenKeys subkey
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORS, and the target SID get full access
    $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) {
        # Subkey didn't exist; create and ACL appropriately
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Subkey existed; make sure ACLs are correct
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

Il seguente esempio illustra come eseguire il provisioning delle voci di registro HKLM adeguate per un pool di applicazioni che viene eseguita come utente,áexample@contoso.comá(UPN dell'account utente Microsoft). Il pool di applicazioni consiste in un pool di applicazioni a 32 bit che esegue CLR v2.0 (ASP.NET 2.0 or 3.5).

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

Invece, se il pool di applicazioni Ŕ a 64 bit ed esegue CLR v4.0 (ASP.NET 4.0 or 4.5), il comando sarÓ:

PS> Provision-AutoGenKeys -FrameworkVersion 4.0 -Architecture 64 -UPN "example@contoso.com"

Anche se le chiavi generate automaticamente vengono memorizzate in HKLM, la sottochiave del registro che conserva il materiale di crittografia segreto per ogni account viene aggiunta all'elenco di controllo di accesso (ACL). In questo modo il materiale di crittografia non pu˛ essere letto da altri account utente.

Appendice C: crittografia dell'elemento <machineKey> nei file di configurazione

╚ possibile che gli amministratori di server non desiderino che informazioni altamente sensibili (ad esempio, il materiale della chiave <machineKey>) sia visualizzato come testo normale nei file di configurazione. In questo caso, gli amministratori decidono di sfruttare una funzionalitÓ di .NET Framework nota come "configurazione protetta". Questa funzionalitÓ permette di crittografare alcune parti dei file .config. Se i contenuti di tali file di configurazione vengono divulgati, i contenuti delle varie parti resteranno segreti.

╚ possibile trovare una breve panoramica relativa alla configurazione protetta sul sito Web MSDN. ╚ presente anche un'esercitazione su come proteggere gli elementi <connectionStrings> e <machineKey> del file Web.config.
Nota: questo Ŕ un articolo a "PUBBLICAZIONE RAPIDA", creato direttamente all'interno dell'organizzazione di supporto Microsoft. Le informazioni contenute nel presente documento vengono fornite "cosý come sono" in risposta alle problematiche riscontrate. A causa della rapiditÓ con cui vengono resi disponibili, i materiali possono contenere errori di battitura e sono soggetti a modifica senza preavviso, in qualsiasi momento. Per altre considerazioni, vedere le Condizioni per l'utilizzo.

ProprietÓ

Identificativo articolo: 2915218 - Ultima modifica: venerdý 20 giugno 2014 - Revisione: 2.0
Le informazioni in questo articolo si applicano a:
  • 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
Chiavi:á
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

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