我在这个问题上发布一个新的线程，因为我在这里find的所有解决scheme都不适合我。
我试图configuration一个apache2通过keytab在AD2012服务器上使用Kerberos进行身份validation。
首先，我激活了AD中的所有encryptionmsDS-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
这是我使用的keytab：
klist -kte /etc/apache2/http.keytab
Keytab name: FILE:/etc/apache2/http.keytab KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------------- 14 01/01/1970 01:00:00 HTTP/[email protected] (des-cbc-crc) 14 01/01/1970 01:00:00 HTTP/[email protected] (des-cbc-md5) 14 01/01/1970 01:00:00 HTTP/[email protected] (arcfour-hmac) 14 01/01/1970 01:00:00 HTTP/[email protected] (aes256-cts-hmac-sha1-96) 14 01/01/1970 01:00:00 HTTP/[email protected] (aes128-cts-hmac-sha1-96)
如果我使用keytab来authenticationKDC，一切工作正常：
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/[email protected] Valid starting 06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/[email protected] renew until 07/04/2017 20:32:08, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
我现在configuration一个.htaccess来testing这个authentication：
AuthType Kerberos AuthName "Kerberos Login" KrbAuthRealm REALM.LOCAL Krb5KeyTab /etc/apache2/http.keytab KrbServiceName HTTP/server.realm.local Require valid-user
添加时，我试图validation我有这在日志中：
[debug] src / mod_auth_kerb.c（1939）：[client 192.168.4.16] kerb_authenticate_user with user（NULL）and auth_type Kerberos
[debug] src / mod_auth_kerb.c（1691）：[client 192.168.4.16]使用KRB5 GSS-APIvalidation客户端数据
[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模块不支持。 检查你的IEconfiguration。
[debug] src / mod_auth_kerb.c（1138）：[client 192.168.4.16] GSS-API major_status：00010000，minor_status：00000000
[error] [client 192.168.4.16] gss_accept_sec_context（）失败：请求了不支持的机制（，未知错误）
networking跟踪显示TGS_REQ主体在AES256中被encryption，在PA-DATA被TGTencryption。 但我接受KRB5KDC_ERR_ETYPE_NOSUPP作为回应。
如果我手动authentication服务，我得到这个：
kinit用户名
knvo HTTP/[email protected]
klist -e
Valid starting 06/04/2017 20:32:09 07/04/2017 06:32:09 krbtgt/[email protected] 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/[email protected] renew until 07/04/2017 20:32:08, Etype (skey, tkt): des-cbc-crc, des-cbc-md5
我不知道DESencryption来自哪里。
任何关于什么可能是错误的见解？ 我怎样才能进一步调查？
更新：我现在怀疑与DES支持AD服务帐户。 对于我读的它可能禁用任何其他密码algorithm。 我没有进入广告，所以现在不能testing。
这确实是由于在AD中激活了DES支持。 这实际上覆盖了其他的密码algorithm。
所以在服务帐户上禁用它使得AES256中的协议起作用。