Rechercher
SupportConsoleDéveloppeursCommencer un essaiContact

3.5. Application du contrôle d'accès aux objets de stratégie de groupe dans RHEL

download PDF

Un GPO ( Group Policy Object ) est un ensemble de paramètres de contrôle d'accès stockés dans Microsoft Active Directory (AD) qui peuvent s'appliquer aux ordinateurs et aux utilisateurs dans un environnement AD. En spécifiant des GPO dans AD, les administrateurs peuvent définir des politiques de connexion honorées par les clients Windows et les hôtes Red Hat Enterprise Linux (RHEL) connectés à AD.

Les sections suivantes décrivent comment vous pouvez gérer les GPO dans votre environnement :

3.5.1. Comment SSSD interprète les règles de contrôle d'accès aux GPO

Par défaut, SSSD récupère les objets de stratégie de groupe (GPO) des contrôleurs de domaine Active Directory (AD) et les évalue pour déterminer si un utilisateur est autorisé à se connecter à un hôte RHEL particulier joint à AD.

SSSD associe AD Windows Logon Rights aux noms de service PAM (Pluggable Authentication Module) afin d'appliquer ces autorisations dans un environnement GNU/Linux.

En tant qu'administrateur AD, vous pouvez limiter la portée des règles GPO à des utilisateurs, groupes ou hôtes spécifiques en les répertoriant sur le site security filter.

Limitations du filtrage par les hôtes

Les anciennes versions de SSSD n'évaluent pas les hôtes dans les filtres de sécurité AD GPO.

  • RHEL 8.3.0 and newer: SSSD prend en charge les utilisateurs, les groupes et les hôtes dans les filtres de sécurité.
  • RHEL versions older than 8.3.0: SSSD ignore les entrées d'hôtes et ne prend en charge que les utilisateurs et les groupes dans les filtres de sécurité.
    Pour s'assurer que SSSD applique le contrôle d'accès basé sur les GPO à un hôte spécifique, créez une nouvelle unité d'organisation (OU) dans le domaine AD, déplacez le système vers la nouvelle OU, puis liez les GPO à cette OU.

Limitations du filtrage par groupes

SSSD ne prend actuellement pas en charge les groupes intégrés d'Active Directory, tels que Administrators avec Security Identifier (SID) S-1-5-32-544. Red Hat recommande de ne pas utiliser les groupes intégrés AD dans les GPO AD ciblant les hôtes RHEL.

Ressources supplémentaires

3.5.2. Liste des paramètres GPO pris en charge par SSSD

Le tableau suivant présente les options SSSD qui correspondent aux options GPO Active Directory telles qu'elles sont spécifiées dans le site Group Policy Management Editor sous Windows.

Tableau 3.1. Options de contrôle d'accès aux GPO récupérées par SSSD
Option GPOOption correspondante sssd.conf

Autoriser la connexion locale
Refuser la connexion locale

ad_gpo_map_interactive

Autoriser la connexion via les services de bureau à distance
Refuser la connexion via les services de bureau à distance

ad_gpo_map_remote_interactive

Accéder à cet ordinateur à partir du réseau
Refuser l'accès à cet ordinateur à partir du réseau

ad_gpo_map_network

Autoriser la connexion en tant que travail par lots
Refuser la connexion en tant que travail par lots

ad_gpo_map_batch

Autoriser la connexion en tant que service
Refuser la connexion en tant que service

ad_gpo_map_service

Ressources supplémentaires

  • Pour plus d'informations sur ces paramètres sssd.conf, tels que les services PAM (Pluggable Authentication Module) qui correspondent aux options GPO, voir l'entrée de page du manuel sssd-ad(5).

3.5.3. Liste des options SSSD permettant de contrôler l'application des GPO

Vous pouvez définir les options SSSD suivantes pour limiter la portée des règles GPO.

L'option ad_gpo_access_control

Vous pouvez définir l'option ad_gpo_access_control dans le fichier /etc/sssd/sssd.conf pour choisir entre trois modes différents de fonctionnement du contrôle d'accès basé sur les GPO.

Tableau 3.2. Tableau des valeurs ad_gpo_access_control
Valeur de
ad_gpo_access_control		Comportement

