I post a new thread on this problem because all the solution I found here didn't work for me.
I'm trying to configure an apache2 to authenticate with Kerberos on a AD2012 server via a keytab.
First I activated all encryptions I could in the AD msDS-EncryptedSupportedTypes
This is my client (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
Here is the keytab I use :
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)
If I use the keytab to authenticate with the KDC everything works fine :
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
I configure now a .htaccess
to test the authentification like this :
AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm REALM.LOCAL
Krb5KeyTab /etc/apache2/http.keytab
KrbServiceName HTTP/server.realm.local
Require valid-user
Add when I tried to authenticate I have this in the logs :
[debug] src/mod_auth_kerb.c(1939): [client 192.168.4.16] kerb_authenticate_user entered with user (NULL) and auth_type Kerberos
[debug] src/mod_auth_kerb.c(1691): [client 192.168.4.16] Verifying client data using KRB5 GSS-API
[debug] src/mod_auth_kerb.c(1707): [client 192.168.4.16] Client didn't delegate us their credential
[debug] src/mod_auth_kerb.c(1735): [client 192.168.4.16] Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration.
[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() failed: An unsupported mechanism was requested (, Unknown error)
A network trace showed me that the TGS_REQ
body is encrypted in AES256 as well as the TGT in the PA-DATA
. But I receveive KRB5KDC_ERR_ETYPE_NOSUPP
in response.
If I authenticate manually for the service, I obtain this :
kinit username
kvno 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
I have no idea where the DES encryption comes from.
Any insights about what might be wrong ? How can I go further in my investigations ?
UPDATE: I'm now suspecting the AD service account with the DES support. For what I read it may disable any other cipher algorithm. I don't have access to the AD so cannot test right now.