Görünüm durumu iletikimlik kodu (MAC) hatalarını çözme

Görünüm durumu nedir?

Görünüm durumu, bir ASP.NET uygulamasında WebForms (.aspx) sayfaları arasında gidiş-dönüş olan bilgilerdir. __VIEWSTATE alanının HTML biçimlendirmesi aşağıdakilere benzer:

<giriş türü="gizli" adı="__VIEWSTATE" id="__VIEWSTATE" value="..." />__VIEWSTATE alanında depolanabilecek bir öğenin bir örneği, Düğme denetiminin metnidir. Bir kullanıcı düğmeyi tıklatarsa, Button_Click olay işleyicisi Düğme'nin metnini görünüm durumu alanından ayıklayabilirsiniz. ASP.NET görünüm durumuna çok daha ayrıntılı bir genel bakış için Microsoft Geliştirici Ağı (MSDN) web sitesindeki ASP.NET Görünüm Durumuna Genel Bakış konusuna bakın. __VIEWSTATE alanı, postback'teki sayfayı yeniden oluşturmak için kullanılan önemli bilgiler içerdiğinden, saldırganın bu alanı kurcalayamayacağından emin olun. Bir saldırgan kötü amaçlı bir __VIEWSTATE yükü gönderdiyse, saldırgan uygulamayı başka türlü gerçekleştirmeyecek bir eylemi gerçekleştirmesi için kandırabilir. Bu tür bir tahrifat saldırısını önlemek için__VIEWSTATE alanı bir ileti kimlik doğrulama kodu (MAC) tarafından korunur. ASP.NET, bir postback oluştuğunda __VIEWSTATE yüküyle birlikte gönderilen MAC'i doğrular. MAC'i hesaplamak için kullanılan anahtar, uygulamanın Web.config dosyasındaki öğesinde belirtilir. Saldırgan <machineKey> öğesinin içeriğini tahmin edemediğinden, saldırgan __VIEWSTATE yükünü kurcalamaya çalışırsa saldırgan geçerli bir MAC sağlayamaz. ASP.NET geçerli bir MAC sağlanmadığını algılar ve ASP.NET kötü amaçlı isteği reddeder.

MAC doğrulama hatalarına ne neden olur?

MAC doğrulama hatası aşağıdaki örneğe benzer:

