Giải quyết xem trạng thái thông báo lỗi xác thực mã (MAC)

Xem trạng thái là gì?

Xem trạng thái là thông tin vòng vấp giữa WebForms (. aspx) trang trong ứng dụng ASP.NET. Đánh dấu HTML cho trường _ _ VIEWSTATE giống như sau:

< nhập nhập = "ẩn" tên = "_ số VIEWSTATE" ID = "_ _ VIEWSTATE" giá trị = "..."/>Một ví dụ về một mục có thể được lưu trữ trong trường _ _ VIEWSTATE là văn bản điều khiển nút. Nếu người dùng nhấp vào nút, trình xử lý sự kiện Button_Click sẽ có thể trích xuất văn bản của nút từ trường xem trạng thái. Xem chủ đề ASP.net xem trạng thái tổng quan trên trang web Microsoft Developer Network (MSDN) để biết tổng quan chi tiết hơn về trạng thái xem ASP.net. Vì trường _ _ VIEWSTATE chứa thông tin quan trọng được sử dụng để tái tạo lại trang trên postback, đảm bảo kẻ tấn công không thể giả mạo trường này. Nếu kẻ gửi một trọng tải nguy hiểm _ VIEWSTATE, kẻ tấn công có thể có khả năng lừa ứng dụng thực hiện một hành động mà nếu không sẽ không có thực hiện. Để ngăn chặn loại tấn công giả mạo này, trường _ _ VIEWSTATE được bảo vệ bằng mã xác thực thư (MAC). ASP.NET xác nhận MAC được gửi cùng với trọng tải _ VIEWSTATE khi một postback xảy ra. Khoá được sử dụng để tính toán MAC được chỉ định trong phần tử của ứng dụng trong tệp web. config. Vì kẻ tấn công không thể đoán nội dung của các yếu tố < machineKey >, kẻ tấn công không thể cung cấp một máy MAC hợp lệ nếu kẻ tấn công cố giả mạo với trọng tải _ VIEWSTATE. ASP.NET sẽ phát hiện một máy MAC hợp lệ chưa được cung cấp và ASP.NET sẽ từ chối yêu cầu độc hại.

Nguyên nhân gây ra lỗi soát hợp lệ MAC?

Lỗi soát hợp lệ MAC sẽ giống như ví dụ sau:

