Aller au contenu

Groupe Protected Users, authentification Kerberos, silotage AD et poste PAW

La sécurisation des annuaires Active Directory est un enjeu majeur de la sécurisation des infrastructures.

L'ANSSI insiste particulièrement sur l'importance du cloisonnement dans cette sécurisation et sur la mise en place d'un silotage des serveurs avec une authentification Kerberos. Ceci étant mentionné dans leurs recommandations pour l'administration sécurisée des SI reposant sur l'AD.

Nos solutions cyberelements.io ou cyberelements Cleanroom offrent une grande flexibilité sur l'implémentation de cette sécurisation, qui peut être décomposée en quatre niveaux d'intégration différents pouvant être appliqués progressivement :

Configuration des applications RDP pour le support de Kerberos

Attention !

Pour parvenir à paramétrer une application RDP privilégiée ou HTML5 RDP privilégiée pour supporter Kerberos, il vous faut au préalable réaliser la configuration 1 de la ou des Edges Gateways qui seront utilisées pour se connecter en RDP avec Kerberos.

Afin qu'une application privilégiée RDP ou HTML5 RDP puisse se connecter à un serveur RDP avec Kerberos, 4 conditions de paramétrage sont requises :

  1. Le paramétrage du SSO ne peut pas être défini sur Désactivé, il doit donc être Activé, Fixe ou Demander
  2. Le mode sans agent doit être impérativement actif
  3. Le nom du serveur renseigné doit être un FQDN (renseignez l'adresse IP du serveur provoquera un défaut d'authentification)
  4. Kerberos ne doit pas être désactivé dans les paramètres avancés de l'application RDP ou HTML5 RDP
Example

Pour configurer une application RDP privilégiée pour se connecter en Kerberos au serveur RDP my-rds-server, il sera nécessaire de :

  • Définir le niveau de SSO sur un paramètre différent de Désactivé, ici défini à Activé (1), puis activer le mode sans agent (2) et finalement indiquer le nom FQDN du serveur RDP (3)
  • Veiller à ce que Kerberos ne soit pas désactivé (4)
Diagramme des échanges 
flowchart LR
    subgraph WAN
        USER(User workstation)
    end
    subgraph Cloud or DMZ
        MEDIA(Mediation Controller)
    end
    subgraph LAN
        GW(Edge Gateway)
        KDC(Kerberos Domain Controller)
        RDP(RDP Server)
    end

    USER --- |1| MEDIA --> |1| GW
    GW -.- |2| MEDIA -.-> |2| USER
    GW --> |3| KDC
    KDC -.-> |4| GW
    GW --> |5| KDC
    KDC -.-> |6| GW
    GW --> |7| RDP
    RDP -.-> |8| GW
Hold "Ctrl" to enable pan & zoom
  1. L'utilisateur ouvre une application privilégiée RDP ou HTML5 RDP avec support de l'authentification Kerberos
  2. L'utilisateur est connecté sur la Edge Gateway en mode sans agent
  3. La Edge Gateway demande un jeton TGT au Kerberos Domain Controller (KDC)
  4. Le KDC retourne un TGT chiffré et signé
  5. La Edge Gateway demande un ticket de service incluant le TGT précédent
  6. Le KDC retourne le ticket de service chiffré avec clef de service
  7. La Edge Gateway réalise une demande d'accès vers le serveur RDP en incluant le ticket de service
  8. Le serveur RDP approuve l'accès au service et la connexion RDP est initialisée

Configuration des applications RDP pour le support du blindage Kerberos

Attention !

Pour parvenir à paramétrer une application RDP privilégiée ou HTML5 RDP privilégiée pour supporter le blindage Kerberos, il vous faut au préalable réaliser la configuration 1 et 2 de la ou des Edges Gateways qui seront utilisées pour se connecter en RDP avec blindage Kerberos.

Afin qu'une application privilégiée RDP ou HTML5 RDP puisse se connecter à un serveur RDP avec un blindage Kerberos, 5 conditions de paramétrage sont requises :

  1. Le paramétrage du SSO ne peut pas être défini sur Désactivé, il doit donc être Activé, Fixe ou Demander
  2. Le mode sans agent doit être impérativement actif
  3. Le nom du serveur renseigné doit être un FQDN (renseignez l'adresse IP du serveur provoquera un défaut d'authentification)
  4. Kerberos ne doit pas être désactivé dans les paramètres avancés de l'application RDP ou HTML5 RDP
  5. Préciser le nom du compte ordinateur de service à utiliser pour le blindage Kerberos en ajoutant un $ à la fin