'/' Uygulamasında Sunucu Hatası. Viewstate MAC doğrulama başarısız oldu. Bu uygulama bir web çiftliği veya küme tarafından barındırılan ise, <machineKey> yapılandırmaaynı doğrulamaAnahtar ve doğrulama algoritması belirtir emin olun. AutoGenerate bir kümede kullanılamaz. Açıklama: Geçerli web isteğinin yürütülmesi sırasında işlenmemiş bir özel durum oluştu. Hata ve kodda nereden kaynaklandığı hakkında daha fazla bilgi için lütfen yığın izini gözden geçirin. Özel Durum Ayrıntıları: System.Web.HttpException: viewstate MAC doğrulama başarısız oldu. Bu uygulama bir Web Farm veya küme tarafından barındırılan ise, <machineKey> yapılandırmaaynı doğrulamaAnahtar ve doğrulama algoritması belirtir emin olun. AutoGenerate bir kümede kullanılamaz. Kaynak Hatası: [İlgili kaynak satırı yok] Kaynak Dosya: ... Hat: 0 Yığın İzleme: [ViewStateException: Geçersiz görünüm durumu. İstemci IP: ::1 Bağlantı noktası: 40653 Gönderen: http://localhost:40643/MyPage.aspx Yol: /MyPage.aspx Kullanıcı Temsilcisi: Mozilla/5.0 (uyumlu; MSIE 10.0; Windows NT 6.2; VAY CANI64; Trident/6.0) Görünüm Durumu: ...] [HttpException (0x80004005): Viewstate MAC doğrulama başarısız oldu. Bu uygulama bir Web Farm veya küme tarafından barındırılan ise, <machineKey> yapılandırmaaynı doğrulamaAnahtar ve doğrulama algoritması belirtir emin olun. AutoGenerate bir kümede kullanılamaz. Daha fazla bilgi için http://go.microsoft.com/fwlink/?LinkID=314055 bakın.] System.Web.UI.ViewStateException.ThrowError(Exception iç, String persistedState, String errorPageMessage, Boolean macValidationError) +190 System.Web.UI.ViewStateException.ThrowMacValidationError(Özel Durum iç, String persistedState) +46 System.Web.UI.ObjectStateFormatter.Deserialize(String inputString, Amaç amacı) +861 System.Web.UI.ObjectStateFormatter.System.Web.UI.IStateFormatter2.Deserialize(String serializedState, Amaç amacı) +51 System.Web.UI.Util.DeserializeWithAssert(IStateFormatter2 formatter, String serializedState, Amaç amacı) +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) içinde ...:0 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +1300 System.Web.HttpApplication.ExecuteStep(IExecutionStep adım, Boolean& tamamlanmışSynchronously) +140

Neden 1: Web uygulaması bir çiftlikte çalışıyor (çok sunuculu ortam)

ASP.NET otomatik olarak her uygulama için bir şifreleme anahtarı oluşturur ve anahtarı HKCU kayıt kovanında saklar. Uygulamanın yapılandırmasında açık <machineKey> öğesi yoksa bu otomatik oluşturulan anahtar kullanılır. Ancak, otomatik olarak oluşturulan bu anahtar anahtarı oluşturan bilgisayariçin yerel olduğundan, bu senaryo bir çiftlikte çalışan uygulamalar için bir soruna neden olur. Çiftlikteki her sunucu kendi yerel anahtarını oluşturur ve çiftlikteki sunucuların hiçbiri hangi anahtarın kullanılacağı konusunda anlaşamaz. Sonuç olarak, bir sunucu farklı bir sunucunun tükettiği bir __VIEWSTATE yükü oluşturursa, tüketici bir MAC doğrulama hatasıyla karşılaşır.

Çözünürlük 1a: Açık bir <machineKey> öğesi oluşturma Uygulamanın Web.config dosyasına açık bir <machineKey> öğesi ekleyerek geliştirici, ASP.NET otomatik oluşturulan şifreleme anahtarını kullanmamalarını söyler. <machineKey> öğesi nin nasıl üretilene ilişkin talimatlar için Ek A'ya bakın. Bu öğe Web.config dosyasına eklendikten sonra, uygulamayı çiftlikteki her sunucuya yeniden dağıtın. Not Microsoft Azure web siteleri gibi bazı web barındırma hizmetleri, her uygulamanın otomatik olarak oluşturulan anahtarını arka uç sunucularında eşitlemek için adımlar atar. Bu, açık bir <machineKey> öğesi belirtmemiş uygulamaların, uygulama bir çiftlikte çalışıyor olsa bile bu ortamlarda çalışmaya devam etmesini sağlar. Uygulamanız bir üçüncü taraf barındırma hizmetinde çalışıyorsa, bu durumun sizin için geçerli olup olmadığını belirlemek için lütfen barındırma sağlayıcınıza başvurun.
Çözünürlük 1b: Yük dengeleyicisinde afiyeti etkinleştirme Siteleriniz bir yük dengeleyicisinin arkasında çalışıyorsa, sunucu yakınlığının sorunu geçici olarak çözmesini etkinleştirebilirsiniz. Bu, belirli bir istemcinin yük dengeleyicisinin arkasındaki tek bir fiziksel sunucuyla etkileşimkurmasını sağlar, böylece tüm şifreleme yükleri aynı sunucu tarafından hem oluşturulur hem de tüketilir. Bu soruna uzun vadeli bir çözüm olarak kabul edilmemelidir. Sunucu yakınlığı etkinleştirildiğinde bile, yük dengeleyicilerinin afiyetine sahip olduğu özgün sunucu çevrimdışı olursa, çoğu yük dengeleyicisi istemciyi farklı bir fiziksel sunucuya yönlendirir. Bu, yeni sunucunun istemcinin şu anda sahip olduğu şifreleme yüklerini (__VIEWSTATE gibi, kimlik doğrulama biletleri, MVC'ler anti-sahte belirteçleri ve diğer hizmetler gibi) reddetmesine neden olur. Açık bir <machineKey> öğesi kullanmak ve uygulamayı yeniden dağıtmak sunucu yakınlığını etkinleştirmek yerine tercih edilmelidir.

Neden 2: Alt işlem IIS 7.0 uygulama havuzu kimliğini kullanır

Internet Information Services (IIS) 7.0 (Windows Vista, Windows Server 2008) uygulama havuzu kimliğitanıttı, uygulamaları çalıştıran sunucular için artan güvenlik sağlamaya yardımcı olan yeni bir yalıtım mekanizması ASP.NET. Ancak, uygulama havuzu kimliği altında çalışan sitelerin HKCU kayıt defterine erişimi yoktur. ASP.NET otomatik olarak oluşturulan <machineKey> tuşlarını burada saklar. Sonuç olarak, uygulama havuzu sıfırlandığında otomatik olarak oluşturulan anahtarı ASP.NET süretir. Bu nedenle, w3wp.exe sıfırlanır her zaman, yeni bir geçici anahtar oluşturulur. Not Bu, IIS 7.5 (Windows 7, Windows Server 2008 R2) ve sonraki sürümlerde bir sorun değildir. IIS'nin bu sürümlerinde, ASP.NET otomatik olarak oluşturulan anahtarlarını uygulama havuzu sıfırlamalarından kurtulan farklı bir konumda sürdürebilir.

Çözünürlük 2a: aspnet_regiis yardımcı programını kullanın ASP.NET yüklemeleri bir yardımcı program, aspnet_regiis.exeiçerir. Bu yardımcı program, yönetilen bir uygulamayı çalıştırmak için gereken yapılandırmaları gerçekleştirmek için IIS ile ASP.NET arabirimine olanak tanır. Bu yapılandırmalardan biri, otomatik olarak oluşturulan makine anahtarlarının kalıcılığını etkinleştirmek için kayıt defteri kovanında gerekli anahtarları oluşturur. Öncelikle, sitenizin hangi uygulama havuzunı kullandığını belirlemeniz gerekir. Bu, IIS ile birlikte verilen inetmgr yardımcı programı kullanılarak belirlenebilir. Soldaki ağaç görünümünde sitenizi seçin, Websit e'yi sağtıklatın ve ardından Gelişmiş Ayarlar'ıtıklatın. Görünen iletişim kutusu uygulama havuzu adını gösterir. ASP.NET 4.0 uygulama havuzu için uygun kayıt defteri anahtarlarını iskelek için aşağıdaki adımları izleyin:
1. Bir yönetim komut istemi açın.
2. Uygulama havuzunuzun 32 bit veya 64 bit olup olmadığına bağlı olarak uygun dizini bulun:
  - 32 bit uygulama havuzu: cd /d %windir%\Microsoft.NET\Framework\v4.0.30319
  - 64 bit uygulama havuzu: cd /d %windir%\Microsoft.NET\Framework64\v4.0.30319
3. Dizine taşıyın, aşağıdaki komutu yazın ve enter tuşuna basın:
  
  aspnet_regiis -ga "IIS APPPOOL\app-pool-name"
Uygulama havuzu 2,0 veya 3,5 uygulama havuzuASP.NET ise aşağıdaki adımları izleyin:
1. Bir yönetim komut istemi açın.
2. Uygulama havuzunuzun 32 bit veya 64 bit olup olmadığına bağlı olarak uygun dizini bulun:
  - 32 bit uygulama havuzu: cd /d %windir%\Microsoft.NET\Framework\v2.0.50727
  - 64 bit uygulama havuzu: cd /d %windir%\Microsoft.NET\Framework64\v2.0.50727
3. Dizine taşıyın, aşağıdaki komutu yazın ve enter tuşuna basın:
  
  aspnet_regiis -ga "IIS APPPOOL\app-pool-name"
Örneğin, uygulama havuzunuz Benim Uygulama Havuzum (önceki resimde olduğu gibi) adlandırılmışsa, aşağıdaki komutu çalıştırın:

aspnet_regiis -ga "IIS APPPOOL\Benim Uygulama Havuzu" Not Sistem hizmetleri APPHOSTSVC ve WAS, IIS APPPOOL\* adlarını uygun şekilde çözmek için aspnet_regiis yardımcı programı için çalışıyor olabilir.
Çözünürlük 2b: Açık bir <machineKey> öğesi oluşturma Uygulamanın Web.config dosyasına açık bir <machineKey> öğesi ekleyerek geliştirici, ASP.NET otomatik oluşturulan şifreleme anahtarını kullanmamalarını söyler. <machineKey> öğesi nin nasıl üretilene ilişkin talimatlar için Ek A'ya bakın.

Neden 3: Uygulama havuzu LoadUserProfile=false kullanılarak yapılandırılır

Uygulama havuzu özel bir kimlikle çalışıyorsa, IIS kimlik için kullanıcı profilini yüklemiş olmayabilir. Bu otomatik oluşturulan <machineKey>devam ASP.NET için HKCU kayıt kullanılamaz hale yan etkisi vardır. Bu nedenle, uygulama her yeniden başlatılında yeni bir otomatik oluşturulan anahtar oluşturulur. Daha fazla bilgi için Microsoft web sitesindeki Kullanıcı Profili bölümüne bakın.

Çözünürlük 3a: aspnet_regiis yardımcı programını kullanın Bunun için talimatlar Çözünürlük 2aaynıdır. Daha fazla bilgi için bu bölüme bakın.
Çözünürlük 3b: Açık <machineKey> kullanın Uygulamanın Web.config dosyasına açık bir <machineKey> öğesi ekleyerek geliştirici, ASP.NET otomatik oluşturulan şifreleme anahtarını kullanmamalarını söyler. <machineKey> öğesi nin nasıl üretilene ilişkin talimatlar için Ek A'ya bakın.
Çözünürlük 3c: Gerekli HKCU kayıt anahtarlarının el ile sağlanması Aspnet_regiis yardımcı programını çalıştıramıyorsanız, HKCU'da uygun kayıt defteri anahtarlarını sağlamak için bir Windows PowerShell komut dosyası kullanabilirsiniz. Daha fazla bilgi için Ek B'ye bakın.
Çözünürlük 3d: Bu uygulama havuzu için LoadUserProfile=true ayarlayın Kullanıcı profilinin bu uygulama havuzunun içine yüklenmeside de etkinleştirebilirsiniz. Bu, HKCU kayıt defteri kovanı, geçici klasör ve diğer kullanıcıya özgü depolama konumları uygulama için kullanılabilir hale getirir. Ancak, bu alt işlem için disk veya bellek kullanımı nın artmasına neden olabilir. Bu ayarı etkinleştirme hakkında daha fazla bilgi için öğeye bakın.

Neden 4: Page.ViewStateUserKey özelliği nin değeri yanlışdır

Yazılım geliştiricileri__VIEWSTATE alanına site ler arası istek sahteciliği koruması eklemek için Page.ViewStateUserKey özelliğini kullanmaya karar verebilir. Page.ViewStateUserKey özelliğini kullanıyorsanız, genellikle geçerli kullanıcının kullanıcı adı veya kullanıcının oturum tanımlayıcısı gibi bir değerolarak ayarlanır. Microsoft Visual Studio 2012 ve sonraki sürümlerde WebForms uygulamaları için proje şablonları bu özelliği kullanan örnekler içerir. Daha fazla bilgi için Microsoft Geliştirici Ağı (MSDN) web sitesindeki Page.ViewStateUserKey Özelliği konusuna bakın. ViewStateUserKey özelliği belirtilirse, değeri nesil zamanında __VIEWSTATE'e yakar. __VIEWSTATE alanı tüketildiğinde, sunucu geçerli Sayfanın ViewStateUserKey özelliğini denetler ve __VIEWSTATE alanını oluşturmak için kullanılan değerle karşılaşır. Değerler eşleşmiyorsa, istek kötü amaçlı olarak reddedilir. ViewStateUserKey ile ilgili bir hata örneği tarayıcıda açık iki sekmeleri olan bir istemci olacaktır. İstemci Kullanıcı A olarak oturum açtı ve ilk sekmede, ViewStateUserKey özelliği "Kullanıcı A" bulunan bir __VIEWSTATE ile bir Sayfa işlenir. İkinci sekmede, istemci oturumu açar ve kullanıcı B olarak tekrar oturum açar. İstemci ilk sekmeye geri döner ve formu gönderir. ViewStateUserKey özelliği "Kullanıcı B" içerebilir (çünkü istemcinin kimlik doğrulama çerezi bunu söyler). Ancak, istemcinin gönderdiği __VIEWSTATE alanı "Kullanıcı A" içerir. Bu uyuşmazlık hataya neden olur.

Çözünürlük 4a: ViewStateUserKey'in doğru ayarlı olduğunu doğrulayın Uygulamanız ViewStateUserKey özelliğini kullanıyorsa, hem görünüm durumu oluşturulduğunda hem de tüketildiğinde özelliğin değerinin aynı olduğunu doğrulayın. Geçerli oturum açmış kullanıcının kullanıcı adını kullanıyorsanız, kullanıcının hala oturum açtığından ve kullanıcının kimliğinin posta geri gönderme sırasında değişmediğinden emin olun. Geçerli kullanıcının oturum tanımlayıcısını kullanıyorsanız, oturumun zaman dolmadığından emin olun. Bir çiftlik ortamında çalışıyorsanız, <machineKey> elemanlarının eşleştirdiğinden emin olun. Bu öğelerin nasıl üretilene ilişkin talimatlar için Ek A'ya bakın.

Ek A: Bir <machineKey> eleman nasıl üretilir?

Güvenlik uyarısı Bir düğmeyi tıklatarak sizin için bir <machineKey> öğesi oluşturacak birçok web sitesi vardır. Bu sitelerden birinden elde ettiğiniz <machineKey> öğesini asla kullanmayın. Bu anahtarların güvenli bir şekilde oluşturulup oluşturulmadığını veya gizli bir veritabanına kaydedilip kaydedilmediklerini bilmek mümkün değildir. Yalnızca kendi oluşturduğunuz <machineKey> yapılandırma öğelerini kullanmalısınız.

Bir <machineKey> öğesi kendiniz oluşturmak için aşağıdaki Windows PowerShell komut dosyasını kullanabilirsiniz:

# 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)
  }
}

