Skip to main content

Authentication Mechanism - NTLM and Kerberos

Authentication Mechanisms Under Windows

General

If you wish to use integrated security for logging in, and the components are distributed over several computers and a database is in use that requires an integrated login, successful login to a database will depend on the settings made in the IIS and on the authentication method selected.

Windows systems support two different authentication methods: NTLM only permits a login to be forwarded once ("singlehop"). Kerberos on the other hand allows a login to be forwarded multiple times ("multihop").

Previously, Cockpit 10 and CSP Server only supported NTLM. As of Release 2, Kerberos authentication is also supported.

Comparison Between NTLM and Kerberos

NTLM (NT Lan Manager) is an authentication method that allows the identity of a client to be validated. The identity of the server is not checked.

NTLM works within Windows domains, across domain boundaries and in networks that use workgroups rather than domains.

As soon as the server has verified the identity of the client, the server process can be promoted to the client's user context in order to obtain integrated access to resources on which the identity under which the server was originally running would not otherwise have permissions.

Kerberos is an authentication mechanism that allows the identity of both the client and the server to be verified. This enhances security as this approach renders "man in the middle" attacks or "spoofing" virtually impossible (extremely difficult).

Kerberos only works in Windows domains or between domains which have a trusted relationship with each other, for instance domains from the same forest (cluster of several domains).

As soon as mutual authentication is completed, the server process can be promoted to the client's user context. The identity of the client can also be delegated on, i.e. if the server in turn acts as the client of another server (e.g. a database), the server process of the server at the end of this 3-part chain can also be promoted to the client's user context (beginning of the chain). This allows SSO ("single sign-on") to be implemented by multi-layer applications.

Example: Cockpit 10 with Microsoft Analysis Services as the database server

In this case, the identity of the client (the one running the Web browser) must be passed through (delegated) to the database server, otherwise integrated login to the database is not possible. NTLM allows a maximum of one hop, but this scenario can be implemented with Kerberos. It should also be noted that in this scenario IIS and Cockpit 10 are acting both as server and as client. The Web browser acts purely as a client and the Analysis Services Server acts purely as a server, since each represents one end of the chain.

For further information refer to the following sections.

Prerequisites for Using Kerberos

The following requirements must be met to allow Kerberos to be used successfully:

  • The authentification mechanism Kerberos can currently only be used successfully in a distributed application (Multi-Server Installation). As a workaround, the use of a virtual server within the Web server can be considered as alternative to an additional hardware server.
  • The database used must support Kerberos. The following databases support Kerberos:
    • SQL Server/Analysis Services Server 2008/2008R2 onwards
    • Infor PM OLAP/Infor BI
    • IBM Cognos TM1
  • The client and server and all links in the chain must be in the same domain or in domains which have a trusted relationship with each other.
  • The domain must possess ADS (Active Directory), i.e. the domain controller must be Windows 2000 Server or later.
  • Windows 2000 domain controllers must be running on the highest functional level.
  • All the hosts on which components of the chain are running must be granted permission to delegate at the domain controller. This can be restricted to individual services for each computer. The notes indicate that the corresponding GUI is only available if an SPN (Service Principal Name) is registered for the computer.
  • Cockpit 10 must be configured appropriately, see Kerberos SSO with Cockpit 10.
  • Although browsers, for example Firefox, are known to be able to use Kerberos, depending on the browser this can mean special configurations or settings or the installation of additional third-party plug-ins for the browser. Therefore Cubeware is not able to take responsibility for the correct functioning of Kerberos-based authentication for non-Microsoft browsers.

Note: Test the authentication on a client machine. Do not use the machine on which the IIS is installed.

Kerberos SSO with Cockpit 10

The following settings are required to be able to use Kerberos with Cockpit 10.

CSP Server

If Cockpit 10 is to be operated with Kerberos SSO, the use of Kerberos must be extended to include CSP Server.

On the domain controller, the server host on which the CSP Server is running must have delegation permission and an SPN must be entered for the user under which the CSP Server service is running.

