Khắc phục sự cố Windows xác thực (không có thách thức) trong IIS 7.5?


21

Tôi biết rằng có hàng ngàn báo cáo về những người gặp sự cố khi Xác thực Windows tích hợp hoạt động với IIS, nhưng tất cả chúng đều dẫn đến các trang web không áp dụng hoặc giải pháp mà tôi đã thử. Tôi đã triển khai hàng tá trang web như thế này trước đây, do đó, có điều gì đó kỳ lạ đang xảy ra với máy chủ / cấu hình hoặc tôi đã xem xét điều này quá lâu và không thấy rõ ràng.

Nói một cách đơn giản, mọi thứ hoạt động hoàn hảo trên máy cục bộ của tôi, nhưng lại sụp đổ trên máy chủ sản xuất, theo như tôi có thể nói có cùng cấu hình .

Trên máy cục bộ:

  • Máy đang chạy Windows 7 Ultimate, Gói dịch vụ 1, IIS 7.5.
  • Trang web đã được thử nghiệm thành công, sử dụng cả IIS và Máy chủ phát triển web VS.
  • Cấu hình trang web IIS có tất cả các phương thức xác thực bị tắt ngoại trừ Xác thực Windows.
  • Máy cục bộ không có trên bất kỳ miền nào.
  • Các nhà cung cấp được thiết lập là đàm phán và NTLM (không phải đàm phán: Kerberos).
  • Bảo vệ mở rộng là Tắt.
  • Tất cả các trình duyệt được kiểm tra (IE, Firefox, Chrome) hiển thị lời nhắc thách thức và cho phép tôi đăng nhập vào miền localhost bằng tài khoản Windows (cục bộ) của mình.
  • Tất cả các trình duyệt được kiểm tra cũng hoạt động bằng cách sử dụng địa chỉ IP cục bộ mờ - vì vậy bản thân các trình duyệt dường như không quan tâm liệu trang web xuất hiện "cục bộ" hay "từ xa".
  • Tôi đã thêm một dòng hiển thị vào trang web hiển thị người dùng hiện đang đăng nhập và nó hiển thị chính xác những gì tôi mong đợi (bất kỳ người dùng địa phương nào tôi đã đăng nhập).

Trên máy từ xa:

  • Máy chủ đang chạy Windows Server 2008 R2, IIS 7.5.
  • Đang tải trang web dẫn đến lỗi ngay lập tức 401.2: Bạn không được phép xem trang này do các tiêu đề xác thực không hợp lệ. Không có thách thức nhắc nhở bao giờ xuất hiện.
  • Cấu hình trang web IIS có tất cả các phương thức xác thực bị tắt ngoại trừ Xác thực Windows.
  • Máy từ xa không có trên bất kỳ miền nào.
  • Các nhà cung cấp được thiết lập là đàm phán và NTLM (không phải đàm phán: Kerberos).
  • Bảo vệ mở rộng là Tắt.
  • Trên máy từ xa (phiên máy tính để bàn từ xa), lỗi tương tự xuất hiện trong Internet Explorer bất kể tên miền là localhost hay địa chỉ IP bên ngoài.
  • Nếu tôi cố gắng xem trang web từ xa từ máy cục bộ của mình , lỗi vẫn là 401, nhưng hơi khác một chút. Không có mã phụ, với văn bản: Quyền truy cập bị từ chối do thông tin không hợp lệ.
  • Các Windows Authentication vai trò tính năng IIS được cài đặt.
  • Các WindowsAuthentication module được gia tăng (ở cấp Server).
  • Lỗi chính xác tương tự xảy ra nếu tôi tắt Xác thực Windows và bật Xác thực cơ bản.
  • Trang web sẽ tải nếu tôi tắt Xác thực Windows và bật Ẩn danh (rõ ràng).
  • Tôi đã thực hiện theo tất cả các bước khắc phục sự cố trên Hỗ trợ của Microsoft: Khắc phục sự cố lỗi HTTP 401 trong IIS
  • Tôi đã thử cách giải quyết được hiển thị trên một trang hỗ trợ khác của Microsoft (được cho là buộc NTLM là phương pháp duy nhất).