ASP.NET 4.0 uygulamaları için, bir <machineKey> öğesi oluşturmak için parametreler olmadan Generate-MachineKey'i aşağıdaki gibi arayabilirsiniz:

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

2.0 ve 3.5 uygulamaları ASP.NET HMACSHA256'yı desteklemez. Bunun yerine, uyumlu bir <machineKey> öğesi oluşturmak için SHA1'i aşağıdaki gibi belirtebilirsiniz:

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

Bir <machineKey> öğesine sahip olur olmaz, web.config dosyasına koyabilirsiniz. <machineKey> öğesi yalnızca uygulamanızın kökündeki Web.config dosyasında geçerlidir ve alt klasör düzeyinde geçerli değildir.

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

Desteklenen algoritmaların tam listesi için Windows PowerShell komut isteminden Generate-MachineKey yardımını çalıştırın.

Ek B: Otomatik olarak oluşturulan anahtarları sürdürmek için kayıt defterisağlama

Varsayılan olarak, ASP.NETs otomatik olarak oluşturulan anahtarları HKCU kayıt defterinde kalıcı olduğundan, kullanıcı profili IIS alt işlemine yüklenmediyse ve uygulama havuzu geri dönüşümleri varsa bu anahtarlar kaybolabilir. Bu senaryo, standart Windows kullanıcı hesapları olarak uygulama havuzları çalıştıran paylaşılan barındırma sağlayıcıları etkileyebilir. Bu durumu aşmak için ASP.NET, HKCU kayıt defteri yerine HKLM kayıt defterinde otomatik olarak oluşturulan anahtarların kalıcı olarak oluşturulmasını sağlar. Bu genellikle aspnet_regiis yardımcı programı kullanılarak gerçekleştirilir (bkz. "Çözünürlük 2a: Aspnet_regiis yardımcı programını kullan" bölümündeki talimatlara bakınız). Ancak, bu yardımcı programı çalıştırmak istemeyen yöneticiler için aşağıdaki Windows PowerShell komut dosyası kullanılabilir:

# 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)
    }
  }
}

Aşağıdaki örnek, kullanıcı olarak çalışan bir uygulama havuzu için uygun HKLM kayıt defteri girişlerinin nasıl sağlandığını gösterir example@contoso.com (bu Windows kullanıcı hesabının UPN'sidir). Bu uygulama havuzu CLR v2.0 (ASP.NET 2.0 veya 3.5) çalıştıran bir 32 bit uygulama havuzudur.

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

Uygulama havuzu bunun yerine CLR v4.0 (ASP.NET 4.0 veya 4.5 çalışan bir 64-bit uygulama havuzu ise, komutu aşağıdaki gibidir:

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

Otomatik olarak oluşturulan anahtarlar HKLM'de depolansa da, şifreleme materyalinin diğer kullanıcı hesapları tarafından okunamaması için her kullanıcı hesabının gizli şifreleme materyalini tutan kayıt defteri alt anahtarı bir erişim denetim listesine (ACL) eklenir.

Ek C: Yapılandırma dosyalarında <machineKey> öğesinin şifrelemesi

Sunucu yöneticileri ,<machineKey> anahtar malzeme gibi son derece hassas bilgilerin yapılandırma dosyalarında düz metin biçiminde olmasını istemeyebilir. Bu durumda, yöneticiler "korumalı yapılandırma" olarak bilinen .NET Framework özelliğinden yararlanmaya karar verebilirler. Bu özellik, .config dosyalarının belirli bölümlerini şifrelemenizi sağlar. Bu yapılandırma dosyalarının içeriği açıklanırsa, bu bölümlerin içeriği gizli kalır. MSDN web sitesinde korumalı yapılandırmaya kısa bir genel bakış bulabilirsiniz. Ayrıca Web.config dosyasının <connectionStrings> ve <machineKey> öğelerinin nasıl korunup korunabildiğini anlatan bir öğretici içerir.