Kerberos SSO - Internet Explorer and Firefox settings

The topics I describe in this article have been newly and more thoroughly explored, and I have prepared an extensive series Kerberos protocol with focus on SSO in AD DS. This article is most closely related to the part Kerberos Part 10 - Web Browsers Settings.

For implementing Single sign-on (SSO), we will consider the secure Kerberos protocol, which is described in the previous article Kerberos protocol and Single sign-on. MS client OS from Windows 2000 version natively support the Kerberos protocol and even prefer it over the older proprietary Microsoft NTLM protocol (which is not considered secure today). Windows also provide an API for applications to use this protocol. The Local Security Authority (LSA) handles user authentication and calls the Security Support Provider Interface (SSPI), which is an interface that communicates with authentication protocols (and its functions can be used by applications), such as Kerberos SSP.

Problems in Windows

In practice, when deploying SSO for applications, we encountered two problems on the client. Both arise from the increasing security of clients that MS is striving for. Here is a brief description and possible solutions.

Providing TGT and session key

Microsoft increased security in the OS by limiting the interface for obtaining the TGT/session key pair from the Kerberos authentication package. When we have an application on a Windows client (written, for example, in Java) that uses Kerberos authentication, it can use one of two interfaces. Either SSPI, which provides complete Kerberos services, or LsaCallAuthenticationPackage from the Windows SDK, whose functions provide a mechanism for obtaining a ticket from the Kerberos cache. And when using LsaCallAuthenticationPackage, we need to be able to obtain the session key from the system. For such purposes, it can be enabled via the registry. It is the AllowTGTSessionKey value, which is by default [dword] 0 (the function returns only the TGT without the session key, so it cannot be used for SSO) and we can change it to 1. In Windows XP, this key is located in

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\

In Windows 7, Vista, 2000, Server 2003, Server 2008, it is

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters\

The description is in the article Registry Key to Allow Session Keys to Be Sent in Kerberos Ticket-Granting-Ticket. The change takes effect after a restart. Another finding is that the application must run under local administrator (when using UAC in Windows 7, it must be manually started), otherwise it will not be able to obtain the TGT. Everything would improve if programmers used SSPI, as is the case in Internet Explorer or Firefox.

The described problem may be accompanied by an error in Java:

GSSException: No valid credentials provided (Mechanism level: No valid credentials provided (Mechanism level: Integrity check on decrypted field failed (31)))

Extended Protection for Authentication

Another increase in security brought by the Extended Protection for Authentication technology (channel binding token - CBT). If there is a problem with it, it can be turned off. The error manifests, for example, when Java is running on the server (fixed in JRE 6 update 21) and we connect from Internet Explorer. During SSO, it logs the error ChannelBinding not provided!. The description is in the MS articles Extended Protection for Authentication Overview and Extended Protection for Authentication. The problem is solved by the following registry setting (although the value 2 is not listed by MS as possible), a restart is required on Windows XP.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\SuppressExtendedProtection=dword:00000002

SSO to a web application

General way how SSO works for web applications. In a web browser, we open an address (send an HTTP/Post/Get request to the web server). Authentication is required here, and the application is set to use SSO, which the web server supports. So the web server sends the client SPNEGO authentication negotiation (HTTP 401 Authenticate/Negotiate). The browser accepts the request, and now it depends on whether it has IWA enabled and also the web server address. If not, it rejects the negotiation, and it is up to the web server or rather the application how it behaves. If it is enabled, the protocol is negotiated, we only consider Kerberos, so the web server must support this. If everything is in order, the web browser uses the SSPI (Security Support Provider Interface) system libraries and obtains a service ticket from the KDC. This service ticket is sent as a response to the web server (authorization SPNEGO token in the HTTP header). The server processes it, obtains the user ID, verifies it, and if everything is in order, passes the user information to the application.

Internet Explorer settings

Internet Explorer (IE) as an MS application naturally supports Integrated Windows Authentication. This method can be disabled in the settings, but it is enabled by default. It only applies to internet addresses that belong to the Local Intranet group.

So the requirements for SSO to work in IE are:

• enable Integrated Windows Authentication - enabled by default (settings in the menu Tools - Internet Options - Advanced - section Security)
• set the server address among Local Intranet - by default, the option Automatically detect intranet network is enabled, so local addresses should be automatically detected (settings in the menu Tools - Internet Options - Security - Local Intranet - Sites - Advanced), but it is safer to set the address directly

When entering addresses among Local Intranet, we can directly enter the server address, such as www.domain.com (then it applies to both http and https protocols) or we can specify the protocol 1 or we can include the entire domain (and all subordinate addresses) using *.domain.com. Instead of DNS names, we can also use IP addresses (optional octets replaced with an asterisk), but in practice, I had problems with this setting.

