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.

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.

Lors de l'installation d'un contrôleur de domaine dans un environnement existant ou dans une nouvelle forêt vous devez disposer de droits spécifiques en fonction de votre déploiement. Le tableau suivant, décrit les droits minimums requis pour effectuer l'opération.

Si vous utilisez une forêt multi-domaines vous comprendrez sans doute l'intérêt d'interroger le catalogue global. Lorsque vous exécutez une commande comme « Get-ADUser » en spécifiant un contrôleur de domaine mais sans préciser le port de destination, vous allez interroger le port ldap par défaut (389). Il est possible d'interroger le catalogue global en précisant le port « 3268 ». Dans l'exemple, ci-dessous nous recherchons un compte d'abord sur la partition d'annuaire ensuite dans le catalogue global. Nous sélectionnons deux attributs distincts (SamAccountName et AccountExpirest).

En lisant un article sur internet, j'ai lu que pour migrer les contrôleurs de domaine de Windows 2003 vers Windows 2016, il fallait effectuer une migration intermédiaire, car le scénario n'est pas supporté. Effectivement la migration des contrôleurs de domaine Windows 2003 vers Windows 2016 n'est pas supportée, d'ailleurs le système d'exploitation Windows 2003 n'est plus supporté.

La méthode et les étapes de migration vers des contrôleurs de domaine en Windows Server 2019, reste identique aux versions précédentes.

http://www.pbarth.fr/node/89

Un résumé dans les grandes lignes des étapes :

Cloud

Vous ne serez sans doute pas surpris d'apprendre que de plus en plus, les services que nous fournissons sont orientés vers le Cloud. Que l'on parle de produits comme Office 365 ou d'ensemble de services, comme des applications Web, des machines virtuelles, des outils de gestion identités (Azure AD) etc. …