Mailing List Archive

Setting a new keytab file from windows DC made kerberos work! But still
something missing!

With KrbMethodK5Passwd=off users should open protected page without
credentials prompt , this is true for my user (cedtm), but the other users
can't.

Setting KrbMethodK5Passwd=on, my user still open the page without prompt
but other users, correctly, get the credential pop-up.

Here is a the apache error.log, connencting with different users to the
same client

SET KrbMethodK5Passwd off:
utente@intranet:~$ tail /var/log/apache2/https443_error.log -f | grep kerb
user test - get error:
[auth_kerb:debug] [pid 43964] src/mod_auth_kerb.c(1963): [client
172.16.3.101:63038] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
user cedtm - works:
[auth_kerb:debug] [pid 43966] src/mod_auth_kerb.c(1963): [client
172.16.3.101:63099] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[auth_kerb:debug] [pid 43966] src/mod_auth_kerb.c(1963): [client
172.16.3.101:63099] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[auth_kerb:debug] [pid 43966] src/mod_auth_kerb.c(1296): [client
172.16.3.101:63099] Acquiring creds for HTTP@intranet.zzz.it
[auth_kerb:debug] [pid 43966] src/mod_auth_kerb.c(1719): [client
172.16.3.101:63099] Verifying client data using KRB5 GSS-API with our
SPNEGO lib
[auth_kerb:debug] [pid 43966] src/mod_auth_kerb.c(1735): [client
172.16.3.101:63099] Client didn't delegate us their credential
[auth_kerb:debug] [pid 43966] src/mod_auth_kerb.c(1754): [client
172.16.3.101:63099] GSS-API token of length 185 bytes will be sent back
[auth_kerb:debug] [pid 43966] src/mod_auth_kerb.c(1869): [client
172.16.3.101:63099] kerb_authenticate_a_name_to_local_name cedtm@XXX.LOCAL
-> cedtm


SET KrbMethodK5Passwd on:
utente@intranet:~$ tail /var/log/apache2/https443_error.log -f | grep kerb
user test - get access entering user and password
[auth_kerb:debug] [pid 44010] src/mod_auth_kerb.c(1963): [client
172.16.3.101:63290] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[auth_kerb:debug] [pid 44014] src/mod_auth_kerb.c(1963): [client
172.16.3.101:63289] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[auth_kerb:debug] [pid 44014] src/mod_auth_kerb.c(1046): [client
172.16.3.101:63289] Using HTTP/intranet.zzz.it@XXX.LOCAL as server
principal for password verification
[auth_kerb:debug] [pid 44014] src/mod_auth_kerb.c(752): [client
172.16.3.101:63289] Trying to get TGT for user test@XXX.LOCAL
[auth_kerb:debug] [pid 44014] src/mod_auth_kerb.c(662): [client
172.16.3.101:63289] Trying to verify authenticity of KDC using principal
HTTP/intranet.zzz.it@XXX.LOCAL
[auth_kerb:debug] [pid 44014] src/mod_auth_kerb.c(1128): [client
172.16.3.101:63289] kerb_authenticate_user_krb5pwd ret=0 user=test@XXX.LOCAL
authtype=Basic
[auth_kerb:debug] [pid 44014] src/mod_auth_kerb.c(1869): [client
172.16.3.101:63289] kerb_authenticate_a_name_to_local_name test@XXX.LOCAL
-> test
user cedtm - get access directly
[auth_kerb:debug] [pid 44011] src/mod_auth_kerb.c(1963): [client
172.16.3.101:63368] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[auth_kerb:debug] [pid 44011] src/mod_auth_kerb.c(1963): [client
172.16.3.101:63368] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[auth_kerb:debug] [pid 44011] src/mod_auth_kerb.c(1296): [client
172.16.3.101:63368] Acquiring creds for HTTP@intranet.zzz.it
[auth_kerb:debug] [pid 44011] src/mod_auth_kerb.c(1719): [client
172.16.3.101:63368] Verifying client data using KRB5 GSS-API with our
SPNEGO lib
[auth_kerb:debug] [pid 44011] src/mod_auth_kerb.c(1735): [client
172.16.3.101:63368] Client didn't delegate us their credential
[auth_kerb:debug] [pid 44011] src/mod_auth_kerb.c(1754): [client
172.16.3.101:63368] GSS-API token of length 185 bytes will be sent back
[auth_kerb:debug] [pid 44011] src/mod_auth_kerb.c(1869): [client
172.16.3.101:63368] kerb_authenticate_a_name_to_local_name cedtm@XXX.LOCAL
-> cedtm

I don't understand why the user "cedtm" has always SSO granted, while the
user "test" gets error with KrbMethodK5Passwd=off, looks like "test" miss
something, how could i check for this?
And why "cedtm" get SSO acces even if KrbMethodK5Passwd is "on"?

Thanks again. Marco