Вот конфигурация модуля Apache HTTP Kerberos в /etc/apache2/сайты-доступны/my.server.tld.conf:
# ...
<Местоположение />
Аутентификация "SSO-аутентификация"
Тип аутентификации Kerberos
KrbAuthRealms МОЙ.ДОМЕН.ДВУ
KrbServiceName HTTP/[email protected]
Krb5Keytab /etc/apache2/kerb5.my.server.tld.ktab
KrbMethodNegotiate On
KrbMethodK5Пароль включен
Требовать действительного пользователя
</местоположение>
# ...
И конфигурация Kerberos в /etc/krb5.conf:
[libdefaults]
default_realm = МОЙ.ДОМЕН.ДВУ
# ...
[сферы]
МОЙ.ДОМЕН.ДВУ = {
kdc = my.ad.server.1.tld
kdc = my.ad.server.2.tld
admin_server = my.ad.server.1.tld
}
# ...
[область_домена]
дружественный.домен.tld = МОЙ.ДОМЕН.ДВУ
.friendly.domain.tld = МОЙ.ДОМЕН.ДВУ
# ...
Веб-сервер Apache HTTP установлен на Debian GNU/Linux 10.
Файл keytab был сгенерирован на my.ad.server.1.tld, который является Windows Server, с ктпасс команда.
С этой конфигурацией все отлично работает как на Edge, так и на Firefox на компьютерах с Windows в МОЙ.ДОМЕН.ДВУ домен.
Моя проблема связана с клиентами, которые используют Microsoft Edge (новый с движком Chromium) или Google Chrome на компьютерах с Windows за пределами домена.
При первом подключении к мой.server.tld, браузер получает WWW-аутентификация: переговоры и WWW-Authenticate: Basic realm="SSO Authentication" заголовки.
В Microsoft Edge, в отличие от Firefox, диалоговое окно аутентификации, которое появляется с WWW-аутентификация: переговоры это не тот, что из браузера, а диалог аутентификации Windows, и он не работает, что бы мы ни печатали.
После первой неудачной попытки входа в систему браузер выдает второй запрос, и на этот раз он получает только WWW-Authenticate: Basic realm="SSO Authentication" заголовок. Появится диалоговое окно аутентификации браузера, и оно работает. Дальнейшая навигация внутри мой.server.tld затем будет генерироваться много диалогов аутентификации Windows в фоновом режиме.Например, если на странице есть изображение, для него будет показано диалоговое окно аутентификации.
Я заметил, что если машина Windows подключена к внутренней сети МОЙ.ДОМЕН.ДВУ и мы явно указываем домен в диалоге проверки подлинности Windows, он также отлично работает (т.е. мой-пользователь@мой.домен.tld как имя пользователя).
Имея в виду все вышесказанное, я теперь задаюсь вопросом...
- Действительно ли возможно заставить его работать с диалоговым окном встроенной проверки подлинности Windows на компьютерах с Windows?
- Есть ли способ «принудительно» использовать домен для аутентификации, чтобы свести на нет необходимость указывать его явно, например
мой-пользователь@мой.домен.tld для машин за пределами МОЙ.ДОМЕН.ДВУ домен?
я уже пытался добавить default_domain = my.domain.tld внутри конфигурации области Kerberos или для получения Kerberos TGT с кинит на сервере Debian GNU/Linux 10 безуспешно.
Чтение журналов Apache HTTP с помощью Трассировка LogLevel8 в каждой ситуации похоже, что пока появляется диалоговое окно проверки подлинности Windows, возвращается токен NTLM, из-за чего он работает неправильно.
Когда это работает
Где угодно с Firefox
ИЛИ ЖЕ
С компьютером внутри домена, внутренней сети (Edge или Chrome)
ИЛИ ЖЕ
С компьютером вне домена, внешней сети и с использованием мой-пользователь@мой.домен.tld (край или хром):
mod_authz_core.c(820): AH01626: результат авторизации Require valid-user : disabled (пока нет аутентифицированного пользователя)
mod_authz_core.c(820): AH01626: результат авторизации <RequireAny>: отклонено (еще нет аутентифицированного пользователя)
src/mod_auth_kerb.c(1963): kerb_authenticate_user введен с user (NULL) и auth_type Kerberos
src/mod_auth_kerb.c(1296): Получение кредитов для HTTP/my.server.tld
src/mod_auth_kerb.c(1719): проверка данных клиента с использованием KRB5 GSS-API.
src/mod_auth_kerb.c(1735): Клиент не делегировал нам свои учетные данные
src/mod_auth_kerb.c(1754): токен GSS-API длиной 180 байт будет отправлен обратно.
mod_authz_core.c(820): AH01626: результат авторизации Require valid-user: предоставлено
mod_authz_core.c(820): AH01626: результат авторизации <RequireAny>: предоставлен
Когда это не работает
С компьютером вне домена, внешней сети (Edge или Chrome):
mod_authz_core.c(820): AH01626: результат авторизации Require valid-user : disabled (пока нет аутентифицированного пользователя)
mod_authz_core.c(820): AH01626: результат авторизации <RequireAny>: отклонено (еще нет аутентифицированного пользователя)
src/mod_auth_kerb.c(1963): kerb_authenticate_user введен с user (NULL) и auth_type Kerberos
src/mod_auth_kerb.c(1296): Получение кредитов для HTTP/my.server.tld
src/mod_auth_kerb.c(1719): проверка данных клиента с использованием KRB5 GSS-API.
src/mod_auth_kerb.c(1735): Клиент не делегировал нам свои учетные данные
src/mod_auth_kerb.c(1763): Предупреждение: полученный токен выглядит как NTLM, который не поддерживается модулем Kerberos. Проверьте конфигурацию IE.
src/mod_auth_kerb.c(1156): GSS-API major_status:00010000, minor_status:00000000
gss_accept_sec_context() не удалось: был запрошен неподдерживаемый механизм (, Неизвестная ошибка)
Раздражает то, что он отлично работает в Firefox, но не в браузерах с последним движком Chromium. Это потому, что он использует аутентификацию NTLM вместо базовой?
