In this article:

Step 1. Installing and Setting Up Kerberos on DBMS Server

Step 2. Creating Keytab Files and Setting Up HTTP and postgres Services

Step 4. Setting Up Web Application Back End

Step 6. Domain User Authorization in the System

Setting Up Domain/Integrated Domain Authentication on Apache2 Web Server

To set up domain or integrated domain authentication on Apache2 web server using PostgreSQL DBMS, follow the steps below.

NOTE. It is assumed that the web application is already installed in Linux OS.

Step 1. Installing and Setting Up Kerberos on DBMS Server

To install and set up Kerberos on PostgreSQL DBMS server:

Make sure that the following packages are installed for Kerberos protocol:

krb5-user, krb5-config in Debian-based distributions.
krb5-kinit, libkrb5 in ALT Linux.

If the packages are not installed, install them:

Debian-based distributions:

sudo apt-get install krb5-user krb5-config

ALT Linux:

sudo apt-get install krb5-kinit libkrb5

In RedHat-based distributions additional packages are not needed to be installed.

Make sure that domain information is added in the /etc/krb5.conf file. If information is not added, add it, for example:

[libdefaults]
  default_realm = DOMAIN.RU
[realms]
  DOMAIN.RU = {
    kdc = domain.server.name
    admin_server = domain.server.name
  }
[domain_realm]
  .domain.ru = DOMAIN.RU
  domain.ru = DOMAIN.RU

For details see Kerberos documentation.

Make sure that domain user is available:

kinit <domain user name>
***Enter use password***
klist

If "kinit: Generic preauthentication failure while getting initial credentials" error occurs, open the /etc/krb5.conf file and add the following strings in the [libdefaults] section:

default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5

After executing the operations the Kerberos client is installed and set up on PostgreSQL DBMS server.

Step 2. Creating Keytab Files and Setting Up HTTP and postgres Services

Keytab files are used to authenticate users without entering password in Astra Linux Directory (ALD) in Linux OS or Active Directory (AD) in Windows OS. A Keytab file stores names of Kerberos principals and corresponding encrypted keys obtained based on Kerberos passwords.

NOTE. The HTTP service is used only for integrated domain authentication.

Astra Linux Directory

To create keytab files and set up HTTP and postgres services when using ALD in Linux OS:

Prepare separate servers with ALD domain:

On ALD domain controller.
On ALD clients - local computers with BI server, web server, PostgreSQL DBMS.

NOTE. It is assumed that BI server, web server and PostgreSQL DBMS are located on different servers.

Open and fill in the /etc/hosts file located on the ALD domain controller and its clients. For example:

# IP-address          FQDN                      hostname
111.111.111.111       ald-server.domain.ald     ald-server
111.111.111.112       bi-server.domain.ald      bi-server
111.111.111.113       web-server.domain.ald     web-server
111.111.111.114       pgsql-server.domain.ald   pgsql-server

NOTE. If the domain name system (DNS) is set up, skip this step.

Install the packages ald-client-common, fly-admin-ald-client, ald-admin on each ALD client:

sudo apt install ald-client-common fly-admin-ald-client ald-admin

Include ALD clients to the domain. To do this, execute commands on each client and specify domain administrator password:

BI server:

sudo ald-client join ald-server.domain.ald --hostname bi-server.domain.ald

Web server:

sudo ald-client join ald-server.domain.ald --hostname web-server.domain.ald

PostgreSQL DBMS:

sudo ald-client join ald-server.domain.ald --hostname pgsql-server.domain.ald

Reboot the operating system on each ALD client.
Create an HTTP service for BI server and a postgres service for DBMS on the ALD domain controller:

ald-admin service-add HTTP/bi-server.domain.ald
ald-admin sgroup-svc-add HTTP/bi-server.domain.ald --sgroup=mac
ald-admin service-add postgres/pgsql-server.domain.ald
ald-admin sgroup-svc-add postgres/pgsql-server.domain.ald --sgroup=mac

Create and fill in keytab files on BI server (HTTP) and PostgreSQL DBMS (postgres):

For the HTTP service:

keytab="/<path to the folder where Keytab file will be created on BI server>/keytab"
ald-client update-svc-keytab HTTP/bi-server.domain.ald --ktfile="$keytab"
chown apache $keytab
chmod 644 $keytab

For the postgres service:

keytab="/<path to the folder where Keytab file will be created in DBMS>/keytab"
ald-client update-svc-keytab postgres/pgsql-server.domain.ald --ktfile="$keytab"
chown postgres "$keytab"
chmod 644 "$keytab"

Specify full path to Keytab files:

In the BI server configuration file fp10.x-biserver.conf in the <Location> section:

GssapiCredStore keytab:<path to Keytab file for HTTP service>

BI server configuration file in Apache2 instance depends on Linux OS version:

/etc/apache2-fp10.x/mods-available/fp10.x-biserver.conf in Debian-based distributions.
/etc/httpd-fp10.x/conf.d/fp10.x-biserver.conf in RedHat-based distributions.
/etc/httpd2-fp10.x/conf/mods-avaible/fp10.x-biserver.conf in ALT Linux.

NOTE. Path to keytab file in fp10.x-biserver.conf is set only for integrated domain authentication.

In the PostgreSQL DBMS configuration file /var/lib/pgpro/ent-13/data/postgresql.conf:

# GSSAPI using Kerberos
krb_server_keyfile = '<path to Keytab file for postgres service>'
krb_caseins_users = on

NOTE. Address of the postgresql.conf file may differ depending on DBMS version.

Restart the BI server.
Restart PostgreSQL DBMS server.

After executing the operations, Keytab files are created to work with Kerberos and HTTP and postgres services are set up.

Absolute delegation is used in ALD.

Active Directory

To create keytab files and set up HTTP and postgres services when using AD in Windows OS:

Prepare separate servers with AD domain:

On AD domain controller.
On AD clients - local computers with BI server, web server, PostgreSQL DBMS.

NOTE. It is assumed that BI server, web server and PostgreSQL DBMS are located on different servers.

Create users for HTTP and postgres services using the Active Directory Users and Computers utility located on the sever with with AD domain. The example of created user for HTTP service:

Make sure that the User Cannot Change Password and Password Never Expires checkboxes are selected for the user.

Create keytab files and link them to corresponding created users on BI server (HTTP) and PostgreSQL DBMS (postgres) using PowerShell:

For the HTTP service:

ktpass -princ HTTP/<principal name> -mapuser <user name with domain> -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass <user password> -out C:\<path to folder, in which a keytab file is created on BI server>\keytab.keytab

For the postgres service:

ktpass -princ postgres/<principal name> -mapuser <user name with domain> -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass <user password> -out C:\<path to folder, in which keytab file is to be created in DBMS>\keytab.keytab

The example of command for HTTP service:

ktpass -princ HTTP/sng-sso-bi.nvg.team@NVG.TEAM -mapuser sng-sso-bi_http@NVG.TEAM -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass Qwerty1 -out C:\KeyTab\sng-sso-bi_http.keytab

Check if users are linked with HTTP and postgres services:

setspn -L <user name without domain>

If the link is set, the message with principal is displayed. For example:

Registered ServicePrincipalNames for CN=sng-sso-bi_http,OU=Kerberos,OU=NVG,DC=nvg,DC=team:
    HTTP/sng-sso-bi.nvg.team

Specify full path to Keytab files:

In the BI server configuration file fp10.x-biserver.conf in the <Location> section:

GssapiCredStore keytab:<path to Keytab file for HTTP service>

BI server configuration file in Apache2 instance depends on Linux OS version:

/etc/apache2-fp10.x/mods-available/fp10.x-biserver.conf in Debian-based distributions.
/etc/httpd-fp10.x/conf.d/fp10.x-biserver.conf in RedHat-based distributions.
/etc/httpd2-fp10.x/conf/mods-avaible/fp10.x-biserver.conf in ALT Linux.

NOTE. Path to keytab file in fp10.x-biserver.conf is set only for integrated domain authentication.

In the PostgreSQL DBMS configuration file /var/lib/pgpro/ent-13/data/postgresql.conf:

# GSSAPI using Kerberos	
krb_server_keyfile = '<path to Keytab file for postgres service>'
krb_caseins_users = on

NOTE. Address of the postgresql.conf file may differ depending on DBMS version.

Restart the BI server.

Restart PostgreSQL DBMS server.

After executing the operations, keytab files are created to work with Kerberos, and HTTP and postgres services are set up.

NOTE. If user properties are changed, keytab file should be recreated.

Unlimited and limited delegation can be used in AD:

To use unlimited delegation, select the Trust This User for Delegation to Any Service (Kerberos only) radio button on the Delegation tab in user properties.
To use limited delegation:

Select the Trust This User for Delegation to Specified Services Only > Use Any Authentication Protocol radio button on the Delegation tab in user properties.
Enable the GssapiUseS4U2Proxy option in the fp10.x-biserver.conf BI server configuration file in the <Location> section:

GssapiUseS4U2Proxy On

BI server configuration file in Apache2 instance depends on Linux OS version:

/etc/apache2-fp10.x/mods-available/fp10.x-biserver.conf in Debian-based distributions.
/etc/httpd-fp10.x/conf.d/fp10.x-biserver.conf in RedHat-based distributions.
/etc/httpd2-fp10.x/conf/mods-avaible/fp10.x-biserver.conf in ALT Linux.

Step 3. Setting Up BI Server

By default, during BI server installation, configuration files of the Apache2 instance are located in the folder:

/etc/apache2-fp10.x in Debian-based distributions.
/etc/httpd-fp10.x in RedHat-based distributions.
/etc/httpd2-fp10.x in ALT Linux.

To set up BI server:

Install Apache2 takin into account the specified modules:

Debian-based distributions:

apt install apache2 libsasl2-modules-gssapi-mit libapache2-mod-auth-gssapi

RedHat-based distributions:

yum install httpd lighttpd-mod_authn_gssapi cyrus-sasl-gssapi

ALT Linux:

apt-get install apache2-base apache2-httpd-worker apache2-mod_auth_gssapi libsasl2-plugin-gssapi

After executing the operations the Apache2 instance is installed in the folder:

/etc/apache2 in Debian-based distributions.
/etc/httpd in RedHat-based distributions.
/etc/httpd2 in ALT Linux.

Copy new configuration files of Apache2 instance to the instances created on installing BI server:

Debian-based distributions:

cp /etc/apache2/mods-available/auth_gssapi.load /etc/apache2-fp10.x/mods-available/
cp /etc/apache2/mods-available/session.load /etc/apache2-fp10.x/mods-available/
cp /etc/apache2/mods-available/session_cookie.load /etc/apache2-fp10.x/mods-available/

RedHat-based distributions:

cp /etc/httpd/conf.modules.d/01-session.conf /etc/httpd-fp10.x/conf.modules.d/
cp /etc/httpd/conf.modules.d/10-auth_gssapi.conf /etc/httpd-fp10.x/conf.modules.d/

ALT Linux:

cp /etc/httpd2/conf/mods-available/auth_gssapi.load /etc/httpd2-fp10.x/conf/mods-available/
cp /etc/httpd2/conf/mods-available/session.load /etc/httpd2-fp10.x/conf/mods-available/
cp /etc/httpd2/conf/mods-available/session_cookie.load /etc/httpd2-fp10.x/conf/mods-available/

Enable the missing Apache2 modules in Debian-based distributions and in ALT Linux.

a2enmod-fp10.x auth_gssapi
a2enmod-fp10.x authz_user
a2enmod-fp10.x authn_core
a2enmod-fp10.x headers
a2enmod-fp10.x session
a2enmod-fp10.x session_cookie
a2enmod-fp10.x rewrite
a2enmod-fp10.x setenvif

The specified modules are enabled by default in RedHat-based distributions.

Change configuration files of BI server in the Apache2 instance:

fp10.x-biserver.conf

envvars

Set up the CORS mechanism to increase system security during data exchange between different domains. To do this, set the headers Origin, Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers at the end of the file:

/etc/apache2-fp10.x/sites-available/webserver.conf in Debian-based distributions.
/etc/httpd-fp10.x/conf.d/webserver.conf RedHat-based distributions.
/etc/httpd2-fp10.x/conf/sites-available/webserver.conf in ATL Linux.

<IfModule mod_headers.c>
    SetEnvIf Origin ^(<allowed domain>)$ CORS_ALLOW_ORIGIN=$1
    Header always set Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN
    Header merge Vary "Origin"	
    Header always set Access-Control-Allow-Methods "POST, OPTIONS, <HTTP request methods>"
    Header always set Access-Control-Allow-Headers "get-ppbi-time, content-type, soapaction, accept-language, cache-control, Authorization, <HTTP request headers>"</IfModule>
	
RewriteEngine On	
RewriteCond %{REQUEST_METHOD} OPTIONS	
RewriteRule ^(.*)$ $1 [R=200,L]

In the substitutions:

<allowed domain>. Specify the domain as a regular expression, for which getting of requests will be allowed. For example, the regular expression for the example.com domain:

https?://(?:.+\.)?example\.com(?::\d{1,5})?

This setting enables the use of the CORS mechanism on the parent and the child domains, and it is also dynamically installed to the current protocol, domain, port without the use of overriding rules.

<HTTP request methods>. Specify additional methods to access resource. The POST and OPTIONS methods are mandatory.
<HTTP request headers>. Specify headers used by resource. The headers get-ppbi-time,content-type, soapaction, accept-language, cache-control, Authorization are mandatory.

NOTE. Make sure that the specified parameters of the CORS mechanism meet the requirements of the resource in use.

Open the Metabases.xml file for edit that is located in the /opt/foresight/fp10.x-biserver/etc folder and execute the following operations:

Set the Authentication attribute with the value:

2. Integrated domain authentication.
4. Domain authentication.

Make sure that the value of the SERVER parameter is full domain DNS name of server. If IP address is set, replace it.

After executing the operations the BI server is set up.

The example of the Metabases.xml file:

<PP>
  <Metabases>
    <REPOSITORY_ID Name="REPOSITORY_ID" Authentication="4" Driver="DRIVER_ID" Package="STANDARDSECURITYPACKAGE" DebugMode="1">
      <LogonData DATABASE="DATABASE_NAME" SERVER="SERVER_DATABASE"/>
      <Credentials Authentication="4"/>
    </REPOSITORY_ID>
  </Metabases>
</PP>

Where:

REPOSITORY_ID. Unique repository identifier.
DRIVER_ID. DBMS Driver Identifier of repository – POSTGRES.
DATABASE_NAME. Identifier of the database created during DBMS back end preparation. If the metadata repository was created in a custom schema, specify custom schema identifier via the point after the database identifier. For example: DATABASE_NAME.SCHEMA_NAME.
SERVER_DATABASE. Full domain DNS name used for registration of the database server.

Check if full domain DNS name of server is specified in the files:

/etc/opt/foresight/fp10.x-webserver/envvars.

Set up working with directory services.

Restart the BI server.

After executing the operations the BI server is set up to work with Apache2 web server.

Step 4. Setting Up Web Application Back End

To set up web application back end:

Open the PP.xml file for edit located in the /opt/foresight/fp10.x-webserver/config file and specify the empty line as a value of the url attribute in the <proxy> section. For example:

<?xml version="1.0" encoding="utf-8" ?>
<pp>
  <proxy url=""/> <!-- url is set in the PP_SOM environment variable -->
  <metabase id="REPOSITORY_ID" />
  <ServiceCM ParamsUrl="http://web-server.domain.ald:8110/fp10.x/r/#/settings" />
  <modules commonModulesUrl="http://web-server.domain.ald:8110/fp10.x/r/#" />
</pp>

Specify full domain DNS name of the server, on which Apache2 web server is located:

Open the file for edit:

/etc/apache2-fp10.x-web/sites-available/webserver.conf in Debian-based distributions.
/etc/httpd-fp10.x-web/conf.d/00-virtualhost.conf in RedHat-based distributions.
/etc/httpd2-fp10.x-web/conf/sites-available/000-default.conf in ALT Linux.

Specify the ServerName parameter in the <VirtualHost> section. For example:

ServerName web-server.domain.ald

After executing the operations the web application back end is set up.

Step 5. Preparing DBMS Server

To prepare PostgreSQL DBMS server:

Make sure that domain group support is enabled. When working with domain groups, access permissions are granted to DBMS users included in the group without explicit adding of each account in the security manager.

NOTE. Support of domain groups is available if there are groups as roles and users included in these roles on DBMS level.

Set up authentication based on GSSAPI method according to PostgreSQL documentation.
Set up use of full domain user name if required. By default, when a domain user is added to PostgreSQL DBMS, a short user name without domain is used. To use full name, set the USEUPN parameter to True in the file /opt/foresight/fp10.x-biserver/etc/Metabases.xml:

<LogonData ... USEUPN="true"/>

Step 6. Domain User Authorization in the System

To authorize the domain user in the system:

Add domain users and/or groups in the security manager.
Log in to the system using the domain user name. In the login dialog box select the repository, enter domain user name in the format: domain\name and password:

After executing the operations the domain user is authenticated. If the user is authorized successfully, the object navigator opens.