Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

RDS – Le durcissement des serveurs casse le SSO

L’application de stratégies de durcissement (hardening) standard telles que les baselines Microsoft ou les benchmarks CIS peut avoir des effets de bord parfois compliqués à élucider.

Dans le cas qui nous intéresse, le Single Sign On ne fonctionnait plus sur une ferme Remote Desktop suite à l’application des baselines Microsoft : lors de l’ouverture d’une RemoteApp via le portail RDWeb, une popup d’authentification apparaissait au lieu de démarrer l’application de façon transparente.


La stratégie responsable de ce comportement est Computer Configuration\Policies\Administrative Templates\Windows
Components\Remote Desktop Services\Remote Desktop Session
Host\Security\Always prompt for password upon connection : comme son nom l’indique, elle force le service Remote Desktop à demander un mot de passe lors de la connexion ce qui bloque implicitement le SSO.

Il est donc nécessaire de créer une GPO qui va venir « remplacer » ce paramètre de durcissement uniquement pour les serveurs de la ferme RDS, en l’appliquant dans leur OU ou en filtrant l’application de la GPO sur le groupe dont ils sont membres.

Point bonus : si le SSO échoue dès l’accès au site RDWeb et que vous voyez la mire d’authentification à la place, pensez à ajouter son URL aux « sites Intranet local » (PAS aux « sites de confiance »! Et attention à bien ajouter tout alias, nom court, fqdn… qui pourrait être utilisé)!
Vous pouvez réaliser cette manipulation soit manuellement (plutôt pour tester), soit idéalement par GPO également : User/ Policies/administrative templates/Windows Components/Internet Explorer/Internet Controle Panel/Security Page/Site to Zone Assignment List


Connexion d’une machine Linux à Active Directory avec SSSD

Intégrer des serveurs ou des postes Linux dans un environnement Windows Active Directory (AD) est un excellent moyen de centraliser la gestion des utilisateurs et des accès. Finie l’époque où il fallait jongler avec des configurations LDAP et Kerberos complexes et fragiles. Aujourd’hui, SSSD (System Security Services Daemon) fait le travail de manière robuste et sécurisée.

Voici un guide rapide pour lier votre machine Linux à votre domaine AD en quelques minutes.

Pourquoi choisir SSSD ?

  • Gestion du cache : Permet aux utilisateurs de se connecter même si le contrôleur de domaine est temporairement inaccessible.
  • Performance : Centralise les requêtes d’authentification et réduit la charge sur le réseau.
  • Simplicité : S’intègre parfaitement avec realm, un outil qui automatise la majeure partie de la configuration.

Étape 1 : Les prérequis indispensables

Avant de lancer les commandes, assurez-vous que :

  1. Votre machine Linux a une adresse IP fixe ou statique via DHCP.
  2. Le fichier /etc/resolv.conf pointe bien vers les serveurs DNS de votre Active Directory.
  3. L’heure de votre machine Linux est parfaitement synchronisée avec celle du contrôleur de domaine (le protocole Kerberos ne tolère pas plus de 5 minutes de décalage).

Étape 2 : Installation des paquets

Sur une distribution basée sur Ubuntu / Debian, installez les outils nécessaires avec la commande suivante :

Bash

sudo apt update
sudo apt install sssd sssd-tools realmd adcli krb5-user packagekit sssd-ad

(Note : Durant l’installation, Kerberos peut vous demander le nom de votre royaume. Inscrivez-le en MAJUSCULES, ex: MONENTREPRISE.LOCAL).

Étape 3 : Découverte et jonction au domaine

C’est ici que la magie de realmd opère. Tout d’abord, vérifiez que Linux voit bien votre domaine AD :

Bash

realm discover monentreprise.local

Si tout est correct, lancez la jonction au domaine. Vous aurez besoin des identifiants d’un compte Administrateur de l’AD (ou d’un compte ayant les droits de joindre des machines au domaine) :

