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 the support email excerpt below; this is the info I used from support way back when to address the upper-case / lower-case kerberos issue:  note that I assume no liability for damaged systems, etc. if you try this on your installation -- use with caution -- and note that making such changes without the blessing of official Sophos Support (if you are on a commercial license) may void your support agreement -- if you do have official support, see if they can pull up the original Astaro Support ticket that I worked originally for more info, maybe that will help them along ... the case info:  Ticket#2010020610000181] CaseID 00115705 -- this dates back to March 2010:

-------------------------------------

To add entries to the keytable, you can do the following:

net ads keytab add $ENTRY -U username%password

In the command, $ENTRY has to be one of the following (and you'll need to add each
one):
host/FQDN@domain
host/hostname@domain
hostname@domain
HTTP/FQDN@domain
HTTP/hostname@domain

To see your keytab, you can run the following commands:
ktutil (this will switch to a different shell) read_kt /etc/krb5.keytab list q (to quit)

Here is an example of my testlab keytab file:
   1    4 host/dot10.ad2.testastaro.com@AD2.TESTASTARO.COM
   2    4 host/dot10.ad2.testastaro.com@AD2.TESTASTARO.COM
   3    4 host/dot10.ad2.testastaro.com@AD2.TESTASTARO.COM
   4    4            host/dot10@AD2.TESTASTARO.COM
   5    4            host/dot10@AD2.TESTASTARO.COM
   6    4            host/dot10@AD2.TESTASTARO.COM
   7    4                DOT10$@AD2.TESTASTARO.COM
   8    4                DOT10$@AD2.TESTASTARO.COM
   9    4                DOT10$@AD2.TESTASTARO.COM
  10    4 HTTP/dot10.ad2.testastaro.com@AD2.TESTASTARO.COM
  11    4 HTTP/dot10.ad2.testastaro.com@AD2.TESTASTARO.COM
  12    4 HTTP/dot10.ad2.testastaro.com@AD2.TESTASTARO.COM
  13    4            HTTP/dot10@AD2.TESTASTARO.COM
  14    4            HTTP/dot10@AD2.TESTASTARO.COM
  15    4            HTTP/dot10@AD2.TESTASTARO.COM

Bruce, I always do the join with upper case. Do you know if that avoids the problem?

Cheers - Bob

Sorry for any short responses!  Posted from my iPhone.

I know at the customer site that the ticket info above came from, we tried it both ways.  For some reason, some clients were using a different case for the authentication request... and it also became random.  No one I have ever talked to (whether a Windoze guru -- and I'm pretty well versed in Windoze-- or Winbind guru) has been able to explain it.

Many thanks Bruce,

I try all your suggestions but without success :-(
So I try to remove the AD configuration and rename the UTM using only lower-case chars.
I used upper-case only in the Single-Sing-On step for the domain name (DOMAIN.LOCAL).
Now it works but I don't know until when.
This is the keytab sistuation now:

proxy:/root # net ads keytab list
Vno  Type        Principal
  2  DES cbc mode with CRC-32            HTTP/proxy.domain.local@DOMAIN.LOCAL
  2  DES cbc mode with RSA-MD5           HTTP/proxy.domain.local@DOMAIN.LOCAL
  2  ArcFour with HMAC/md5               HTTP/proxy.domain.local@DOMAIN.LOCAL
  2  DES cbc mode with CRC-32            host/proxy.domain.local@DOMAIN.LOCAL
  2  DES cbc mode with RSA-MD5           host/proxy.domain.local@DOMAIN.LOCAL
  2  ArcFour with HMAC/md5               host/proxy.domain.local@DOMAIN.LOCAL
  2  DES cbc mode with CRC-32            HTTP/proxy@DOMAIN.LOCAL
  2  DES cbc mode with RSA-MD5           HTTP/proxy@DOMAIN.LOCAL
  2  ArcFour with HMAC/md5               HTTP/proxy@DOMAIN.LOCAL
  2  DES cbc mode with CRC-32            host/proxy@DOMAIN.LOCAL
  2  DES cbc mode with RSA-MD5           host/proxy@DOMAIN.LOCAL
  2  ArcFour with HMAC/md5               host/proxy@DOMAIN.LOCAL


proxy:/usr/lib/mit/sbin # ./ktutil
ktutil:  read_kt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    2 HTTP/proxy.domain.local@DOMAIN.LOCAL
   2    2 HTTP/proxy.domain.local@DOMAIN.LOCAL
   3    2 HTTP/proxy.domain.local@DOMAIN.LOCAL
   4    2 host/proxy.domain.local@DOMAIN.LOCAL
   5    2 host/proxy.domain.local@DOMAIN.LOCAL
   6    2 host/proxy.domain.local@DOMAIN.LOCAL
   7    2               HTTP/proxy@DOMAIN.LOCAL
   8    2               HTTP/proxy@DOMAIN.LOCAL
   9    2               HTTP/proxy@DOMAIN.LOCAL
  10    2               host/proxy@DOMAIN.LOCAL
  11    2               host/proxy@DOMAIN.LOCAL
  12    2               host/proxy@DOMAIN.LOCAL

As you can see it lacks of the three entries PROXY@DOMAIN.LOCAL but it works.
I let you know if the sistuation remains stable.

Bye.

Hi all,

I can confirm...after the rejoin with UTM name in lower-case all ok until now.
So my conclusion: use always lower-case on the UTM name.

Bye.