Tại sao khi tôi thêm quyền truy cập IIS_IUSRS RW vào một thư mục, nó không tự động cho phép truy cập ISUR RW?


11

Tôi đang sử dụng IIS7 (Windows Server 2008 x64) và tôi có thiết lập trang web bằng xác thực ẩn danh. Danh tính người dùng anon được cấu hình là IUSR. Ứng dụng ghi các tệp vào một thư mục và tôi cấp quyền cho nhóm IIS_IUSRS RW cho thư mục. Điều này không hoạt động. Tôi phải cung cấp cho IUSR RW một cách rõ ràng để cho phép ứng dụng ghi vào thư mục.

Theo hiểu biết của tôi, danh tính nhóm ứng dụng sẽ tự động được thêm vào nhóm IIS_IUSRS. Tôi giả định rằng IUSR (hoặc bất kỳ danh tính người dùng ẩn danh nào) cũng là một thành viên ngụ ý của nhóm IIS_IUSRS. Có vẻ như đây không phải là trường hợp.

Trong khi khắc phục sự cố, tôi sử dụng Trình giám sát quy trình để xem quyền truy cập vào thư mục và xác định rằng Dịch vụ mạng (danh tính nhóm ứng dụng) đang mạo danh IUSR (đây là điều tôi mong đợi) nhưng việc cho phép RW cho nhóm IIS_IUSRS không cho phép IUSR truy cập tập tin (Truy cập bị từ chối).

Bất cứ ai cũng có thể giải thích liệu IUSR là hoặc không phải là thành viên của nhóm IIS_IUSRS?

Tôi đã xem lại tài liệu sau đây và không tìm thấy câu trả lời chắc chắn:

Hiểu tài khoản người dùng và nhóm tích hợp trong IIS 7

Danh tính nhóm ứng dụng

Câu trả lời:


14

Đó là bởi vì đây là hai điều khác nhau. IIS_IUSRS là nhóm dành cho Tài khoản quy trình công nhân IIS . Điều này có nghĩa là danh tính mà nhóm ứng dụng tự chạy. IUSR là danh tính người dùng ẩn danh. Điều đó có nghĩa là danh tính mà IIS tin là người dùng đang truy cập trang web.

Bây giờ mặc dù bạn không nói ra, hãy để tôi đoán - ứng dụng này là asp cổ điển? (Nếu không, nếu là .Net thì bạn phải sử dụng mạo danh). Dù bằng cách nào, điều xảy ra là các tài nguyên được truy cập dưới dạng danh tính mạo danh, nghĩa là người dùng ẩn danh trong trường hợp của bạn, nghĩa là IUSR. Đó là lý do tại sao bạn phải cấp cho nó quyền. Trong .Net, nếu bạn tắt mạo danh, bạn sẽ thấy rằng IIS_IUSRS sẽ hoạt động như bạn mong đợi. Trong Classic ASP (và đối với các tệp tĩnh), bạn không có lựa chọn nào, việc mạo danh luôn được "bật"; vì vậy, nó luôn luôn là danh tính người dùng được sử dụng, không phải danh tính nhóm. Vì vậy, vì IIS_IUSRS dành cho danh tính nhóm, nên nó không hoạt động.


Chỉnh sửa sau khi OP thêm thông tin:

Rất dễ nhầm lẫn giữa IUSR và IIS_IUSRS vì tên của chúng. Để thấy rằng chúng khác nhau là hãy nhớ rằng IIS_IUSRS là sự thay thế cho IIS_WPG trong IIS6, đó là Nhóm quy trình công nhân. Đối với các nhóm này, bạn thêm tài khoản mà bạn muốn chạy nhóm của mình bên dưới, không phải danh tính anon, đặc quyền anon được cho là hạn chế hơn. ví dụ. đôi khi bạn có thể muốn sử dụng tài khoản miền để chạy nhóm cho phép kerberos đến các tài nguyên mạng khác. Sau đó, bạn sẽ thêm tài khoản dịch vụ đó vào nhóm này.

Khi tính năng mạo danh được kích hoạt, pool / process giả vờ là người dùng vì nó được thông báo. Trong trường hợp anon auth (trường hợp của bạn), người dùng đó là IUSR. Trong trường hợp windows auth, đó sẽ là danh tính windows \ domain của người dùng. Đây cũng là lý do tại sao bạn nhận được một hiệu suất với sự mạo danh, bởi vì quá trình này phải chuyển sang một danh tính khác để truy cập tài nguyên.

