У нас есть 2 леса / домена: ad.local (не управляемый нами) и ad2.local (управляемый нами)
Мы устанавливаем между ними двустороннее доверие.
Теперь предположим, что у меня есть приложение на сервере, подключенном к ad2.local: app.ad2.local
Это приложение принимает LDAP или Kerberos (с apache)
Из того, что я прочитал, невозможно запросить доверенных пользователей через LDAP (поправьте меня, если я ошибаюсь), поэтому мы выбрали Kerberos.
Пока мне удалось войти в систему с пользователями из ad2.local, но не из ad.local.
Когда я пытаюсь войти в систему с пользователями из ad.local, я получаю следующие ошибки:
[Thu Mar 19 11:07:48.155074 2020] [authz_core:debug] [pid 20267] mod_authz_core.c(809): [client IP:33274] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Thu Mar 19 11:07:48.155213 2020] [authz_core:debug] [pid 20267] mod_authz_core.c(809): [client IP:33274] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Mar 19 11:07:48.155248 2020] [auth_kerb:debug] [pid 20267] src/mod_auth_kerb.c(1954): [client IP:33274] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Mar 19 11:07:55.188879 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Thu Mar 19 11:07:55.188985 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Mar 19 11:07:55.189019 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1954): [client IP:33346] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Mar 19 11:07:56.083017 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Thu Mar 19 11:07:56.083102 2020] [authz_core:debug] [pid 3421] mod_authz_core.c(809): [client IP:33346] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Thu Mar 19 11:07:56.083137 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1954): [client IP:33346] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[Thu Mar 19 11:07:56.083286 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1295): [client IP:33346] Acquiring creds for HTTP@APP_FQDN
[Thu Mar 19 11:07:56.087966 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1708): [client IP:33346] Verifying client data using KRB5 GSS-API
[Thu Mar 19 11:07:56.088023 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1724): [client IP:33346] Client didn't delegate us their credential
[Thu Mar 19 11:07:56.088038 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1752): [client IP:33346] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[Thu Mar 19 11:07:56.088053 2020] [auth_kerb:debug] [pid 3421] src/mod_auth_kerb.c(1155): [client IP:33346] GSS-API major_status:00010000, minor_status:00000000
[Thu Mar 19 11:07:56.088182 2020] [auth_kerb:error] [pid 3421] [client IP:33346] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)
Вот моя конфигурация apache:
<Location /application>
AuthType Kerberos
AuthName "Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbSaveCredentials Off
KrbAuthRealms AD.LOCAL AD2.LOCAL
Krb5KeyTab /etc/kerberos.keytab
KrbLocalUserMapping On
require valid-user
</Location>
И etc / krb5.conf:
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
dns_lookup_realm = false
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
pkinit_anchors = /etc/pki/tls/certs/ca-bundle.crt
# default_realm = EXAMPLE.COM
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = AD2.LOCAL
[realms]
# EXAMPLE.COM = {
# kdc = kerberos.example.com
# admin_server = kerberos.example.com
# }
AD2.LOCAL = {
kdc = dc.AD2.LOCAL
# auth_to_local = RULE:[1:$1@$0](^.*@AD.LOCAL$)s/@AD.LOCAL/@ad.local/
# auth_to_local = DEFAULT
}
AD.LOCAL = {
kdc = master.ad.local
}
[domain_realm]
# .example.com = EXAMPLE.COM
# example.com = EXAMPLE.COM
ad2.local = AD2.LOCAL
.ad2.local = AD2.LOCAL
ad.local = AD.LOCAL
.ad.local = AD.LOCAL
Кто-нибудь знает, в чем может быть проблема?
Проблема в одном из двух. Либо клиент лаборатории не смог разрешить DC в ad.local с введенными вами кредитами, поэтому он вернулся к NTLM. Он смог разрешить DC в ad2.local так что он смог сделать Kerberos. Или просьба к ad.local не располагал достаточной информацией, чтобы направить вас в другой домен.
На неподключенном клиенте Windows Windows попытается разрешить домены, просмотрев введенные вами учетные данные и используя часть области в качестве подсказки. Если вы введете user@ad.local он попытается найти контроллер домена с использованием DNS SRV _kerberos._tcp.ad.local. Если вы введете ad\user, у клиента (вероятно) недостаточно информации для создания успешного DNS-запроса, поэтому он возвращается к NTLM.
Предполагая, что это удалось, и вы смогли решить ad.local правильно, этот DC теперь должен знать, для какого приложения он должен выпустить билет. Windows будет использовать запрошенное имя хоста и отправит его на ad.local. Если введенное имя хоста app, контроллер домена не найдет никаких записей и не вернет ошибку «служба не найдена» (что заставляет клиента возвращаться к NTLM). Если введенное имя app.ad2.local тогда DC должен распознать .ad2.local суффикс (потому что он настроен на доверии) и начать переход к ad2.local который затем выдаст вам билет на app.ad2.local.
Использование полностью определенных имен должно помочь. Если это не сработает, включите forest search order на ad.local домен также может помочь.
В противном случае я рекомендую выполнить трассировку сети (Wireshark) на клиентском компьютере и наблюдать за трафиком, когда он пытается связаться с контроллерами домена.