Kerberos Authentication

Document created by ggallo Employee on Aug 3, 2017Last modified by ggallo Employee on Aug 4, 2017
Version 2Show Document
  • View in full screen mode

OVERVIEW

This document outlines the requirements for Kerberos Authentication as part of a BOARD implementation.

These requirements may apply where Windows Authentication is used as the authentication type for BOARD Client users, and/or BOARD Web Access.

The following only applies to BOARD Versions 8.1.1 and later

ABOUT KERBEROS

Microsoft describes the Kerberos protocol in the following way: “The Kerberos authentication protocol provides a mechanism for mutual authentication between entities before a secure network connection is established. Throughout this documentation, the two entities are called the client and the server even though secure network connections can be made between servers. Both client and server can also be referred to as security principals.

Refer to this link for more information on Windows authentication methods: SSP Packages Provided by Microsoft (Windows)  

 

 

KERBEROS AND BOARD

In some environments, Kerberos is the default authentication mechanism used for Windows Authentication, specifically impacting BOARD in the following scenarios:

  • Windows Authentication is used for BOARD Client authentication, where the server environment is Windows 2008 R2 (or greater) and client systems are running Windows 7 (or greater) – or users access the BOARD Client application via Citrix/Terminal Services
  • Windows Authentication is used for BOARD web access, where the server environment is Windows 2008 R2 (or greater)– regardless of whether the BOARD Web Server is installed on the same server as the BOARD Engine, or not
  • BOARD engine service is NOT running in “Local system account” mode

 

 

BOARD Client Authentication

In scenarios similar to those described above, users may be unable to log in to BOARD – via Windows Authentication – using the BOARD Client application, if the necessary Kerberos entries are not registered. In these instances, a network diagnostic utility such as KerbTray will report that the client machine is attempting to authenticate with the BOARD server machine using the Service Principal Name:

host/{BOARD Server Name or FQDN} 

(eg. host/MyBoardServer or host/MyBoardServer.MyDomain.com)

 

If this SPN (Service Principal Name) is not registered in Active Directory, Kerberos authentication will fail.

(Note: you can often verify whether Kerberos issues are causing authentication issues by using an IP address to connect to the server – if this works, but connecting via the host name does not, it is very likely Kerberos issues which are causing authentication to fail. A utility like KerbTray can be used to diagnose the issues further).

 

The following steps must be followed in order to allow Kerberos authentication to work correctly between the BOARD client(s) and server:

  1. Ensure that the BOARD Engine service is running under a dedicated Windows account
  2. Register the SPN (Service Principal Name) relating to the BOARD Engine service – eg.
    SETSPN –S BOARDENGINE/{Board Server} {Board Engine Service Account} 

    and

    SETSPN –S BOARDENGINE/{Board Server FQDN} {Board Engine Service Account} 

    Where {Board Server} is the server where the BOARD Engine service is running; {Board Server FQDN} is the fully-qualified domain name of the server where the BOARD Engine service is running; and {Board Engine Service Account} is the Windows user account that the BOARD Engine service is running under.

    For example:

    SETSPN –S BOARDENGINE/MyBoardServer MYDOMAIN\BoardSvcAccount
    and
    SETSPN –S BOARDENGINE/MyBoardServer.MyDomain.com MYDOMAIN\BoardSvcAccount

    It is strongly recommended that the SETSPN command be run for both the Netbios name, and the fully-qualified domain name, of the server.

    This will ensure that users who connect either via the Netbios name, or the fully-qualified domain name, will be able to take advantage of Kerberos authentication.

    (Note: SETSPN should be run on a Domain Controller server, with elevated permissions – ie. “Run As Administrator”. Ensure you manually type in the SETSPN commands – do not copy from the document, as copying and pasting frequently results in mis-interpretation of parameters)

  3. Allow a brief period of time for the SPN registrations to be propagated between the necessary domain servers (approximately 10-15 minutes should be sufficient)
  4. Open “Active Directory Users and Computers”, preferably on a domain controller or similar. Under the “View” menu, enable the “Advanced Features” option. Perform the following step for both the COMPUTER account that relates to the server where the BOARD Engine server is running (eg. MyBoardServer) and the USER account that relates to the user account that the BOARD Engine service is running under (eg. MYDOMAIN\BoardSvcAccount):
    • Click on the “Delegation” tab
    • Select the option “Trust this computer for delegation to any service (Kerberos only)”

      For example:

       

       

  5. Restart the BOARD Engine service. Attempt to log in (using Windows Authentication) via the BOARD Client application again

     

    authentication should now be successful

 

BOARD Web Server Authentication

Steps required to configure Kerberos authentication for the BOARD Web Server are similar to those for the BOARD Client, with some additional steps required for the web server component. Firstly, follow steps 1 through to 5 in Section BOARD Client Authentication, to correctly configure the BOARD Engine service for Kerberos Authentication.

 

Next, follow the next steps to complete the configuration for the BOARD Web Server:

  1. Ensure that the BOARD Web Engine service is running under a dedicated Windows account (the user account for the BOARD Web Engine service should be different to the BOARD Engine service’s user account)
  2. Register the SPN (Service Principal Name) relating to the BOARD Web Engine service – eg.
    SETSPN –S http/{Board Web Server} {Web Engine Service Account} 
    and
    SETSPN –S http/{Board Web Server FQDN} {Web Engine Service Account}
    Where {Board Web Server} is the server where the Board Web Engine service is running; {Board Web Server FQDN} is the fully-qualified domain name of the server where the BOARD Web Engine service is running; and {Web Engine Service Account} is the Windows user account that the BOARD Web Engine service is running under.
    IMPORTANT: Please note, in this instance the service type is “http”, not “host” For example:
    SETSPN –S http/MyBoardWebServer MYDOMAIN\BoardWebAccount 
    and
    SETSPN –S http/MyBoardWebServer.MyDomain.com MYDOMAIN\BoardWebAccount
    It is strongly recommended that the SETSPN command be run for both the Netbios name, and the fully-qualified domain name, of the server. This will ensure that users who connect either via the Netbios name, or the fully-qualified domain name, will be able to take advantage of Kerberos authentication.
    (Note: SETSPN should be run on a Domain Controller server, with elevated permissions. Ensure you manually type in the SETSPN commands – do not copy from the document, as copying and pasting frequently results in misinterpretation of parameters)

  3. Allow a brief period of time for the SPN registrations to be propagated between the necessary domain servers (approximately 10-15 minutes should be sufficient)
  4. Open “Active Directory Users and Computers”, preferably on a domain controller or similar. Under the “View” menu, enable the “Advanced Features” option. Perform the following step for both the COMPUTER account that relates to the server where the BOARD Web Engine server is running (eg. MyBoardWebServer) and the USER account that relates to the user account that the BOARD Web Engine service is running under (eg. MYDOMAIN\BoardWebAccount):  Click on the “Delegation” tab  Select the option “Trust this computer for delegation to any service (Kerberos only)”

    For Example



  5. Restart the BOARD Engine service. Attempt to log in (using Windows Authentication) via the BOARD Client application again

    authentication should now be successful
1 person found this helpful

Attachments

    Outcomes