Lỗi máy chủ trong '/' ứng dụng. Xác thực của Viewstate MAC không thành công. Nếu ứng dụng này được lưu trữ bởi một nhóm trang web hoặc cụm, đảm bảo rằng cấu hình < machineKey > chỉ định cùng một thuật toán validationKey và xác nhận. AutoGenerate không được sử dụng trong cụm. Mô tả: Các ngoại lệ xảy ra trong quá trình thực hiện yêu cầu web hiện tại. Vui lòng đánh giá dấu vết xếp chồng để biết thêm thông tin về lỗi và nơi nó có nguồn gốc trong mã. Ngoại lệ chi tiết: System. web. HttpException: xác thực Viewstate MAC không thành công. Nếu ứng dụng này được lưu trữ bởi một trang trại web hoặc cụm, đảm bảo rằng cấu hình < machineKey > chỉ định cùng một thuật toán validationKey và xác nhận. AutoGenerate không được sử dụng trong cụm. Nguồn lỗi: [không có dòng nguồn liên quan] Tệp nguồn:... Đường dây: 0 Dấu vết xếp chồng: [ViewStateException: Viewstate không hợp lệ. IP khách hàng::: 1 Cổng: 40653 Referer: http://localhost:40643/MyPage.aspx Đường dẫn:/MyPage.aspx Tác nhân người dùng: Mozilla/5.0 (tương thích; MSIE 10,0; Windows NT 6,2; WOW64 Trident/6.0) ViewState:...] [HttpException (0x80004005): xác thực Viewstate MAC không thành công. Nếu ứng dụng này được lưu trữ bởi một trang trại web hoặc cụm, đảm bảo rằng cấu hình < machineKey > chỉ định cùng một thuật toán validationKey và xác nhận. AutoGenerate không được sử dụng trong cụm. Xem http://go.microsoft.com/fwlink/?LinkID=314055 để biết thêm thông tin.] System. web. UI. ViewStateException. ThrowError (ngoại lệ bên trong, Chuỗi persistedState, Chuỗi errorPageMessage, boolean macValidationError) + 190 System. web. UI. ViewStateException. ThrowMacValidationError (ngoại lệ bên trong, Chuỗi persistedState) + 46 System. web. UI. ObjectStateFormatter. Deserialize (chuỗi inputString, mục đích mục đích) + 861 System. web. UI. ObjectStateFormatter. System. web. UI. IStateFormatter2. Deserialize (chuỗi serializedState mục đích) + 51 System. web. UI. util. Deserializewithkhẳng định (IStateFormatter2 Formatter, Chuỗi serializedState mục đích) + 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. Processrequestwithnokhẳng định (bối cảnh HttpContext) + 48 System. web. UI. Page. ProcessRequest (bối cảnh HttpContext) + 234 ASP. mypage_aspx. ProcessRequest (HttpContext bối cảnh) trong...: 0 System. web. CallHandlerExecutionStep. System. web. HttpApplication. IExecutionStep. Execute () + 1300 System. web. HttpApplication. ExecuteStep (IExecutionStep bước, boolean & completedSynchronously) + 140

Nguyên nhân 1: ứng dụng web đang chạy trong một nhóm (môi trường đa máy chủ)

ASP.NET tự động tạo khoá mật mã cho mỗi ứng dụng và lưu trữ khoá trong Trung tâm đăng ký HKCU. Tự động tạo khoá này được sử dụng nếu không rõ ràng < machineKey > yếu tố cấu hình của ứng dụng. Tuy nhiên, vì khoá tạo tự động này là cục bộ với máy tính đã tạo khoá, tình huống này gây ra sự cố cho các ứng dụng chạy trong nhóm. Mỗi máy chủ trong nhóm sẽ tạo khóa địa phương riêng của mình, và không ai trong số các máy chủ trong trang trại sẽ đồng ý về chìa khóa để sử dụng. Kết quả là, nếu một máy chủ tạo ra một trọng tải _ _ VIEWSTATE tiêu thụ máy chủ khác nhau, người tiêu dùng sẽ gặp phải lỗi soát hợp lệ MAC.

Giải pháp 1A: tạo một yếu tố > < machineKey rõ ràng Bằng cách thêm một phần tử rõ ràng < machineKey > vào tệp web. config của ứng dụng, nhà phát triển cho ASP.NET không sử dụng khoá mật mã tự động tạo ra. Xem phụ lục a để biết hướng dẫn về cách tạo một yếu tố < machineKey >. Sau khi phần tử này được thêm vào tệp web. config, redeploy ứng dụng cho mỗi máy chủ trong nhóm. Lưu ý Một số dịch vụ lưu trữ web, chẳng hạn như các trang web Microsoft Azure, thực hiện các bước để đồng bộ hóa khóa tự động tạo của mỗi ứng dụng trên các máy chủ Back-end. Điều này cho phép các ứng dụng đã không chỉ định một yếu tố < machineKey > rõ ràng để tiếp tục làm việc trong các môi trường, ngay cả khi các ứng dụng đang chạy trong một nhóm. Nếu ứng dụng của bạn đang chạy trên một dịch vụ lưu trữ bên thứ ba, xin vui lòng liên hệ với nhà cung cấp lưu trữ của bạn để xác định xem trường hợp này áp dụng cho bạn.
Giải pháp 1B: cho phép mối quan hệ trong cân bằng tải Nếu các trang web của bạn hoạt động sau cân bằng tải, bạn có thể bật đồng dạng máy chủ để tạm thời khắc phục sự cố. Điều này giúp đảm bảo rằng bất kỳ khách hàng nào chỉ tương tác với một máy chủ vật lý phía sau cân bằng tải để tất cả mật mã hoá sẽ được tạo ra bởi và tiêu thụ bởi cùng một máy chủ. Điều này không nên được coi là một giải pháp dài hạn cho vấn đề. Ngay cả khi đồng dạng máy chủ được kích hoạt, hầu hết tải bằng sẽ chuyển hướng khách hàng đến một máy chủ vật lý khác nếu máy chủ gốc mà bằng tải được affinitized đi ngoại tuyến. Điều này khiến máy chủ mới từ chối mật mã hoá (chẳng hạn như _ VIEWSTATE, hình thức xác thực vé, MVCs chống giả mạo thẻ và các dịch vụ) mà khách hàng hiện có. Sử dụng một yếu tố < machineKey > rõ ràng và bố trí ứng dụng sẽ được ưa thích hơn cho phép đồng dạng máy chủ.

Nguyên nhân 2: quá trình riêng biệt sử dụng nhận dạng vùng ứng dụng IIS 7,0

Dịch vụ thông tin Internet (IIS) 7,0 (Windows Vista, Windows Server 2008) giới thiệu nhận dạng hồ sơ ứng dụng, cơ chế cô lập mới giúp cung cấp tăng bảo mật cho các máy chủ chạy ứng dụng ASP.net. Tuy nhiên, các trang web đang chạy trong danh tính hồ sơ ứng dụng không có quyền truy cập vào đăng ký HKCU. Đây là nơi ASP.NET Runtime lưu trữ tự động tạo ra < machineKey > phím. Kết quả là ASP.NET không thể tồn tại tự động tạo khoá khi ứng dụng vùng được đặt lại. Do đó, mỗi lần w3wp. exe được đặt lại, khoá tạm thời mới được tạo ra. Lưu ý Đây không phải là một vấn đề trong IIS 7,5 (Windows 7, Windows Server 2008 R2) và phiên bản mới hơn. Trên các phiên bản của IIS, ASP.NET có thể duy trì các phím tự động tạo ra trong một vị trí khác mà vẫn tồn tại nhóm ứng dụng Reset.

Độ phân giải 2A: sử dụng tiện ích aspnet_regiis ASP.NET cài đặt chứa một tiện ích, aspnet_regiis. exe. Tiện ích này cho phép ASP.NET giao diện với IIS để thực hiện các cấu hình cần thiết để chạy một ứng dụng quản lý. Một trong các cấu hình tạo khoá cần thiết trong Trung tâm đăng ký để cho phép sự bền bỉ của tự động tạo ra phím máy. Trước tiên, bạn phải xác định hồ bơi ứng dụng trang web của bạn đang sử dụng. Điều này có thể được xác định bằng cách sử dụng tiện ích inetmgr đi kèm với IIS. Chọn trang web của bạn trong xem cây ở bên trái, bấm chuột phải vào quản lý Website, và sau đó nhấp vào cài đặt nâng cao. Hộp thoại xuất hiện sẽ hiển thị tên hồ bơi ứng dụng. Để đài khoá đăng ký thích hợp cho một hồ ASP.NET 4,0 ứng dụng, hãy làm theo các bước sau:
1. Mở dấu nhắc lệnh quản trị.
2. Xác định vị trí thư mục phù hợp, tùy thuộc vào việc hồ bơi ứng dụng của bạn là 32-bit hoặc 64-bit:
  - 32-bit ứng dụng hồ bơi: CD/d%windir%\Microsoft.NET\Framework\v4.0.30319
  - 64-bit ứng dụng hồ bơi: CD/d%windir%\Microsoft.NET\Framework64\v4.0.30319
3. Di chuyển vào thư mục, gõ lệnh sau, và sau đó nhấn Enter:
  
  aspnet_regiis-ga "IIS APPPOOL\app-pool-name"
Nếu Hồ bơi ứng dụng là một ASP.NET 2,0 hoặc 3,5 ứng dụng vùng, hãy làm theo các bước sau:
1. Mở dấu nhắc lệnh quản trị.
2. Xác định vị trí thư mục thích hợp, tuỳ thuộc vào việc hồ bơi ứng dụng của bạn là 32-bit hoặc 64-bit:
  - 32-bit ứng dụng hồ bơi: CD/d%windir%\Microsoft.NET\Framework\v2.0.50727
  - 64-bit ứng dụng hồ bơi: CD/d%windir%\Microsoft.NET\Framework64\v2.0.50727
3. Di chuyển vào thư mục, gõ lệnh sau, và sau đó nhấn Enter:
  
  aspnet_regiis-ga "IIS APPPOOL\app-pool-name"
Ví dụ: Nếu vùng ứng dụng của bạn có tên là Hồ bơi ứng dụng của tôi (như trong hình trước đó), hãy chạy lệnh sau:

aspnet_regiis-ga "IIS APPPOOL\My ứng dụng nhóm" Lưu ý Hệ thống dịch vụ APPHOSTSVC và có thể phải chạy tiện ích aspnet_regiis để giải quyết IIS APPPOOL \ * tên phù hợp.
Độ phân giải 2B: tạo một yếu tố > < machineKey rõ ràng Bằng cách thêm một phần tử rõ ràng < machineKey > vào tệp web. config của ứng dụng, nhà phát triển cho ASP.NET không sử dụng khoá mật mã tự động tạo ra. Xem phụ lục a để biết hướng dẫn về cách tạo một yếu tố < machineKey >.

Nguyên nhân 3: vùng ứng dụng được cấu hình bằng cách sử dụng LoadUserProfile = false

Nếu vùng ứng dụng đang chạy với một danh tính tuỳ chỉnh, IIS có thể không có nạp hồ sơ người dùng cho danh tính. Điều này có tác dụng phụ làm cho HKCU đăng ký không có sẵn cho ASP.NET để duy trì tự động tạo ra < machineKey >. Do đó, khoá tự động tạo mới sẽ được tạo ra mỗi lần ứng dụng chạy lại. Xem phần hồ sơ người dùng trên trang web của Microsoft để biết thêm thông tin.

Giải pháp 3A: sử dụng tiện ích aspnet_regiis Hướng dẫn này là giống như độ phân giải 2A. Xem phần đó để biết thêm thông tin.
Giải pháp 3B: sử dụng một rõ ràng < machineKey > Bằng cách thêm một phần tử rõ ràng < machineKey > vào tệp web. config của ứng dụng, nhà phát triển cho ASP.NET không sử dụng khoá mật mã tự động tạo ra. Xem phụ lục a để biết hướng dẫn về cách tạo một yếu tố < machineKey >.
Giải pháp 3c: cung cấp các khoá đăng ký HKCU bắt buộc theo cách thủ công Nếu bạn không thể chạy tiện ích aspnet_regiis, bạn có thể sử dụng tập lệnh Windows PowerShell để cung cấp các khoá đăng ký thích hợp trong HKCU. Xem phụ lục B để biết thêm thông tin.
Độ phân giải 3D: đặt LoadUserProfile = đúng cho nhóm ứng dụng này Bạn cũng có thể cho phép tải hồ sơ người dùng bên trong vùng ứng dụng này. Điều này làm cho Trung tâm đăng ký HKCU, thư mục tạm thời và các vị trí lưu trữ dành riêng cho người dùng khác có sẵn cho ứng dụng. Tuy nhiên, điều này có thể làm tăng sử dụng đĩa hoặc bộ nhớ cho trình riêng biệt. Xem phần tử để biết thêm thông tin về cách bật thiết đặt này.

Nguyên nhân 4: thuộc tính Page. ViewStateUserKey có một giá trị không đúng

Nhà phát triển phần mềm có thể quyết định sử dụng thuộc tính Page. ViewStateUserKey để thêm yêu cầu qua trang web giả mạo bảo vệ trường _ _ Viewstate. Nếu bạn sử dụng thuộc tính Page. ViewStateUserKey , nó thường được đặt thành giá trị như tên người dùng hiện tại hoặc số nhận dạng phiên của người dùng. Mẫu dự án cho ứng dụng WebForms trong Microsoft Visual Studio 2012 và các phiên bản chứa mẫu sử dụng thuộc tính này. Xem chủ đề trang. ViewStateUserKey thuộc tính trên trang web Microsoft Developer Network (MSDN) để biết thêm thông tin. Nếu thuộc tính Viewstateuserkey được chỉ định, giá trị của nó được ghi vào _ _ Viewstate thời gian tạo. Khi trường _ _ VIEWSTATE tiêu thụ, máy chủ kiểm tra thuộc tính Viewstateuserkey hiện tại của trang và xác nhận nó với giá trị được sử dụng để tạo trường _ _ Viewstate. Nếu giá trị không phù hợp, yêu cầu bị từ chối là có khả năng độc hại. Ví dụ về lỗi liên quan đến ViewStateUserKey sẽ là một khách hàng có hai tab mở trong trình duyệt. Khách hàng được đăng nhập như người dùng A và trong tab đầu tiên, một trang được thực hiện với một _ _ VIEWSTATE thuộc tính Viewstateuserkey chứa "người dùng A." Trong tab thứ hai, khách hàng đăng xuất và sau đó đăng nhập lại là người dùng B. Khách hàng đi trở lại tab đầu tiên và nộp biểu mẫu. Thuộc tính Viewstateuserkey có thể chứa "người dùng B" (vì đó là cookie xác thực của khách hàng nói). Tuy nhiên, trường _ _ VIEWSTATE khách hàng gửi có "người dùng A." Không khớp này gây ra lỗi.

Giải pháp 4A: xác minh rằng ViewStateUserKey được đặt đúng Nếu ứng dụng của bạn sử dụng thuộc tính Viewstateuserkey , xác minh rằng giá trị của thuộc tính giống nhau cả khi xem trạng thái được tạo ra và khi nó được tiêu thụ. Nếu bạn đang sử dụng tên người dùng đã đăng nhập hiện tại, đảm bảo rằng người dùng vẫn đăng nhập và nhận dạng của người dùng đã không thay đổi tại thời postback. Nếu bạn đang sử dụng định danh phiên của người dùng hiện tại, đảm bảo rằng phiên không hết thời gian. Nếu bạn đang chạy trong một môi trường trang trại, đảm bảo rằng các yếu tố < machineKey > phù hợp. Xem phụ lục A để biết hướng dẫn về cách tạo các yếu tố này.

Phụ lục A: làm thế nào để tạo ra một < machineKey > yếu tố

Cảnh báo bảo mật Có rất nhiều các trang web sẽ tạo ra một < machineKey > phần tử cho bạn với một nút bấm. Không bao giờ sử dụng một yếu tố < machineKey > mà bạn đã lấy từ một trong các trang web này. Không thể biết liệu các phím được tạo ra một cách an toàn hoặc nếu họ đang được ghi vào một cơ sở dữ liệu bí mật. Bạn chỉ nên sử dụng các yếu tố cấu hình < machineKey > mà bạn đã tự tạo.

Để tạo một yếu tố < machineKey >, bạn có thể sử dụng tập lệnh Windows PowerShell sau:

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

Đối với ASP.NET 4,0 ứng dụng, bạn chỉ có thể gọi tạo machinekey không có tham số để tạo ra một < machinekey > yếu tố như sau:

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

ASP.NET 2,0 và 3,5 ứng dụng không hỗ trợ HMACSHA256. Thay vào đó, bạn có thể chỉ định SHA1 để tạo ra một tương thích < machineKey > phần tử như sau:

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

Ngay sau khi bạn có một yếu tố < machineKey >, bạn có thể đặt nó trong tệp web. config. Phần tử < machineKey > chỉ hợp lệ trong tệp web. config thư mục gốc của ứng dụng của bạn và không hợp lệ ở cấp độ thư mục.

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

Để có danh sách đầy đủ các thuật toán được hỗ trợ, chạy Trợ giúp tạo MachineKey từ dấu nhắc Windows PowerShell.

Phụ lục B: cung cấp sổ đăng ký để duy trì tự động tạo khoá

Theo mặc định, vì ASP. NETs tự động tạo khoá luôn trong sổ đăng ký HKCU, các phím có thể bị mất nếu hồ sơ người dùng không được tải vào trình IIS riêng biệt và sau đó hồ bơi ứng dụng tái chế. Trường hợp này có thể ảnh hưởng đến các nhà cung cấp lưu trữ được chia sẻ đang chạy ứng dụng hồ là tiêu chuẩn tài khoản người dùng Windows. Để làm việc xung quanh trường hợp này, ASP.NET cho phép sự bền bỉ tự động tạo khoá trong sổ đăng ký HKLM thay vì HKCU đăng ký. Điều này thường được thực hiện bằng cách sử dụng tiện ích aspnet_regiis (xem hướng dẫn trong phần "giải pháp 2A: sử dụng tiện ích aspnet_regiis"). Tuy nhiên, cho các quản trị viên không muốn chạy tiện ích này, lệnh Windows PowerShell sau đây có thể được sử dụng thay thế:

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

Ví dụ sau cho thấy làm thế nào để cung cấp các mục đăng ký HKLM thích hợp cho nhóm ứng dụng chạy như người dùng, example@contoso.com (đây là UPN của tài khoản người dùng Windows). Hồ bơi ứng dụng này là một 32-bit ứng dụng bơi đang chạy CLR v 2.0 (ASP.NET 2,0 hoặc 3,5).

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

Nếu Hồ bơi ứng dụng thay vì là một 64-bit ứng dụng vùng đang chạy CLR v 4.0 (ASP.NET 4,0 hoặc 4,5), lệnh là như sau:

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

Mặc dù tự động tạo khoá được lưu trữ trong HKLM, khoá con đăng ký chứa mỗi tài khoản người dùng bí mật mã hoá tài liệu được thêm vào một danh sách kiểm soát truy nhập (ACL) để các tài liệu mật mã hoá không thể đọc bởi các tài khoản người dùng.

Phụ lục C: mã hóa phần tử < machineKey > trong tập tin cấu hình

Quản trị viên máy chủ có thể không muốn thông tin rất nhạy cảm như < machinekey > tài liệu chính để Bein văn bản thuần mẫu trong tệp cấu hình. Nếu đây là trường hợp, quản trị viên có thể quyết định tận dụng tính năng .NET Framework được gọi là "bảo vệ cấu hình." Tính năng này cho phép bạn mã hóa một số phần của tệp. config. Nếu nội dung của các tập tin cấu hình này đã từng được tiết lộ, nội dung của các phần này sẽ vẫn còn bí mật. Bạn có thể tìm thấy một tổng quan về cấu hình được bảo vệ trên trang web MSDN. Nó cũng chứa một hướng dẫn về cách bảo vệ các yếu tố < connectionStrings > và < machineKey > tệp web. config.