Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 1 reply
  • Subscribers 2 subscribers
  • Views 6002 views
  • Users 0 members are here
Options
Suggested
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

Kerberos not working for ONE user. How can I fix "Key table entry not found"?

Someone7272

function="adir_auth_process_negotiate" file="auth_adir.c" line="1600" message="gss_accept_sec_context: Key table entry not found"

This problem has been badly affecting one machine resulting in "Authentication failed" messages every time a user logged onto this machine attempts to browse the web. The machine in question has been able to use the web successfully up until recently.

We're using a home UTM9 license, and I've tried everything, from flushing the authentication cache, unjoining/rejoining the domain and even a factory reset. Also, on the Authentication Server page, both the server settings and example user tests pass successfully.

The web proxy is operating in standard mode, and settings are delivered using wpad.dat.

Looking around, I found several discussions about the same issue, but they did not help me to resolve the problem.

This is obviously some kind of problem with the transparent domain user authentication, but it's working fine for all other users.

Does know how to fix this?

EDIT: The UTM is running on VMware Workstation. And it's at version 9.404-5.



This thread was automatically locked due to age.
Parents
  • 0

    I think I found the problem...

    I used klist to check the Kerberos tickets the problematic machine is using for proxy authentication.

    When Internet Explorer is used, it uses an incorrect Kerberos ticket that looks like this:

    Client: [username] @ DOMAIN.LOCAL
    Server: HTTP/[UTMNAME].DOMAIN.LOCAL @ DOMAIN.LOCAL

    And when Firefox is used, it uses the correct Kerberos ticket that looks like this:

    Client: [username] @ DOMAIN.LOCAL
    Server: HTTP/[utmname].domain.local @ DOMAIN.LOCAL

    Notice that when IE is used, the UTM's FQDN is specified in CAPITALS, which is causing Kerberos authentication to fail. Whereas Firefox specifies the correct, lowercase UTM FQDN which authenticates successfully.

    The WPAD file specifies the proxy FQDN in lowercase, so why is Internet Explorer attempting to negotiate with ALLCAPS? All other machines on the network (even with Internet Explorer) don't have this problem.

Reply
  • 0

    I think I found the problem...

    I used klist to check the Kerberos tickets the problematic machine is using for proxy authentication.

    When Internet Explorer is used, it uses an incorrect Kerberos ticket that looks like this:

    Client: [username] @ DOMAIN.LOCAL
    Server: HTTP/[UTMNAME].DOMAIN.LOCAL @ DOMAIN.LOCAL

    And when Firefox is used, it uses the correct Kerberos ticket that looks like this:

    Client: [username] @ DOMAIN.LOCAL
    Server: HTTP/[utmname].domain.local @ DOMAIN.LOCAL

    Notice that when IE is used, the UTM's FQDN is specified in CAPITALS, which is causing Kerberos authentication to fail. Whereas Firefox specifies the correct, lowercase UTM FQDN which authenticates successfully.

    The WPAD file specifies the proxy FQDN in lowercase, so why is Internet Explorer attempting to negotiate with ALLCAPS? All other machines on the network (even with Internet Explorer) don't have this problem.

Children
No Data
Unfiltered HTML