MAC-fouten (Message Authentication Code) in de weergavestatus oplossen

Vertaalde artikelen Vertaalde artikelen
Artikel ID: 2915218 - Bekijk de producten waarop dit artikel van toepassing is.
Alles uitklappen | Alles samenvouwen

Wat is de weergavestatus?

De weergavestatus is informatie die wordt uitgewisseld tussen pagina's met webformulieren (.aspx) in een ASP.NET-toepassing. De HTML-opmaak voor het veld __VIEWSTATE ziet er ongeveer als volgt uit:

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

Een voorbeeld van een item dat kan worden opgeslagen in het veld __VIEWSTATE, is de tekst van een knop. Als een gebruiker op de knop klikt, kan de gebeurtenishandler Button_Click de tekst van de knop ophalen uit het veld met de weergavestatus. Zie het onderwerp Overzicht van de weergavestatus van ASP.NET op de MSDN-website (Microsoft Developer Network) voor een gedetailleerd overzicht van de weergavestatus van ASP.NET.

Omdat het veld __VIEWSTATE belangrijke informatie bevat die wordt gebruikt om de pagina te reconstrueren bij het terugposten, moet u zorgen dat een aanvaller niet kan knoeien met dit veld. Als een aanvaller schadelijke inhoud voor __VIEWSTATE verzendt, kan de aanvaller de toepassing ertoe aanzetten een actie uit te voeren die anders niet zou worden uitgevoerd.

Om een dergelijke aanval te voorkomen, wordt het veld __VIEWSTATE beschermd door een MAC (Message Authentication Code). ASP.NET valideert de MAC die samen met de inhoud van __VIEWSTATE wordt verzonden wanneer een terugpostgebeurtenis plaatsvindt. De sleutel die wordt gebruikt om de MAC te berekenen, is opgegeven in het element <machineKey> in het bestand Web.config van de toepassing. Omdat de aanvaller de inhoud van het element <machineKey> niet kan raden, kan de aanvaller geen geldige MAC opgeven om met de inhoud van __VIEWSTATE te knoeien. ASP.NET ontdekt dat er geen geldige MAC is opgegeven en ASP.NET weigert de schadelijke aanvraag.

Waardoor worden MAC-validatiefouten veroorzaakt?

Een MAC-validatiefout ziet er ongeveer als volgt uit:

Serverfout in '/' toepassing.

Validatie van MAC voor weergavestatus is mislukt. Als de host voor deze toepassing een webfarm of cluster is, moet u ervoor zorgen dat in de <machineKey>-configuratie dezelfde validationKey en hetzelfde validatiealgoritme worden gebruikt. AutoGenerate kan niet worden gebruikt in een cluster.

Beschrijving: Er is een niet-verwerkte uitzondering opgetreden tijdens de uitvoering van de huidige webaanvraag. Raadpleeg de stacktracering voor meer informatie over de fout en waar deze voorkomt in de code.

Details van uitzondering: System.Web.HttpException : Validatie van MAC voor weergavestatus is mislukt. Als de host voor deze toepassing een webfarm of cluster is, moet u ervoor zorgen dat in de <machineKey>-configuratie dezelfde validationKey en hetzelfde validatiealgoritme worden gebruikt. AutoGenerate kan niet worden gebruikt in een cluster.

Bronfout: [Geen relevante bronregels]

Bronbestand: ... Regel: 0

Stacktrace:

[ViewStateException: Ongeldige weergavestatus.
Client-IP: ::1
Poort: 40653
Verwijzende site: http://localhost:40643/MijnPagina.aspx
Pad: /MijnPagina.aspx
Gebruikersagent: Mozilla/5.0 (compatibel; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
Weergavestatus: ...]

[HttpException (0x80004005): Validatie van MAC voor weergavestatus is mislukt. Als de host voor deze toepassing een webfarm of cluster is, moet u ervoor zorgen dat in de <machineKey>-configuratie dezelfde validationKey en hetzelfde validatiealgoritme worden gebruikt. AutoGenerate kan niet worden gebruikt in een cluster.

Zie http://go.microsoft.com/fwlink/?LinkID=314055 voor meer informatie.]
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

Oorzaak 1: De webtoepassing wordt uitgevoerd in een farm (omgeving met meerdere servers)

ASP.NET genereert automatisch een cryptografische sleutel voor elke toepassing en slaat de sleutel op in de HKCU-registercomponent. Deze automatisch gegenereerde sleutel wordt gebruikt als er geen expliciet <machineKey>-element bestaat in configuratie van de toepassing. Maar omdat deze automatisch gegenereerde sleutel lokaal aanwezig is op de computer die de sleutel heeft gemaakt, veroorzaakt dit scenario een probleem voor toepassingen die in een farm worden uitgevoerd. Elke server in de farm genereert een eigen lokale sleutel en de servers in de farm gebruiken niet allemaal dezelfde sleutel. Als een server inhoud voor __VIEWSTATE genereert die door een andere server wordt gebruikt, treedt er daardoor een MAC-validatiefout op bij de gebruiker.
  • Oplossing 1a: Een expliciet <machineKey>-element maken

    Als een ontwikkelaar een expliciet <machineKey>-element aan het bestand Web.config van de toepassing toevoegt, weet ASP.NET dat er geen automatisch gegenereerde sleutel moet worden gebruikt. Zie Bijlage A voor instructies voor het genereren van een <machineKey>-element. Als dit element is toegevoegd aan het bestand Web.config, implementeert u de toepassing opnieuw op elke server in de farm.

    Opmerking Sommige webhostingservices, zoals Microsoft Azure-websites, nemen maatregelen om de automatisch gegenereerde sleutel van elke toepassing te synchroniseren op hun back-endservers. Zo kunnen toepassingen waarvoor geen expliciet <machineKey>-element is opgegeven, blijven werken in die omgevingen, zelfs als de toepassing wordt uitgevoerd in een farm. Als uw toepassing wordt uitgevoerd via een hostingservice, neemt u contact op met uw hostingprovider om te bepalen of deze situatie voor u geldt.

  • Oplossing 1b: Affiniteit inschakelen in de netwerktaakverdeler

    Als uw sites achter een netwerktaakverdeler werken, kunt u serveraffiniteit inschakelen om het probleem tijdelijk te omzeilen. Zo zorgt u ervoor dat elke client slechts met één fysieke server samenwerkt achter de netwerktaakverdeler, zodat alle cryptografische inhoud door dezelfde server wordt gegenereerd en gebruikt.

    U moet dit niet zien als een oplossing voor het probleem op lange termijn. Zelfs als serveraffiniteit is ingeschakeld, sturen de meeste netwerktaakverdelers de client door naar een andere fysieke server als de oorspronkelijke server waaraan de netwerktaakverdelers zijn gekoppeld, is uitgeschakeld. Hierdoor weigert de nieuwe server cryptografische inhoud (zoals __VIEWSTATE, tickets voor formulierverificatie, antivervalsingstokens van MVC, en andere services) die de client momenteel heeft.

    Een expliciet <machineKey>-element gebruiken en de toepassing opnieuw implementeren heeft de voorkeur boven het inschakelen van serveraffiniteit.

Oorzaak 2: Het werkproces gebruikt de identiteit van de groep van toepassingen voor IIS 7.0

In Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) is de identiteit van groep van toepassingen geïntroduceerd, een nieuwe isolatiemechanisme om de beveiliging te verbeteren van servers waarop ASP.NET-toepassingen worden uitgevoerd. Sites die worden uitgevoerd onder de identiteit van de groep van toepassingen, hebben echter geen toegang tot het HKCU-register. En daar slaat de ASP.NET-runtime de automatisch gegenereerde <machineKey>-sleutels op. Het resultaat is dat ASP.NET de automatisch gegenereerde sleutel niet kan bewaren wanneer de groep van toepassingen opnieuw wordt ingesteld. Daarom wordt elke keer een nieuwe tijdelijke sleutel gegenereerd wanneer w3wp.exe opnieuw wordt ingesteld.

Opmerking Dit is geen probleem in IIS 7.5 (Windows 7, Windows Server 2008 R2) en latere versies. In deze versies van IIS kan ASP.NET de automatisch gegenereerde sleutels bewaren op een andere locatie, die blijft bestaan als de groep van toepassingen opnieuw wordt ingesteld.
  • Oplossing 2a: Het hulpprogramma aspnet_regiis gebruiken

    Installaties van ASP.NET bevatten het hulpprogramma aspnet_regiis.exe. Via dit hulpprogramma kan ASP.NET communiceren met IIS om de configuraties uit te voeren die zijn vereist voor het uitvoeren van een beheerde toepassing. Een van deze configuraties maakt de benodigde sleutels in de registercomponent om automatisch gegenereerde computersleutels te kunnen bewaren.

    U moet eerst bepalen welke groep van toepassingen uw site gebruikt. Dit kunt u bepalen met het hulpprogramma inetmgr dat bij IIS wordt geleverd. Selecteer uw site in de structuurweergave aan de linkerkant, klik met de rechtermuisknop op Website beheren en klik vervolgens op Geavanceerde instellingen. In het dialoogvenster dat verschijnt, wordt de naam van de groep van toepassingen weergegeven.

    Deze afbeelding samenvouwenDeze afbeelding uitklappen
    Geavanceerde instellingen


    Ga als volgt te werk om de juiste registersleutels voor een groep van toepassingen van ASP.NET 4.0 in te stellen:
    1. Open een administratieve opdrachtprompt.
    2. Zoek de juiste map, afhankelijk van de versie van de groep van toepassingen (32-bits of 64-bits):
      • Groep van 32-bits toepassingen: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • Groep van 64-bits toepassingen: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319

    3. Ga naar de map, typ de volgende opdracht en druk vervolgens op Enter:

      aspnet_regiis -ga "IIS APPPOOL\naam-van-groep-van-toepassingen"

    Als de groep van toepassingen een groep van ASP.NET 2.0 of 3.5 is, gaat u als volgt te werk:
    1. Open een administratieve opdrachtprompt.
    2. Zoek de juiste map, afhankelijk van de versie van de groep van toepassingen (32-bits of 64-bits):
      • Groep van 32-bits toepassingen: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • Groep van 64-bits toepassingen: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Ga naar de map, typ de volgende opdracht en druk vervolgens op Enter:

      aspnet_regiis -ga "IIS APPPOOL\naam-van-groep-van-toepassingen"

    Als de naam van uw groep van toepassingen bijvoorbeeld My App Pool is (zoals in de vorige afbeelding), voert u de volgende opdracht uit:
     
    aspnet_regiis -ga "IIS APPPOOL\My App Pool"


    Opmerking De systeemservices APPHOSTSVC en WAS moeten mogelijk zijn gestart om APPPOOL\*-namen van IIS correct om te zetten met het hulpprogramma aspnet_regiis.

  • Oplossing 2b: Een expliciet <machineKey>-element maken

    Als een ontwikkelaar een expliciet <machineKey>-element aan het bestand Web.config van de toepassing toevoegt, weet ASP.NET dat er geen automatisch gegenereerde sleutel moet worden gebruikt. Zie Bijlage A voor instructies voor het genereren van een <machineKey>-element.


Oorzaak 3: De groep van toepassingen is geconfigureerd met LoadUserProfile=false

Als de groep van toepassingen wordt uitgevoerd met een aangepaste identiteit, heeft IIS mogelijk niet het juiste gebruikersprofiel geladen voor de identiteit. Hierdoor is het HKCU-register niet beschikbaar voor ASP.NET om de automatisch gegenereerde <machineKey> in te bewaren. Daarom wordt elke keer een nieuwe automatisch gegenereerde sleutel gemaakt wanneer de toepassing opnieuw wordt gestart. Zie het gedeelte Gebruikersprofiel op de Microsoft-website voor meer informatie.
  • Oplossing 3a: Het hulpprogramma aspnet_regiis gebruiken

    De instructies hiervoor zijn hetzelfde als in Oplossing 2a. Zie dat gedeelte voor meer informatie.

  • Oplossing 3b: Een expliciete <machineKey> gebruiken

    Als een ontwikkelaar een expliciet <machineKey>-element aan het bestand Web.config van de toepassing toevoegt, weet ASP.NET dat er geen automatisch gegenereerde sleutel moet worden gebruikt. Zie Bijlage A voor instructies voor het genereren van een <machineKey>-element.

  • Oplossing 3c: De vereiste HKCU-registersleutels handmatig inrichten

    Als u het hulpprogramma aspnet_regiis niet kunt uitvoeren, kunt u met een Windows PowerShell-script de juiste registersleutels in HKCU inrichten. Zie Bijlage B voor meer informatie.

  • Oplossing 3d: LoadUserProfile=true instellen voor deze groep van toepassingen

    U kunt ook inschakelen dat het gebruikersprofiel in deze groep van toepassingen wordt geladen. Hierdoor zijn de HKCU-registercomponent, de tijdelijke map en andere gebruikersspecifieke opslaglocaties beschikbaar voor de toepassing. Dit kan echter leiden tot meer schijf- of geheugengebruik voor het werkproces. Zie het element <processModel> voor meer informatie over het inschakelen van deze instelling.

Oorzaak 4: De eigenschap Page.ViewStateUserKey heeft een onjuiste waarde

Softwareontwikkelaars kunnen de eigenschap Page.ViewStateUserKey gebruiken om voor alle sites bescherming tegen vervalsing van aanvragen toe te voegen aan het veld __VIEWSTATE. Als u de eigenschap Page.ViewStateUserKey gebruikt, is deze gewoonlijk ingesteld op een waarde zoals de gebruikersnaam of de sessie-id van de huidige gebruiker. De projectsjablonen voor toepassingen met webformulieren in Microsoft Visual Studio 2012 en latere versies bevatten voorbeelden waarin deze eigenschap wordt gebruikt. Zie het onderwerp De eigenschap Page.ViewStateUserKey op de MSDN-website (Microsoft Developer Network) voor meer informatie.

Als de eigenschap ViewStateUserKey is opgegeven, wordt de waarde hiervan in __VIEWSTATE gebrand tijdens het genereren. Wanneer het veld __VIEWSTATE wordt gebruikt, vergelijkt de server de eigenschap ViewStateUserKey van de huidige pagina met de waarde die is gebruikt om het veld __VIEWSTATE te genereren. Als de waarden niet overeenkomen, wordt de aanvraag geweigerd omdat deze mogelijk schadelijk is.

Een voorbeeld van een fout met betrekking tot ViewStateUserKey is een client die twee tabbladen heeft geopend in de browser. De client is aangemeld als Gebruiker A en in het eerste tabblad wordt een pagina weergegeven met een __VIEWSTATE waarvoor de eigenschap ViewStateUserKey 'Gebruiker A' bevat. In het tweede tabblad meldt de gebruiker zich af en meldt zich daarna weer aan als Gebruiker B. De client keert terug naar het eerste tabblad en verzendt het formulier. De eigenschap ViewStateUserKey kan 'Gebruiker B' bevatten (want dat is wat de verificatiecookie van de klant zegt). Het veld __VIEWSTATE dat de client heeft verzonden, bevat echter 'Gebruiker A'. Hierdoor wordt de fout veroorzaakt.
  • Oplossing 4a: Controleren of ViewStateUserKey correct is ingesteld

    Als uw toepassing de eigenschap ViewStateUserKey gebruikt, controleert u of de waarde van de eigenschap hetzelfde is wanneer de weergavestatus wordt gegenereerd en wanneer deze wordt gebruikt. Als u de gebruikersnaam van de aangemelde gebruiker gebruikt, moet u controleren of de gebruikers nog is aangemeld en of de identiteit van de gebruiker niet is gewijzigd op het moment van terugposten. Als u de sessie-id van de huidige gebruiker gebruikt, controleert u of de sessie niet verlopen is.

    Als de toepassing in een serverfarm wordt uitgevoerd, controleert u of de <machineKey>-elementen overeenkomen. Zie Bijlage A voor meer informatie over het genereren van deze elementen.

Bijlage A: Een <machineKey>-element genereren

Beveiligingswaarschuwing

Veel websites genereren een <machineKey>-element voor u waarvoor u op een knop moet klikken. Gebruik nooit een <machineKey>-element dat u van een van deze sites hebt gekregen. U kunt namelijk niet weten of deze sleutels veilig zijn gemaakt of dat ze worden opgenomen in een geheime database. Gebruik altijd alleen <machineKey>-configuratie-elementen die u zelf hebt gemaakt.


U kunt het volgende Windows PowerShell-script gebruiken om zelf een <machineKey>-element te genereren:

# Genereert een <machineKey>-element dat kan worden gekopieerd en geplakt in een Web.config-bestand.
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)
  }
}

