Nous avons vu comment mettre en place des certificats pour les connexions LDAP sécurisées SSL ou StartTLS dans le magasin de certificat du compte de l'ordinateur du contrôleur de domaine.

La solution est généralement suffisante, mais il peut arriver que vos contrôleurs de domaine disposent de plusieurs certificats qui répondent au besoin des connexions LDAP sécurisées pour des usages différents.

Nous avons vu dans la première partie, comment activer les audits afin de rechercher les connexions LDAP non sécurisées sur le port 389(ou 3268 pour le catalogue global).

Lorsque vous avez détecté et corrigé les connexions non sécurisées, vous pouvez activer des paramètres pour les postes clients Windows et pour les contrôleurs de domaine afin d'exiger la signature. Cela supprime les authentifications simples et SASL non signé.

Il est recommandé de configurer les clients avant la mise en œuvre du paramètre sur les contrôleurs de domaine.

Vous avez peut-être déjà entendu parler des problèmes sur Kerberos depuis l'installation des mises à jour du mois de novembre.

En effet des problèmes reconnus par Microsoft peuvent exister sur l'authentification Kerberos depuis l'application des mises à jour.

Il y aura pas mal de choses à dire sur les mises à jour du mois de novembre, vu qu'elle intègre deux évolutions progressives sur le protocole Kerberos et une sur Netlogon.

Dans l'actualité Microsoft depuis quelques mois l'évolution des services d'identités avec un nouveau nom, Microsoft Entra et une nouvelle interface d'administration :

https://entra.microsoft.com/#home

Microsoft Entra comprend :

Il y a deux ans, j'avais publié deux articles sur la mise en œuvre de LAPS.

[AD Sécurité] Gérer vos comptes administrateurs locaux avec LAPS (partie 1)

J'avais déjà publié un message sur la stratégie de mot de passe affiné et sur la commande « Get-ADUserResultantPasswordPolicy » ainsi qu'un article plus détaillé sur la stratégie de mot de passe dans un domaine Active Directory.

Vous trouverez dans ce post quelques informations sur l'installation des DC sous Windows server 2022.

Avant de promouvoir un nouveau contrôleur de domaine, il faut généralement mettre à jour le schéma Active Directory.

Depuis 2012 et la fin de « dcpromo.exe », l'assistant de configuration des services Active Directory effectue la mise à jour automatiquement lors de la promotion.

La commande suivante permet de connaître la version du schéma :

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 :

Dans la première partie nous avons :

• Installer LAPS sur le poste de management
• Etendue le schéma de l'annuaire AD
• Déléguer le droit d'enregistrer le mot de passe dans l'annuaire au compte de l'ordinateur
• Déléguer le droit de lire le mot de passe à un compte spécifique de l'équipe support.

Dans cette seconde partie, nous allons :

Dans la gestion quotidienne des comptes de l'annuaire Active Directory, il n'est pas recommandé d'utiliser systématiquement des comptes membre de « Admins du domaine ». Il est possible de déléguer ces opérations à des groupes d'utilisateurs spécifiques. Vous pouvez par exemple, limiter le droit de réinitialiser le mot de passe à une partie de l'équipe IT, vous pouvez également déléguer le droit de remplir certaines informations comme la fonction ou le service de l'utilisateur à l'équipe RH.

J'avais écrit il y a pas mal de temps un article sur le déplacement des rôles FSMO depuis les consoles Active Directory : http://www.pbarth.fr/node/79 .

Dans cet article nous allons voir comment déplacer rapidement l'ensemble des rôles FSMO avec PowerShell.

Les premières commandes que nous allons voir, permettent de déterminer les serveurs qui disposent des rôles actuellement.

Pour déterminer les serveurs qui disposent des rôles FSMO du domaine vous pouvez utiliser la commande :

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 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.

Dans un article précédent, nous avons expliqué de manière simplifiée le principe de l'authentification NTLm . Nous allons dans cet article tenté d'expliquer le principe de fonctionnement de Kerberos. L'authentification Kerberos est assurée par le centre de distribution de clés (KDC) des contrôleurs de domaine Active Directory.