Kerberos/Browser Support

From Authentication Tools for Joomla! (JAuthTools)

Jump to: navigation, search

Most browsers have no issues, this page documents issues with specific browsers. Failed browsers typically revert to Basic authentication and challenge the user for a password. Browser may have failed due to configuration issues however where possible this variable has been removed. Where possible all testing is done in the same environment but potentially different machines, though this may not hold true of all platforms.


Internet Explorer

Internet Explorer has its ups and its downs. Some versions of IE will work perfectly yet others may not.

Tested working versions:

  • Internet Explorer 7.0.5730.13 on Windows XP SP2
  • Internet Explorer 6.0.2900.2180.xpsp_sp2_gdr.080814-1233 on Windows XP SP2
  • Internet Explorer 6.0.2900.2180.xpsp_sp2_gdr.050301-1519 on Windows XP SP2
  • Internet Explorer 7.0.6001.18000 on Windows Vista SP1

Tested failed browsers:

  • Internet Explorer 7.0.5730.13 on Windows XP SP2 (possible configuration error)
  • Internet Explorer 6.0.3790.3959 on Windows Server 2003 SP2 Standard Edition

Possible conflicting factors:

  • Novell client software seems to modify systems and cause issues of their own. The test environment for IE is a shared AD/Novell environment (joined by Novell IDM).

Other Notes

  • In one of my test non-domain joined virtual machines I installed IE7 to receive an error about intranet settings being turned off however when I looked at the particular area they were on. Enabling them from the information bar had the effect that "automatically detect intranet network" was unticked though the three child options were ticked.

Text below copyright Microsoft Corporation. Used under fair use provisions for education purposes.

  • Intranet settings are now disabled in Internet Explorer by default. Click for more options. information bar notice

Internet Explorer detected an intranet webpage address, but intranet address checking is not on. Click the Information bar for more information or see What do I need to know about intranet security settings?
If you are connected to an intranet but receive an Information bar notice that an intranet address has been detected, it means that Internet Explorer did not automatically detect your intranet. To tell Internet Explorer that you are on an intranet, follow the steps in the section above.

Do I need to set anything in Internet Explorer to have intranet security?

Not usually. When you first install Internet Explorer, it will check to see if you are on an intranet and set address checking appropriately. Your network administrator can also control whether Internet Explorer uses the intranet security zone settings. If Internet Explorer recognizes that you are on an intranet, you do not need to do anything else. If it does not recognize that you're on an intranet, follow these steps to to tell Internet Explorer that you are on one:

To tell Internet Explorer that you are on an intranet

In Internet Explorer, click the Tools button, and then click Internet Options. Click the Security tab, and then click Local intranet. Click the Sites button. In the Local intranet dialog box, clear the Automatically detect intranet network check box, if it is selected. Select all other check boxes, and then click OK twice.


Assuming that you have Kerberos set up on your client (e.g. Windows machine joined to the domain, Linux or Mac OS X box set up to obtain a Kerberos ticket) all you should need to do is set "network.negotiate-auth.trusted-uris" to the name of your web server. With this it should work.

Tested working browsers:

  • Firefox 3.0.1 on Windows XP SP2
  • Firefox 3.0.2 on Mac OS X 10.4
  • Firefox 3.0.x on Mac OS X 10.5

Tested failed browsers:

  • Firefox on SuSE Linux 10


Safari has no configuration option and if its working at the lower levels, 'just works' and if not then you've got to dig through the lower levels to work out what is wrong. This applies to both Windows and Mac versions.

When Kerberos is working properly on your Mac and everything is set up appropriatly, Safari will automatically authenticate the user using Digest authentication. Keep in mind that you might need to set up DNS names that the realm is also responsible for to ensure that it works properly. Kerberos with Safari occurs at the CFNetwork layer, which can make debugging a bit hard. The Kerberos ticket was acquired using the Kerberos utility manually (/System/Library/CoreServices/Kerberos). The Mac OS X 10.4 testing was completed with the Microsoft Active Directory integration enabled on the Mac (e.g. joined to the domain). Safari appears to have issues with sites that are not on the same DNS domain as the Kerberos domain whislt Firefox doesn't appear to exhibit this behaviour on the same .

In limited testing Safari on Windows seems to send an NTLM token in response to the authentication request, which when using mod_auth_kerb results in an error. Testing was done on a stock Windows 2003 install with the exception of the installation of Windows Installer 3.1 to allow Safari to install. In extended testing in a different environment, Safari appeared to handle Kerberos style authentication fine in some situations but failed in others (typically where NTLM was required for Firefox to automatically work).

Tested working browsers:

  • Safari 3.0.4 on Mac OS X 10.4
  • Safari 3.0.x on Mac OS X 10.5
  • Safari 3.2.1 on Windows XP SP2 (using IIS server)

Known issues:

  • Websites not sharing their DNS name in the domain will fail to work in some cases (10.4)

Google Chrome

Google Chrome seems to ignore the Kerberos ticket and directly prompts with a password dialogue when challenged. Testing was done on a stock Windows 2003 install with the exception of the installation of Windows Installer 3.1 to allow Safari to install. Further testing on XP SP2 against Microsoft IIS servers appears to confirm that Chrome is incapable of handling either NTLM or Kerberos authentication.

Personal tools