☰

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

tag-icon • tag-icon authentication apache2 kerberos
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/[email protected]
  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 Server, с помощью 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, то все работает нормально (то есть [email protected]как имя пользователя).

Учитывая все вышесказанное, я теперь задаюсь вопросом...

  • Возможно ли на самом деле заставить его работать с диалоговым окном встроенной проверки подлинности Windows на компьютерах с Windows?
  • Есть ли способ «заставить» использовать домен для аутентификации, чтобы исключить необходимость указывать его явно, как [email protected]для машин за пределами MY.DOMAIN.TLDдомена?

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

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

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

Везде с Firefox
ИЛИ
С компьютером внутри домена, внутренняя сеть (Edge или Chrome)
ИЛИ
С помощью компьютера вне домена, внешней сети и с использованием [email protected](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

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

Связанный контент