Điểm:1

Apache HTTP với Kerberos không hoạt động với bộ điều hướng do Chromium cung cấp trên các máy bên ngoài miền

lá cờ gb

Đây là cấu hình mô-đun HTTP Kerberos của Apache trong /etc/apache2/sites-available/my.server.tld.conf:

#...
<Vị trí />
  Tên xác thực "Xác thực SSO"
  AuthType Kerberos
  KrbAuthRealms MY.DOMAIN.TLD
  KrbServiceName HTTP/[email protected]
  Krb5Keytab /etc/apache2/kerb5.my.server.tld.ktab
  KrbMethodĐàm phán
  KrbMethodK5Passwd On
  Yêu cầu người dùng hợp lệ
</Vị trí>
#...

Và cấu hình Kerberos trong /etc/krb5.conf:

[libdefaults]
  default_realm = MY.DOMAIN.TLD

#...

[cõi]
  MY.DOMAIN.TLD = {
    kdc = my.ad.server.1.tld
    kdc = my.ad.server.2.tld
    admin_server = my.ad.server.1.tld
  }

#...

[miền_cõi]
  thân thiện.domain.tld = MY.DOMAIN.TLD
  .friend.domain.tld = MY.DOMAIN.TLD

#...

Máy chủ web Apache HTTP được cài đặt trên Debian GNU/Linux 10.

Tệp keytab được tạo trên my.ad.server.1.tld, là Windows Server, với ktpass chỉ huy.
Với cấu hình này, mọi thứ hoạt động tốt trên cả Edge và Firefox trên máy Windows trong MY.DOMAIN.TLD miền.

Sự cố của tôi đến từ các máy khách sử dụng Microsoft Edge (phiên bản mới có công cụ Chromium) hoặc Google Chrome trên các máy Windows bên ngoài miền.

Trong lần kết nối đầu tiên với my.server.tld, trình duyệt nhận được WWW-Xác thực: Đàm phánWWW-Xác thực: Vương quốc cơ bản="Xác thực SSO" tiêu đề.

Với Microsoft Edge và không giống như Firefox, hộp thoại xác thực bật lên với WWW-Xác thực: Đàm phán không phải là hộp thoại từ trình duyệt, mà là hộp thoại xác thực Windows và nó không hoạt động, bất kể chúng tôi nhập gì.

Sau lần thử đăng nhập đầu tiên không thành công, trình duyệt sẽ đưa ra yêu cầu thứ hai và lần này anh ta chỉ nhận được WWW-Xác thực: Vương quốc cơ bản="Xác thực SSO" tiêu đề. Hộp thoại xác thực trình duyệt bật lên và nó hoạt động. điều hướng thêm bên trong my.server.tld sau đó sẽ tạo ra nhiều hộp thoại xác thực Windows trong nền.Ví dụ: nếu có một hình ảnh trên một trang, nó sẽ hiển thị hộp thoại xác thực cho hình ảnh đó.

Tôi nhận thấy rằng nếu máy Windows được kết nối trong mạng nội bộ của MY.DOMAIN.TLD và chúng tôi chỉ định rõ ràng tên miền trong hộp thoại xác thực Windows, nó cũng hoạt động tốt (tức là [email protected] làm tên người dùng).

Với tất cả những điều trên trong đầu, bây giờ tôi tự hỏi...

  • Có thực sự có thể làm cho nó hoạt động với hộp thoại Xác thực Windows tích hợp trên máy Windows không?
  • Có cách nào để "buộc" tên miền được sử dụng để xác thực, để vô hiệu hóa nhu cầu chỉ định nó một cách rõ ràng như [email protected] cho các máy bên ngoài MY.DOMAIN.TLD miền?

Tôi đã cố gắng thêm default_domain = my.domain.tld bên trong cấu hình vương quốc Kerberos hoặc để nhận Kerberos TGT với dệt vải trên máy chủ Debian GNU/Linux 10 không thành công.

Đọc nhật ký của Apache HTTP với Dấu vết logLevel8 với mọi tình huống, có vẻ như hộp thoại xác thực Windows bật lên, mã thông báo NTLM được trả về, điều này khiến nó không hoạt động chính xác.

Khi nó hoạt động

Mọi nơi với Firefox
HOẶC
Với máy tính bên trong miền, mạng nội bộ (Edge hoặc Chrome)
HOẶC
Với máy tính ngoài miền, mạng ngoài và sử dụng [email protected] (Cạnh hoặc Chrome):

