Beheben von Fehlern bezüglich des Ansichtszustand-Nachrichtenauthentifizierungscodes (MAC)

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 2915218 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Was ist der Ansichtszustand?

Beim Ansichtszustand handelt es sich um Informationen, die zwischen WebForms-Seiten einer ASP.NET-Anwendungen ausgetauscht werden. Das HTML-Markup für das Feld __VIEWSTATE sieht etwa wie folgt aus:

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

Ein Beispiel für ein Element, das im Feld __VIEWSTATE gespeichert werden könnte, ist der Text eines Button-Steuerelements. Wenn der Benutzer auf die Schaltfläche klickt, kann der Button_Click-Ereignishandler den Text der Button-Schaltfläche aus dem Feld __VIEWSTATE extrahieren. Eine ausführlichere Übersicht über den ASP.NET-Ansichtszustand finden Sie im Thema Übersicht über den ASP.NET-Ansichtszustand auf der Microsoft Developer Network (MSDN)-Website.

Weil das Feld __VIEWSTATE wichtige Informationen enthält, die beim Postback zum Rekonstruieren der Seite verwendet werden, stellen Sie sicher, dass Angreifer dieses Feld nicht manipulieren können. Wenn es einem Angreifer gelänge, eine bösartige __VIEWSTATE-Nutzlast zu senden, dann könnte der Angreifer die Anwendung potenziell dazu bringen, eine Aktion auszuführen, die ansonsten nicht ausgeführt worden wäre.

Um diese Art von Manipulationsangriffen zu vermeiden, wird das Feld __VIEWSTATE durch einen Nachrichtenauthentifizierungscode (MAC) geschützt. ASP.NET überprüft den MAC, der zusammen mit der __VIEWSTATE-Nutzlast übermittelt wird, wenn ein Postback erfolgt. Der Schlüssel wird verwendet, um den MAC entsprechend der Angabe im<machineKey>-Element der Datei "Web.config" der Anwendung zu berechnen. Weil Angreifer den Inhalt des <machineKey>-Elements nicht erraten können, kann ein Angreifer keinen gültigen MAC bereitstellen, wenn er die __VIEWSTATE-Nutzlast zu manipulieren versucht. ASP.NET erkennt, dass kein gültiger MAC bereitgestellt wurde, und ASP.NET weist die bösartige Anforderung zurück.

Wodurch werden MAC-Validierungsfehler verursacht?

Ein MAC-Validierungsfehler ähnelt dem folgenden Beispiel:

Serverfehler in der Anwendung '/'.

Fehler bei der Validierung von ViewState-MAC. Wenn diese Anwendung von einer Webfarm oder einem Cluster gehostet wird, stellen Sie sicher, dass die <machineKey>-Konfiguration den gleichen validationKey und Validierungsalgorithmus angibt. AutoGenerate kann in einem Cluster nicht verwendet werden.

Beschreibung: Beim Ausführen der aktuellen Webanforderung ist eine nicht behandelte Ausnahme aufgetreten. Überprüfen Sie die Stapelüberwachung, um weitere Informationen über diesen Fehler anzuzeigen und festzustellen, wo dieser Fehler im Code verursacht wurde.

Ausnahmedetails: System.Web.HttpException : Fehler bei der Validierung von ViewState-MAC. Wenn diese Anwendung von einer Webfarm oder einem Cluster gehostet wird, stellen Sie sicher, dass die <machineKey>-Konfiguration den gleichen validationKey und Validierungsalgorithmus angibt. AutoGenerate kann in einem Cluster nicht verwendet werden.

Quellfehler: [Keine relevanten Quellzeilen]

Quelldatei: ... Zeile: 0

Stapelüberwachung:

[ViewStateException: Ungültiger ViewState.
Client-IP: ::1
Port: 40653
Referenz: http://localhost:40643/MyPage.aspx
Pfad: /MyPage.aspx
Benutzeragent: Mozilla/5.0 (kompatibel; MSIE 10.0; Windows NT 6.2; WOW64; Trident/6.0)
ViewState: ...]

