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