Я отправляю новую ветку по этой проблеме, потому что все решения, которые я нашел здесь, не помогли мне.
Я пытаюсь настроить apache2 для аутентификации с помощью Kerberos на сервере AD2012 с помощью keytab.
Сначала я активировал все шифрования, какие мог, в AD msDS-EncryptedSupportedTypes
Это мой клиент (debian) krb5.conf
:
[logging]
default = FILE:/var/log/krb5.log
[libdefaults]
default_realm = REALM.LOCAL
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true
# for testing purpose only
allow_weak_crypto = true
default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5
[realms]
REALM.LOCAL = {
kdc = kdc.realm.local
admin_server = kdc.realm.local
default_domain = realm.local
}
[domain_realm]
.realm.local = REALM.local
realm.local = REALM.LOCAL
Вот таблица ключей, которую я использую:
klist -kte /etc/apache2/http.keytab[1234 visible Если я использую keytab для аутентификации с помощью KDC, все работает нормально:
kinit -Vkt /etc/apache2/http.keytab HTTP / server.realm. local
Authenticated to kerberos v5
klist -e
Ticket cache: FILE:/tmp/krb5cc_0 Default principal: HTTP/server.realm.local@REALM.LOCAL Valid starting 06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/REALM.LOCALS@REALM.LOCAL renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Сейчас я настраиваю
.htaccess
для проверки аутентификации следующим образом:AuthType Kerberos AuthName "Kerberos Login" KrbAuthRealm REALM.LOCAL Krb5KeyTab /etc/apache2/http.keytab KrbServiceName HTTP/server.realm.local Require valid-user
Добавьте, когда я пытался аутентифицироваться, у меня есть это в журналах:
m пытается настроить apache2 для аутентификации с помощью Kerberos на сервере AD2012 через keytab.Сначала я активировал все шифрования, какие мог, в AD
msDS-EncryptedSupportedTypes
Это мой клиент (debian)
krb5.conf
:[logging] default = FILE:/var/log/krb5.log [libdefaults] default_realm = REALM.LOCAL kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true # for testing purpose only allow_weak_crypto = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 [realms] REALM.LOCAL = { kdc = kdc.realm.local admin_server = kdc.realm.local default_domain = realm.local } [domain_realm] .realm.local = REALM.local realm.local = REALM.LOCAL
Вот таблица ключей, которую я использую:
klist -kte /etc/apache2/http.keytab[1234 visible Если я использую keytab для аутентификации с помощью KDC, все работает нормально:
kinit -Vkt /etc/apache2/http.keytab HTTP / server.realm. local
Authenticated to kerberos v5
klist -e
Ticket cache: FILE:/tmp/krb5cc_0 Default principal: HTTP/server.realm.local@REALM.LOCAL Valid starting 06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/REALM.LOCALS@REALM.LOCAL renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Сейчас я настраиваю
.htaccess
для проверки аутентификации следующим образом:AuthType Kerberos AuthName "Kerberos Login" KrbAuthRealm REALM.LOCAL Krb5KeyTab /etc/apache2/http.keytab KrbServiceName HTTP/server.realm.local Require valid-user
Добавьте, когда я пытался аутентифицироваться, у меня есть это в журналах:
m пытается настроить apache2 для аутентификации с помощью Kerberos на сервере AD2012 через keytab.Сначала я активировал все шифрования, какие мог, в AD
msDS-EncryptedSupportedTypes
Это мой клиент (debian)
krb5.conf
:[logging] default = FILE:/var/log/krb5.log [libdefaults] default_realm = REALM.LOCAL kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true # for testing purpose only allow_weak_crypto = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 [realms] REALM.LOCAL = { kdc = kdc.realm.local admin_server = kdc.realm.local default_domain = realm.local } [domain_realm] .realm.local = REALM.local realm.local = REALM.LOCAL
Вот таблица ключей, которую я использую:
klist -kte /etc/apache2/http.keytab
Keytab name: FILE:/etc/apache2/http.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------------- 14 01/01/1970 01:00:00 HTTP/server.realm.local@REALM.LOCAL (des-cbc-crc) 14 01/01/1970 01:00:00 HTTP/server.realm.local@REALM.LOCALS (des-cbc-md5) 14 01/01/1970 01:00:00 HTTP/server.realm.local@REALM.LOCAL (arcfour-hmac) 14 01/01/1970 01:00:00 HTTP/server.realm.local@REALM.LOCAL (aes256-cts-hmac-sha1-96) 14 01/01/1970 01:00:00 HTTP/server.realm.local@REALM.LOCAL (aes128-cts-hmac-sha1-96)
Если я использую keytab для аутентификации с помощью KDC, все работает нормально:
kinit -Vkt /etc/apache2/http.keytab HTTP / server.realm. local
Authenticated to kerberos v5
klist -e
Ticket cache: FILE:/tmp/krb5cc_0 Default principal: HTTP/server.realm.local@REALM.LOCAL Valid starting 06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/REALM.LOCALS@REALM.LOCAL renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
Сейчас я настраиваю
.htaccess
для проверки аутентификации следующим образом:AuthType Kerberos AuthName "Kerberos Login" KrbAuthRealm REALM.LOCAL Krb5KeyTab /etc/apache2/http.keytab KrbServiceName HTTP/server.realm.local Require valid-user
Добавьте, когда я пытался аутентифицироваться, у меня есть это в журналах:
[debug] src / mod_auth_kerb.c (1939): [клиент 192.168.4.16] kerb_authenticate_user введен с пользователем (NULL) и auth_type Kerberos
[debug] src / mod_auth_kerb.c (1691): [client 192.168.4.16] Проверка данных клиента с помощью KRB5 GSS-API
[debug] src / mod_auth_kerb.c (1707): [client 192.168.4.16] Клиент не делегировал нам свои учетные данные
[debug] src / mod_auth_kerb.c (1735): [client 192.168.4.16] Предупреждение: похоже, полученный токен является NTLM, который не поддерживается модулем Kerberos. Проверьте конфигурацию вашего IE.
[отладка] src / mod_auth_kerb.c (1138): [клиент 192.168.4.16] GSS-API major_status: 00010000, minor_status: 00000000
[ошибка] [клиент 192.168.4.16] gss_accept_sec_context () не удалось: был запрошен неподдерживаемый механизм (, неизвестная ошибка)
Сетевая трассировка показала мне, что тело
TGS_REQ
зашифровано в AES256 как а также TGT вPA-DATA
. Но в ответ я получилKRB5KDC_ERR_ETYPE_NOSUPP
.Если я аутентифицирую службу вручную, я получаю следующее:
kinit username
knvo HTTP / server.realm.local@REALM.LOCAL
klist -e
Valid starting 06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/REALM.LOCAL@REALM.LOCAL renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 06/04/2017 20:35:00 07/04/2017 06:32:09 HTTP/server.realm.local@REALM.LOCAL renew until 07/04/2017 20:32:08, Etype (skey, tkt): des-cbc-crc, des-cbc-md5
Я понятия не имею, где Шифрование DES происходит из.
Есть какие-нибудь идеи о том, что может быть не так? Как я могу продолжить свои исследования?
ОБНОВЛЕНИЕ: Теперь я подозреваю, что учетная запись службы AD с поддержкой DES. Насколько я читал, это может отключить любой другой алгоритм шифрования. У меня нет доступа к AD, поэтому сейчас не могу протестировать.
Это действительно произошло из-за активации поддержки DES в AD. Это фактически отменяет любые другие алгоритмы шифрования.
Таким образом, отключение этого параметра в учетной записи службы заставило согласование работать в AES256.