Verwaltung - Single sign-on 

Page / - last modified by gru on 10.03.2021, 10:15 

Single sign-on 
last modified by gru
on 10.03.2021, 10:15

Table of Contents
Using NTLM
Synchronize with frontend server
Domain controller host
NTLM authentication
Host name of the domain controller host
Windows domain name
Computer account
computer account password
LDAP user lookup
Port
SSL encryption
Hop count
User account (with domain)
User account password
Base DN für user lookup
Settings for Kerberos authentication
Use Kerberos
Synchronize with frontend server
Username
Password
File krb5.conf
File login.conf
Client module name
Server module name
LDAP user search
Domain controller host
SSL connection
Referral hops
User account (with domain)
User account password
Base DN for user lookup
Make user data available to forms

Single sign-on for Ntlm and Kerberos is a Xima® Formcycle license module which is subject to additional costs.
Content [ Hide ] 
•	Using NTLM
•	Synchronize with 
•	Domain controller host
•	NTLM authentication
•	Host name of the domain controller host
•	Windows domain name
•	Computer account
•	computer account password
•	LDAP user lookup
•	Port
•	SSL encryption
•	Hop count
•	User account (with domain)
•	User account password
•	Base DN für user lookup
•	Settings for Kerberos authentication
•	Use Kerberos
•	Synchronize with frontend server
•	Username
•	Password
•	File krb5.conf
•	File login.conf
•	Client module name
•	Server module name
•	LDAP user search
•	Domain controller host
•	SSL connection
•	Referral hops
•	User account (with domain)
•	User account password
•	Base DN for user lookup
•	Make user data available to forms
 
