2

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/[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)

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/[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

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/[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

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.

2
  • the command is kvno, not knvo Jun 24, 2021 at 14:34
  • good catch, updated
    – Plup
    Jul 15, 2021 at 15:34

1 Answer 1

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .