Проверка подлинности 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

список -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): [клиент 192.168.4.16] Проверка данных клиента с использованием GSS-API KRB5

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

[debug] src/mod_auth_kerb.c(1735): [клиент 192.168.4.16] Предупреждение: полученным токеном является NTLM, который не поддерживается модулем Kerberos. Проверьте свою конфигурацию IE.

[debug] 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

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