mod_authz_core.c(820): AH01626: kết quả ủy quyền của Yêu cầu người dùng hợp lệ: bị từ chối (chưa có người dùng được xác thực)
mod_authz_core.c(820): AH01626: kết quả ủy quyền của <RequireAny>: bị từ chối (chưa có người dùng được xác thực)
src/mod_auth_kerb.c(1963): kerb_authenticate_user được nhập với người dùng (NULL) và auth_type Kerberos
src/mod_auth_kerb.c(1296): Nhận tín dụng cho HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Xác minh dữ liệu khách hàng bằng KRB5 GSS-API
src/mod_auth_kerb.c(1735): Khách hàng không ủy quyền cho chúng tôi thông tin xác thực của họ
src/mod_auth_kerb.c(1754): Mã thông báo GSS-API có độ dài 180 byte sẽ được gửi lại
mod_authz_core.c(820): AH01626: kết quả ủy quyền của Yêu cầu người dùng hợp lệ: được cấp
mod_authz_core.c(820): AH01626: kết quả ủy quyền của <RequireAny>: được cấp

Khi nó không hoạt động

Với máy tính ngoài miền, mạng ngoài (Edge hoặc Chrome):

mod_authz_core.c(820): AH01626: kết quả ủy quyền của Yêu cầu người dùng hợp lệ: bị từ chối (chưa có người dùng được xác thực)
mod_authz_core.c(820): AH01626: kết quả ủy quyền của <RequireAny>: bị từ chối (chưa có người dùng được xác thực)
src/mod_auth_kerb.c(1963): kerb_authenticate_user được nhập với người dùng (NULL) và auth_type Kerberos
src/mod_auth_kerb.c(1296): Nhận tín dụng cho HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Xác minh dữ liệu khách hàng bằng KRB5 GSS-API
src/mod_auth_kerb.c(1735): Khách hàng không ủy quyền cho chúng tôi thông tin xác thực của họ
src/mod_auth_kerb.c(1763): Cảnh báo: mã thông báo đã nhận có vẻ là NTLM, không được mô-đun Kerberos hỗ trợ. Kiểm tra cấu hình IE của bạn.
src/mod_auth_kerb.c(1156): GSS-API major_status:00010000, minor_status:00000000
gss_accept_sec_context() không thành công: Một cơ chế không được hỗ trợ đã được yêu cầu (, Lỗi không xác định)

Phần khó chịu của tất cả những điều này là nó hoạt động hoàn hảo trên Firefox, nhưng không hoạt động trên các trình duyệt có công cụ Chromium gần đây. Có phải vì nó quay trở lại xác thực NTLM thay vì xác thực Cơ bản không?

Điểm:1
lá cờ jp

Tôi có thể sai, nhưng đối với tôi, bộ điều hướng chỉ gửi thông tin xác thực Kerberos đến các trang đáng tin cậy. Vì vậy, đối với các máy tính trong miền, trình điều hướng của họ coi máy chủ web của bạn là trang web "mạng nội bộ" (= đáng tin cậy, = có thể gửi thông tin xác thực).Nhưng đối với những người khác, yêu cầu thông tin xác thực do máy chủ web của bạn thực hiện sẽ bị loại bỏ. Vì vậy, có lẽ bằng cách thêm FQDN của máy chủ web của bạn vào các trang web đáng tin cậy của máy tính bên ngoài, nó sẽ thực hiện thủ thuật?

lá cờ gb
Cảm ơn bạn đã dành thời gian. Đúng là `WWW-Authenticate: Negotiate` sẽ không được gửi nếu trang web không đáng tin cậy, tuy nhiên, việc thêm `my.server.tld` vào `network.negotiate-auth.trusted-uris` trong Firefox (ví dụ) sẽ được gửi không giúp. Nhưng tôi nghĩ rằng tôi đã tìm thấy sự cố... Kerberos yêu cầu khách hàng phải có quyền truy cập vào máy chủ DC, đây không phải là trường hợp của tôi. Khi điều đó xảy ra, Firefox chuyển về Cơ bản và nó hoạt động, nhưng Edge chuyển về NTLM và chúng tôi đã không định cấu hình NTLM.
lá cờ cn
@kagmole: `Kerberos yêu cầu máy khách phải có quyền truy cập vào máy chủ DC, đây không phải là trường hợp của tôi.` Mã thông báo Kerberos phải được tạo bởi một DC, vì vậy không có bất kỳ thứ gì Kerberos gửi từ máy khách và nó không rơi quay lại NTLM đó chỉ là mã thông báo. Nếu tài khoản người dùng đã đăng nhập nằm trong một miền, nó có thể cố gắng gửi mã thông báo Kerberos, nhưng nếu đó không phải là cùng một miền hoặc một miền đáng tin cậy thì nó sẽ không thành công.
lá cờ gb
@GregAskew cảm ơn vì những hiểu biết sâu sắc của bạn. Vì vậy, nếu tôi hiểu chính xác, `KrbMethodK5Passwd` vẫn là "xác thực Kerberos", nhưng được thực hiện bằng mã thông báo `Authorization Basic`?
lá cờ gb
@Tệ nhất là bạn đã đúng. Bây giờ tôi đã thêm `https://*.server.tld` vào mạng nội bộ đáng tin cậy trong tùy chọn Internet và nó hoạt động cho Google Chrome và Microsoft Edge.

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.