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.
Best Answer
It was indeed due to the activation of the DES support in AD. This actually override any other cipher algorithms.
So disabling it on the service account made the negociation works in AES256.