Single sign-on for Kerberos is a paid formcycle add-on module.

Kerberos allows a one-time logon or single sign-on. In a subsequent step, user data can be provided via an LDAP server. The authentication of the Kerberos login service can only be configured once per system, the providing of user data via an LDAP server can be overridden within the clients. The configuration of Kerberos therefore differs depending on whether the login service is configured in the system settings or within a client.

Contents

Configuration in the system settings

The global Kerberos configuration is set in the system settings.

Authentication

Use Kerberos

This switch can be used to enable/disable global Kerberos user authentication.

Synchronize with frontend server

If this switch is activated, the current configuration is transferred to all (reachable) frontend servers when the settings are saved.

Username

Windows domain account that is required to access the Key Distribution Center (KDC) to initiate the subsequent authentication process.
In most cases, this is a user account from AD that acts as a service account and is not intended to log on to a workstation.

A username with domain (FQDN) is required if no default_realm is defined in the krb5.conf file, under the [libdefaults] section. Example: user@EXCAMPLE.COM

If AES encryption is used for communication between formcycle and the KDC in the further configuration, it is essential that the user name is case sensitive. In the "Pre-Authentication" process, a hash value is created. Part of this hash value is the user name, which must correspond to the exact information in the Active Directory (AD), otherwise a user login will fail! 

This user must be registered e.g. in the Active Directory the hosts of the callable URLs to be used as well as the computer name of the application server as ServiePrincipalName starting with the service class HTTP. You can find more about this here or here.

Password

Password of the service account.

Client modul name

The name used in the login.conf file to define the clients.

Der Name, welcher in der login.conf Datei für die Definition der Clients verwendet wird.

Name of server module

The name used in the login.conf file to define the server.
If errors occur occasionally or permanently when calling forms with Kerberos enabled (HTTP status 400), the Kerberos ticket exceeds the default size limit of the HTTP header set by the application server (e.g. Tomcat). A solution is to increase this limit which is described here.

File krb5.conf

Here the content of the krb5.conf file is defined, in which the configuration for Kerberos is specified.
Among other things, the encryption methods supported by the system are listed here, as well as the realm (administration area) currently to be used and its mapping to a KDC.

File structure

The notation to be used within the file is based on Windows INI files, that is, individual sections are given a section name (in square brackets). Each section contains no or several assignments, which can be defined in the following form:

foo = bar

foobar = {
    foo = bar
    some = input
}

Section names

• [libdefaults]: Contains the settings used by the Kerberos V5 library.
• [realms]: Realm-specific contact information and settings.
• [domain_realm]: Defines the mapping of server host names to Kerberos realms.

[libdefaults]

The [libdefaults] section may contain the following mappings:

• default_realm: Defines the Kerberos administration realm to use by default.
• default_tkt_enctypes: Defines a list of supported session key encryption types that the client should request when an AS (Authentication Server) request is made. The order of each type corresponds to its preference from highest to lowest. The values within the list can be separated by commas or spaces.
• default_tgs_enctypes: Defines a list of supported session key encryption types that the client should request when a TGS (Ticket Granting Server) request is made. The order of each type corresponds to its preference from highest to lowest. The values within the list can be separated by commas or spaces.
• permitted_enctypes: Defines all encryption types that are permitted for use in session key encryption.

An example configuration for the [libdefaults] section may look like this:

[libdefaults]
 default_realm = EXAMPLE.COM
 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac
 default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac
 permitted_enctypes   = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 des3-cbc-sha1 arcfour-hmac-md5 camellia256-cts-cmac camellia128-cts-cmac des-cbc-crc des-cbc-md5 des-cbc-md4 rc4-hmac

[realms]

Each tag in the [realms] section is the name of a Kerberos administrative 'realm'. The value of the variable is a collection of mappings that define the properties of a particular realm. The following mappings can be defined for each realm:

• kdc: Defines the name or address of a computer on which a KDC (Key Distribution Center) for this administration realm is running (usually this is the server under which the Active Directory is accessible). An optional port number can be specified, separated by a colon.
• debug: A boolean value which defines whether debug messages should appear in the log.

An example configuration for the [realms] section may look like this:

[realms]
   EXAMPLE.COM = {
 kdc = domain.example.com
   }

[domain_realm]

The [domain_realm] section contains a mapping from a domain name or the host name to a Kerberos realm name. The tag name can be a host or domain name, where domain names are prefixed by a dot (.). The expected value is the name of a Kerberos realm for that particular host or domain. Host or domain names should be lowercase.
An example configuration for the [domain_realm] section may look like this:

[domain_realm]
   .example.com = EXAMPLE.COM

File login.conf

This defines the contents of the login.conf file and thus which authentication technology to use for client and server.

An example configuration may look like this:

spnego-client {
   com.sun.security.auth.module.Krb5LoginModule required;
};

spnego-server {
   com.sun.security.auth.module.Krb5LoginModule required
   refreshKrb5Config=true
   storeKey=true
   isInitiator=false;
};

LDAP user search

The following settings are necessary to obtain user information from the authenticated user via LDAP (MS Active Directory or OpenLDAP). The determined user data is then available for authorizations. The user search can be overridden within clients. See section Configuration within clients.

Configuration of the LDAP server for user search.

Domain controller host*

FQN (Full Qualified Name) and Port of the Active Directory Controller.
Example: domain.example.com Port: 389

SSL connection

This switch can be used to specify whether SSL should be used for communication with the LDAP server.

Hop count*

Specifies the maximum number of referral hops to be performed on the LDAP server.
A value of 0 disables a sequence of referrals.

User account (with domain)*

This account must have the permission to send search requests (user object) to the Active Directory.

A username with domain name (FQDN) is required. Example: user@EXCAMPLE.COM

User account password*

Password for the user account above.

BaseDN for search*

LDAP BaseDN under which the authenticated user is searched.
Example: ou="internal", dc="example", dc="com"

User ID attributes

A set of AD attributes can be specified which should be used for user identification. These attributes will be tried in the specified order for user identification. If no attributes are specified, then by default the following attributes are attempted in this order for user identification: sAMAccountName, userPrincipalName, uid, and DN. The default behavior can also be configured using the ldap.override.filter.user.login parameter in the application properties.

User filter

LDAP filter for searching a user after successful Kerberos authentication. The username obtained by authentication can be divided into individual components, which can be used to search for the user in LDAP. In the example test/admin@EXAMPLE.COM the following components are available:

{0}: test/admin@EXAMPLE.COM

{1}: test/admin

{2}: test

{3}: admin

{4}: EXAMPLE.COM

So these components can be used to define an LDAP filter to find the user on the LDAP server, for example:

(sAMAccountName={2})

In the given example, this filter would define the LDAP filter for the user search as follows:

(sAMAccountName=test)

If no value is set, the following LDAP filter is used by default:

(|(sAMAccountName={0})(userPrincipalName={0})(uid={0})(DN={0}))

The default behavior can also be configured using the ldap.override.filter.kerberos.user parameter in the application properties.

Configuration within clients

Within clients, the global LDAP user search configuration can be overridden. If a client Kerberos login service is used in forms, the global authentication configuration of Kerberos (see above) is used with the LDAP user search configured in the client Kerberos login service.

The following information is required to configure the client-specific LDAP user search:

LDAP connection: An existing LDAP connection must be selected.

BaseDN for user search: see BaseDN for search above.

User filter: see user filter above.

Theoretical consideration of the connection of several KDCs/domains

If multiple KDC servers or domains are desired for a global Kerberos login ability, this is theoretically possible via the standard MIT Kerberos implementation provided by Java and used by FORMCYCLE. However, the following configurations should be noted here:

• For each KDC server/domain a separate realm must be defined.
• The list to be defined under [domain_realm] must be used to specify which request URL should be handled by which realm.
• If cross realm authentication is desired, a cross realm trust must be established. This serves to the purpose that a user from realm A can also log in within the realm B. For example, this can be realized with a direct realm trust where principals are created on each relevant server against the other realms. For the realms A.REALM.COM and B.REALM.COM this would be for exemplary krbtgt/A.REALM.COM@B.REALM.COM and krbtgt/B.REALM.COM@A.REALM.COM.
• Use the same name and a strong password for the service principal or configure a keytab file.
• To query the correct user data after the Kerberos login, either an LDAP server with access to the whole forest of the realms or the functionality of the client-specific LDAP servers must be configured. It may also be necessary to adjust the responsible LDAP filter.

Using LDAP user data within forms

For using LDAP user data within forms, see here.