Menyelesaikan tampilan status pesan otentikasi kode (MAC) galat

Apa yang dimaksud dengan tampilan negara?

Lihat status adalah informasi yang tersandung bulat antara halaman WebForms (. aspx) di aplikasi ASP.NET. HTML markup kolom _ _ VIEWSTATE menyerupai berikut ini:

< input type = "Hidden" name = "_ _ VIEWSTATE" id = "_ _ VIEWSTATE" value = "..."/>Salah satu contoh dari item yang mungkin disimpan di bidang _ _ VIEWSTATE adalah teks tombol kontrol. Jika pengguna mengklik tombol, penanganan kejadian Button_Click akan dapat mengekstrak teks tombol dari bidang tampilan status. Lihat topik ASP.net Lihat status tampilan di situs web Microsoft Developer Network (MSDN) untuk Ikhtisar jauh lebih rinci dari status tampilan ASP.net. Karena kolom _ _ VIEWSTATE berisi informasi penting yang digunakan untuk merekonstruksi halaman postback, pastikan bahwa penyerang tidak dapat mengutak-atik kolom ini. Jika penyerang mengirimkan muatan _ _ VIEWSTATE berbahaya, penyerang dapat berpotensi mengelabui aplikasi ke melakukan tindakan yang dinyatakan tidak akan dilakukan. Untuk mencegah jenis perusakan serangan, kolom _ _ VIEWSTATE dilindungi oleh kode otentikasi pesan (MAC). ASP.NET memvalidasi MAC yang dikirim bersama-sama dengan beban _ _ VIEWSTATE saat postback terjadi. Kunci yang digunakan untuk menghitung MAC ditentukan dalam aplikasi elemen dalam web. config file. Karena penyerang tidak menebak konten elemen < machineKey >, penyerang tidak dapat memberikan MAC berlaku jika penyerang mencoba mengutak-atik payload _ VIEWSTATE. ASP.NET akan mendeteksi bahwa MAC yang valid belum disediakan, dan ASP.NET akan menolak permintaan berbahaya.

Apa yang menyebabkan kesalahan validasi MAC?

Galat validasi MAC akan mirip contoh berikut:

Galat server di aplikasi '/'. Validasi viewstate MAC gagal. Jika aplikasi ini di-hosting oleh Kampung web atau kluster, pastikan bahwa < machineKey > konfigurasi menentukan algoritma validationKey dan validasi yang sama. AutoGenerate tidak dapat digunakan di kluster. Deskripsi: tidak tertangani pengecualian terjadi selama pelaksanaan permintaan web saat ini. Silakan Tinjau jejak tumpukan untuk informasi lebih lanjut tentang galat dan mana berasal dari kode. Rincian pengecualian: System. web. HttpException: validasi viewstate MAC gagal. Jika aplikasi ini di-hosting oleh Web Farm atau cluster, pastikan bahwa < machineKey > konfigurasi menentukan algoritma validationKey dan validasi yang sama. AutoGenerate tidak dapat digunakan di kluster. Galat sumber: [tidak ada baris sumber yang relevan] Sumber file:... Baris: 0 Stack Trace: [ViewStateException: viewstate tidak valid. Klien IP::: 1 Pelabuhan: 40653 Referer: http://localhost:40643/MyPage.aspx Jalur:/MyPage.aspx User-Agent: Mozilla/5.0 (kompatibel; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) ViewState:...] [HttpException (0x80004005): validasi viewstate MAC gagal. Jika aplikasi ini di-hosting oleh Web Farm atau cluster, pastikan bahwa < machineKey > konfigurasi menentukan algoritma validationKey dan validasi yang sama. AutoGenerate tidak dapat digunakan di kluster. Lihat http://go.microsoft.com/fwlink/?LinkID=314055 untuk informasi lebih lanjut.] System. web. UI. ViewStateException. ThrowError (pengecualian dalam string persistedState, string errorPageMessage, Boolean macValidationError) + 190 System. web. UI. ViewStateException. ThrowMacValidationError (pengecualian dalam, string persistedState) + 46 System. web. UI. ObjectStateFormatter. Deserialize (string inputString, tujuan) + 861 System. web. UI. ObjectStateFormatter. System. web. UI. IStateFormatter2. Deserialize (string serializedState, tujuan) + 51 System. web. UI. util. Deserializewithmenegaskan (IStateFormatter2 formatter, string serializedState, tujuan tujuan) + 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. Processrequestwithnomenegaskan (HttpContext konteks) + 48 System. web. UI. Page. ProcessRequest (HttpContext konteks) + 234 ASP. mypage_aspx. ProcessRequest (konteks HttpContext) di...: 0 System. web. CallHandlerExecutionStep. System. web. HttpApplication. IExecutionStep. Execute () + 1300 System. web. HttpApplication. ExecuteStep (IExecutionStep langkah, Boolean & completedSynchronously) + 140

Penyebab 1: aplikasi web berjalan di daerah (lingkungan multi server)

ASP.NET secara otomatis menghasilkan kunci kriptografi untuk setiap aplikasi dan menyimpan kunci di sarang registri HKCU. Kunci ini dihasilkan otomatis digunakan jika tidak ada eksplisit < machineKey > elemen dalam konfigurasi aplikasi. Namun, karena kunci ini dihasilkan otomatis lokal ke komputer yang dibuat kunci, skenario ini menyebabkan masalah untuk aplikasi yang berjalan di daerah. Setiap server di daerah akan menghasilkan kunci lokal sendiri, dan tidak ada server di Kampung akan setuju pada kunci yang digunakan. Hasilnya adalah bahwa, jika satu server menghasilkan beban _ _ VIEWSTATE yang mengkonsumsi server yang berbeda, konsumen akan mengalami kegagalan validasi MAC.

Resolusi 1A: membuat elemen eksplisit < machineKey > Dengan menambahkan elemen < machineKey > eksplisit ke berkas web. config aplikasi, pengembang memberitahu ASP.NET untuk tidak menggunakan kunci kriptografi yang dihasilkan otomatis. Lihat lampiran a untuk petunjuk tentang cara membuat elemen < machineKey >. Setelah elemen ini ditambahkan ke berkas web. config, redeploy aplikasi untuk setiap server di Kampung. Catatan Beberapa layanan web hosting, seperti situs web Microsoft Azure, ambil langkah untuk mensinkronisasi kunci buatan otomatis setiap aplikasi di server back-end mereka. Hal ini memungkinkan aplikasi yang belum ditetapkan eksplisit < machineKey > elemen untuk terus bekerja di lingkungan ini, bahkan jika aplikasi berjalan di daerah. Jika aplikasi Anda berjalan pada layanan hosting pihak ketiga, hubungi penyedia hosting Anda untuk menentukan apakah situasi ini berlaku untuk Anda.
Resolusi 1B: mengaktifkan afinitas di penyeimbang beban Jika situs Anda beroperasi di belakang penyeimbang beban, Anda dapat mengaktifkan afinitas server untuk sementara bekerja di sekitar masalah. Ini membantu memastikan bahwa klien tertentu hanya berinteraksi dengan satu server fisik di belakang penyeimbang beban sehingga semua muatan kriptografis akan dihasilkan oleh dan dikonsumsi oleh server yang sama. Ini tidak boleh dianggap sebagai solusi jangka panjang untuk masalah. Bahkan ketika afinitas server diaktifkan, sebagian besar penyeimbang beban akan mengarahkan klien ke server fisik yang berbeda jika server asli yang penyeimbang beban affinitized pergi offline. Hal ini menyebabkan server baru untuk menolak kriptografis muatan (seperti _ _ VIEWSTATE, bentuk otentikasi Tiket, MVCs anti-pemalsuan bukti, dan layanan lainnya) yang klien saat ini. Menggunakan elemen eksplisit < machineKey > dan redeploy aplikasi harus lebih disukai melalui mengaktifkan afinitas server.

Penyebab 2: proses pengerjaan menggunakan identitas Pool aplikasi IIS 7,0

Layanan informasi internet (IIS) 7,0 (Windows Vista, Windows Server 2008) memperkenalkan identitas Pool aplikasi, mekanisme isolasi baru yang membantu memberikan peningkatan keamanan untuk server yang menjalankan aplikasi ASP.net. Namun, situs yang berjalan di bawah identitas Pool aplikasi tidak memiliki akses ke registri HKCU. Di sinilah ASP.NET runtime menyimpan kunci yang dihasilkan otomatis < machineKey >. Hasilnya adalah bahwa ASP.NET tidak dapat bertahan kunci yang dihasilkan otomatis ketika Pool aplikasi reset. Oleh karena itu, setiap kali w3wp. exe reset, kunci sementara yang baru akan dibuat. Catatan Ini bukan masalah di IIS 7,5 (Windows 7, Windows Server 2008 R2) dan versi yang lebih baru. Pada versi IIS, ASP.NET dapat bertahan yang dihasilkan otomatis kunci di lokasi yang berbeda yang bertahan ulang Pool aplikasi.

Resolusi 2A: menggunakan utilitas aspnet_regiis ASP.NET instalasi berisi utilitas, aspnet_regiis. exe. Utilitas ini memungkinkan ASP.NET antarmuka dengan IIS untuk melakukan konfigurasi yang diperlukan untuk menjalankan aplikasi yang dikelola. Salah satu konfigurasi ini membuat kunci yang diperlukan dalam kumpulan registri untuk mengaktifkan persistensi kunci mesin yang dihasilkan secara otomatis. Pertama, Anda harus menentukan Pool aplikasi mana yang menggunakan situs Anda. Ini dapat ditentukan dengan menggunakan utilitas inetmgr yang disertakan dengan IIS. Pilih situs Anda dalam tampilan hierarki di sebelah kiri, klik kanan Kelola website, dan kemudian klik Pengaturan lanjut. Kotak dialog yang muncul akan menampilkan nama Pool aplikasi. Untuk perancah kunci registri yang sesuai untuk Pool aplikasi ASP.NET 4,0, ikuti langkah berikut:
1. Buka wantian perintah administratif.
2. Temukan direktori yang sesuai, tergantung pada apakah Pool aplikasi Anda adalah 32-bit atau 64-bit:
  - Pool aplikasi 32-bit: CD/d%windir%\Microsoft.NET\Framework\v4.0.30319
  - Pool aplikasi 64-bit: CD/d%windir%\Microsoft.NET\Framework64\v4.0.30319
3. Pindah ke direktori, ketik perintah berikut, dan kemudian tekan ENTER:
  
  aspnet_regiis-ga "IIS APPPOOL\app-pool-name"
Jika Pool aplikasi ASP.NET 2,0 atau 3,5 Pool aplikasi, ikuti langkah berikut:
1. Buka wantian perintah administratif.
2. Temukan direktori yang sesuai, tergantung pada apakah Pool aplikasi Anda adalah 32-bit atau 64-bit:
  - Pool aplikasi 32-bit: CD/d%windir%\Microsoft.NET\Framework\v2.0.50727
  - Pool aplikasi 64-bit: CD/d%windir%\Microsoft.NET\Framework64\v2.0.50727
3. Pindah ke direktori, ketik perintah berikut, dan kemudian tekan ENTER:
  
  aspnet_regiis-ga "IIS APPPOOL\app-pool-name"
Sebagai contoh, jika Pool aplikasi bernama saya Pool aplikasi (seperti gambar sebelumnya), jalankan perintah berikut ini:

aspnet_regiis-ga "IIS APPPOOL\My App Pool" Catatan Layanan sistem APPHOSTSVC dan WAS mungkin harus berjalan untuk utilitas aspnet_regiis untuk menyelesaikan IIS APPPOOL \ * nama dengan benar.
Resolusi 2B: membuat elemen eksplisit < machineKey > Dengan menambahkan elemen < machineKey > eksplisit ke berkas web. config aplikasi, pengembang memberitahu ASP.NET untuk tidak menggunakan kunci kriptografi yang dihasilkan otomatis. Lihat lampiran a untuk petunjuk tentang cara membuat elemen < machineKey >.

Penyebab 3: Pool aplikasi dikonfigurasi dengan menggunakan LoadUserProfile = false

Jika Pool aplikasi berjalan dengan identitas kustom, IIS mungkin tidak memuat profil pengguna untuk identitas. Ini memiliki efek samping membuat registri HKCU tidak tersedia untuk ASP.NET untuk bertahan yang dihasilkan otomatis < machineKey >. Oleh karena itu, baru dihasilkan otomatis kunci akan dibuat setiap kali aplikasi dimulai ulang. Lihat bagian profil pengguna di situs web Microsoft untuk informasi lebih lanjut.

Resolusi 3a: menggunakan utilitas aspnet_regiis Petunjuk untuk ini adalah sama dengan resolusi 2A. Lihat bagian itu untuk informasi lebih lanjut.
Resolusi 3B: menggunakan < machineKey eksplisit > Dengan menambahkan elemen < machineKey > eksplisit ke berkas web. config aplikasi, pengembang memberitahu ASP.NET untuk tidak menggunakan kunci kriptografi yang dihasilkan otomatis. Lihat lampiran a untuk petunjuk tentang cara membuat elemen < machineKey >.
Resolusi 3c: menetapkan kunci registri HKCU diperlukan secara manual Jika Anda tidak dapat menjalankan utilitas aspnet_regiis, Anda dapat menggunakan skrip Windows PowerShell untuk menetapkan kunci registri yang sesuai di HKCU. Lihat Lampiran B untuk informasi lebih lanjut.
Resolusi 3D: set LoadUserProfile = true untuk Pool aplikasi ini Anda juga dapat mengaktifkan memuat profil pengguna di dalam Pool aplikasi ini. Hal ini membuat sarang registri HKCU, folder sementara, dan lokasi penyimpanan khusus pengguna lainnya yang tersedia untuk aplikasi. Namun, ini dapat menyebabkan peningkatan penggunaan disk atau memori untuk proses pengerjaan. Lihat elemen untuk informasi selengkapnya tentang cara mengaktifkan pengaturan ini.

Penyebab 4: properti Page. ViewStateUserKey memiliki nilai yang salah

Pengembang perangkat lunak dapat memutuskan untuk menggunakan properti Page. ViewStateUserKey untuk menambahkan lintas-situs permintaan pemalsuan perlindungan kolom _ _ viewstate. Jika Anda menggunakan properti Page. ViewStateUserKey , biasanya ditetapkan ke nilai seperti nama pengguna saat ini atau pengidentifikasi sesi pengguna. Template proyek untuk aplikasi WebForms di Microsoft Visual Studio 2012 dan versi yang lebih baru berisi contoh yang menggunakan properti ini. Lihat topik Page. ViewStateUserKey properti di situs web Microsoft Developer Network (MSDN) untuk informasi lebih lanjut. Jika properti Viewstateuserkey ditetapkan, nilainya dibakar ke _ _ viewstate pada waktu pembuatan. Ketika kolom _ _ VIEWSTATE dikonsumsi, server memeriksa properti Viewstateuserkey halaman saat ini dan memvalidasi terhadap nilai yang digunakan untuk membuat kolom _ _ viewstate. Jika nilai tidak cocok, permintaan ditolak sebagai berpotensi berbahaya. Contoh dari kegagalan terkait ViewStateUserKey akan klien yang memiliki dua tab terbuka di browser. Klien masuk sebagai pengguna A, dan di tab pertama, halaman yang disajikan dengan _ _ VIEWSTATE properti Viewstateuserkey yang berisi "pengguna a." Di tab kedua, klien log keluar dan kemudian log kembali sebagai pengguna B. Klien kembali ke tab pertama dan mengirimkan formulir. Properti Viewstateuserkey mungkin berisi "pengguna B" (karena itu adalah apa yang cookie otentikasi klien mengatakan). Namun, kolom _ _ VIEWSTATE yang klien dikirim berisi "pengguna A." Ketidakcocokan ini menyebabkan kegagalan.

Resolusi 4A: verifikasi bahwa ViewStateUserKey diatur dengan benar Jika aplikasi Anda menggunakan properti Viewstateuserkey , verifikasi bahwa nilai properti yang sama saat melihat status yang dihasilkan dan ketika dikonsumsi. Jika Anda menggunakan pengguna login saat ini masuk, pastikan bahwa pengguna masih login dan identitas pengguna tidak berubah pada saat postback. Jika Anda menggunakan pengidentifikasi sesi pengguna saat ini, pastikan bahwa sesi belum habis. Jika Anda menjalankan di lingkungan Farm, pastikan bahwa < machineKey > elemen cocok. Lihat Lampiran A untuk petunjuk tentang cara membuat elemen ini.

Lampiran A: cara membuat elemen < machineKey >

Peringatan keamanan Ada banyak situs web yang akan menghasilkan elemen < machineKey > untuk Anda dengan mengklik tombol. Jangan gunakan elemen < machineKey > yang Anda peroleh dari salah satu situs ini. Tidak mungkin untuk mengetahui apakah kunci ini dibuat dengan aman atau jika mereka sedang direkam ke database rahasia. Anda hanya harus menggunakan < machineKey > elemen konfigurasi yang Anda buat sendiri.

Untuk membuat elemen < machineKey > sendiri, Anda dapat menggunakan skrip Windows PowerShell berikut ini:

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

Untuk aplikasi ASP.NET 4,0, Anda hanya dapat memanggil menghasilkan-machinekey tanpa parameter untuk menghasilkan elemen < machinekey > sebagai berikut:

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

ASP.NET 2,0 dan 3,5 aplikasi tidak mendukung HMACSHA256. Namun, Anda dapat menentukan SHA1 untuk menghasilkan elemen < machineKey > yang kompatibel sebagai berikut:

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

Segera setelah Anda memiliki elemen < machineKey >, Anda dapat memasukkannya ke dalam berkas web. config. Elemen < machineKey > hanya berlaku di berkas web. config di akar aplikasi dan tidak valid di tingkat subfolder.

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

Untuk daftar lengkap algoritma yang didukung, jalankan bantuan menghasilkan-MachineKey dari wantian Windows PowerShell.

Lampiran B: penyediaan registri untuk bertahan tombol dihasilkan otomatis

Secara default, karena ASP. NETs dihasilkan otomatis kunci disimpan di registri HKCU, kunci ini mungkin hilang jika profil pengguna tidak dimuat ke proses pengerjaan IIS dan kemudian Pool aplikasi mendaur ulang. Skenario ini dapat mempengaruhi penyedia shared hosting yang menjalankan kumpulan aplikasi sebagai akun pengguna Windows standar. Untuk mengatasi situasi ini, ASP.NET memungkinkan bertahan Auto-dihasilkan kunci dalam registri HKLM bukannya HKCU registri. Hal ini biasanya dilakukan dengan menggunakan utilitas aspnet_regiis (Lihat petunjuk pada "2A resolusi: menggunakan utilitas aspnet_regiis" bagian). Namun, untuk administrator yang tidak ingin menjalankan utilitas ini, skrip Windows PowerShell berikut dapat digunakan sebagai gantinya:

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

Contoh berikut menunjukkan cara menetapkan entri registri HKLM sesuai untuk Pool aplikasi yang berjalan sebagai pengguna, example@contoso.com (ini adalah UPN akun pengguna Windows). Pool aplikasi ini adalah Pool aplikasi 32-bit yang menjalankan CLR v 2.0 (ASP.NET 2,0 atau 3,5).

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

Jika Pool aplikasi bukan Pool aplikasi 64-bit yang menjalankan CLR v 4.0 (ASP.NET 4,0 atau 4,5), perintah adalah sebagai berikut:

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

Meskipun kunci otomatis yang dihasilkan disimpan di HKLM, subkunci registri yang memegang materi kriptografi rahasia setiap akun pengguna ditambahkan ke daftar kontrol akses (ACL) sehingga bahan kriptografik tidak dapat dibaca oleh akun pengguna lain.

Lampiran C: mengenkripsi elemen < machineKey > dalam berkas konfigurasi

Administrator server mungkin tidak ingin sangat sensitif informasi seperti bahan kunci < machineKey > bein bentuk plaintext dalam berkas konfigurasi. Jika demikian, administrator dapat memutuskan untuk mengambil keuntungan dari fitur .NET Framework yang dikenal sebagai "dilindungi konfigurasi." Fitur ini memungkinkan Anda mengenkripsi bagian tertentu dari berkas. config. Jika isi dari file konfigurasi ini pernah diungkapkan, isi Bagian ini akan tetap rahasia. Anda dapat menemukan ikhtisar singkat konfigurasi yang dilindungi pada MSDN website. Ini juga berisi tutorial tentang cara melindungi < connectionStrings > dan < machineKey > elemen berkas web. config.