Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Before I blindly jump on "trial an error" tests, I'd like to ask some general questions on Kerberos Authentication for Webservers. I want to evaluate what's possible with Kerberos. The main benefit would, of course, be Single-Sign-On. But it might also be an appropriate alternative to LDAP Authentication etc. (and luckily our Active Directory already includes a Kerberos KDC). Help, hints and discussion are most welcome!

I'd like to discuss a rather complex setup to find the limitations: MS Browser -> Linux Squid Proxy -> (Linux httpd Reverse-Proxy) -> Linux httpd Webserver

1) As far as I understood, both Webserver and Browser need a permanent connection to the KDC to obtain and verify Authentication Tickets, right?

2) Our KDC is accessible only on our internal network. Does that mean that no clients from outside our network would ever be able to authenticate on our websites? If so, would it then be possible to place a reverse-proxy in our network (with access to our KDC) to obtain Kerberos Tickets in behalf of the browser? Could the webserver himself obtain a Ticket in behalf of the browser? And would that be an appropriate workaround? Should I rather use a fallback ldap authentication to handle external clients (the LDAP Server only needs to be available to the Webserver and not the Browser)?

3) How does kerberos work when proxies (normal forward-proxies such as squid) are used? Does the Proxy obtain Tickets in behalf of the Browser? Is there some sort of passthrough mechanism I could use? Do I actually need to change anything on my proxy to prevent it breaking kerberos auth? I found a lot of HOWTOs on the Internet, but non of them stated clearly whether they allow general access to the proxy or access to a website behind the proxy.

I'll probalby pop into some more questions, but I think it might be a good starting point to gain some insight into Ticket based Authentication.

Thanx in advance!

share|improve this question
up vote 2 down vote accepted

To answer your questions,

  1. Yes, webserver and Browser/client need to connect to the KDC to verify the tickets. You must do a kinit/domain login to get TGT and further the webbrowser will get a HTTP service ticket to access the webserver.

  2. Exposing kerberos/domaincontroller on internet is not a good practice. Try using webauth.

  3. I do not understand what you intended to do with proxy, but you could get a proxiable ticket from kerberos and use it based on your need.

Firefox already supports gss-api negotiate methods. All you have to do is do a kinit and configure the negotiate-auth in about:config and access your web page. If you are using apache check mod_auth_kerb. Lighttpd also has some kerberos support.

share|improve this answer
My company struggled a lot trying to implement the "Sun Java System Access Manager" for single sign on - without much luck. So I'd very much prefer a solution without any thirdparty products. For now I just want to find some answers on Kerberos, because we already have the infrastructure. Unluckily most of the tutorials on the web assume an environment where everything is accessable to anyone. – DonEstefan Oct 22 '10 at 15:48
Thanks for your answer.My intention with the proxy is like this: We host a webapplication in our DMZ. The internal Network has to go through a proxy (squid) to access this application. Squid needs authentication to be used. The webapplication also needs Authentication to be used. External Visitors can access that website through a apache-reverse-proxy. I just wanted to find out which parts of that scenario can be managed using Kerberos. – DonEstefan Nov 15 '10 at 20:08
We also noticed that older squid versions made ntlm authentication impossible, because the authentication needed a http header that squid wasn't able to handle correctly. I wanted to know if I need to expect a similar behaviour when using kerberos. We don't want squid to confuse the different users or to make login attempts impossible ;) – DonEstefan Nov 15 '10 at 20:51
Regarding to my question 1) - Reading I realized that there is no simple answer. 1a) Usually the client needs a permanent connection to the KDC. The Server only needs a single, initial connection to the KDC (kinit?) - to create a static long-term secret used to verify all client tickets created by the same KDC. 1b) when using "ticket delegation" the webserver also needs a permanent connection to the KDC. 1c) when using "Protocol transition" only the server needs a permanent connection to the KDC. Let me know when I'm wrong – DonEstefan Nov 15 '10 at 21:35
Just to clarify, hear permanent connection means connection required only when authentication happens but not all the time. Server needs a single initial connection means, you will extract the keytab for your service principal and keep it in your server where application is running. For protocol transision, your client and service needs to contact kerberos. I do not see a need for a protocol transition here. Its used if service1 has to access service2 on behalf of the user. – kalyan Nov 16 '10 at 4:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.