User interface for setting up Ldap authentication via Ntlm. Available only if the license allows it.
Ntlm (NT LAN Manager) can be used to authenticate users of a form.
A common use case are forms used internally by some company, and that may be accessed only by the employees of that company. The user data of the active directory can be accessed via Ntlm.
Ntlm may not be available depending on your license.
Using NTLM
Activate this option to use Ntlm.
Synchronize with frontend server
Activate this option to transmit the current configuration to all connected and available frontend servers when saving these settings.
Domain controller host
The host (FQN) of the active directory controller used for authenticating users via Ntlm and transmitting their data over Ldap.
Example: domain.example.com
Connection to the Ldap server for the Ldap search account has been established successfully
NTLM authentication
The following settings are required for enabling users to authenticate via Ntlm.
Host name of the domain controller host
The host name of the active directory controller.
Example: domain
Windows domain name
Different forms of the domain name can be used depending on the active directory.
Example: example.de oder example0
Here you must specify the domain name to which the user accounts to be authenticated belong.
This domain name may be different from the domain of the computer account (This is the computer's NetBIOS name, not the DNS / FQDN name).
The Windows domain name to be used can be determined, for example, by opening a Windows console (Start / Run / cmd) on a client logged into the domain and entering the following command:
echo %userdomain%
Computer account
The computer account must have been granted permission to perform user verification. It must not be a regular user account.
A computer account is recognizable by the '$' character in the domain name. e.g. example$@domain.de
Help pages of ca technologies on creating a computer account for NTLM authentication on active directory server.
computer account password
Password of the computer account.
LDAP user lookup
The following settings concern the user lookup after a successful Ntlm authenication.
Port
The port for connecting to the Ldap server for the user lookup.
SSL encryption
Enables SSL encryption when communicating the the Ldap server.
Hop count
The number of hop counts or referrals. Setting this to 0 disables following references.
User account (with domain)
Account to be used for looking up users.  It must have been granted permission to perform user lookup.
Example: ldap@example.de
User account password
Password of the user account.
Base DN für user lookup
Ldap base DN used for looking up authenticated users.
Example: ou="users", dc="example", dc="de"
Settings for Kerberos authentication
 
User interface for editing the settings for Kerberos authentication. Available only when the license includes this option.
Kerberos can be used to authenticate form users. This is often used for internal forms meant only for the employees of a company. The data of the current user can be retrieved from an active directory as well.
Kerberos authentication is available only when the license includes this option.
Use Kerberos
Activate this switch to enable Kerberos authentication.
Synchronize with frontend server
When activated, all changes to the configuration will be sent to all available frontend servers.
Username
The Window Domain account required for accessing the Key Distribution Center (KDC) and beginning the authentication process. 
Normally this is the user account of the active directory that is setup as a service account.
When no default_realm has been specified in the section [libdefaults] of the file krb5.conf, you will need to enter the username with a domain (FQDN).
Example: user@EXCAMPLE.COM
To this user you must, in Active Directory for example, register the Domians to be used as ServiePrincipalName beginning with the service class HTTP. You can find more information here or here.
Password
Password of the service account.
File krb5.conf
Enter the content of the file krb5.conf, ie. the configuration file for Kerberos.
Among other settings, the available encryption methods, the current real and its mapping to a KDC should be set.
File structure
The file format is similar to Windows INI files. It contains of individual sections, introduced by their names in brackets. Each section may or may not contain several key-value pairs:
foo = bar
or
foobar = {
    foo = bar
    some = input
}
Section names
•	[libdefaults]
 Contains settings used by the Kerberos library v5.
•	[realms]}} Realm-specific settings and contact information.{{/litem}}
•	{{litem title=
A list of supported session key encryption methods that should be requested by the client when performing an AS (authentication server) request. The priority of each method is given by the order in which they have been specified, the first one being the method with the highest priority. Several methods can be separated with commas or spaces.
•	{{litem title="default_tgs_enctypes}}A list of supported session key encryption methods that should be requested by the client when performing a TGS (ticket granting server) request. The priority of each method is given by the order in which they have been specified, the first one being the method with the highest priority. Several methods can be separated with commas or spaces.{{/litem}}
•	permitted_enctypes
A list of all allowed session key encryption methods.
A simple configuration for the [libdefaults] section might look as follows:
[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
 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
 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
[realms]
Each key in the [realms] section represents the name of a Kerberos realm. The value is a list of mappings, defining the properties of each realm. The following properties can be set:
•	kdc: The name or address of a server running a KDC (key distribution center) for this realm, usually the server with the active directory. When necessary, the port number can be specified by appending it separated by a column.
A simple configuration for the [realms] section might look as follows:
[realms]
   EXAMPLE.COM = {
 kdc = domain.example.com
   }
[domain_realm]
The section [domain_realm] contains a mapping from domain names or host names to Kerberos realm names. The key can be a host or domain name, but domain names must be prefixed with a period. The value must be the name of a Kerberos realm for this host or domain. Host and domain names should be spelled with lower case letters.
A simple configuration for the [domain_realm] section might look as follows:
[domain_realm]
   .example.com = EXAMPLE.COM
File login.conf
The content of the file login.conf, which contains login-related settings such as the authentication method between clients and servers.
A sample configuration might look as follows:
spnego-client {
   com.sun.security.auth.module.Krb5LoginModule required;
};

spnego-server {
   com.sun.security.auth.module.Krb5LoginModule required
   refreshKrb5Config=true
   storeKey=true
   isInitiator=false;
};
Client module name
The name in the login.conf file for the client to be used, eg. spnego-client.
Server module name
The name in the login.conf file for the server to be used, eg. spnego-server.
When you keep getting a HTTP 400 error with Kerberos activated, the most likely cause is that the HTTP header size of the Kerberos ticket exceeds the default header size limit of the application server, eg. Tomcat of JBoss. See the help pages on changing the HTTP header size limit.
LDAP user search
The following settings are required to retrieve information about the authenticated user from an Ldap (MS active directory). This data is then available in the form and can be accessed by JavaScript code.
Domain controller host
FQN (fully qualified name) and port of the active directory controller.
Example: domain.example.com Port: 389
SSL connection
When activated, all communications with the LDAP server will be encrypted with SSL.
Referral hops
The maximum number of referral hops that may be performed on the LDAP server. Setting this to 0 deactivates referral hops and no references will be followed.
User account (with domain)
This account must have been granted permission to send search queries to the active directory.
This needs to be a username suffixed with the domain.
Example: user@EXCAMPLE.COM
User account password
Password for the user account.
Base DN for user lookup
The LDAP baseDN used for looking up the authenticated user.
Example: ou="intern", dc="example", dc="com"
Make user data available to forms
The LDAP user data for the currently authenticated user are stored in the JavaScript object window.XFC_METADATA.user.rawData and can be accessed via JavaScript.
Which data the JSON structure contains under the rawData property depends mainly on the read rights of the LDAP account, which executes the user search in the LDAP system.
To access the property //userPrincipalName// of the user from JavaScript, use the following code: 
try {
   // Auslesen der Property und Anzeige in einem Label
   var elem = $('[name=txt1]');
   var ldap = XFC_METADATA.user.rawData;
   if(ldap.hasOwnProperty('userPrincipalName')) {
        elem.html(ldap.userPrincipalName);
    }
} catch (err)  {}