Аутентификация 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

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

Добавьте, когда я пытался аутентифицироваться, у меня есть это в журналах:

[отладка] src / mod_auth_kerb.c (1939): [клиент 192.168.4.16] kerb_authenticate_user введен с пользователем (NULL) и auth_type Kerberos

[отладка] src / mod_auth_kerb.c (1691): [клиент 192.168.4.16] Проверка данных клиента с помощью KRB5 GSS-API

[отладка] src / mod_auth_kerb.c (1707): [клиент 192.168.4.16] Клиент не делегировал нам свои учетные данные

[отладка] src / mod_auth_kerb.c (1735): [клиент 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 имя пользователя

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