Cuối cùng nhưng không kém phần quan trọng, tôi đã thử bật FREB cho các lỗi 401.2 và kết quả dường như không cho tôi biết bất cứ điều gì hữu ích, tất cả những gì tôi thấy là cảnh báo sau:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName IIS Web Core
Thông báo 2
httpStatus 401
HttpR Lý do không được phép
httpSubStatus 2
ErrorCode 2147942405
ConfigExceptionInfo
Thông báo AUTHENTICATE_REQUEST
Truy cập ErrorCode bị từ chối. (0x80070005)

... điều này dường như chỉ nói cho tôi những gì tôi đã biết (rằng nó chỉ đơn giản là từ chối yêu cầu thay vì đàm phán thông tin đăng nhập).

Dấu vết chỉ ra rằng mô-đun WindowsAuthentication được tải chính xác vì có một NOTIFY_MODULE_STARTdòng với ModuleName= WindowsAuthentication(và nhiều sự kiện tiếp theo khác của ASP.NET - [un] may mắn thay, không có lỗi hay cảnh báo thú vị nào ở đây).

Bất cứ ai có thể cho tôi biết những gì tôi có thể thiếu ở đây?


Cập nhật nhanh:

Tôi hơi khó chịu khi gửi toàn bộ kết xuất Wireshark vì nó sẽ tiết lộ IP, URL và các thứ khác, nhưng tôi đã so sánh song song các phản hồi HTTP từ localhost và máy chủ từ xa trong Fiddler, và nó có vẻ khá tự - chắc chắn vấn đề là gì:

Lưu trữ cục bộ:

HTTP / 1.1 401 trái phép
Kiểm soát bộ nhớ cache: riêng tư
Loại nội dung: văn bản / html; bộ ký tự = utf-8
Máy chủ: Microsoft-IIS / 7.5
WWW-xác thực: Đàm phán
WWW-Xác thực: NTLM
X-Powered-By: ASP.NET
Ngày: Thứ bảy, 17 tháng 12 năm 2011 23:42:34 GMT
Độ dài nội dung: 6399
Hỗ trợ proxy: Xác thực dựa trên phiên

Xa:

HTTP / 1.1 401 trái phép
Loại nội dung: văn bản / html
Máy chủ: Microsoft-IIS / 7.5
X-Powered-By: ASP.NET
Ngày: Thứ bảy, 17 tháng 12 năm 2011 23:43:13 GMT
Độ dài nội dung: 1293

Ngoài một số khác biệt dường như không quan trọng như kiểm soát bộ đệm, sự khác biệt chính là máy chủ từ xa không gửi các tiêu đề WWW-xác thực trở lại máy khách.

Vì vậy, tôi đoán rằng sẽ thu hẹp câu hỏi xuống: Tại sao IIS không gửi các tiêu đề WWW-xác thực khi Windows xác thực dường như được cài đặt, tải và kích hoạt độc quyền?


Tâm trí nắm bắt một bản ghi chép rõ ràng của nỗ lực xác thực (trước tiên hãy thay đổi mật khẩu của bạn thành một thứ gì đó vứt đi - chúng tôi không muốn mật khẩu thật của bạn băm trên mạng)? 18 tháng trở lại, một bản vá Windows đã thực hiện một số thay đổi đối với đàm phán HTTP NTLM (nhân tiện, các hệ thống có được vá hết không?) Làm nổ tung ứng dụng của nhà cung cấp và cho tôi nhiều kinh nghiệm hơn tôi quan tâm khi phân tích đàm phán đàm phán.
Shane Madden

@ShaneMadden: Tôi rất bận tâm về tất cả các thông tin khác nhau mà tôi sẽ tiết lộ, nhưng tôi có thể thực hiện một phiên Fiddler gần như giống nhau, và ít nhất tôi có thể ẩn danh IP và v.v. trong thực tế tôi đã làm, kết quả sẽ khá tự giải thích (khách hàng không hiển thị lời nhắc thông tin xác thực vì máy chủ không yêu cầu bất kỳ).
Aaronaught

Thật thú vị, có vẻ như ai đó đã báo cáo vấn đề này trên Stack Overflow - thật đáng buồn, không có câu trả lời nào cả.
Aaronaught

@Aaronaught Làm thế nào bạn có được một tên người dùng khác ở đây so với trên Cooking? Khi tôi lần đầu tiên nhìn thấy câu hỏi này, tôi nghĩ rằng đó là một người giả mạo bạn.
Phường - Phục hồi Monica