Nếu bạn đang sử dụng .NET và xác thực ẩn danh, thì tôi không hiểu tại sao bạn lại cho phép mạo danh. Trong trường hợp bạn không sử dụng hoặc không cần mạo danh, bạn nên lưu ý thêm một số mánh khóe trong trường hợp IIS7: bạn có thể khiến IUSR của mình biến mất hoàn toàn và chấm dứt mọi sự nhầm lẫn. Tôi nghĩ bạn sẽ thích điều đó, và đó cũng là phương pháp ưa thích của tôi. Tất cả bạn phải làm là bảo nó sử dụng lại danh tính nhóm làm danh tính ẩn danh .

Vì vậy, sau này, bạn sẽ chỉ phải đối phó với nhóm IIS_IUSRS. Nhưng đừng nhầm lẫn, điều này vẫn không có nghĩa là hai cái này giống nhau! Có thể nhận dạng quá trình có thể thay thế cho IUSR, nhưng không phải là cách khác!

Một số mẹo nhỏ khác của IIS7 cần lưu ý: nếu bạn nhìn vào IIS_IUSRS, nó có thể trống. Đó là bởi vì danh tính nhóm ảo của bạn được tự động thêm vào nó khi nhóm bắt đầu, vì vậy bạn không phải lo lắng về những điều này.

Bảng này sẽ giúp làm rõ hơn cách xác định danh tính thực thi luồng:

Mạo danh Tài nguyên truy cập ẩn danh được truy cập dưới dạng

Đã bật IUSR_computer đã bật trong IIS5 / 6 hoặc,
                                       IUSR trong IIS7 hoặc,
                                       Nếu bạn thay đổi tài khoản người dùng anon 
                                       trong IIS, bất cứ điều gì bạn đặt ở đó
Đã vô hiệu hóa MYDOM \ MyName
Vô hiệu hóa NT Author \ Network Service (danh tính nhóm)
Cơ quan NT bị vô hiệu hóa \ Dịch vụ mạng (danh tính nhóm)


Chúng tôi đang xác định sử dụng .Net (nhắm mục tiêu 3.5) nhưng có thể đang sử dụng mạo danh. Tôi sẽ phải kiểm tra với các nhà phát triển của tôi để chắc chắn. Sự nhầm lẫn của tôi bắt nguồn từ thực tế mà tôi giả định (có vẻ không chính xác) rằng danh tính người dùng ẩn danh tự động là thành viên của nhóm IIS_IUSRS. Vì anh ấy không cho phép tôi làm rõ và làm ơn sửa tôi nếu tôi lo lắng.

1) Sử dụng ASP cổ điển, quyền truy cập tệp sử dụng danh tính người dùng ẩn danh. Trong IIS 7 trở lên, người dùng này không phải là thành viên của nhóm IIS_IUSRS theo mặc định. 2) Sử dụng ASP.Net, quyền truy cập tệp sử dụng danh tính người dùng ẩn danh nếu tính năng mạo danh được bật. Trong IIS 7 trở lên, người dùng này không phải là thành viên của nhóm IIS_IUSRS theo mặc định. 3) Sử dụng ASP.Net, quyền truy cập tệp sử dụng danh tính quy trình worker nếu việc mạo danh bị vô hiệu hóa. Trong IIS 7 trở lên, người dùng này luôn là thành viên của nhóm IIS_IUSRS theo mặc định.

Có hoàn toàn chính xác trên tất cả các điểm! Để hoàn toàn rõ ràng, trong # 1 và # 2, bạn nên thêm "nếu IIS anon auth được bật", điều mà tôi không phải đưa vào trước đó vì bạn đã nói rằng bạn đang sử dụng anon. Xem bảng tôi đã thêm để giải thích rõ hơn điều này.
Amit N Nikol

Cảm ơn bạn rất nhiều vì đã làm rõ điều này. Nó đồng ý với những gì tôi đã tìm thấy qua bản dùng thử và lỗi nhưng tôi chưa thấy tài liệu này rõ ràng ở bất cứ đâu. Điều quan trọng đối với các quản trị viên sử dụng LUA trên máy chủ của họ khi thiết lập các ứng dụng IIS cần có quyền ghi.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.