IUSR và IWAM bắt đầu từ những ngày đầu của IIS khi bạn cài đặt nó một cách riêng biệt (không phải là một thành phần HĐH). Theo mặc định, nếu một trang web cho phép xác thực ẩn danh, tài khoản IUSR được sử dụng đối với các quyền trên HĐH. Điều này có thể được thay đổi từ mặc định. Có một số đề xuất bảo mật để ít nhất đổi tên tài khoản, vì vậy đó không phải là tài khoản "đã biết", giống như có một đề xuất đổi tên tài khoản quản trị viên trên máy chủ. Bạn có thể tìm hiểu thêm về IUSR và xác thực tại MSDN .
IWAM được thiết kế cho mọi ứng dụng ngoài quy trình và chỉ được sử dụng trong IIS 6.0 khi bạn ở chế độ cách ly IIS 5.0. Bạn thường thấy nó với các đối tượng COM / DCOM.
Đối với danh tính nhóm ứng dụng, mặc định là chạy dưới dạng Dịch vụ mạng. Bạn không nên chạy như Hệ thống cục bộ vì tài khoản đó có quyền lớn hơn tài khoản của quản trị viên. Vì vậy, về cơ bản, điều đó đưa bạn đến Dịch vụ mạng, Dịch vụ địa phương hoặc tài khoản cục bộ / tên miền khác ngoài hai tài khoản đó.
Để làm gì, nó phụ thuộc. Một lợi thế của việc rời khỏi nó là Dịch vụ mạng là đây là tài khoản đặc quyền hạn chế trên máy chủ. Tuy nhiên, khi nó truy cập tài nguyên trên mạng, nó xuất hiện dưới dạng Domain \ ComputerName $, nghĩa là bạn có thể gán các quyền cho phép tài khoản Dịch vụ mạng truy cập các tài nguyên như SQL Server chạy trên một hộp khác. Ngoài ra, vì nó xuất hiện dưới dạng tài khoản máy tính, Nếu bạn bật xác thực Kerberos, SPN đã sẵn sàng nếu bạn truy cập trang web bằng tên máy chủ.
Trường hợp bạn cân nhắc thay đổi nhóm ứng dụng thành tài khoản miền Windows cụ thể nếu bạn muốn một tài khoản cụ thể truy cập các tài nguyên được nối mạng như tài khoản dịch vụ truy cập SQL Server cho ứng dụng dựa trên web. Có các tùy chọn khác trong ASP.NET để thực hiện việc này mà không thay đổi danh tính nhóm ứng dụng, vì vậy điều này không còn cần thiết nữa. Một lý do khác mà bạn xem xét khi sử dụng tài khoản người dùng tên miền là bạn đang thực hiện xác thực Kerberos và bạn có nhiều máy chủ web phục vụ một ứng dụng web. Một ví dụ điển hình là nếu bạn có hai hoặc nhiều máy chủ web phục vụ Dịch vụ báo cáo SQL Server. Giao diện người dùng có thể sẽ đến một url chung như báo cáo.mydomain.com hoặc báo cáo.mydomain.com. Trong trường hợp đó, SPN chỉ có thể được áp dụng cho một tài khoản trong AD. Nếu bạn có nhóm ứng dụng chạy trong Dịch vụ mạng trên mỗi máy chủ thì điều đó sẽ không hoạt động, bởi vì khi họ rời khỏi máy chủ, chúng sẽ xuất hiện dưới dạng Domain \ ComputerName $, nghĩa là bạn có nhiều tài khoản như bạn có máy chủ phục vụ ứng dụng. Giải pháp là tạo một tài khoản miền, đặt danh tính nhóm ứng dụng trên tất cả các máy chủ thành cùng một tài khoản người dùng tên miền và tạo một SPN, từ đó cho phép xác thực Kerberos. Trong trường hợp một ứng dụng như SSRS, nơi bạn có thể muốn chuyển thông tin đăng nhập của người dùng đến máy chủ cơ sở dữ liệu phía sau, thì xác thực Kerberos là bắt buộc vì sau đó bạn sẽ phải định cấu hình ủy quyền Kerberos. d có nhiều tài khoản như bạn có máy chủ phục vụ ứng dụng. Giải pháp là tạo một tài khoản miền, đặt danh tính nhóm ứng dụng trên tất cả các máy chủ thành cùng một tài khoản người dùng tên miền và tạo một SPN, từ đó cho phép xác thực Kerberos. Trong trường hợp một ứng dụng như SSRS, nơi bạn có thể muốn chuyển thông tin đăng nhập của người dùng đến máy chủ cơ sở dữ liệu phía sau, thì xác thực Kerberos là bắt buộc vì sau đó bạn sẽ phải định cấu hình ủy quyền Kerberos. d có nhiều tài khoản như bạn có máy chủ phục vụ ứng dụng. Giải pháp là tạo một tài khoản miền, đặt danh tính nhóm ứng dụng trên tất cả các máy chủ thành cùng một tài khoản người dùng tên miền và tạo một SPN, từ đó cho phép xác thực Kerberos. Trong trường hợp một ứng dụng như SSRS, nơi bạn có thể muốn chuyển thông tin đăng nhập của người dùng đến máy chủ cơ sở dữ liệu phía sau, thì xác thực Kerberos là bắt buộc vì sau đó bạn sẽ phải định cấu hình ủy quyền Kerberos.
Tôi biết đó là rất nhiều để đưa vào, nhưng câu trả lời ngắn gọn là, ngoại trừ Hệ thống cục bộ, nó phụ thuộc.