Riešenie zobrazenie stavu správy overovací kód (MAC) chyby

Čo je stav zobrazenia?

Zobraziť stav je informácie, ktoré sa zaokrúhliť medzi WebForms (. aspx) stránky v aplikácii ASP.NET. HTML značky _ VIEWSTATE pole sa podobá nasledujúcemu hláseniu:

< typ vstupu = "skrytý" name = "_ _ VIEWSTATE" ID = "_ _ VIEWSTATE" hodnota = "..."/>Jeden príklad položky, ktorá môže byť uložená v poli _ VIEWSTATE je text ovládacieho prvku tlačidla. Ak používateľ klikne na tlačidlo, obslužný program udalostí Button_Click bude môcť extrahovať text tlačidla z poľa Stav zobrazenia. Pozrite si tému ASP.net Zobraziť stav prehľad na webovej lokalite Microsoft Developer Network (MSDN) pre oveľa podrobnejšie prehľad stavu ASP.net zobrazenia. Pretože pole _ VIEWSTATE obsahuje dôležité informácie, ktoré sa používa na rekonštrukciu stránky na postback, uistite sa, že útočník nemôže manipulovať s týmto poľom. Ak útočník odoslal zlomyseľný _ VIEWSTATE užitočného zaťaženia, útočník mohol potenciálne trik aplikácie do vykonania akcie, ktoré by inak nebolo vykonané. Ak chcete zabrániť tomuto druhu manipulácie útoku, _ _ VIEWSTATE pole je chránený overovací kód správy (MAC). ASP.NET overuje MAC, ktorý je predložený spolu s _ _ VIEWSTATE užitočného zaťaženia pri postback nastane. Kľúč, ktorý sa používa na výpočet MAC je špecifikovaný v aplikácii prvok v súbore web. config. Pretože útočník nemôže odhadnúť obsah < machineKey > prvok, útočník nemôže poskytnúť platný MAC, ak útočník pokúsi manipulovať s údajovou časťou _ VIEWSTATE. ASP.NET rozpozná, že platný MAC nebol poskytnutý, a ASP.NET odmietne požiadavku na škodlivý.

Čo spôsobuje chyby overenia pravosti systému MAC?

Chyba overenia MAC bude podobať nasledujúcemu príkladu:

Chyba servera v aplikácii "/". Overenie systému ViewState MAC zlyhalo. Ak táto aplikácia hosťuje webovej farmy alebo klastra, uistite sa, že < machineKey > Konfigurácia určuje rovnaké validationKey a overovací algoritmus. Automatické generovanie sa nedá použiť v klastri. Popis: počas vykonania aktuálnej webovej požiadavky sa vyskytla nespracovaná výnimka. Skontrolujte trasovanie zásobníka ďalšie informácie o chybe a kde vznikol v kóde. Podrobnosti o výnimke: System. Web. HttpException: overenie ViewState MAC zlyhala. Ak táto aplikácia hosťuje webovej farmy alebo klastra, uistite sa, že < machineKey > Konfigurácia určuje rovnaké validationKey a overovací algoritmus. Automatické generovanie sa nedá použiť v klastri. Zdroj chyba: [žiadne relevantné zdrojové riadky] Zdrojový súbor:... Linka: 0 Trasovanie zásobníka: [ViewStateException: neplatný ViewState. Klient IP::: 1 Port: 40653 Referer: http://localhost:40643/MyPage.aspx Cesta:/MyPage.aspx User-Agent: Mozilla/5.0 (kompatibilný; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) ViewState:...] [HttpException (0x80004005): overenie ViewState MAC zlyhala. Ak táto aplikácia hosťuje webovej farmy alebo klastra, uistite sa, že < machineKey > Konfigurácia určuje rovnaké validationKey a overovací algoritmus. Automatické generovanie sa nedá použiť v klastri. Pozri http://go.microsoft.com/fwlink/?LinkID=314055 pre viac informácií.] System. Web. UI. ViewStateException. ThrowError (výnimka vnútorné, reťazec persistedState, reťazec errorPageMessage, Boolean macValidationError) + 190 System. Web. UI. ViewStateException. ThrowMacValidationError (výnimka vnútorné, reťazec persistedState) + 46 System. Web. UI. ObjectStateFormatter. Deserialize (reťazec inputString, účel účel) + 861 System. Web. UI. ObjectStateFormatter. System. Web. UI. IStateFormatter2. Deserialize (reťazec serializedState, účel účel) + 51 System. Web. UI. util. DeserializeWithAssert (IStateFormatter2 Formatter, reťazec serializedState, účel účel) + 67 System. Web. UI. HiddenFieldPageStatePersister. Load () + 444 System. Web. UI. Page. LoadPageStateFromPersistenceMedium () + 368 System. Web. UI. Page. LoadAllState () + 109 System. Web. UI. Page. ProcessRequestMain (Boolovská hodnota includeStagesBeforeAsyncPoint, Boolovská hodnota includeStagesAfterAsyncPoint) + 7959 System. Web. UI. Page. ProcessRequest (Boolovská hodnota includeStagesBeforeAsyncPoint, Boolovská hodnota includeStagesAfterAsyncPoint) + 429 System. Web. UI. Page. ProcessRequest () + 125 System. Web. UI. Page. Processrequestwithnoasser(HttpContext kontext) + 48 System. Web. UI. Page. ProcessRequest (HttpContext kontext) + 234 ASP. mypage_aspx. ProcessRequest (HttpContext kontext) v...: 0 System. Web. CallHandlerExecutionStep. System. Web. HttpApplication. IExecutionStep. Execute () + 1300 System. Web. HttpApplication. ExecuteStep (IExecutionStep krok, Boolean & Completedsynchrónne) + 140

Príčina 1: webová aplikácia je spustená v farme (multi-server prostredie)

ASP.NET automaticky generuje kryptografický kľúč pre každú aplikáciu a uloží kľúč do podregistra HKCU. Tento automaticky vygenerovaný kľúč sa používa, ak nie je explicitný < machineKey > prvok v konfigurácii aplikácie. Avšak, pretože tento automaticky vygenerovaný kľúč je lokálny počítač, ktorý vytvoril kľúč, tento scenár spôsobuje problém pre aplikácie, ktoré sa spúšťajú vo farme. Každý server vo farme vygeneruje svoj vlastný lokálny kľúč a žiadny zo serverov v poľnohospodárskom podniku sa nebude dohodnúť na tom, ktorý kľúč sa má použiť. Výsledkom je, že ak jeden Server generuje údajová časť _ VIEWSTATE, že iný server spotrebuje, spotrebiteľ bude mať zlyhanie overenia pravosti systému MAC.

Rezolúcia 1a: vytvoriť explicitný < machineKey > prvok Pridaním explicitné < machineKey > prvok súboru Web. config aplikácie, Developer hovorí ASP.NET nepoužívať automaticky generované kryptografický kľúč. Pokyny na vytvorenie < machineKey > prvku nájdete v dodatku A . Po pridaní tohto prvku do súboru Web. config, znova nasadiť aplikáciu na každý server vo farme. Poznámka: Niektoré webhostingové služby, napríklad webové lokality spoločnosti Microsoft Azure, podniknú kroky na synchronizáciu automaticky vygenerovaného kľúča každej aplikácie naprieč ich koncovým serverom. To umožňuje aplikáciám, ktoré nezadali explicitné < machineKey > prvok pokračovať v práci v týchto prostrediach, aj keď aplikácia je spustená vo farme. Ak je vaša aplikácia spustená na hostiteľskej službe tretej strany, obráťte sa na svojho poskytovateľa hostingu a zistite, či sa táto situácia vzťahuje na vás.
Rezolúcia 1b: povoliť afinitu v Load vyrovnávanie Ak vaše stránky fungujú za load balancer, môžete zapnúť afinitu k serveru dočasne obísť problém. To pomáha zabezpečiť, že každý klient iba spolupracuje s jedným fyzickým serverom za Load vyrovnávanie tak, že všetky kryptografické zaťaženie budú generované a spotrebované na rovnakom serveri. Toto by sa nemalo považovať za dlhodobé riešenie problému. Dokonca aj vtedy, keď je zapnutá afinita servera, väčšina load balancer presmeruje klienta na iný fyzický server, ak pôvodný server, na ktoré boli tieto load balancer affinitized prejde do režimu offline. To spôsobí, že nový server odmietnuť kryptografické zaťaženie (napríklad _ _ VIEWSTATE, formuláre overovanie vstupenky, MVCs anti-falšovanie tokeny a ďalšie služby), že klient má v súčasnosti. Pomocou explicitný < machineKey > prvok a opätovné nasadenie aplikácie by mali byť uprednostňované nad umožňujúce afinitu k serveru.

Príčina 2: pracovník proces používa identita fondu aplikácií IIS 7,0

Internetové informačné služby (IIS) 7,0 (Windows Vista, Windows Server 2008) predstavil identita fondu aplikácií, nový izolačnýmechanizmus, ktorý pomáha poskytovať zvýšenú bezpečnosť pre servery, ktoré spúšťajú ASP.NET aplikácie. Však stránky, ktoré sú spustené pod identita fondu aplikácií nemajú prístup k databáze Registry HKCU. To je miesto, kde ASP.NET runtime ukladá svoje auto-generované < machineKey > kľúče. Výsledkom je, že ASP.NET nemôže pretrvávať automaticky vygenerovaný kľúč pri obnovení fondu aplikácií. Preto zakaždým, keď w3wp. exe je reset, nový dočasný kľúč je generovaný. Poznámka: Toto nie je problém v službe IIS 7,5 (Windows 7, Windows Server 2008 R2) a novšie verzie. V týchto verziách služby IIS, ASP.NET môže pretrvávať jeho auto-generované kľúče na inom mieste, ktoré prežíva fondu aplikácií obnoví.

Riešenie 2a: použite pomôcku Aspnet_regiis ASP.NET zariadenia obsahujú pomôcku, Aspnet_regiis. exe. Tento nástroj umožňuje ASP.NET rozhranie s IIS vykonávať konfigurácie, ktoré sú potrebné na spustenie spravované aplikácie. Jedna z týchto konfigurácií vytvorí potrebné kľúče v podregistri databázy Registry na umožnenie pretrvávania automaticky generované kľúče stroja. Najprv musíte určiť, ktorý fond aplikácií používa vaše webové stránky. To možno určiť pomocou nástroja inetmgr , ktorý je súčasťou IIS. Vyberte svoje stránky v stromovom zobrazení vľavo, kliknite pravým tlačidlom myši Spravovať website, a potom kliknite na tlačidlo Rozšírené nastavenia. Dialógové okno, ktoré sa zobrazí, zobrazí názov fondu aplikácií. Na lešenie príslušné kľúče databázy Registry pre fond aplikácií ASP.NET 4,0, postupujte nasledovne:
1. Otvorte správcovské príkazový riadok.
2. Vyhľadajte príslušný adresár v závislosti od toho, či fond aplikácií je 32-bitová alebo 64-bitová verzia:
  - 32-bitový fond aplikácií: CD/d%windir%\Microsoft.NET\Framework\v4.0.30319
  - 64-bitový fond aplikácií: CD/d%windir%\Microsoft.NET\Framework64\v4.0.30319
3. Presunúť do adresára, zadajte nasledovný príkaz a stlačte kláves ENTER:
  
  Aspnet_regiis-GA "IIS APPPOOL\app-pool-name"
Ak fond aplikácií je ASP.NET 2,0 alebo 3,5 fondu aplikácií, postupujte nasledovne:
1. Otvorte správcovské príkazový riadok.
2. Vyhľadajte príslušný adresár v závislosti od toho, či fond aplikácií je 32-bitová alebo 64-bitová verzia:
  - 32-bitový fond aplikácií: CD/d%windir%\Microsoft.NET\Framework\v2.0.50727
  - 64-bitový fond aplikácií: CD/d%windir%\Microsoft.NET\Framework64\v2.0.50727
3. Presunúť do adresára, zadajte nasledovný príkaz a stlačte kláves ENTER:
  
  Aspnet_regiis-GA "IIS APPPOOL\app-pool-name"
Ak sa napríklad fond aplikácií nazýva môj fond aplikácií (ako v predchádzajúcom obrázku), spustite nasledujúci príkaz:

Aspnet_regiis-GA "IIS APPPOOL\My App pool" Poznámka: Systémové služby APPHOSTSVC a bol môže byť spustený pre pomôcku Aspnet_regiis na riešenie IIS APPPOOL \ * názvy vhodne.
Riešenie 2b: vytvoriť explicitné < machineKey > prvok Pridaním explicitné < machineKey > prvok súboru Web. config aplikácie, Developer hovorí ASP.NET nepoužívať automaticky generované kryptografický kľúč. Pokyny na vytvorenie < machineKey > prvku nájdete v dodatku A .

Príčina 3: fond aplikácií je nakonfigurovaný pomocou LoadUserProfile = FALSE

Ak fond aplikácií je spustený s vlastnou identitou, IIS pravdepodobne nenačítal používateľský profil identity. To má vedľajší účinok tvorby databázy Registry HKCU k dispozícii pre ASP.NET pretrvávajú automaticky generované < machineKey >. Preto sa vytvorí nový automaticky vygenerovaný kľúč vždy, keď sa aplikácia reštartuje. Ďalšie informácie nájdete v časti používateľský profil na webovej lokalite spoločnosti Microsoft.

Rezolúcia 3a: použite pomôcku Aspnet_regiis Pokyny pre Toto sú rovnaké ako rezolúcia 2a. Pozri túto sekciu pre viac informácií.
Rezolúcia 3b: použite explicitné < machineKey > Pridaním explicitné < machineKey > prvok súboru Web. config aplikácie, Developer hovorí ASP.NET nepoužívať automaticky generované kryptografický kľúč. Pokyny na vytvorenie < machineKey > prvku nájdete v dodatku A .
Rezolúcia 3c: poskytovanie požadovaných kľúčov databázy Registry HKCU manuálne Ak nemôžete spustiť pomôcku Aspnet_regiis, môžete použiť skript prostredia Windows PowerShell na poskytovanie vhodných kľúčov databázy Registry v HKCU. Ďalšie informácie nájdete v dodatku B .
Rozlíšenie 3D: Set LoadUserProfile = True pre tento fond aplikácií Môžete tiež povoliť načítanie profilu používateľa v rámci tohto fondu aplikácií. To robí podregister HKCU databázy Registry, dočasný priečinok a iné User-špecifické ukladacie miesta k dispozícii aplikácie. To však môže spôsobiť zvýšenie disku alebo pamäte pre pracovník procesu. Ďalšie informácie o zapnutí tohto nastavenia nájdete v prvku .

Príčina 4: vlastnosť Page. ViewStateUserKey má nesprávnu hodnotu

Vývojári softvéru sa môžu rozhodnúť použiť vlastnosť Page. ViewStateUserKey na pridanie požiadavky na ochranu proti falšovaniu do poľa _ ViewState. Ak použijete vlastnosť Page. ViewStateUserKey , zvyčajne je nastavená na hodnotu, akou je používateľské meno aktuálneho používateľa alebo identifikátor relácie používateľa. Šablóny projektu pre aplikácie WebForms Microsoft Visual Studio 2012 a novšie verzie obsahujú vzorky, ktoré používajú túto vlastnosť. Pozrite si stránku. ViewStateUserKey vlastnosť tému na webovej lokalite Microsoft Developer Network (MSDN) Ďalšie informácie. Ak je zadaná vlastnosť Viewstateuserkey , jej hodnota je spálená do _ ViewState v čase generovania. Keď sa spotrebuje pole _ VIEWSTATE, server skontroluje vlastnosť Viewstateuserkey aktuálnej stránky a overuje ju proti hodnote, ktorá bola použitá na GENEROVANIE poľa _ ViewState. Ak sa hodnoty nezhodujú, žiadosť je zamietnutá ako potenciálne škodlivý. Príkladom ViewStateUserKey-súvisiace zlyhanie by klient, ktorý má dve karty otvorené v prehľadávači. Klient je prihlásený ako používateľ a, a na prvej karte, stránka je vykreslený _ VIEWSTATE, ktorého Viewstateuserkey vlastnosť obsahuje "User a." V druhej karte, klient prihlási a potom prihlási späť ako používateľ B. Klient vráti na prvú kartu a odošle formulár. Vlastnosť Viewstateuserkey môže obsahovať "User B" (pretože to je to, čo klient overenie cookie hovorí). Pole _ VIEWSTATE, ktoré klient odoslal obsahuje "používateľ A." Tento nesúlad spôsobuje zlyhanie.

Riešenie 4a: Overte, či je správne nastavený ViewStateUserKey Ak vaša aplikácia používa vlastnosť Viewstateuserkey , overte, či je hodnota vlastnosti rovnaká ako pri generácii stavu zobrazenia a pri jej konzumácii. Ak používate aktuálne prihláseného používateľa užívateľské meno, uistite sa, že používateľ je stále prihlásený a že totožnosť používateľa sa nezmenila v čase postback. Ak používate identifikátor relácie aktuálneho používateľa, uistite sa, že relácia nebola vypršala. Ak používate v prostredí farmy, uistite sa, že < machineKey > prvky zápas. Pokyny na generovanie týchto prvkov nájdete v dodatku A .

Dodatok A: ako generovať < machineKey > prvok

Upozornenie zabezpečenia Existuje mnoho webových stránok, ktoré budú generovať < machineKey > prvok pre vás s kliknutím na tlačidlo. Nikdy nepoužívajte < machineKey > prvok, ktorý ste získali z jednej z týchto lokalít. Je nemožné vedieť, či tieto kľúče boli vytvorené bezpečne, alebo ak sú zaznamenané do tajnej databázy. Mali by ste len niekedy používať < machineKey > konfiguračné prvky, ktoré ste vytvorili sami.

Generovať < machineKey > prvok sami, môžete použiť nasledujúci skript prostredia Windows PowerShell :

# Generates a <machineKey> element that can be copied + pasted into a Web.config file.
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)
  }
}

