Аутентификация Apache Kerberos: KDC не поддерживает тип шифрования

Я отправляю новую ветку по этой проблеме, потому что все решения, которые я нашел здесь, не помогли мне.

Я пытаюсь настроить 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, поэтому сейчас не могу протестировать.

2
задан 7 April 2017 в 06:32
1 ответ

Это действительно произошло из-за активации поддержки DES в AD. Это фактически отменяет любые другие алгоритмы шифрования.

Таким образом, отключение этого параметра в учетной записи службы заставило согласование работать в AES256.

1
ответ дан 3 December 2019 в 12:36

Теги

Похожие вопросы