Par défaut, le dossier qui renferme les fichiers de configuration GPO est local. Ainsi si vous avez plusieurs AD les fichiers peuvent être différents.
Pour éviter ça, on va mettre en place le magasin central.
On copie donc le répertoire PolicyDefinition de C:\Windows vers le dossier Sysvol\Domain\Policies.
Voilà, vos templates administratifs seront maintenant synchronisés sur tout vos DC.
Par défaut on ne collecte pas assez d’informations sur les événements touchant l’AD.
Pallions ça grâce à une GPO.
On ne va pas se mentir, la configuration dépendra de votre capacité de traitement.
Pour du « standard », utilisez plutôt cette version :
Enfin, activer les détails des logs lors des connexions, déconnexions, arrêts et démarrages des sessions.
Il convient de désactiver le service « spooler » sur tous les contrôleurs de domaine.
Pour ce faire, services.msc :
Désactiver complètement ce service via le clic droit/Propriétés :
L’utilisation du service d’impression pour l’extraction d’information fait parti d’un bulletin dédié chez Microsoft : https://msrc.microsoft.com/update-guide/en-US/vulnerability/ADV190006
La Default Domain Policy contient un début de règles concernant les mots de passe.
Cette règle est bien trop faible pour être dans un réseau de production.
Je conseil de créer :
– une GPO pour les utilisateurs sans pouvoir,
– une GPO pour les administrateurs,
– une GPO dédiée à vos comptes de services.
Concernant les règles à mettre dans chacune des GPO, deux écoles :
Pour ceux ce demandant ce qu’est le NIST et pourquoi prendre leur standard ? Parce que l’ANSSI a suivi les règles du NIST, règle définie sans études de l’aveu même de l’auteur.
Article ici : https://www.developpez.com/actu/153757/L-ingenieur-du-NIST-qui-a-recommande-l-adoption-des-MdP-difficiles-a-retenir-regrette-ce-conseil-le-NIST-preconise-les-MdP-longs-et-faciles-a-retenir
Par défaut, rien n’est audité concernant Powershell, ainsi en cas de compromission vous n’avez aucune trace des commandes saisies ou scripts exécutés.
Pour ce faire, encore une petite GPO.
Sécurisé aussi la version de Powershell :
Une fois la GPO appliquée, vous verrez les entrées dans « Microsoft-Windows-PowerShell/Operational ».
Exemple:
Documentation Microsoft : https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_logging_windows?view=powershell-7.1
Windows permet a n’importe quels utilisateurs authentifiés de lister les utilisateurs connectés au poste sur lequel il est actuellement.
Heureusement, Microsoft fournit aussi un script pour pallier ça: https://gallery.technet.microsoft.com/Net-Cease-Blocking-Net-1e8dcb5b
Si votre serveur n’est pas en version 2019 à jours, LLMNR est activé à l’installation.
Par sécurité il est préférable de créer une GPO pour le désactiver expressément.
Exemple de CVE: https://nvd.nist.gov/vuln/detail/CVE-2020-17467
Les administrateurs de domaine sont aussi administrateurs des postes de travail et serveurs qui sont dans le même domaine.
On va donc interdire à ces comptes de se connecter aux postes de travail à l’aide d’une GPO qui pourra s’appliquer aux serveurs aussi.
Ce rendre à Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment
Modifier « Deny this computer from the network » pour interdire « domain admin ».
Appliquer cette même configuration pour les autres « Deny ».
Attention, dans le cas d’un réseau déjà en production il est très important de vérifier qu’aucun de vos comptes administrateur n’utilise un de ces types de connexions.
Maintenant votre infrastructure AD est à peu près propre pour aller avec votre installation en Tier 3 : https://docs.microsoft.com/fr-fr/security/compass/privileged-access-access-model