This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Web Proxy: Key table entry not found

For whatever reason, certain hosts can no longer access the web through the Astaro web proxy in SSO under Active Directory due to the following error:

[FONT="Courier New"]httpproxy[9752]: [ 0x88cd510] adir_auth_process_negotiate (auth_adir.c:311) gss_accept_sec_context: Key table entry not found [/FONT]

Anyone?  I have put an authentication bypass in place for the affected hosts.  I have reset the computer accounts in AD and re-joined them to the domain.


This thread was automatically locked due to age.
  • Try using the IP for the proxy setting in IE; this forces the SSO authentication to use NTLM instead of Kerberos; in our case, while Astaro figures out the Kerberos issue, this made it work.  If your problem sounds like ours, I highly recommend that you start a case with Astaro support so they can chase this problem down.


    Ding, Ding!

    WE HAVE A WINNER!

    Thanks, man.
  • Follow Bruce's advice on this one.  he's most likely been much more in depth with this issue right now than i..[:)]
  • Hey pneumatic, you're welcome. If your system is running a commercial license with maintenance, do please take a few minutes to start a case with Astaro; so far my Customer is the only reported case that is working like this, it'll probably help them (Astaro) figure out the Kerberos issue if they can collect data about your instance of the problem as well.  If they want to link the cases together, PM me for the case number I have open.
  • I'm not commercial yet but I will be soon.
  • Hey pneumatic, you're welcome. If your system is running a commercial license with maintenance, do please take a few minutes to start a case with Astaro; so far my Customer is the only reported case that is working like this, it'll probably help them (Astaro) figure out the Kerberos issue if they can collect data about your instance of the problem as well.  If they want to link the cases together, PM me for the case number I have open.


    hey bruce.  have you tried removing the AD sso form the astaro..rebooting..and then rejoining the astaro via authentication section?  If hte key has become corrupted on the astaro this is going to be the only way to rebuild it easily.
  • Taking a gander at what this error means it means the kerebros daemon on the astaro doesn't have the user credentials available.  I bet because somehow the key(s) became corrupted.  I would try removing the AD information from the astaro..reboot..and then rejoin.  This will fully rebuild the kerebros keytable(s) on the astaro and should rectify this issue.
  • I went so far as to do all of this including deletion of /etc/krb5.keytab (just to make sure that it would be regenerated) and it did not resolve the issue.
  • I went so far as to do all of this including deletion of /etc/krb5.keytab (just to make sure that it would be regenerated) and it did not resolve the issue.


    no you need to fully remove the configuration from astaro and reboot so you clear all the configurations..then try again.  Simply removing the kerberos file isn't enough.
  • Just an update on this issue:

    William, no, removing the ASG from the domain and re-adding it makes no difference in this case (first thing I tried, anyway)...

    There is no corruption of the key tables, either; here's the answer:

    Astaro support found that some clients were triggering Kerberos to look for uppercase spellings of the AD domain; they have yet to be able to explain why / how... but this was triggering the failure.  They went in and manually created uppercase entries that matched the lowercase entries, and thus far, the customer's problem is solved.  I don't know if they plan to add a fix that would just automatically create the uppercase entries, but that would be one way to fix it.

    They used kutil  ktutil(8) - Linux man page  to manipulate the file.   Be warned that using this without Astaro Support's blessing may result in voided warranties / support and / or downtime.
  • Interesting..glad that worked out.  I'll keep that one in mind.