Example

Pour configurer une application RDP privilégiée pour se connecter en Kerberos blindé au serveur RDP my-rds-server en utilisant le compte ordinateur svc_cyberelements, il sera nécessaire de :

  • Définir le niveau de SSO sur un paramètre différent de Désactivé, ici défini à Activé (1), puis activer le mode sans agent (2) et finalement indiquer le nom FQDN du serveur RDP (3)
  • Veiller à ce que Kerberos ne soit pas désactivé (4) et que le nom du compte ordinateur de service soit indiqué en n'oubliant pas l'ajout du caractère $ (5)
Diagramme des échanges 
flowchart LR
    subgraph WAN
        USER(User workstation)
    end
    subgraph Cloud or DMZ
        MEDIA(Mediation Controller)
    end
    subgraph LAN
        GW(Edge Gateway)
        KDC(Kerberos Domain Controller)
        RDP(RDP Server)
    end

    USER --- |1| MEDIA --> |1| GW
    GW -.- |2| MEDIA -.-> |2| USER
    GW --> |3| KDC
    KDC -.-> |4| GW
    GW --> |5| KDC
    KDC -.-> |6| GW
    GW --> |7| RDP
    RDP -.-> |8| GW
Hold "Ctrl" to enable pan & zoom
  1. L'utilisateur ouvre une application privilégiée RDP ou HTML5 RDP avec support de l'authentification Kerberos
  2. L'utilisateur est connecté sur la Edge Gateway en mode sans agent
  3. La Edge Gateway demande un jeton TGT au Kerberos Domain Controller (KDC) en utilisant les informations du compte ordinateur de service
  4. Le KDC retourne un TGT chiffré et signé
  5. La Edge Gateway demande un ticket de service incluant le TGT précédant
  6. Le KDC retourne le ticket de service chiffré avec clef de service
  7. La Edge Gateway réalise une demande d'accès vers le serveur RDP en incluant le ticket de service
  8. Le serveur RDP approuve l'accès au service et la connexion RDP est initialisée

Spécificités de l'architecture dans un contexte de silotage AD

Attention !

Dans un contexte où l'Active Directory est siloté, il est normalement paramétré l'utilisation de Kerberos blindé pour les comptes administrateurs. Par conséquent il est nécessaire de réaliser les configurations 1 et 2 pour la ou les Edges Gateways qui seront utilisées pour se connecter à des serveurs RDP.

Lorsque cyberelements.io ou cyberelements Cleanroom est utilisé dans un contexte de silotage AD, le compte ordinateur de service utilisé pour le blindage Kerberos doit être affecté à un silo.
Cela sous-entend que s'il est nécessaire d'accéder à des machines en RDP appartenant à différents tiers, il sera nécessaire de créer autant de compte ordinateur de service placé dans les différents tiers cibles.

L'architecture du produit peut elle aussi être impactée.
Cette modification intervient essentiellement sur le nombre de Edge Gateways déployées où il est recommandé d'en avoir au moins une dédiée à l'accès d'un tiers particulier. Pour autant, si le contexte ne permet pas de déployer autant de Edges Gateways une architecture à Edge Gateway unique peut elle aussi être utilisée :

flowchart LR
    subgraph WAN
        USER(User workstation)
    end
    subgraph Cloud or DMZ
        MED(Mediation Controller)
    end
    subgraph LAN
        subgraph T2
            GW-T2(Edge Gateway T2)
            RDP-T2(RDP Server T2)
        end
        subgraph T1
            GW-T1(Edge Gateway T1)
            RDP-T1(RDP Server T1)
        end
        subgraph T0
            GW-T0(Edge Gateway T0)
            KDC(Kerberos Domain Controller)
            RDP-T0(RDP Server T0)
        end
    end

    USER ==TLS/HTTPS==> MED

    MED ~~~ GW-T0
    MED ~~~ GW-T1
    MED ~~~ GW-T2

    GW-T0 ==TLS==> MED
    GW-T0 ~~~ MED
    GW-T0 ~~~ MED
    GW-T0 ~~~ MED
    GW-T0 --Kerberos/LDAPS--> KDC
    GW-T0 -..-> |RDP| RDP-T0

    GW-T1 ==TLS==> MED
    GW-T1 ~~~ MED
    GW-T1 ~~~ MED
    GW-T1 --Kerberos/LDAPS--> KDC
    GW-T1 -..-> |RDP| RDP-T1

    GW-T2 ==TLS==> MED
    GW-T2 ~~~ MED
    GW-T2 --Kerberos/LDAPS--> KDC
    GW-T2 -..-> |RDP| RDP-T2
Hold "Ctrl" to enable pan & zoom

Avec cette architecture, le paramétrage des applications RDP est identique à celui pour le support du blindage Kerberos.

flowchart LR
    subgraph WAN
        USER(User workstation)
    end
    subgraph Cloud or DMZ
        MED(Mediation Controller)
    end
    subgraph LAN
        GW(Edge Gateway)
        subgraph T2
            RDP-T2(RDP Server T2)
        end
        subgraph T1
            RDP-T1(RDP Server T1)
        end
        subgraph T0
            KDC(Kerberos Domain Controller)
            RDP-T0(RDP Server T0)
        end
    end

    USER ==TLS/HTTPS==> MED

    MED ~~~ GW

    GW ==TLS==> MED
    GW ~~~ MED
    GW --Kerberos/LDAPS--> KDC
    GW-.-> |RDP| RDP-T0
    GW -.-> |RDP| RDP-T1
    GW -.-> |RDP| RDP-T2
Hold "Ctrl" to enable pan & zoom

Avec cette architecture, le paramétrage des applications RDP est identique à celui pour le support du blindage Kerberos.
Cependant il doit aussi être prévu d'appliquer un fichier keytab à la Edge Gateway de connexion contenant plusieurs comptes de service.

Spécificités de la connexion à un poste PAW

Un poste PAW (Privileged Access Workstation) est un poste dédié à des tâches d'administration sur un tiers défini.
Du fait de la criticité de ce poste, un renforcement des paramètres de sécurités du poste est très souvent appliqué. Parmi les renforcements appliqués, le principe de ne pas exposer de services sur le réseau permet d'assurer qu'aucune porte dérobée ou service présentant des failles de sécurité ne puisse être exploité.

Ce dernier principe rend donc théoriquement impossible l'accès distant au poste PAW. Pour autant cyberelements.io ou cyberelements Cleanroom permettent d'établir une connexion au poste PAW sans avoir le moindre service en écoute sur le réseau local grâce à :

  • L'activation des services Bureau à distance
  • Paramétrage du pare-feu local pour interdire l'accès au service bureau à distance par toutes adresses IP différentes de celles du poste PAW ou localhost
  • L'installation d'une Edge Gateway incorporée qui permettra de donner l'accès, localement, au service bureau à distance du poste PAW
flowchart LR
    subgraph WAN
        USER(User workstation)
    end
    subgraph Cloud or DMZ
        MED(Mediation Controller)
    end
    subgraph LAN
        subgraph T1
            GW(Edge Gateway T1)
            subgraph PAW_T1 [PAW T1]
                RDP{{RDP Server}}
                GW-WIN{{Embeded Edge Gateway}}
            end
        end
        subgraph T0
            KDC(Kerberos Domain Controller)
        end
    end

    USER ==TLS/HTTPS==> MED

    MED ~~~ GW & GW-WIN
    GW & GW-WIN ==TLS==> MED
    GW & GW-WIN ~~~ MED

    GW & PAW_T1 --> |Kerberos/LDAPS| KDC

    GW-WIN -.-> |RDP| RDP

    GW --x |No connection available| PAW_T1
Hold "Ctrl" to enable pan & zoom 
flowchart LR
    subgraph WAN
        USER(User workstation)
    end
    subgraph Cloud or DMZ
        MED(Mediation Controller)
    end
    subgraph LAN
        subgraph T1
            GW(Edge Gateway T1)
            subgraph PAW_T1 [PAW T1]
                RDP{{RDP Server}}
                GW-WIN{{Embeded Edge Gateway}}
            end
        end
        subgraph T0
            KDC(Kerberos Domain Controller)
        end
    end

    USER --- |1| MED --> |1| GW
    GW -.- |2| MED -.-> |2| USER
    GW --> |3| KDC
    KDC -.-> |4| GW
    GW --> |5| KDC
    KDC -.-> |6| GW
    MED --> |7| GW & GW-WIN
    GW --- |8| MED --- |8| GW-WIN --> |8| RDP
    RDP -.- |9| GW-WIN -.- |9| MED -.-> |9| GW
Hold "Ctrl" to enable pan & zoom
  1. L'utilisateur ouvre une application privilégiée RDP ou HTML5 RDP avec support de l'authentification Kerberos en direction d'un poste PAW
  2. L'utilisateur est connecté sur la Edge Gateway en mode sans agent
  3. La Edge Gateway demande un jeton TGT au Kerberos Domain Controller (KDC) en utilisant les informations du compte ordinateur de service
  4. Le KDC retourne un TGT chiffré et signé
  5. La Edge Gateway demande un ticket de service incluant le TGT précédant
  6. Le KDC retourne le ticket de service chiffré avec clef de service
  7. Le Mediation Controller annonce à la Edge Gateway ainsi qu'à la Edge Gateway incorporée qu'un tunnel est ouvert entre eux, le tunnel passant par le Mediation Controller
  8. La Edge Gateway réalise une demande d'accès vers le serveur RDP en incluant le ticket de service en passant par le Mediation Controller et la Edge Gateway incorporée
  9. Le serveur RDP approuve l'accès au service et la connexion RDP est initialisée

Prérequis sur le poste PAW

Les prérequis spécifiques à appliquer sur le poste PAW (Privileged Access Workstation) pour la connexion de cyberelements.io ou cyberelements Cleanroom se résument à :

  1. Activer le service Bureau à distance
  2. Modifier le pare-feu local pour interdire l'accès au service Bureau à distance pour toutes les machines sauf le poste PAW lui-même
  3. Modification du comportement de Kerberos blindé pour toujours fournir les revendications
  4. Installation d'une Edge Gateway Windows en mode incorporé

Activation du service Bureau à distance

L'activation du service Bureau à distance peut être manuel tel que décrit dans la documentation Microsoft Activer le Bureau à distance sur votre PC.
Mais il est aussi possible d'utiliser une GPO pour activer le service :

  • Chemin vers le paramètre de GPO : Configuration ordinateur > Stratégies > Modèles d'administration > Composants Windows > Services Bureau à distance> Hôte de la session Bureau à distance > Connexions
  • Paramètre : Autoriser les utilisateurs à se connecter à l'aide des services Bureau à distance
  • Valeur : Activé

Modification des règles de pare-feu

Pour des raisons de sécurité, il est important de restreindre les accès au niveau du pare-feu afin d’interdire les accès depuis l’extérieur sur le port RDP.

Par défaut, lors de l’activation du RDP, Windows va positionner 2 règles de pare-feu autorisant les accès sur le port 3389 en UDP et en TCP.
Ces 2 règles sont à modifier afin de n’autoriser les connexions RDP que depuis l’adresse IP distante 127.0.0.1.

Si ces règles n’existent pas, il est nécessaire de les créer manuellement sur le serveur ou via une GPO.

Modification du comportement du Kerberos blindé

Une modification du comportement du Kerberos est aussi nécessaire.

Pour cela vous pouvez mettre en place la GPO suivante :

  • Chemin vers le paramètre de GPO : Configuration d’ordinateur > Stratégies > Modèles d’administration > Système > KDC
  • Paramètre : Prise en charge du contrôleur de domaine Kerberos pour les revendications, l’authentification composée et le blindage Kerberos
  • Valeur : Activé, Toujours fournir les revendications

Cette modification n’a pas d’incidence sur la sécurité de l’implémentation du silotage AD et du Kerberos renforcé.

Installation d'une Edge Gateway Windows en mode incorporé

Prérequis

Avant de poursuivre, veuillez installer une Edge Gateway Windows sur le poste PAW et la connecter au Mediation Controller : Installer une Edge Gateway Windows

Après installation de la Edge Gateway Windows, il est nécessaire de la basculer en mode incorporé.

Accédez à l'interface Web du serveur Mediation Controller ou de votre tenant cyberelements.io avec l'URI /console.

Exemples

Si l'accès au Mediation Controller sur son adresse IP Web est 10.0.10.10, alors l'accès à l'interface system utilisera l'URL : https://10.0.10.10/console.

Si l'accès au Mediation Controller est possible avec un nom DNS, par exemple cyberelements-cleanroom.domain.local, alors l'accès à l'interface system utilisera l'URL : https://cyberelements-cleanroom.domain.local/console.

Si la plateforme utilisée est cyberelements.io alors l'accès peut se faire simplement via l'accès à son tenant, par exemple pour un nom de tenant my-tenant l'accès serait le suivant : https://my-tenant.cyberelements.io.
Il est aussi possible d'accèder directement au fomulaire de connexion de la console d'administration via https://my-tenant.cyberelements.io/console.

Une fois connecté, veillez à supprimer la déclaration de la Edge Gateway Windows depuis le module Gestion des passerelles.

La Edge Gateway Windows est maintenant prête à être utilisée comme une Edge Gateway incorporée.

