Dans cet article, nous allons voir le suivi du verrouillage de compte par suite d'une succession de tentatives de connexion avec un mot de passe erroné.

L'environnement de test est composé de deux contrôleurs de domaine : LAB2016dc1 et LAB2019DC2 et d'un poste client Windows 10 LABCL1. Tous les rôles FSMO sont gérés par LAB2016DC1.

La stratégie de verrouillage a été définie dans la GPO « Default Domain Policy ». Nous avons défini un verrouillage de 10 minutes si pendant une durée de 10 minutes, 3 mauvais mot de passe sont saisie.

J'avais déjà écrit un article sur les niveaux d'authentification NTLM :

Nous avons vu dans un article précédent, comment activer DNSSEC sur les zones DNS de votre domaine Active Directory. Nous avons également vu le rôle joué par les ancres de confiance pour la signature des enregistrements DNS.

Dans cette article nous allons voir comment mettre à jour les ancres de confiance publié par l'IANA concernant la racine d'internet. Le lien suivant https://data.iana.org/root-anchors/root-anchors.xml permet de retrouver les ancres de confiances.

Principe de DNSSec

DNSSec est un mécanisme de sécurité permettant de signer les enregistrements DNS d'une zone afin de protéger votre environnement. La signature permet de réduire le risque de d'empoisonnement du cache du client DNS et d'éviter certaines attaques de type Man In The Middle.

DNSSEC est comparable à une autorité de certification qui utiliserait des certificats pour faire de la signature. 

D

Dans cette série d'articles, nous allons voir quelques bonnes pratiques liées à la gestion DNS dans un environnement Active Directory et comment se protéger d'attaques de type DNS Spoofing ou DNS Cache Poisoning .

Il est possible de gérer le comportement d'autres navigateurs à l'aide des stratégies de groupe. Vous retrouverez par exemple les fichiers admx concernant Firefox dans le lien suivant : https://github.com/mozilla/policy-templates/releases.

Si vous avez installé la mise à jour de septembre sur Windows 2016 Server, vous pouvez rencontrer des erreurs lors de l’affichage des options de sécurité dans les stratégies de groupe (gpedit.local ou gpmc.msc pour les domaines AD), comme présenté dans l’image ci-dessous :

L’erreur est décrite dans le lien suivant :

Si vous souhaitez migrer, votre application de synchronisation  Azure AD Connect vers un nouveau serveur, une méthode simple consiste à installer l'outil sur le nouveau serveur en mode préproduction. Le mode de préproduction configure les éléments de la synchronisation, mais les données ne sont pas réellement copiées d'un vers l'autre. Vous pouvez suivre les étapes suivantes :

La gestion des comptes locaux des postes de travail membre du domaine peut s'avérer délicate. Il peut arriver de devoir utiliser un compte local avec des droits d'administrations sur l'ordinateur. Mais la gestion du mot de passe de ce compte présent sur l'ensemble des postes peut poser un problème. Il existe une solution gratuite proposée par Microsoft permettant de gérer des mots de passe uniques pour un compte spécifique sur l'ensemble des postes membres du domaine : Microsoft Local Administrator Password Solution (LAPS).

Il y a quelques années j'avais écrit sur un article sur la gestion des utilisateurs et groupe locaux à l'aide des GPO. Je vous présente ici, une autre méthode qui existe depuis 2008 et qui utilise les préférences dans les stratégies de groupes. L'objectif est d'ajouter un groupe spécifique en tant qu'administrateurs des postes de travail, afin d'éviter d'utiliser des mots de passe de comptes administrateurs du domaine sur les postes.

Si votre parc ne dispose pas d'OS antérieur à Windows Vista/ Windows Server 2008, vous pouvez envisager de désactiver SMB 1.0. Nous avons vu dans l'article précédent comment activer l'audit des demandes de connexions avec SMB 1.0, ce qui vous permettra de vérifier si des postes utilisent encore ce protocole obsolète. Dans cet article nous allons voir, comment modifier la configuration sur un ou l'ensemble de vos serveurs pour ne plus accepter de connexion SMB1.0.

À la suite de questions sur la compatibilité entre les OS anciens et récent dans un domaine AD, je vais essayer de résumer quelques informations utiles sur les protocoles de partage de fichiers (SMB). Dans un domaine Active Directory nous avons aux minimums deux partages présents sur tous les contrôleurs de domaine (en bonne santé) : « NetLogon » et « Sysvol ». Ces partages mettent à disposition des postes membres du domaine, les scripts et les paramètres de stratégie de groupes. Les protocoles d'accès aux partages de fichiers chez Microsoft sont assez anciens et ont évolué avec le temps.

Il est possible que vous souhaitiez gérer et exécuter des commandes PowerShell à distance sur des postes de travail ou des serveurs membres. Les commandes PowerShell Invoke-Command et Enter-PSSession peuvent vous aider à condition que les postes cibles acceptent la gestion à distance.

Pour cela il est possible d'utiliser une stratégie de groupe, afin de configurer et démarrer le service WinRM (Windows Remote Management). Dans cette stratégie vous devrez configurer les éléments suivants.

Il est possible d'utiliser le cryptage BitLocker pour protéger par exemple, les postes nomades. Cela limite le risque de vol de données en cas de perte ou de vol du matériel.

Par défaut, BitLocker voudra utiliser un module sécurisé (TPM), sinon l'option ne sera pas disponible, comme dans l'image ci-dessous. Il est possible de modifier cette limitation avec les stratégies de l'ordinateur.