@Ward: Bất kỳ ai cũng có thể chỉnh sửa tên người dùng của họ, đó là một phần của hồ sơ. Đây là bản gốc của tôi, chỉ sử dụng những người khác trên các trang web phi công nghệ.
Aaronaught

Câu trả lời:


14

Vấn đề được giải quyết. Cuối cùng tôi đã quyết định so sánh danh sách mô-đun cạnh nhau và thực sự có một cái bị thiếu. Hóa ra có hai mô-đun Xác thực Windows:

Danh sách mô-đun

Trên máy chủ, WindowsAuthenticationmô-đun được quản lý ở đó, nhưng không phải là bản gốc được WindowsAuthenticationModuletô sáng ở trên. Tại sao nó được cấu hình theo cách đó là dự đoán của bất kỳ ai, nhưng rõ ràng nếu mô-đun gốc không được tải, mô-đun được quản lý sẽ vui vẻ tải và âm thầm thất bại.

Vì vậy, đối với bất kỳ độc giả nào trong tương lai gặp phải vấn đề này, hãy đảm bảo bạn đã tải cả hai mô-đun , vì IIS sẽ không cảnh báo bạn nếu thiếu một trong số chúng.


Mô-đun WindowsAuthentication được quản lý không giống như mô-đun. Nó hỗ trợ cho các danh tính Windows trong ASP.Net và nó luôn được cài đặt (khi cài đặt ASP.Net). Tuy nhiên, Windows Authentication mẹ đẻ Module này là những gì được cài đặt khi bạn đánh dấu vào phần Windows Auth trong Server Manager, và đó là những gì bạn cần để cho rằng tùy chọn xác thực để trở thành có thể nhìn thấy trong GUI xác thực.
TristanK

@TristanK: Trong trường hợp này, thành phần đó đã được đánh dấu, nhưng mô-đun không được cài đặt. (Tuy nhiên, tùy chọn này hiển thị trong GUI xác thực - vì vậy tôi khá chắc chắn rằng màn hình phụ thuộc vào mô-đun được quản lý chứ không phải mô-đun gốc.)
Aaronaught

Tôi nghĩ rằng nó có thể đã nhận được theo cách này do một số giả mạo với các tệp cấu hình (có thể là Applicationhost.config). Nhưng tôi đoán nó không thành vấn đề làm thế nào nó thoát khỏi đòn đánh; nó đã làm.
Aaronaught

Vâng, rõ ràng. Windows Auth không hoạt động trừ khi có lỗi xảy ra; trong trường hợp này, trong khi câu hỏi cho biết cấu hình giống hệt nhau, hóa ra là không đúng sự thật; vì vậy nó không hoạt động như nhau. QED.
TristanK

1
Sự cố mô-đun bị thiếu này chỉ cắn tôi trong Windows Server 2012 R2. Thật đáng kinh ngạc khi không có dấu hiệu khi tình trạng này xảy ra. Dù sao, cảm ơn rất nhiều vì câu trả lời này; Tôi đã xé tóc ra theo nghĩa đen!
Rob Davis

4

Chúng tôi thấy rằng điều này không nhất thiết phải khắc phục sự cố cho các nhà phát triển làm việc cục bộ trên các trang web ASP.NET chạy trong Xác thực Windows. Chúng tôi đã tìm thấy một bản hack registry vô hiệu hóa kiểm tra loopback; cái này đã sửa nó: -

khoá đăng ký - HKEY_LOCAL_MACHINE \ HỆ THỐNG \ CurrentControlset \ Control \ Lsa

Tạo một DWORD với giá trị 1 được gọi là "DisableLoopbackCheck"

Bạn sẽ phải khởi động lại máy để cài đặt có hiệu lực


Tôi thấy tôi có thể chuyển đổi giữa DisableLoopbackCheck là 1 và 0 và thay đổi sẽ có hiệu lực ngay lập tức. Ngoài ra, bạn có thể thấy ID sự kiện 4625 trong nhật ký sự kiện Nhật ký bảo mật với thông báo "Tài khoản không đăng nhập được".
alastairtree

Cảm ơn bạn! Chỉ mất 2 ngày để xác thực IIS và các phiên bản .Net để tìm thấy vì tôi đang sử dụng tệp máy chủ của mình để tạo một mục nhập DNS giả trong khi kiểm tra di chuyển trang web.
JohnLBevan
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.