Apache HTTP с Kerberos не работает с навигаторами на основе Chromium-на машинах вне домена

Вот конфигурация модуля Apache HTTP Kerberos в/etc/apache2/sites-available/my.server.tld.conf:

#...
<Location />
  Authname "SSO Authentication"
  AuthType Kerberos
  KrbAuthRealms MY.DOMAIN.TLD
  KrbServiceName HTTP/my.server.tld@MY.DOMAIN.TLD
  Krb5Keytab /etc/apache2/kerb5.my.server.tld.ktab
  KrbMethodNegotiate On
  KrbMethodK5Passwd On
  Require valid-user
</Location>
#...

И конфигурация Kerberos в/etc/krb5.conf:

[libdefaults]
  default_realm = MY.DOMAIN.TLD

#...

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

#...

[domain_realm]
  friendly.domain.tld = MY.DOMAIN.TLD
 .friendly.domain.tld = MY.DOMAIN.TLD

#...

Веб-сервер Apache HTTP установлен на Debian GNU/Linux 10.

Файл keytab был сгенерирован на my.ad.server.1.tld, который является сервером Windows, с помощью команды ktpass.
С этой конфигурацией все отлично работает как на Edge, так и на Firefox на машинах Windows в домене MY.DOMAIN.TLD.

Моя проблема связана с клиентами, которые используют Microsoft Edge (новый с движком Chromium)или Google Chrome на компьютерах Windows за пределами домена.

При первом подключении к my.server.tldбраузер получает заголовки WWW-Authenticate: Negotiateи WWW-Authenticate: Basic realm="SSO Authentication".

В Microsoft Edge, в отличие от Firefox, диалоговое окно аутентификации, которое появляется с WWW-Authenticate: Negotiate, — это не диалоговое окно аутентификации в браузере, а диалоговое окно аутентификации Windows, и оно не работает, что бы мы ни вводили.

После первой неудачной попытки входа браузер выдает второй запрос, и на этот раз он получает только заголовок WWW-Authenticate: Basic realm="SSO Authentication". Появится диалоговое окно аутентификации браузера, и оно работает. Дальнейшая навигация внутри my.server.tldбудет генерировать множество диалогов аутентификации Windows в фоновом режиме. Например, если на странице есть изображение, для него будет показано диалоговое окно аутентификации.

Я заметил, что если Windows-машина подключена к внутренней сети MY.DOMAIN.TLDи мы явно указываем домен в диалоге аутентификации Windows, она также работает нормально (, т.е. my-user@my.domain.tldв качестве имени пользователя).

Имея в виду все вышеизложенное, я задаюсь вопросом...

  • Можно ли заставить его работать с диалоговым окном встроенной проверки подлинности Windows на компьютерах с Windows?
  • Есть ли способ «принудительно» использовать домен для аутентификации, чтобы свести на нет необходимость указывать его явно, как my-user@my.domain.tldдля машин за пределами домена MY.DOMAIN.TLD?

Я уже пытался добавить default_domain = my.domain.tldв конфигурацию области Kerberos или получить TGT Kerberos с kinitна сервере Debian GNU/Linux 10, но безуспешно.

При чтении журналов Apache HTTP с LogLevel trace8в каждой ситуации кажется, что пока появляется диалоговое окно проверки подлинности Windows, возвращается токен NTLM, из-за чего он работает неправильно.

При работе

Где угодно с Firefox
ИЛИ
С компьютером внутри домена, внутренняя сеть (Edge или Chrome)
ИЛИ
С компьютером вне домена, внешняя сеть и с использованиемmy-user@my.domain.tld(Edge или Chrome):

mod_authz_core.c(820): AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
src/mod_auth_kerb.c(1963): kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
src/mod_auth_kerb.c(1296): Acquiring creds for HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verifying client data using KRB5 GSS-API
src/mod_auth_kerb.c(1735): Client didn't delegate us their credential
src/mod_auth_kerb.c(1754): GSS-API token of length 180 bytes will be sent back
mod_authz_core.c(820): AH01626: authorization result of Require valid-user : granted
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: granted

Когда он не работает

С компьютером вне домена, внешней сети (Edge или Chrome):

mod_authz_core.c(820): AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
mod_authz_core.c(820): AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
src/mod_auth_kerb.c(1963): kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
src/mod_auth_kerb.c(1296): Acquiring creds for HTTP/my.server.tld
src/mod_auth_kerb.c(1719): Verifying client data using KRB5 GSS-API
src/mod_auth_kerb.c(1735): Client didn't delegate us their credential
src/mod_auth_kerb.c(1763): Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
src/mod_auth_kerb.c(1156): GSS-API major_status:00010000, minor_status:00000000
gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)

Раздражает то, что он отлично работает на Firefox, но не браузеры с последним движком Chromium. Это потому, что он использует аутентификацию NTLM вместо базовой?

1
задан 26 August 2021 в 14:57
1 ответ

Я могу ошибаться, но для меня навигатор отправляет учетные данные Kerberos только на доверенные сайты. Итак, для компьютеров в домене их навигатор рассматривает ваш веб-сервер как сайт «интрасеть» (= доверенный, = может отправлять учетные данные). Но для других запрос учетных данных, сделанный вашим веб-сервером, игнорируется. Итак, возможно, добавление полного доменного имени вашего веб-сервера в доверенные сайты внешних компьютеров поможет?

1
ответ дан 1 September 2021 в 13:53

Теги

Похожие вопросы