enforcing

Les règles de contrôle d'accès basées sur les GPO sont évaluées et appliquées.
This is the default setting in RHEL 8.

permissive

Les règles de contrôle d'accès basées sur les GPO sont évaluées mais not appliquées ; un message syslog est enregistré chaque fois que l'accès est refusé. Il s'agit du paramètre par défaut dans RHEL 7.
Ce mode est idéal pour tester les ajustements de politique tout en permettant aux utilisateurs de continuer à se connecter.

disabled

Les règles de contrôle d'accès basées sur les GPO ne sont ni évaluées ni appliquées.

L'option ad_gpo_implicit_deny

L'option ad_gpo_implicit_deny est définie par défaut sur False. Dans cet état par défaut, les utilisateurs sont autorisés à accéder si les GPO applicables ne sont pas trouvés. Si vous définissez cette option sur True, vous devez explicitement autoriser l'accès des utilisateurs à l'aide d'une règle de GPO.

Vous pouvez utiliser cette fonctionnalité pour renforcer la sécurité, mais veillez à ne pas refuser l'accès involontairement. Red Hat recommande de tester cette fonctionnalité lorsque ad_gpo_access_control est défini sur permissive.

Les deux tableaux suivants montrent quand un utilisateur est autorisé ou refusé en fonction des droits de connexion autorisés et refusés définis du côté du serveur AD et de la valeur de ad_gpo_implicit_deny.

Tableau 3.3. Comportement de connexion avec ad_gpo_implicit_deny défini sur False (default)
autoriser les règlesrègles de refusrésultat

manquant

manquant

tous les utilisateurs sont autorisés

manquant

présent

seuls les utilisateurs ne figurant pas dans les règles de refus sont autorisés

présent

manquant

seuls les utilisateurs figurant dans les règles d'autorisation sont autorisés

présent

présent

seuls les utilisateurs figurant dans les règles d'autorisation (allow-rules) et non dans les règles de refus (deny-rules) sont autorisés

Tableau 3.4. Comportement de connexion avec ad_gpo_implicit_deny réglé sur True
autoriser les règlesrègles de refusrésultat

manquant

manquant

aucun utilisateur n'est autorisé

manquant

présent

aucun utilisateur n'est autorisé

présent

manquant

seuls les utilisateurs figurant dans les règles d'autorisation sont autorisés

présent

présent

seuls les utilisateurs figurant dans les règles d'autorisation (allow-rules) et non dans les règles de refus (deny-rules) sont autorisés

Ressources supplémentaires

  • Pour la procédure de modification du mode d'application des GPO dans SSSD, voir Modification du mode de contrôle d'accès aux GPO.
  • Pour plus de détails sur chacun des différents modes de fonctionnement des GPO, voir l'entrée ad_gpo_access_control dans la page du manuel sssd-ad(5).

3.5.4. Modifier le mode de contrôle d'accès aux GPO

Cette procédure modifie la manière dont les règles de contrôle d'accès basées sur les GPO sont évaluées et appliquées sur un hôte RHEL connecté à un environnement Active Directory (AD).

Dans cet exemple, vous allez changer le mode de fonctionnement de la GPO de enforcing (par défaut) à permissive à des fins de test.

Important

Si les erreurs suivantes s'affichent, cela signifie que les utilisateurs d'Active Directory ne peuvent pas se connecter en raison des contrôles d'accès basés sur les GPO :

  • Sur /var/log/secure: 

    Oct 31 03:00:13 client1 sshd[124914]: pam_sss(sshd:account): Access denied for user aduser1: 6 (Permission denied)
Oct 31 03:00:13 client1 sshd[124914]: Failed password for aduser1 from 127.0.0.1 port 60509 ssh2
Oct 31 03:00:13 client1 sshd[124914]: fatal: Access denied for user aduser1 by PAM account configuration [preauth]

  • Sur /var/log/sssd/sssd__example.com_.log: 

    (Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_perform_hbac_processing] (0x0040): GPO access check failed: [1432158236](Host Access Denied)
(Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_cse_done] (0x0040): HBAC processing failed: [1432158236](Host Access Denied}
(Sat Oct 31 03:00:13 2020) [sssd[be[example.com]]] [ad_gpo_access_done] (0x0040): GPO-based access control failed.

Si ce comportement n'est pas souhaité, vous pouvez temporairement attribuer la valeur ad_gpo_access_control à permissive, comme décrit dans cette procédure, pendant que vous recherchez les paramètres GPO appropriés dans AD.

Conditions préalables

  • Vous avez joint un hôte RHEL à un environnement AD à l'aide de SSSD.
  • La modification du fichier de configuration /etc/sssd/sssd.conf nécessite les autorisations de root.

Procédure

  1. Arrêtez le service SSSD. 

    [root@server ~]# systemctl stop sssd
  2. Open the /etc/sssd/sssd.conf file in a text editor.

  3. Définissez ad_gpo_access_control à permissive dans la section domain pour le domaine AD. 

    [domain/example.com]
ad_gpo_access_control=permissive
...
  4. Enregistrez le fichier /etc/sssd/sssd.conf.

  5. Redémarrez le service SSSD pour charger les modifications de configuration. 

    [root@server ~]# systemctl restart sssd

Ressources supplémentaires

3.5.5. Création et configuration d'une GPO pour un hôte RHEL dans l'interface graphique AD

Un objet de stratégie de groupe (GPO) est un ensemble de paramètres de contrôle d'accès stockés dans Microsoft Active Directory (AD) qui peuvent s'appliquer aux ordinateurs et aux utilisateurs dans un environnement AD. La procédure suivante crée un GPO dans l'interface utilisateur graphique (GUI) AD pour contrôler l'accès à la connexion d'un hôte RHEL intégré directement au domaine AD.

Conditions préalables

  • Vous avez joint un hôte RHEL à un environnement AD à l'aide de SSSD.
  • Vous disposez des privilèges d'administrateur AD pour effectuer des modifications dans AD à l'aide de l'interface graphique.

Procédure

  1. Dans Active Directory Users and Computers, créez une unité d'organisation (OU) à associer au nouveau GPO :

    1. Cliquez avec le bouton droit de la souris sur le domaine.
    2. Choisissez New.
    3. Choisissez Organizational Unit.
  2. Cliquez sur le nom de l'objet ordinateur qui représente l'hôte RHEL (créé lorsqu'il a rejoint Active Directory) et faites-le glisser dans la nouvelle OU. En plaçant l'hôte RHEL dans sa propre OU, la GPO cible cet hôte.

  3. Dans le site Group Policy Management Editor, créez une nouvelle GPO pour l'OU que vous avez créée :

    1. Développer Forest.
    2. Développer Domains.
    3. Élargissez votre domaine.
    4. Cliquez avec le bouton droit de la souris sur la nouvelle OU.
    5. Choisissez Create a GPO in this domain.
  4. Spécifiez un nom pour le nouveau GPO, par exemple Allow SSH access ou Allow Console/GUI access et cliquez sur OK.

  5. Modifiez la nouvelle GPO :

    1. Sélectionnez l'OU dans l'éditeur Group Policy Management.
    2. Cliquez avec le bouton droit de la souris et choisissez Edit.
    3. Sélectionnez User Rights Assignment.
    4. Sélectionner Computer Configuration
    5. Sélectionnez Policies.
    6. Sélectionnez Windows Settings.
    7. Sélectionnez Security Settings.
    8. Sélectionnez Local Policies.
    9. Sélectionnez User Rights Assignment.

  6. Attribuer des autorisations de connexion :

    1. Double-cliquez sur Allow log on locally pour autoriser l'accès à la console locale/à l'interface utilisateur.
    2. Double-cliquez sur Allow log on through Remote Desktop Services pour accorder l'accès SSH.

  7. Ajoutez le(s) utilisateur(s) que vous souhaitez voir accéder à l'une ou l'autre de ces politiques aux politiques elles-mêmes :

    1. Cliquez sur Add User or Group.
    2. Saisissez le nom d'utilisateur dans le champ vide.
    3. Cliquez sur OK.

Ressources supplémentaires

3.5.6. Ressources supplémentaires

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.