Cette semaine, Active Directory a fêté ses 20 ans, tout comme Windows server 2000.

Windows 2000 sorti le 17/02/2000 a vu le remplacement des anciens domaines NT, par un annuaire compatible LDAP prenant en charge les protocoles d'authentification Kerberos.

Si vous n'utilisez pas Azure AD Connect pour synchroniser vos comptes depuis votre domaine local, vous pouvez créer les comptes directement dans l'interface de gestion d'Azure Active Directory. Il est également possible de le faire par script comme par exemple avec PowerShell. Pour cela il vous faudra installer le module PowerShell AzureAD. Vous pouvez également utiliser le module propre à MSOnLine.

Dans l'article suivant nous avons parlé de la gestion des comptes Office 365, stocké dans Azure AD avec PowerShell. Nous avons pour cela installé le module MSOnline. Il existe un autre module permettant de gérer Azure Active Directory et non lié à Office 365 : le module Azure AD.

La commande suivante permet de voir si le module AzureAD est déjà installé et la version que vous disposez :

Le support des produits Windows 7 et Windows Serveur 2008/ 2008R2 a pris fin le 14/01/2020.

Pour ceux qui utilisent encore ces anciennes versions, il n'y aura désormais plus de mise à jour mensuelle y compris pour les correctifs de sécurité.

https://support.microsoft.com/fr-fr/help/4057281/windows-7-support-ended-on-january-14-2020

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.

Dans l'article précédent nous avions vu comment activer la gestion à distance de Windows (WinRM) à l'aide des stratégies de groupe. Cette option vous permet entre autres d'exécuter à distance des commandes PowerShell sur des ordinateurs spécifiques. Une commande PowerShell intéressante est « Get-ComputerInfo ».

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.

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.

Avec Windows Server 2012 R2, un nouveau groupe a été rajouté dans Active Directory : « Protected Users ».

Le groupe « Protected User » permet de réduire les risques liés aux comptes d'administration. L'ajout d'un compte dans ce groupe va modifier certains comportements. Dans cet exemple, nous verrons quelques éléments de protection liés à ce groupe.

À la suite de différents échanges et demande par mail ou autres, j'ai décidé d'ajouter une nouvelle rubrique concernant la sécurité et les bonnes pratiques sur l'administration d'un environnement Active Directory.

C'est un des deux sujets, que je souhaite élargir dans les prochains mois, avec la partie Azure.

Dans la première partie nous avons déployé Azure AD Domain Services. Nous allons maintenant créer une machine virtuelle sous Windows 2019 dans Azure et installer les consoles d'administrations classiques des services de domaine Active Directory.

Pour rappel, nous avons créé un sous réseau virtuel « 10.0.1.0/24 ». Dans notre groupe de ressource « LabAzureADDS » contenant l'ensemble de notre environnement, nous allons sélectionner le réseau virtuel que nous avons créé.

Ce nouveau livre sur les services de domaine Active Directory, vous permettra de vous familiariser avec le module PowerShell sur les opérations que nous effectuons régulièrement.

Le contenu du livre vous permettra de tester les différentes commandes et scripts proposés au fil de la lecture.

Jusqu'au chapitre 5, vous apprendrez à utiliser des commandes PowerShell simple. A partir du chapitre 6, les commandes que vous allez découvrir sont proposés sous forme de fonction ou de script, afin de vous familiariser avec l'automatisation de tâche avec PowerShell.

Dans cet article nous allons voir comment créer une application Web basé sur Drupal 8.

Nous vérons dans la deuxième partie, comment définir un nom de domaine personnalisé pour l'accès depuis un navigateur. Nous avons déjà pu voir dans l'article précédent comment créer une zone DNS dans Azure et assurer la résolution de nom sur Internet : [Azure DNS Zone] Créer une Zone DNS avec PowerShell