Đây có phải là thiết lập Kerberos / AD không?

Chúng tôi có một thiết lập IDAM hơi phức tạp:

Tức là máy và trình duyệt của người dùng cuối ngồi trong một mạng với AD gốc và ứng dụng dựa trên Jetty của chúng tôi và AD mà nó có thể nói chuyện với (AD cục bộ) ngồi ở mạng kia.

Có một sự tin tưởng hai chiều giữa hai AD. Trình duyệt trong mạng mẹ có tên miền cục bộ trong các trang web đáng tin cậy.

Thiết lập của máy chủ Jetty như sau:

• nó sử dụng tệp keytab được tạo chống lại hiệu trưởng trong AD cục bộ
• nó đang chạy như một dịch vụ Windows theo người dùng được xác định trong AD cục bộ
• vương quốc, ánh xạ miền cm và kdc được xác định dựa trên miền của AD cục bộ
• nó sử dụng spnego - isInitiator được đặt thành false; doNotPrompt là đúng; storeKey là đúng

Vấn đề là:

• dưới dạng thử nghiệm, truy cập máy chủ từ trình duyệt bên trong mạng cục bộ (tức là được liên kết với AD cục bộ) hoạt động - Thông tin gỡ lỗi Kerberos xuất hiện trong nhật ký, tôi có thể thấy đàm phán Kerberos chính xác trong lưu lượng HTTP và người dùng được đăng nhập tự động . Xuất sắc.

• tuy nhiên , truy cập máy chủ từ trình duyệt bên trong mạng mẹ (đó là cách người dùng của chúng tôi sẽ làm mọi thứ) không hoạt động! Trình duyệt nhận được một thông báo ngược lại 401 nhưng sau đó sẽ nhắc thông tin đăng nhập, khi được nhập sẽ cho một màn hình trống. Sau đó nhấp vào thanh địa chỉ và nhấn Enter thực hiện một trong hai điều, tùy thuộc vào thông tin đăng nhập dành cho AD từ xa hay cục bộ:

  • Thông tin đăng nhập AD cục bộ sau đó đăng nhập tốt, với Kerberos từ đầu trong nhật ký (yêu cầu GET, phản hồi không xác thực 401, yêu cầu tiêu đề Kerberos, v.v.)
  • thông tin đăng nhập AD từ xa không đăng nhập (yêu cầu NHẬN, phản hồi không xác thực 401, trông giống như tiêu đề NTLM Authorization: Negotiate <60 or so random chars>:)

Dù bằng cách nào, thực tế là nó nhắc là sai!

Có một lời giải thích cho những triệu chứng này? Thiết lập chúng ta có thể làm những gì chúng ta muốn?

Xét về những gì về mô tả ở trên có thể sai: mọi cấu hình tôi đã đề cập liên quan đến máy chủ Jetty phải chính xác, như tôi đã làm. Tôi rất vui được cung cấp thêm chi tiết. Bất kỳ cấu hình nào liên quan đến AD hoặc trình duyệt mạng mẹ đều có khả năng bị nghi ngờ, bởi vì nó không thuộc quyền kiểm soát của tôi và tôi đã có cấu hình được báo cáo cho tôi thay vì tự mình nhìn thấy nó.

Không nhìn thấy gói chụp, tôi đoán SPN HTTP / www.website.com cần phải được đăng ký vào tài khoản chạy ứng dụng. Nhóm Dịch vụ thư mục của Microsoft có một bài đăng nhiều phần tuyệt vời đề cập đến chủ đề này tại URL sau.

https://bloss.technet.microsoft.com/askds/2008/05/29/kerberos-authentication-probols-service-principal-name-spn-issues-part-1/

Chạy một gói chụp (netmon, wireshark) từ máy khách trong mỗi môi trường để xác định SPN nào đang được tìm kiếm. Khi đã được xác định, sử dụng cmp setspn để đăng ký nó vào tài khoản đang chạy ứng dụng.

FWIW, Kerberos chỉ hoạt động trong khi trên mạng LAN. Nếu ai đó cần quyền truy cập mà bộ điều khiển miền không thể truy cập, thì bạn sẽ muốn xem xét một SSO như Shibboleth hoặc ADFS.

EDIT: như được đề cập bởi @ alex-h , các trình duyệt sẽ cần được cấu hình để xác thực âm thầm thông qua Kerberos.

• Internet Explorer - trong khi bài viết TechNet không dành riêng cho ứng dụng của bạn, các bước đều giống nhau.
• Firefox - giống như liên kết IE, không khớp chính xác nhưng các bước đều giống nhau.

Cuối cùng, đây là một vấn đề phổ biến với việc triển khai Microsoft Sharepoint. Họ muốn SSO thông qua Kerberos diễn ra âm thầm một khi người dùng đã xác thực tên miền. Do đó, nếu các câu trả lời trên không giải quyết được vấn đề của bạn, hãy thử kiểm tra các diễn đàn của họ như sau:

Kerberos trên Chrome, Safari hoặc FireFox

Vui lòng thử số 1 từ trình duyệt không bật NTLM (Chrome / Firefox). Có vẻ như vấn đề là bạn đã kích hoạt xác thực trước và có thể không tin tưởng hai chiều.

Để xác thực trước, hãy xem tại đây https://support.microsoft.com/en-us/kb/2749007 và tại đây https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html .