Configurations pour le support du blindage Kerberos

Attention !

Pour que le blindage Kerberos soit utilisé, il est nécessaire que les comptes administrateurs soient placés dans le groupe Protected Users.
Cela a comme impact le fait de forcer le protocole d'authentification Kerberos à la place de NTLM. La Edge Gateway devant au préalable avoir été paramétrée pour supporter l'authentification Kerberos.

Configuration de la Edge Gateway pour son support de l'authentification Kerberos avec des comptes placés dans Protected Users

Le blindage Kerberos a pour principe d'apporter un chiffrement complémentaire des premiers échanges entre le client et le KDC (Kerberos Domain Controller) en utilisant les informations liées à un compte ordinateur.

Cyberelements.io ou cyberelements Cleanroom fonctionnant préférablement sur des machines Debian non reliées à un domaine AD, ces dernières ne possèdent donc pas d'informations d'un compte ordinateur sur l'AD.
Le paramétrage pour supporter le blindage Kerberos se constitue de deux étapes :

• La création d'un compte ordinateur de service dans l'AD
• Le paramétrage du blindage Kerberos sur l'Edge Gateway en se basant sur le compte précédemment créé

Création d'un compte ordinateur de service

Information

Cette page utilisera un compte de service nommé svc_cyberelements comme exemple. Adaptez les commandes suivantes en fonction du nom de votre compte de service.

Attention !

Si vous voulez exploiter des postes PAW, positionnez ce compte de service dans le même silo que les postes PAW cibles.

Depuis le contrôleur de domaine, commencez par créer un compte ordinateur avec un mot de passe servant à générer les tickets Kerberos.

Pour créer ce compte, il est possible d'utiliser la commande Powershell suivante depuis un contrôleur de domaine (adaptez le nom du compte de service, dans l'exemple svc_cyberelements, et l'OU souhaitée, dans l'exemple OU=Service_accounts,DC=domain,DC=local, pour la création du compte de service) :

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

Utilisez la commande suivante pour vérifier que le compte ordinateur est bien créé (remplacer svc_cyberelements par le nom du compte créé précédemment) :

Get-ADComputer -Identity svc_cyberelements -Properties Enabled

Utilisez ensuite l'outil ktpass de Windows afin d'exporter un fichier keytab qui contiendra des clés de chiffrement qui permettront à la passerelle de récupérer le TGT.

Exemple

Exemple pour la création d'un fichier svc_cyberelements.keytab avec le compte d'ordinateur :

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

N'oubliez pas les symboles $ à la fin des noms de comptes et de mettre le nom de domaine en majuscules (obligatoire).

Acceptez chaque demande de confirmation qui pourrait s'afficher par y.

Repositionnez ensuite la valeur de l'attribut UserPrincipalName avec la commande PowerShell suivante :

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

Configuration du blindage Kerberos sur l'Edge Gateway

Récupérez le fichier keytab généré précédemment et copiez-le sur le serveur Edge Gateway.
Dans un contexte où plusieurs fichiers keytab ont été générés et doivent être utilisés sur une même Edge Gateway, veuillez combiner les fichiers keytab en un seul fichier.

Attention

Le fichier keytab contient des clés de chiffrement. Si un attaquant s'en empare, il peut usurper l'identité du compte d'ordinateur associé, réduisant ainsi la sécurité de l'infrastructure.
Ce fichier n'est donc pas à conserver autre part que sur l'Edge Gateway.

Positionnez le fichier dans le répertoire /etc/ipdiva/cleanroom/.

Changez les propriétaires du fichier keytab pour ipdivacareuser pour l'utilisateur et carerecord pour le groupe puis modifiez les droits du fichier (modifier le fichier keytab en fonction du nom de votre propre fichier) :

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

Modifier le fichier de configuration /etc/ipdiva/cleanroom/xrdprecord.ini de la Edge Gateway afin de lui indiquer, via le paramètre keytab=, le chemin vers le fichier keytab préparé précédemment.

Exemple

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

A ce stade, la connexion à des applications RDP privilégiées en mode sans agent (HTML5 ou non) doit fonctionner avec des comptes utilisateurs appartenant à Protected Users et nécessitant donc une authentification Kerberos blindée. Le paramétrage de l'application RDP devant respecter certains prérequis.

Test de la configuration Kerberos

Débogage

Les commandes kinit suivantes peuvent fournir plus de logs après avoir exécuté la commande suivante (valide jusqu'à déconnexion de la session SSH ou console) :

export KRB5_TRACE=/dev/stdout

Débutons par la récupération d'un ticket Kerberos avec une commande similaire à la suivante :

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

Veillez à remplacer l'emplacement du fichier keytab ainsi que le nom du compte de service qui a été créé et son domaine associé.

Si la récupération du ticket Kerberos a réussi, la commande suivante devra indiquer l'existance d'un ticket pour le compte de service :

klist -c /tmp/test_kerberos

Si la récupération est un succès alors il est nécessaire de tenter la récupération d'un ticket pour un utilisateur avec une commande similaire à la suivante :

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

Remplacez user@DOMAIN.LOCAL par un utilisateur susceptible de se connecter en RDP et en Kerberos blindé. Attention le mot de passe de cet utilisateur sera demandé.
Si la récupération d'un ticket est un succès, la commande suivante le fera apparaître :

klist -c

Si une erreur KDC policy rejects request while getting initial credentials est affichée, cela signifie que le KDC a refusé la demande de ticket. Causes possibles :

• kinit n'a pas pu utiliser le ticket /tmp/test_kerberos (si kinit n'arrive pas à l'utiliser, il continue sans message d'erreur avec une demande de ticket basique)
• Le compte de service n'est pas présent dans le silo de l'utilsateur testé. Cela survient lorsque l'AD est siloté et impose le placement du compte ordinateur de service dans le silo adapté.

Des informations complémentaires peuvent être trouvées dans les journaux d’évènements Sécurité du contrôleur de domaine (KDC) utilisé.

Suite aux tests, il est recommandé de supprimer les tickets générés :

kdestroy
kdestroy -c /tmp/test_kerberos

Combiner plusieurs fichiers keytab dans un seul fichier

Si l'architecture cyberelements.io ou cyberelements Cleanroom repose sur une mono Edge Gateway qui permettra l'accès à plusieurs tiers, il est nécessaire de fusionner en un seul fichier keytab l'ensemble des fichiers keytab générés pour les différents comptes de service.

Note

Dans cette section, nous supposerons les fichiers keytab suivants : /root/t0.keytab, /root/t1.keytab et /root/t2.keytab. Ces fichiers doivent avoir été envoyés sur la Edge Gateway.

Pour fusionner les fichiers keytab, connectez-vous à la Edge Gateway, en tant que root, puis utilisez les commandes suivantes :

ktutil
rkt /root/t0.keytab
rkt /root/t1.keytab
rkt /root/t2.keytab
wkt /root/unified.keytab

Les commandes rkt permettent de charger autant de fichiers keytab que nécessaire et la commande wkt permet de générer un nouveau fichier keytab.
Veuillez modifier les chemins des fichiers en fonction de ceux en votre possession.

Pressez la touche Q pour quitter l'utilitaire ktutil.

Récupérez le fichier unified.keytab puis suivez la section Configuration du blindage Kerberos sur l'Edge Gateway.