Web Proxy: Key table entry not found

We are seeing this on more and more systems as of late. All of a sudden kerberos SSO stop working for random PCs.  Every time I report the bug to support they give me a blow off answer. 

While I understand that using IP address in the proxy settings works to falls back to NTLMv2; I would prefer that they fix the kerberos implementation so that it works after all that's what the customers are paying for, the less NTLM running around the network the better and the less downgrading of NTLM security levels and anonymous SID translations I need to turn on.

When we have this problem on 30% of our units; this is not longer a small issue.

Interesting on really old boxes that I've had around since 7.01 there isn't even a krb5.conf  krb5.keytab present.

I guess it's time to file a bug report again.

Hi all,

here still the same problem with UTM 9.004034.

Our active directory domain has two win2003 DCs and two win2008 R2 DCs (domain functional level 2003).
We are migrating our production ASG v8 to a new UTM 9 and we are falling in the same
problem regarding this thread.

The windows clients (windows7 in this case) can surf using the new UTM 9 proxy for a while until they get authorization failed.
In the /var/log/http.log I found this message:

2013:01:15-13:01:47 PROXY01 httpproxy[22875]: id="0003" severity="info" sys="SecureWeb" sub="http" request="0x14a69590" function="adir_auth_proce
ss_negotiate" file="auth_adir.c" line="1076" message="gss_accept_sec_context: Key table entry not found"

The only way to enable the users to surf again is to reboot the client pc.
I notice also that there are not credentials on the cache:

PROXY01:/root # klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)


Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Another workaround is to specify the proxy using the IP address but I'd like to use Kerberos instead of NTLM....

Is there a way to definetively solve this problem?

Have a look at my post in this thread, post #20 https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/p/44463/158615#158615  ...  I bet that will help.

In every scenario I've had where kerberos authentication fails randomly for certain clients, etc. adding lower or upper-cased entries to the key table file for the proxy has fixed it.  No one has been able to explain the root cause of why this happens, but it does.  I've encouraged Support to add a bugfix to just create them automatically when joining a domain, but I don't think they ever submitted my request, or, because it's not an easily repeatable issue, they discarded it possibly.

Note that it seems to be somewhat rare, as I have only 1 customer currently that this is an issue for... 

Note that if you make such changes, they are not persistent across all firmware up2dates; from time to time I've had a firmware up2date that updates some aspect of AD SSO break this, which is easily fixed by going back and re-adding the upper (or lower, as the case may be) case entries to the key table file.  Major firmware updates certainly break this the majority of the time.

Have a look at my post in this thread, post #20 https://community.sophos.com/products/unified-threat-management/astaroorg/f/55/p/44463/158615#158615  ...  I bet that will help.

In every scenario I've had where kerberos authentication fails randomly for certain clients, etc. adding lower or upper-cased entries to the key table file for the proxy has fixed it.  No one has been able to explain the root cause of why this happens, but it does.  I've encouraged Support to add a bugfix to just create them automatically when joining a domain, but I don't think they ever submitted my request, or, because it's not an easily repeatable issue, they discarded it possibly.

Note that it seems to be somewhat rare, as I have only 1 customer currently that this is an issue for... 

Note that if you make such changes, they are not persistent across all firmware up2dates; from time to time I've had a firmware up2date that updates some aspect of AD SSO break this, which is easily fixed by going back and re-adding the upper (or lower, as the case may be) case entries to the key table file.  Major firmware updates certainly break this the majority of the time.