[HttpException (0x80004005): Fehler bei der Validierung von ViewState-MAC. Wenn diese Anwendung von einer Webfarm oder einem Cluster gehostet wird, stellen Sie sicher, dass die <machineKey>-Konfiguration den gleichen validationKey und Validierungsalgorithmus angibt. AutoGenerate kann in einem Cluster nicht verwendet werden.

Weitere Informationen finden Sie unter http://go.microsoft.com/fwlink/?LinkID=314055.]
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

Ursache 1: Die Webanwendung wird in einer Farm (Umgebung mit mehreren Servern) ausgeführt

ASP.NET generiert automatisch kryptografische Schlüssel für jede Anwendung und speichert den Schlüssel in der HKCU-Registrierungsstruktur. Dieser automatisch generierte Schlüssel wird verwendet, wenn die Konfigurationsdatei der Anwendung kein explizites <machineKey>-Element enthält. Weil dieser automatisch generierte Schlüssel nur lokal auf dem Computer, der den Schlüssel generiert hat, bekannt ist, führt dieses Szenario bei Anwendungen, die in einer Farm ausgeführt werden, zu Problemen. Jeder Server in der Farm generiert seinen eigenen lokalen Schlüssel, und die Server in der Farm können sich nicht darauf einigen, welcher Schlüssel verwendet werden soll. Die Folge ist, dass eine __VIEWSTATE-Nutzlast, die von einem Server generiert und von einem anderen Server verwendet wird, bei diesem anderen Server einen MAC-Validierungsfehler auslöst.
  • Lösung 1a: Erstellen eines expliziten <machineKey>-Elements

    Durch das Hinzufügen eines expliziten <machineKey>-Elements zur Datei "Web.config" der Anwendung, weist der Entwickler ASP.NET an, den automatisch generierten kryptografischen Schlüssel nicht zu verwenden. Anweisungen zum Generieren eines <machineKey>-Elements finden Sie in Anhang A. Nachdem dieses Element der Datei "Web.config" hinzugefügt wurde, stellen Sie die Anwendung erneut auf jedem Server in der Farm bereit.

    Hinweis Einige Webhostingdienste, z. B. Microsoft Azure-Websites, versuchen, die automatisch generierten Schlüssel auf den Backendserver zu synchronisieren. Dadurch können die Anwendungen, für die kein explizites <machineKey>-Element angegeben wurde, selbst dann weiterhin in diesen Umgebungen arbeiten, wenn die Anwendung in einer Farm ausgeführt wird. Wenn die Anwendung in einem Hostingdienst eines Drittanbieters ausgeführt wird, beringen Sie über den Anbieter des Hostingdienstes in Erfahrung, ob diese Situation für Sie zutrifft.

  • Lösung 1b: Aktivieren der Affinität im Lastenausgleichsmodul

    Wenn Ihre Websites hinter einem Lastenausgleichsmodul arbeiten, können Sie die Serveraffinität aktivieren, um das Problem zeitweilig zu umgehen. Dadurch lässt sich leichter sicherstellen, dass jeder gegebene Client nur mit einem physischen Server hinter dem Lastenausgleichsmodul zusammenarbeitet, sodass alle kryptografischen Nutzlasten vom gleichen Server generiert und verwendet werden.

    Dies sollte nicht als langfristige Lösung für das Problem betrachtet werden. Selbst wenn die Serveraffinität aktiviert wurde, leiten die meisten Lastenausgleichsmodule den Client zu einem anderen physischen Server weiter, wenn der ursprüngliche Server, an den die Lastenausgleichsmodule durch die Aktivierung der Affinität verwiesen wurden, offline geht. Dies bewirkt, dass der neue Server kryptografische Nutzlasten (wie __VIEWSTATE, Formularauthentifizierungstickets, MVC-Schutz zum Fälschungsschutz und andere Dienste) zurückweist, die der Client derzeit hat.

    Statt die Serveraffinität zu aktivieren, sollte ein explizites <machineKey>-Element verwendet und die Anwendung erneut bereitgestellt werden.

Ursache 2: Der Woirkerprozess verwendet die IIS 7.0-Anwendungspoolidentität

In Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) wurde die Anwendungspoolidentität eingeführt. Dabei handelt es sich um einen neuen Isolierungsmechanismus, der erhöhte Sicherheit für Server bereitstellt, die ASP.NET-Anwendungen ausführen. Wenn Websites unter der Anwendungspoolidentität ausgeführt werden, haben Sie allerdings keinen Zugriff auf die HKCU-Registrierungsstruktur. Dort speichert die ASP.NET-Runtime die automatisch generierten <machineKey>-Schlüssel. Die Folge davon ist, dass ASP.NET den automatisch generierten Schlüssel nicht speichern kann, wenn der Anwendungspool zurückgesetzt wird. Daher wird jedes Mal, wenn "w3wp.exe" zurückgesetzt wird, ein neuer temporärer Schlüssel generiert.

Hinweis In IIS 7.5 (Windows 7, Windows Server 2008 R2) und höheren Versionen tritt dieses Problem nicht auf. In diesen Versionen von IIS kann ASP.NET die automatisch generierten Schlüssel an einem anderen Speicherort speichern, der auch nach dem Zurücksetzen des Anwendungspools verfügbar ist.
  • Lösung 2a: Verwenden des Dienstprogramms "aspnet_regiis"

    ASP.NET-Installationen enthalten ein Dienstprogramm namens aspnet_regiis.exe. Dieses Dienstprogramm kann die ASP.NET-Schnittstelle mit IIS die Konfigurationen durchführen, die zum Ausführen einer verwalteten Anwendung erforderlich sind. Eine dieser Konfigurationen erstellt die erforderlichen Schlüssel in der Registrierungsstruktur, um das Speichern der automatisch generierten Schlüssel zu ermöglichen.

    Zuerst müssen Sie bestimmen, welchen Anwendungspool Ihre Website verwendet. Dies kann mit dem Dienstprogramm inetmgr ermittelt werden, das zum Lieferumfang von IIS gehört. Wählen Sie Ihre Website in der Strukturansicht links aus, klicken Sie mit der rechten Maustaste auf Website verwalten, und klicken Sie dann auf Erweiterte Einstellungen. Das Dialogfeld, das daraufhin geöffnet wird, enthält den Anwendungspoolnamen.

    Bild minimierenBild vergrößern
    Erweiterte Einstellungen


    Gehen Sie folgendermaßen vor, um die entsprechenden Registrierungsschlüssel für einen ASP.NET 4.0-Anwendungspool zu unterstützen:
    1. Öffnen Sie eine administrative Eingabeaufforderung.
    2. Suchen Sie das entsprechende Verzeichnis, je nachdem, ob Sie einen 32-Bit- oder 64-Bit-Anwendungspool verwenden:
      • 32-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
      • 64-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319

    3. Wechseln Sie zu diesem Verzeichnis, geben Sie den folgenden Befehl ein, und drücken Sie die Eingabetaste:

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

    Wenn es sich beim Anwendungspool um einen ASP.NET 2.0- oder 3.5-Anwendungspool handelt, gehen Sie folgendermaßen vor:
    1. Öffnen Sie eine administrative Eingabeaufforderung.
    2. Suchen Sie das entsprechende Verzeichnis, je nachdem, ob Sie einen 32-Bit- oder 64-Bit-Anwendungspool verwenden:
      • 32-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
      • 64-Bit-Anwendungspool: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727

    3. Wechseln Sie zu diesem Verzeichnis, geben Sie den folgenden Befehl ein, und drücken Sie die Eingabetaste:

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

    Wenn der Anwendungspool z. B. My App Pool heißt (wie im vorigen Bild), führen Sie folgenden Befehl aus:
     
    aspnet_regiis -ga "IIS APPPOOL\My App Pool"


    Hinweis Die Systemdienste APPHOSTSVC und WAS müssen unter Umständen ausgeführt werden, damit das Dienstprogramm "aspnet_regiis" APPPOOL\*-Namen von IIS richtig auflösen kann.

  • Lösung 2b: Erstellen eines expliziten <machineKey>-Elements

    Durch das Hinzufügen eines expliziten <machineKey>-Elements zur Datei "Web.config" der Anwendung, weist der Entwickler ASP.NET an, den automatisch generierten kryptografischen Schlüssel nicht zu verwenden. Anweisungen zum Generieren eines <machineKey>-Elements finden Sie in Anhang A.


Ursache 3: Der Anwendungspool ist mit "LoadUserProfile=false" konfiguriert