Pre ASP.NET 4,0 aplikácie, stačí zavolať generovať-machinekey bez parametrov generovať < machinekey > prvok takto:

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

ASP.NET 2,0 a 3,5 aplikácie nepodporujú HMACSHA256. Namiesto toho môžete zadať SHA1 generovať kompatibilný < machineKey > prvok takto:

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

Akonáhle máte < machineKey > prvok, môžete ho dať do súboru Web. config. < MachineKey > prvok je platný iba v súbore web. config v koreňovom adresári aplikácie a nie je platná na úrovni podpriečinka.

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

Úplný zoznam podporovaných algoritmov, spustite Pomocníka generovať-MachineKey z príkazového riadka prostredia Windows PowerShell.

Dodatok B: poskytovanie databázy Registry na pretrvávania automaticky vygenerovaných kľúčov

Predvolene, pretože ASP. NETs auto-generované kľúče pretrvávajú v databáze Registry HKCU, tieto kľúče môžu stratiť, ak profil používateľa nebol načítaný do procesu IIS pracovník a potom fondu aplikácií recykluje. Tento scenár môže ovplyvniť zdieľaný hosting poskytovateľov, ktoré sú spustené fondy aplikácií ako štandardné používateľské kontá systému Windows. Ak chcete obísť túto situáciu, ASP.NET umožňuje pretrvávajúce automaticky generované kľúče v databáze Registry HKLM namiesto HKCU databázy Registry. To sa zvyčajne vykonáva pomocou Aspnet_regiis Utility (pozri pokyny v "riešenie 2a: použite Aspnet_regiis Utility" sekcia). Však pre správcov, ktorí nechcú spustiť tento nástroj, nasledujúci skript prostredia Windows PowerShell môžu byť použité namiesto:

# Provisions the HKLM registry so that the specified user account can persist auto-generated machine keys.
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)
    }
  }
}

Nasledujúci príklad ukazuje, ako stanoviť príslušné položky databázy Registry HKLM pre fond aplikácií, ktorý sa spúšťa ako používateľ, example@contoso.com (Toto je UPN používateľského konta systému Windows). Tento fond aplikácií je 32-bitové fondu aplikácií, ktorý je spustený CLR v 2.0 (ASP.NET 2,0 alebo 3,5).

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

Ak fond aplikácií namiesto je 64-bitové fondu aplikácií, ktorý je spustený CLR v 4.0 (ASP.NET 4,0 alebo 4,5), príkaz je nasledovné:

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

Aj keď auto-generované kľúče sú uložené v HKLM, podkľúč databázy Registry, ktorý drží každého používateľského konta tajné kryptografický materiál sa pridá do zoznamu prístupových práv (ACL) tak, že kryptografický materiál nemôže čítať iné používateľské kontá.

Dodatok C: šifrovanie < machineKey > prvok v konfiguračných súboroch

Správcovia servera nemusia chcieť veľmi citlivé informácie, ako je < machineKey > kľúčový materiál bein PlainText formulára v konfiguračných súboroch. Ak je to tak, správcovia môžu rozhodnúť využiť funkciu .NET Framework známe ako "chránené konfigurácie." Táto funkcia umožňuje zašifrovať určité časti súborov. config. Ak obsah týchto konfiguračných súborov sú niekedy zverejnené, budú tieto oddiely ' obsah naďalej tajné. Stručný prehľad chránenej konfigurácie nájdete na webovej lokalite MSDN. Obsahuje tiež návod, ako chrániť < connectionStrings > a < machineKey > prvky súboru Web. config.