A l'ouverture d'une session, le moniteur de la Edge Gateway Windows démarre automatiquement (visible avec l'icône type:inline dans la barre des tâches). Ce démarrage automatique n'étant pas requis dans l'exploitation des postes PAW, il est nécessaire de le désactiver :

  1. Ouvrez l'éditeur de clefs de registre regedit.exe en tant qu'administrateur
  2. Rendez-vous dans la ruche registre HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
  3. Supprimez la clef IPdivaGateway Monitor
  4. Redémarrez le poste PAW

Configuration des applications RDP pour la connexion à un poste PAW

Attention !

Pour parvenir à paramétrer une application RDP privilégiée ou HTML5 RDP privilégiée pour se connecter à un poste PAW, il vous faut au préalable réaliser les configurations 1 à 3 de la ou des Edges Gateways qui seront utilisées pour se connecter aux postes PAW.

Afin qu'une application privilégiée RDP ou HTML5 RDP puisse se connecter à un poste PAW, 6 conditions de paramétrage sont requises :

  1. Le paramétrage du SSO ne peut pas être défini sur Désactivé, il doit donc être Activé, Fixe ou Demander
  2. Le mode sans agent doit être impérativement actif
  3. Le nom du serveur renseigné doit être un FQDN (renseignez l'adresse IP du serveur provoquera un défaut d'authentification)
  4. Configurer le passage par une Edge Gateway incorporée
  5. Kerberos ne doit pas être désactivé dans les paramètres avancés de l'application RDP ou HTML5 RDP
  6. Préciser le nom du compte ordinateur de service à utiliser pour le blindage Kerberos en ajoutant un $ à la fin

La condition 4 est induite par le paramétrage des postes PAW qui ne doivent pas avoir de services en écoute sur le réseau local, en installant une Edge Gateway sous forme de programme Windows, cette dernière peut avoir accès aux services en écoute sur localhost uniquement.

Example

Pour configurer une application RDP privilégiée pour se connecter en Kerberos blindé au serveur RDP my-rds-server en utilisant le compte ordinateur svc_cyberelements, il sera nécessaire de :

  • Définir le niveau de SSO sur un paramètre différent de Désactivé, ici défini à Activé (1), puis activer le mode sans agent (2), indiquer encore le nom FQDN du serveur RDP (3) et finalement activez le mode Edge Gateway incorporée et précisez le nom de la Edge Gateway Windows qui a été installé sur le poste PAW (4)
  • Veiller à ce que Kerberos ne soit pas désactivé (5) et que le nom du compte ordinateur de service soit indiqué en n'oubliant pas l'ajout du caractère $ (6)

Débogage des ouvertures d'applications RDP avec authentification Kerberos

Afin de permettre de réaliser une première analyse ou de récupérer les éléments nécessaires à Systancia pour une analyse avancée de défaut d'authentification Kerberos, veuillez réaliser les actions suivantes :

  1. Activation des logs de débogage : pour se faire basculez le paramètre debug sous la balise [Kerberos] à true dans le fichier /etc/ipdiva/cleanroom/xrdprecord.ini du serveur Edge Gateway utilisé pour la connexion. Cette action pouvant être réalisée avec la commande suivante : 
    1
    sed -i "3s/false/true/" /etc/ipdiva/cleanroom/xrdprecord.ini

  2. Connectez-vous au portail utilisateur et lancez une application privilégiée, RDP ou RDP HTML5, en mode sans agent et paramétrée pour utiliser Kerberos. Notez les informations suivantes :

    • Heure d'ouverture de l'application
    • Le nom d'utilisateur utilisé pour se connecter au serveur RDP

  3. Sur la Edge Gateway utilisée pour la connexion précédente, récupérez les fichiers suivants :

    • /var/log/syslog : ce fichier contient notamment les logs pour le lancement de la session en mode sans agent.
    • /var/lib/ipdiva/carerecord/log/freerdpout-<USER>-<DATE>.txt : remplacez <USER> par le nom d'utilisateur et <DATE> par la date et heure d'ouverture de l'application récupérée à la précédente étape. Ce fichier contient les logs liés à l'établissement de la session RDP comprenant la phase d'authentification Kerberos.

  4. Désactivation des logs de débogage : pour se faire basculez le paramètre debug sous la balise [Kerberos] à false dans le fichier /etc/ipdiva/cleanroom/xrdprecord.ini du serveur Edge Gateway utilisé pour la connexion. Cette action pouvant être réalisée avec la commande suivante : 

    1
    sed -i "3s/true/false/" /etc/ipdiva/cleanroom/xrdprecord.ini