Configuration using Group Policy

Settings related to Local Intranet in IE can be done using Group Policy (GP) and applied either to the user or the computer. It is recommended to set it for the user. The values are found in GP:

User Configuration - Policies - Administrative Templates - Windows Components - Internet Explorer - Internet Control Panel - Security Page

We open the item Site To Zone Assignment List, enable this policy, and add the addresses we want to include in the zone. For each address, there is one line, in the value name we enter the address (e.g., *.domain.local) and in the value we put the zone number to which we want to assign the address (1 - intranet, 2 - trusted, 3 - internet, 4 - restricted). A side effect, which may be welcome or not, is that after setting this policy, users are prohibited from adding (modifying) addresses in the zones. It may also be useful to know where the zone settings are located in the registry (but not if we set it by policy):

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\

In the same place, we can also enable the policies Intranet Sites: Include all sites that bypass the proxy server, Intranet Sites: Include all network paths (UNC), and Intranet Sites: Include all local (intranet) sites not listed in other zones.

Mozilla Firefox

In Firefox, the use of Integrated Windows Authentication has also been possible for a long time. Firefox uses the system libraries SSPI (Security Support Provider Interface or GSS-API on Linux). The function is generally enabled, but it is necessary to configure the addresses for which it will be used. For all others, Firefox rejects all negotiations from the web server (it could be misused, especially when using NTLM, which sends a password hash). Manual configuration in Firefox is done by entering the text:

about:config

After confirming the warning that configuration changes can be dangerous, we see individual configuration parameters. In the filter, we enter the variable we want to change. In our case, there are two available

for Kerberos it is network.negotiate-auth.trusted-uris

for using NTLM it is

network.automatic-ntlm-auth.trusted-uris

We use Kerberos, so we enter the first value and after filtering it, we click on it. Now we enter the text string. In the value, we can enter the server address directly, such as www.domain.com (then it applies to both http and https protocols) or specify the protocol 1 or we can include the entire domain (and all subordinate addresses) using domain.com. Multiple values can be separated by a comma. The change takes effect immediately.

Configuration using Group Policy

Firefox configuration can be done using JavaScript configuration files. There are many of them, user configuration is located under the user profile. For example, on Windows 7 it is c:\Users\{profile}\AppData\Roaming\Mozilla\Firefox\Profiles\{firefox-profile}.default\. Here is the file prefs.js, which is created automatically and should not be modified. We can create a file user.js, where we enter the settings for the user. Simpler are global configurations, which are located in the directory where Firefox is installed. The default path on 64-bit Windows 7 is c:\Program Files (x86)\Mozilla Firefox\defaults\pref\. Here we can create a file all.js or all-{company name}.js. In the file, we enter the command

pref("network.negotiate-auth.trusted-uris", "list of addresses separated by a comma");

If we want to perform a mass configuration of multiple stations, we can again use Group Policy, although a bit more complicated. Using GP, we ensure the copying of the configuration file. We will assume that we have the "novelty" Group Policy Preferences available, which will make the whole thing easier.

First, we need to create a file with the configuration, the mentioned all.js. Then we need to place it in a shared storage on the network, where the computer/user will have access at startup. One option is the NETLOGON directory on the domain controller (thanks to replication, therefore on all = on the domain share).

Next, we need to decide whether we will apply the policy to the user or the computer. We will be uploading the file to Program Files, so we can create a policy for the computer, but it depends on how we will better apply it. According to that, we then choose the Computer Configuration or User Configuration part in GP. In the example, we choose the user part, the necessary configuration is in

User Configuration - Preferences - Windows Settings - Files

Right-click on the desktop and select New - File. Choose the method, Create should be sufficient. Enter the source path to the shared file and the target location. We will only consider the default installation location, so for 64-bit Windows 7, it is C:\Program Files (x86)\Mozilla Firefox\defaults\pref\all.js. This way, we can have the policy ready.

However, if we have 32-bit OS in the network and we do not want to deal with separation by applying GPO to a container that contains only computers with 32-bit OS and applying a different policy to 64-bit OS (which we cannot do here since we chose the user part of the configuration). We can solve this using Item-level targeting. We still have the properties of the created file open, switch to the Common tab. Here is Item-level targeting, check it and click on Targeting. Through New Item, we enter the parameter we want to compare. The Operating System item would be offered, but in practice, it did not work correctly, so we choose File Match and compare if the directory C:\Program Files (x86)\Mozilla Firefox\defaults\pref exists. In that case, the file is created here.

Then we add the second file with the path C:\Program Files\Mozilla Firefox\defaults\pref\all.js, where we only change the comparison Item Option from Is to Is Not.