Wenn der Anwendungspool mit einer benutzerdefinierten Identität ausgeführt wird, hat IIS möglicherweise das Benutzerprofil für die Identität nicht geladen. Dies hat den Nebeneffekt, dass dann die HKCU-Registierungsstruktur nicht zum Speicher des automatisch generierten <machineKey>-Schlüssels für ASP.NET verfügbar ist. Daher wird jedes Mal, wenn die Anwendung neu gestartet wird, ein neuer automatisch generierter Schlüssel erstellt. Weitere Informationen finden Sie unter Benutzerprofil auf der Microsoft-Website.
  • Lösung 3a: Verwenden des Dienstprogramms "aspnet_regiis"

    Die Anweisungsschritte sind identisch mit denen von Lösung 2a. Weitere Informationen finden Sie in diesem Abschnitt.

  • Lösung 3b: Verwenden eines expliziten <machineKey>-Elements

    Durch das Hinzufügen eines expliziten <machineKey>-Elements zur Datei "Web.config" der Anwendung, weist der Entwickler ASP.NET an, den automatisch generierten kryptografischen Schlüssel nicht zu verwenden. Anweisungen zum Generieren eines <machineKey>-Elements finden Sie in Anhang A.

  • Lösung 3c: Manuelles Bereitstellen der erforderlichen HKCU-Registrierungsschlüssel

    Wenn Sie das Dienstprogramm "aspnet_regiis" nicht ausführen können, dann können Sie mit einem Windows PowerShell-Skript die entsprechenden Registrierungsschlüssel in HKCU bereitstellen. Weitere Informationen finden Sie in Anhang B.

  • Lösung 3d: Set LoadUserProfile=true for this application pool

    Sie können auch das Laden des Benutzerprofils in diesen Anwendungspool aktivieren. Dadurch werden die HKCU-Registrierungsstruktur, temporäre Ordner und andere benutzerspezifische Speicherorte für die Anwendung verfügbar. Allerdings kann dies dazu führen, dass der Worker-Prozess mehr Datenträger- oder Arbeitsspeicher belegt. Weitere Informationen zum Aktivieren dieser Einstellung finden Sie unter dem <processModel>-Element.

Ursache 4: Die Page.ViewStateUserKey-Eigenschaft hat einen falschen Wert

Softwareentwickler können die Page.ViewStateUserKey-Eigenschaft verwenden, um einen Fälschungsschutz für Anforderungen zwischen Websites dem __VIEWSTATE-Feld hinzuzufügen. Wenn Sie die Page.ViewStateUserKey-Eigenschaft verwenden, wird sie in der Regel auf einen Wert festgelegt, der dem Benutzernamen oder der Sitzungs-ID des Benutzers entspricht. Die Projektvorlagen für WebForms-Anwendungen in Microsoft Visual Studio 2012 und späteren Versionen enthalten Beispiele, in denen diese Eigenschaft verwendet wird. Weitere Informationen finden Sie im Thema Page.ViewStateUserKey Property der Microsoft Developer Network (MSDN)-Website.

Wenn die ViewStateUserKey-Eigenschaft angegeben wird, dann wird deren Wert beim Generieren in das __VIEWSTATE integriert. Wenn das __VIEWSTATE-Feld verwendet wird, überprüft der Server die ViewStateUserKey-Eigenschaft der aktuellen Seite und vergleicht sie mit dem Wert, der zum Generieren des __VIEWSTATE-Felds benutzt wurde. Wenn die Werte nicht übereinstimmen, wird die Anforderung als potenziell böswillig abgelehnt.

Ein Beispiel für einen Fehler, der mit der ViewStateUserKey-Eigenschaft zusammenhängt, wäre ein Client, der über zwei im Browser geöffnete Registerkarten verfügt. Der Client ist als "User A" angemeldet, und auf der ersten Registerkarte wird eine Seite mit einem __VIEWSTATE dargestellt, dessen ViewStateUserKey-Eigenschaft "User A" enthält. Auf der zweiten Registerkarte meldet sich der Benutzer ab und dann erneut als "User B" an. Der Client wechselt wieder zur ersten Registerkarte und sendet das Formular. Die ViewStateUserKey-Eigenschaft kann "Benutzer B" enthalten (weil dieser Wert im Authentifizierungscookie des Clients angegeben wird). Das vom Client übermittelte __VIEWSTATE-Feld enthält allerdings "User A". Dieser Konflikt verursacht den Fehler.
  • Lösung 4a: Sicherstellen, dass ViewStateUserKey richtig festgelegt wurde

    Wenn Ihre Anwendung die ViewStateUserKey-Eigenschaft verwendet, stellen Sie sicher, dass diese Eigenschaft beim Generieren des Ansichtszustand und beim Verwenden des Ansichtszustands denselben Wert hat. Wenn Sie den Benutzernamen des aktuell angemeldeten Benutzers verwenden, stellen Sie sicher, dass dieser Benutzer noch angemeldet ist und sich die Identität des Benutzer zum Zeitpunkt des Postback nicht geändert hat. Wenn Sie die Sitzungs-ID des aktuellen Benutzers verwenden, stellen Sie sicher, dass die Sitzung nicht abgelaufen ist.

    Wenn die Anwendung in einer Serverfarmumgebung ausgeführt wird, stellen Sie sicher, dass die <machineKey>-Elemente übereinstimmen. Hinweise dazu, wie Sie diese Elemente generieren, finden Sie in Anhang A.

Anhang A: Generieren von <machineKey>-Elementen

Sicherheitswarnmeldung

Es gibt viele Websites, die für Sie "auf Knopfdruck" ein <machineKey>-Element erstellen. Verwenden Sie nie <machineKey>-Elemente, die Sie von einer dieser Websites bezogen haben. Es lässt sich nicht feststellen, ob diese Schlüssel auf sichere Weise erstellt oder in einer geheimen Datenbank aufgezeichnet wurden. Sie sollten immer nur von Ihnen selbst erstellte <machineKey>-Konfigurationselemente verwenden.


Zum Generieren eines <machineKey>-Elements können Sie das folgendeWindows PowerShell-Skript verwenden:

# Generiert ein <machineKey>-Element, das kopiert und in eine Web.config-Datei eingefügt werden kann.
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)
  }
}

Für ASP.NET 4.0-Anwendungen können Sie einfach Generate-MachineKey ohne Parameter aufrufen, um wie folgt ein <machineKey>-Element zu erstellen:

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

ASP.NET 2.0- und 3.5-Anwendungen unterstützen HMACSHA256 nicht. Stattdessen können Sie angeben, dass SHA1 wie folgt ein kompatibles <machineKey>-Element generiert:

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

Sobald Sie ein <machineKey>-Element haben, können Sie es in der Datei "Web.config" verwenden. Das <machineKey>-Element ist nur in der Datei "Web.config" im Stammordner der Anwendung gültig und auf der Ebene der Unterordner unzulässig.

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

Um ein vollständige Liste der unterstützten Algorithmen zu erhalten, führen Sie help Generate-MachineKey von der Windows PowerShell-Eingabeaufforderung aus.

Anhang B: Bereitstellen der Registrierungsschlüssel zum Speichern der automatisch generierten Schlüssel

Weil die automatischen generierten Schlüssel von ASP.NET standardmäßig in der HKCURegistrierungsstruktur gespeichert werden, gehen diese Schlüssel u. U. verloren, wenn das Benutzerprofil nicht in den Worker-Prozess geladen wurde und der Anwendungspool wiederverwendet wird. Dieses Szenario kann sich auf freigegebene Hostinganbieter auswirken, die Anwendungspools als standardmäßige Windows-Benutzerkonten ausführen.