Bash

sudo realm join -U Administrateur monentreprise.local

Entrez le mot de passe lorsque demandé. Si la commande s’exécute sans erreur, félicitations : votre machine fait officiellement partie du domaine !

Étape 4 : Utilisation et vérification

Pour vérifier que SSSD communique bien avec votre Active Directory, vous pouvez tester la résolution d’un utilisateur de l’AD avec la commande id :

Bash

id utilisateur_ad@monentreprise.local

Le terminal devrait vous renvoyer l’UID, le GID et les groupes Windows de l’utilisateur.

Astuce : Se connecter sans taper le nom de domaine

Par défaut, SSSD vous oblige à vous connecter sous la forme username@domain. Si vous préférez utiliser uniquement le nom d’utilisateur simple (username), modifiez le fichier /etc/sssd/sssd.conf et passez cette option à False :

Ini, TOML

use_fully_qualified_names = False

N’oubliez pas de redémarrer le service après modification :

Bash

sudo systemctl restart sssd

En conclusion

En utilisant le combo realmd + SSSD, l’intégration d’une machine Linux dans un Active Directory Windows devient un jeu d’enfant. Vous bénéficiez d’une authentification centralisée, sécurisée et d’une gestion simplifiée pour vos administrateurs système.

Secure Boot Certificates Power BI Dashboard : guide de déploiement avec Configuration Manager

Suite à l’expiration des certificats Secure Boot en juin, la visibilité sur l’état de conformité des PC est devenue un enjeu majeur.

Afin d’accompagner les équipes d’administration, nous vous partageons un tableau de bord Power BI dédié à Configuration Manager. Compatible avec les environnements Standalone et Co-Managed, il permet d’identifier rapidement les postes concernés, d’analyser les écarts de conformité et de faciliter le suivi des actions de remédiation.
Cet article présente les étapes de déploiement ainsi que les principales fonctionnalités de cette solution :

Prérequis – Tableau de bord Power BI Secure Boot Certificates

Téléchargement de la Configuration Baseline et du rapport Power BI.

Avant de commencer, téléchargez les éléments nécessaires :

Importation de la baseline de configuration Secure Boot

Par défaut, plusieurs informations nécessaires au suivi des certificats Secure Boot ne sont pas disponibles via Hardware Inventory de Configuration Manager.

L’utilisation d’une Configuration Baseline avec un état Compliant / Non-compliant constitue une méthode simple et efficace pour collecter ces informations et suivre la conformité des postes.
Étape 1 – Extraire les fichiers de la baseline Secure Boot Certificates

Étape 2 – Dans la console Configuration Manager, accédez à :
Actifs et conformité > Paramètres de conformité > Baselines de configuration, puis cliquez sur Importer des données de configuration.

Étape 3 – Cliquez sur Ajouter, puis sélectionnez tous les fichiers .cab extraits précédemment.
Étape 4 – Un avertissement relatif à un éditeur inconnu apparaît. Cliquez sur OK pour continuer.

Étape 5 – Cliquez sur Next afin de terminer l’assistant d’importation.

Étape 6 – Une fois créée, déployez la baseline de configuration Secure Boot Certificates.

Une fois créée, déployez la Secure Boot Certificates Configuration Baseline sur les collections de machines concernées.
Après un délai de 24 à 48 heures, vérifiez le nombre de machines Compliant / Non-compliant depuis la console Configuration Manager.

Secure Boot Certificates Power BI Dashboard

À présent, ouvrez le rapport Power BI téléchargé depuis Power BI Desktop afin de connecter les données et d’exploiter le tableau de bord Secure Boot Certificates.

Accept:

Indiquez le serveur SQL Configuration Manager et la base de données SQL utilisée:

Une demande d’autorisation pour la requête Native Database Query peut s’afficher. Cliquez sur OK pour continuer:

Une fois les requêtes terminées :