Voor ASP.NET 4.0-toepassingen kunt u Generate-MachineKey zonder parameters aanroepen om een <machineKey>-element te genereren:

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

ASP.NET 2.0- en 3.5-toepassingen bieden geen ondersteuning voor HMACSHA256. In plaats daarvan kunt u SHA1 opgeven om een compatibele <machineKey>-element te genereren:

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

Zodra u een <machineKey>-element hebt, kunt u dit in het bestand Web.config plaatsen. Het <machineKey>-element is alleen geldig in het bestand Web.config in de hoofdmap van uw toepassing en niet in de submappen.

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

Voor een volledige lijst van ondersteunde algoritmen, voert u help Generate-MachineKey uit vanaf de Windows PowerShell-prompt.

Bijlage B: Het register inrichten om automatisch gegenereerde sleutels te bewaren

Omdat automatisch gegenereerde sleutels van ASP.NET worden bewaard in het HKCU-register, kunnen deze sleutels verloren gaan als het gebruikersprofiel niet is geladen in het IIS-werkproces en de groep van toepassingen wordt gerecycled. Dit scenario kan invloed hebben op gedeelde hostingproviders die groepen van toepassingen uitvoeren als standaard-Windows-gebruikersaccounts.

Om dit probleem te omzeilen, kan ASP.NET de automatisch gegenereerde sleutels bewaren in het HKLM-register in plaats van het HKCU-register. Dit wordt meestal uitgevoerd met het hulpprogramma aspnet_regiis (zie de instructies in 'Oplossing 2a: Het hulpprogramma aspnet_regiis gebruiken'). Beheerders die dit hulpprogramma niet willen uitvoeren, kunnen in plaats daarvan het volgende Windows PowerShell-script gebruiken:

# Het HKLM-register wordt zodanig ingericht dat de opgegeven gebruikersaccount automatisch gegenereerde computersleutels kan bewaren.
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)
    }
  }
}

In het volgende voorbeeld worden de juiste HKLM-registervermeldingen ingericht voor een groep van toepassingen die wordt uitgevoerd als de gebruiker example@contoso.com (dit is de UPN van het Windows-gebruikersaccount). Dit is een groep van 32-bits toepassingen die CLR v2.0 (ASP.NET 2.0 of 3.5) uitvoert.

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

Voor een groep van 64-bits toepassingen die CLR v4.0 (ASP.NET 4.0 of 4.5) uitvoert, gebruikt u de volgende opdracht:

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

Hoewel de automatisch gegenereerde sleutels worden opgeslagen in HKLM, wordt de subsleutel die de geheime cryptografische informatie van elk gebruikersaccount bevat, toegevoegd aan een toegangsbeheerlijst (ACL), zodat de cryptografische informatie niet kan worden gelezen door andere gebruikersaccounts.

Bijlage C: Het <machineKey>-element versleutelen in configuratiebestanden

Serverbeheerders willen vaak niet dat zeer vertrouwelijke informatie, zoals gegevens van <machineKey>-sleutels, als leesbare tekst wordt opgeslagen in configuratiebestanden. In dat geval kunnen beheerders gebruikmaken van een functie van .NET Framework die 'beveiligde configuratie' wordt genoemd. Met deze functie kunt u bepaalde gedeelten van de .config-bestanden versleutelen. Als de inhoud van deze configuratiebestanden ooit openbaar wordt gemaakt, blijft de inhoud van deze gedeelten geheim.

Op de MSDN-website vindt u een beknopt overzicht van beveiligde configuratie. U vindt daar ook een zelfstudie over het beveiligen van de elementen <connectionStrings> en <machineKey> van het bestand Web.config.
Opmerking Dit is een artikel voor snelle publicatie dat rechtstreeks is gemaakt vanuit de ondersteuningsorganisatie van Microsoft. De informatie in dit artikel wordt in de huidige vorm aangeboden in reactie op nieuw geconstateerde problemen. Aangezien artikelen van dit type zeer snel moeten worden gepubliceerd, kan de inhoud typografische fouten bevatten en kan de inhoud zonder voorafgaande kennisgeving worden gewijzigd. Raadpleeg de Gebruiksrechtovereenkomst voor overige aandachtspunten.

Eigenschappen

Artikel ID: 2915218 - Laatste beoordeling: vrijdag 20 juni 2014 - Wijziging: 2.0
De informatie in dit artikel is van toepassing op:
  • 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
Trefwoorden: 
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218

Geef ons feedback

 

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