The element <tsauth> must be present under "<config><applicationbase>" in the file cockweb.cfg and must have the attributes "security" and "targetspn". "security" contains the value "Kerberos" and "targetspn" contains the SPN of the CSP Server. If several CSP Servers are used, predefined logins must be used. The relevant attributes "security" and "targetspn" are then also specified here. If these attributes are not specified, the settings from the file cockweb.cfg are used.

Cockpit 10

On the domain controller, the server host on which Cockpit 10 is running must have delegation permission and an SPN must be entered for the user under which the WebRuntime service is running.

This exact SPN must be entered in the "spn" attribute under "<config><webruntime>" in the file webengine.cfg.

IIS (Internet Information Services)

Only integrated authentication may be enabled under "Directory Security" for the web site. Call the Internet Services Manager. Under Web Sites, right-click to open and the properties for Cockpit 10. Where necessary correct the settings on the "Directory Security" tab.

The following entries must be present in the "<appSettings>" block of the Web.config file:

<add key="impersonate" value="1" />

<add key="usekerberos" value="1" />

Browsers

Mozilla FireFox

Proceed as follows to use Kerberos SSO with Mozilla FireFox:

  • Enter "about:config" in the address bar.
  • Under the two keys "network.negotiate-auth.delegation-uris" and "network.negotiate-auth.trusted-uris", add the name(s) of the server host(s) on which your IIS is/are running.

Target and SPN (Service Principal Names)

This section is intended as background information and is aimed at users familiar with setting up domains and users.

If authentication is initiated via the Security Support Provider Interface (SSPI) in order to achieve mutual authentication via Kerberos and hence multihop capability, the client must be aware of the user context under which the server process is running. This is then used to authenticate the server.

Because it is not normally expedient to have to maintain a target user name on every client or to "hardwire" this into the client, the SPNs ("Service Principal Names") have been introduced to add a level of indirection. These are explicitly associated with user accounts in the directory service (Active Directory). This means that the client must have the SPN available to it. During the authentication process, the SPN is then resolved to a user account via the SPN registration. The user account under which the server process runs can therefore be changed at any time without impacting the clients, provided that the SPNs are maintained appropriately.

Essentially, an SPN is nothing more than a unique identifier. Nevertheless, conventions apply to the way in which they are constructed. The most common is <ServiceName>/<MachineName>[:<Port>]. This structure ensures that every instance of a service running in a domain is assigned a unique SPN. An SPN like this can also be created by the client by concatenating strings.

  • <ServiceName> is freely-definable and is known to the clients.
  • <MachineName> (NetBIOS name, e.g. "myservermachine", or the fully qualified DNS name, e.g. "myservermachine.mydomain.com") and...
  • <Port> have to be known to the client at the time of authentication, because it explicitly connects to a particular server/port.

SPNs are always registered as pairs, once with the NetBIOS name of the server host and once with the DNS name. Many client programs assemble the SPN programmatically prior to establishing a connection by concatenating strings, so it is of no significance whether the client references the NetBIOS name or the DNS name of the server host.

Kerberized server processes must run under a domain user. This must then be specified as the target or be associated with an SPN. If the server is a service running under NT AUTHORITY/NetworkService or LOCAL SYSTEM, the machine account of the server host is taken as the user account that then has to be specified as a target or associated with an SPN.

The command line tool "SETSPN" is available for registering SPNs.

If the kerberized server process is running under a machine account, the "HOST" SPN that is available by default can be used. This is automatically created when adding a computer to a Windows domain and is associated with the machine account. It is usually used for SSO authentication for all standard Windows services that communicate within a domain. The HOST SPN is universal, as it is registered without specifying a port, and can thus be used for all applications that run under a machine account and whose server port does not have to be used as an instance identifier attribute because only one instance of the service runs at any time.

Further Information on Kerberos and Recommendations

Further Information

Further information can be found under:

What is Kerberos? (Source: technet.microsoft.com/en-us/library/cc780469.aspx)

Note: Please understand that we cannot assume any responsibility for the accuracy of this Web page's content.

Recommendations

  • It is not recommended that you install Cockpit 10 on a domain controller.
  • Kerberos authentication works most reliably if SPNs are used that contain the host name as a fully qualified DNS name ("HOST/MyServer.MyDomain.net").

Was this article helpful?

We're sorry to hear that.