Um diese Situation zu umgehen, ermöglicht ASP.NET es, dass die automatisch generierten Schlüssel in der HKLM-Registrierungstruktur statt der HKCU-Registrierungstruktur gespeichert werden. Dies wird in der Regel mit dem Dienstprogramm "aspnet_regiis" ausgeführt (siehe die Anweisungen im Abschnitt "Lösung 2a: Verwenden des Dienstprogramms "aspnet_regiis"). Administratoren, die dieses Dienstprogramm nicht verwenden möchten, können stattdessen das folgende Windows PowerShell-Skript verwenden:

# Stellt die HKLM-Registrierungsstruktur bereit, damit das angegebene Benutzerkonto automatisch generierte Schlüssel beibehalten kann.
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 {
    # Wir brauchen Administratorrechte, um den Vorgang fortzusetzen.
    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
    }
    # HKLM mit der entsprechenden Ansicht in der Registrierung öffnen
    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)
    # ASP.NET-Schlüssel öffnen
    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)
    # Unterschlüssel AutoGenKeys erstellen, wenn er noch nicht vorhanden ist
    $autoGenBaseKey = $aspNetBaseKey.OpenSubKey("AutoGenKeys", $True)
    if ($autoGenBaseKey -eq $null) {
        $autoGenBaseKey = $aspNetBaseKey.CreateSubKey("AutoGenKeys")
    }
    # Die SID für den fraglichen Benutzer abrufen, über die wir diesen AutoGenKeys-Unterschlüssel abrufen können
    $sid = (New-Object System.Security.Principal.WindowsIdentity($upn)).User.Value
    # SYSTEM, ADMINISTRATORS und Ziel-SID erhalten Vollzugriff
    $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) {
        # Unterschlüssel war nicht vorhanden, erstellen und ACL entsprechend festlegen
        $userAutoGenKey = $autoGenBaseKey.CreateSubKey($sid, [Microsoft.Win32.RegistryKeyPermissionCheck]::Default, $regSec)
    } else {
        # Unterschlüssel war vorhanden, sicherstellen, dass ACLs korrekt sind
        $userAutoGenKey.SetAccessControl($regSec)
    }
  }
}

Im folgenden Beispiel wird gezeigt, wie die entsprechenden HKLM-Registrierungseinstellungen für einen Anwendungspool bereitgestellt werden, der unter dem Benutzernamen example@contoso.com ausgeführt wird (dies ist der UPN des Windows-Benutzerkontos). Hierbei handelt es sich um einen 32-Bit-Anwendungspool, der die CLR Version 2.0 (ASP.NET 2.0 oder 3.5) ausführt.

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

Wenn es sich stattdessen um einen 32-Bit-Anwendungspool, der CLR Version 4.0 (ASP.NET 4.0 oder 4.5) ausführt, handelt, dann muss der folgende Befehl ausgeführt werden:

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

Obwohl die automatisch erstellten Schlüssel in HKLM gespeichert werden, wird der Registrierungsunterschlüssel, der das geheime kryptografische Material der einzelnen Benutzerkonten enthält, einer Zugriffssteuerungsliste (Access Control List, ACL) hinzugefügt, damit das kryptografische Material nicht von anderen Benutzerkonten gelesen werden kann.

Anhang C: Verschlüsseln des <machineKey>-Elements in Konfigurationsdateien

Serveradministratoren möchten nicht, dass sehr vertrauliche Informationen, wie die <machineKey>-Schlüssel, als reiner Text in Konfigurationsdateien enthalten sind. In diesem Fall können die Administratoren ein .NET Framework-Feature nutzen, das als "geschützte Konfiguration" bezeichnet wird. Dieses Feature ermöglicht es Ihnen, bestimmte Abschnitte der CONFIG-Dateien zu verschlüsseln. Wenn der Inhalt der Konfigurationsdateien offengelegt wird, dann bleibt de Inhalt dieser Abschnitte trotzdem geschützt.

Sie finden auf der MSDN-Website einen kurzen Überblick über die geschützte Konfiguration. Dort ist auch ein Lernprogramm zum Schützen der <connectionStrings>- und <machineKey>-Elemente der Datei "Web.config" verfügbar.
Hinweis Dies ist ein Artikel, der im Schnellverfahren direkt von der Microsoft-Supportorganisation erstellt wurde. Die hierin enthaltenen Informationen werden als Reaktion auf neue Probleme wie besehen bereitgestellt. Da dieser Artikel im Schnellverfahren erstellt wurde, kann er Tippfehler enthalten und zu einem späteren Zeitpunkt ohne vorherige Ankündigung überarbeitet werden. Weitere zu berücksichtigende Informationen finden Sie in den Nutzungsbedingungen.

Eigenschaften

Artikel-ID: 2915218 - Geändert am: Freitag, 20. Juni 2014 - Version: 2.0
Die Informationen in diesem Artikel beziehen sich auf:
  • 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
Keywords: 
kbsecvulnerability kbsecurity kbsecbulletin kbfix kbexpertiseinter kbbug atdownload KB2915218
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

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