Skip to content

Configurations for Kerberos shielding support

Warning!

In order for Kerberos shielding to be used, administrator accounts must be placed in the Protected Users group.
This forces the Kerberos authentication protocol to be used instead of NTLM. The Edge Gateway must first be configured to support Kerberos authentication.

Configuring the Edge Gateway to support Kerberos authentication with accounts placed in Protected Users

Kerberos shielding provides additional encryption for the initial exchanges between the client and the KDC (Kerberos Domain Controller) using information linked to a computer account.

cyberelements.io or cyberelements Cleanroom preferably run on Debian machines that are not connected to an AD domain, which means that they do not have any computer account information on the AD.
The configuration to support Kerberos shielding consists of two steps:

  • Creating a service computer account in the AD
  • Configuring Kerberos shielding on the Edge Gateway based on the previously created account

Creating a service computer account

Information

This page will use a service account named svc_cyberelements as an example. Adapt the following commands according to the name of your service account.

Warning!

If you want to use PAW workstations, place this service account in the same silo as the target PAW workstations.

From the domain controller, start by creating a computer account with a password used to generate Kerberos tickets.

To create this account, you can use the following Powershell command from a domain controller (adapt the name of the service account, in the svc_cyberelements example, and the desired OU, in the OU=Service_accounts,DC=domain,DC=local example, to create the service account):

1
New-ADComputer -Name svc_cyberelements -SAMAccountName 'svc_cyberelements$' -AccountPassword $Null -Path 'OU=Service_accounts,DC=domain,DC=local'-KerberosEncryptionType AES256 -PasswordNeverExpires $True -Enabled $True

Use the following command to verify that the computer account has been created (replace svc_cyberelements with the name of the account created previously):

1
Get-ADComputer -Identity svc_cyberelements -Properties Enabled

Then use the Windows ktpass tool to export a keytab file that will contain encryption keys that will allow the gateway to retrieve the TGT.

Example

Example for creating a svc_cyberelements.keytab file with the computer account:

1
ktpass /princ 'svc_cyberelements$@DOMAIN.LOCAL' /mapuser 'svc_cyberelements$@DOMAIN.LOCAL' +rndPass /out svc_cyberelements.keytab /crypto AES256-SHA1 /ptype KRB5_NT_SRV_HST /mapop set
Remember to include the $ symbols at the end of account names and to capitalize the domain name (required).

Accept any confirmation prompts that may appear by entering y.

Then reposition the UserPrincipalName attribute value with the following PowerShell command:

1
Set-ADComputer 'svc_cyberelements$' -UserPrincipalName 'svc_cyberelements$@DOMAIN.LOCAL'

Configuring Kerberos shielding on the Edge Gateway

Retrieve the previously generated file keytab and copy it to the Edge Gateway server.
In a context where several keytab files have been generated and must be used on the same Edge Gateway, please combine the keytab files into a single file.

Warning

The keytab file contains encryption keys. If an attacker gets hold of it, they can impersonate the associated computer account, thereby reducing the security of the infrastructure.
This file should therefore not be stored anywhere other than on the Edge Gateway.

Place the file in the /etc/ipdiva/cleanroom/ directory.

Change the keytab file owners to ipdivacareuser for the user and carerecord for the group, then modify the file permissions (modify the keytab file according to the name of your own file):

1
2
chown ipdivacareuser:carerecord /etc/ipdiva/cleanroom/svc_cyberelements.keytab
chmod 640 /etc/ipdiva/cleanroom/svc_cyberelements.keytab

Modify the Edge Gateway /etc/ipdiva/cleanroom/xrdprecord.ini configuration file to specify, via the keytab= parameter, the path to the keytab file prepared previously.

Example

2
keytab=/etc/ipdiva/cleanroom/svc_cyberelements.keytab

At this stage, connecting to privileged RDP applications in agentless mode (HTML5 or otherwise) should work with user accounts belonging to Protected Users and therefore requiring strong Kerberos authentication. The configuration of the RDP application must meet certain prerequisites.

Testing Kerberos configuration

Debugging

The following kinit commands can provide more logs after executing the following command (valid until the SSH or console session is disconnected):

1
export KRB5_TRACE=/dev/stdout

Let's start by retrieving a Kerberos ticket with a command similar to the following:

1
kinit -k -t /etc/ipdiva/cleanroom/svc_cyberelements.keytab 'svc_cyberelements$@DOMAIN.LOCAL' -c /tmp/test_kerberos

Be sure to replace the location of the keytab file, the name of the service account that was created, and its associated domain.

If the Kerberos ticket retrieval was successful, the following command should indicate the existence of a ticket for the service account:

1
klist -c /tmp/test_kerberos

If the retrieval is successful, then it is necessary to attempt to retrieve a ticket for a user with a command similar to the following:

1
kinit -T /tmp/test_kerberos user@DOMAIN.LOCAL

Replace user@DOMAIN.LOCAL with a user who is likely to connect via RDP and Kerberos armoring. Please note that this user's password will be requested.
If the ticket retrieval is successful, the following command will display it:

1
klist -c

If an KDC policy rejects request while getting initial credentials error is displayed, it means that the KDC has denied the ticket request. Possible causes:

  • kinit was unable to use the /tmp/test_kerberos ticket (if kinit cannot use it, it continues without an error message with a basic ticket request)
  • The service account is not present in the silo of the tested user. This occurs when AD is siloed and requires the service computer account to be placed in the appropriate silo.

Additional information can be found in the Sécurité event logs of the domain controller (KDC) used.

Following testing, it is recommended to delete the generated tickets:

1
2
kdestroy
kdestroy -c /tmp/test_kerberos

Combine multiple keytab files into a single file

If the cyberelements.io or cyberelements Cleanroom architecture is based on a single Edge Gateway that will allow access to multiple third parties, it is necessary to merge all the keytab files generated for the different service accounts into a single keytab file.

Note

In this section, we will assume the following keytab files: /root/t0.keytab, /root/t1.keytab and /root/t2.keytab. These files must have been sent to the Edge Gateway.

To merge the keytab files, log in to the Edge Gateway as root, then use the following commands:

1
2
3
4
5
ktutil
rkt /root/t0.keytab
rkt /root/t1.keytab
rkt /root/t2.keytab
wkt /root/unified.keytab

The rkt commands allow you to load as many keytab files as necessary, and the wkt command generates a new keytab file.
Please modify the file paths according to those in your possession.

Press the q key to exit the ktutil utility.

Retrieve the unified.keytab file and follow the Configuring Kerberos shielding on the Edge Gateway section.