Problème de réplication des partages SYSVOL et NETLOGON

Auteur & Source :Seb (bio)

It-central: Cette astuce fonctionne aussi pour les autres versions de Windows Server.

Active Directory - Réplication Sysvol et Netlogon

 

J’ai récemment installé deux nouveaux contrôleurs de domaine en Windows 2003 R2 afin de remplacer un vieux contrôleur de domaine en Windows 2000 qui montrait des signes certains de faiblesse. Problème, après la phase habituelle de dcpromo, les partages SYSVOL et NETLOGON ne se sont pas créés automatiquement sur les deux nouveaux DCs. Les transferts de rôles FSMO se sont eux passés sans problème et Active Directory (utilisateurs, ordinateurs) et le DNS se répliquent parfaitement.

Ce problème est en fait critique puisque si le contrôleur de domaine en Windows 2000 venait à mourir il ne serait plus possible de s’authentifier sur le domaine ni sur les serveurs SQL utilisant l’authentification Windows. Un backup très régulier de l’état du système du DC avec ntbackup est primordial tant que la situation n’est pas stabilisée. D’autre part les stratégies de groupe ne sont pas répliquées et les serveurs ne sont pas intégralement considérés comme des contrôleurs de domaine tant que les partages SYSVOL et NETLOGON n’auront pas été créés.

Sur les DCs en Windows 2003 j’obtenais des erreurs dans l’observateur d’événements :

Type de l’événement : Avertissement
Source de l’événement : NtFrs
Catégorie de l’événement : Aucun
ID de l’événement : 13565
Date : 28/08/2007
Heure : 18:47:17
Utilisateur : N/A
Ordinateur : DC01
Description :
Le service de réplication de fichiers initialise le volume système avec des données venant d’un autre contrôleur de domaine. L’ordinateur DC01 ne peut pas devenir un contrôleur de domaine avant que le traitement ne soit effectué. Le volume système sera alors partagé en tant que SYSVOL.

Pour vérifier le partage SYSVOL, entrez à l’invite de commande :
net share

Lorsque le service de réplication de fichiers aura effectué le processus d’initialisation, le partage SYSVOL apparaîtra.

L’initialisation du volume système peut prendre un certain temps. Cette durée dépend de la quantité de données dans le volume système, de la disponibilité d’autres contrôleurs de domaine et de l’intervalle de réplication entre les contrôleurs de domaine.

Pour plus d’informations, consultez le centre Aide et support à l’adresse http://go.microsoft.com/fwlink/events.asp.

Type de l’événement : Avertissement
Source de l’événement : NtFrs
Catégorie de l’événement : Aucun
ID de l’événement : 13508
Date : 27/08/2007
Heure : 14:17:51
Utilisateur : N/A
Ordinateur : DC01
Description :
Le service de réplication de fichiers a des problèmes à activer la réplication de \\OLDDC.corp.local vers DC01 pour c:\windows\sysvol\domain en utilisant le nom DNS \\OLDDC.corp.local. FRS va essayer à nouveau.
Ci-dessous sont certaines des raisons de cet avertissement.

[1] FRS ne peut pas résoudre le nom DNS \\OLDDC.corp.local correctement à partir de cet ordinateur.
[2] FRS n’est pas en cours d’exécution sur \\OLDDC.corp.local.
[3] Les informations de topologie dans Active Directory pour ce réplica n’ont pas été répliquées à tous les contrôleurs de domaine.

Ce message du journal d’événement apparaîtra une fois par connexion, une fois que le problème a été résolu, vous verrez un autre message indiquant que la connexion a été établie.

Pour plus d’informations, consultez le centre Aide et support à l’adresse http://go.microsoft.com/fwlink/events.asp.
Données :
0000: 00 00 00 00 ….

Le fait de redémarrer le service de réplication de fichiers régénère ces erreurs en permanence.

Sur l’ancien contrôleur de domaine en Windows 2000 :

Type de l’événement : Avertissement
Source de l’événement : NtFrs
Catégorie de l’événement : Aucun
ID de l’événement : 13508
Date : 24/08/2007
Heure : 11:48:13
Utilisateur : N/A
Ordinateur : OLDDC
Description :
Le service de réplication de fichiers a des problèmes à activer la réplication de DC01 vers OLDDC pour c:\winnt\sysvol\domain en utilisant le nom DNS dc01.corp.local. FRS va essayer à nouveau.
Ci-dessous sont certaines des raisons de cet avertissement.

[1] FRS ne peut pas résoudre le nom DNS dc01.corp.local correctement à partir de cet ordinateur.
[2] FRS n’est pas en cours d’exécution sur dc01.corp.local.
[3] Les informations de topologie dans Active Directory pour ce réplica n’ont pas été répliquées à tous les contrôleurs de domaine.

Ce message du journal d’événement apparaîtra une fois par connexion, une fois que le problème a été résolu, vous verrez un autre message indiquant que la connexion a été établie.
Données :
0000: 00 00 00 00 ….

Type de l’événement : Avertissement
Source de l’événement : NtFrs
Catégorie de l’événement : Aucun
ID de l’événement : 13508
Date : 24/08/2007
Heure : 11:48:13
Utilisateur : N/A
Ordinateur : OLDDC
Description :
Le service de réplication de fichiers a des problèmes à activer la réplication de DC02 vers OLDDC pour c:\winnt\sysvol\domain en utilisant le nom DNS DC02.corp.local. FRS va essayer à nouveau.
Ci-dessous sont certaines des raisons de cet avertissement.

[1] FRS ne peut pas résoudre le nom DNS DC02.corp.local correctement à partir de cet ordinateur.
[2] FRS n’est pas en cours d’exécution sur DC02.corp.local.
[3] Les informations de topologie dans Active Directory pour ce réplica n’ont pas été répliquées à tous les contrôleurs de domaine.

Ce message du journal d’événement apparaîtra une fois par connexion, une fois que le problème a été résolu, vous verrez un autre message indiquant que la connexion a été établie.
Données :
0000: 00 00 00 00 ….

Quelques recherches sur Internet montrent que ce problème de non-réplication des partages SYSVOL et NETLOGON est assez commun mais rares sont les solutions disponibles. De plus certaines de ces solutions ne sont pas valides pour les Windows 2000 post-SP3, le mien étant patché en SP4… Enormément d’informations assez vagues et contradictoires indiquent notamment de partager manuellement les répertoires (à ne pas faire !) ou de déplacer les fichiers manuellement (pas très utiles puisque les partages ne sont pas actifs).

Finalement voilà la solution qui a rétabli la réplication entre les trois DCs :

  1. Tous les autres contrôleurs de domaine depuis un DC donné au moyen de leurs IPs et de leur noms DNS complets. Si ce n’est pas le cas il faut corriger cela avant toute chose et vérifier si ça ne résout pas le problème de réplication.
  2. Stopper le service de réplication de fichiers sur tous les DCs
  3. Utiliser regedit pour modifier la clé Burflag de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID et la passer à D4 en hexadécimal sur le contrôleur de domaine disposant d’un SYSVOL et d’un NETLOGON correct
  4. Utiliser regedit pour modifier la clé Burflag de HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID et la passer à D2 en hexadécimal sur les contrôleurs de domaines qui n’ont pas créé les partages SYSVOL et NETLOGON
  5. Redémarrer le service de réplication de fichiers sur le contrôleur de domaine « correct »
  6. Patientez quelques minutes
  7. Redémarrer le service de réplication de fichiers sur les contrôleurs de domaine en erreur de réplication

A ce moment-là les contrôleurs de domaine en Windows 2003 ont enregistré ce message dans l’observateur d’événements :

Type de l’événement : Informations
Source de l’événement : NtFrs
Catégorie de l’événement : Aucun
ID de l’événement : 13516
Date : 28/08/2007
Heure : 18:52:45
Utilisateur : N/A
Ordinateur : DC01
Description :
Le service de réplication de fichiers n’empêche plus l’ordinateur DC01 de devenir un contrôleur de domaine. Le volume système a été correctement initialisé et le service Accès réseau a été averti du fait que le volume système est maintenant prêt à être partagé en tant que SYSVOL.

Entrez « net share » pour vérifier le partage SYSVOL.

Pour plus d’informations, consultez le centre Aide et support à l’adresse http://go.microsoft.com/fwlink/events.asp.

Un net share montre effectivement l’apparition des partages SYSVOL et NETLOGON, ce qui est confirmé par l’utilisation de l’outil Sonar qui montre les partages SYSVOLS en OK au lieu de Not Shared.

L’article KB315457 rentre dans (beaucoup) plus de détails sur cette manipulation.

Share

Comptes et groupes de services : MSA,VSA et gMSA

Auteur & Source : Michel de CREVOISIER .

 

Introduction

Face à un besoin croissant concernant la sécurisation des applications réseau stratégiques (telles que SQL Server, Exchange, IIS, …) et avec la sortie de Windows Server 2008 R2 et Windows 7, deux
nouveaux types de comptes ont été introduits : les VSA (Virtual Service Account) et les MSA (Managed Service Account). Ceux-ci permettent d’une part de s’affranchir de la gestion complexe des mots de passe (blocage, expiration, renouvellement, …) et d’autre part de réduire les opérations de maintenance, souvent considérées comme fastidieuses et complexes.

Grâce à ces derniers :

  • Vous disposerez d’une nouvelle classe de comptes dédiés aux services.
  • Vous n’aurez plus à vous soucier du renouvellement ou de l’expiration des mots de passe étant donné qu’ils sont automatiquement renouvelés.
  • Vous pourrez déléguer l’administration de ces comptes à des non-administrateurs.

Note concernant SQL Server 2008 R2 ou supérieur : si vous faites appel à des MSA ou à des VSA, sachez qu’ils ne peuvent pas être utilisés pour des instances en cluster étant donné que chacun d’entre eux dispose d’un SID différent.

Managed Service Account (MSA)

Présentation

Un MSA est un compte de domaine spécialement assigné à un seul et unique ordinateur et conçu pour exécuter un service. Il ne peut cependant pas être utilisé pour se connecter à un ordinateur. En résumé, il s’agit d’un compte administré par le contrôleur de domaine et incapable d’ouvrir une
session localement. Sa composition est {DOMAIN}\{Service account}$ et les mots de passe générés possèdent une structure de 240 caractères cryptographiques aléatoires.

Applications supportées

Les technologies suivantes sont supportées pour utiliser des comptes MSA :

  • Service Windows : oui
  • Exchange : oui (pour l’envoi de mail) mais configuration supplémentaire requise
  • IIS : oui, pour les pools d’application
  • SQL Server : oui, mais uniquement à partir de SQL Server 2012

Prérequis

Pour mettre en place des MSA, vous devez valider les prérequis suivants :

  • Schéma en version supérieure ou égale à Server 2008 R2
    (Un schéma en version 2008 peut être utilisé, mais la gestion des SPN n’est pas supportée)
  • Installer le compte sur une version supérieure ou égale à Server 2008 R2 ou Windows
  • Installation des commandes PowerShell pour Active Directory côté serveur et client (point 5.1)
  • Installer le Framework 3.5

Limitations

Les MSA possèdent toutefois certaines limitations. De ce fait, ils ne peuvent pas être utilisés sur :

  • De multiples ordinateurs
  • Des nœuds en cluster
  • Un système de load-balancing (NLB) pour des serveurs web utilisant Kerberos
  • Une tâche planifiée

 

Mise en place

Création d’un MSA

Après quoi, vous pouvez constater la création du MSA dans l’OU Managed Service Account :

De la même façon, vous pouvez consulter ses propriétés via la commande suivante :

Association du compte

Il faut ensuite associer le MSA créé avec l’ordinateur sur lequel il sera utilisé :

Installation du compte

Pour terminer, installez ce compte de service sur l’ordinateur cible. Pour cela, placez-vous sur la machine allant utiliser ce compte et exécutez la commande suivante :

Configuration du compte avec un service

Nous allons maintenant configurer ce compte pour être utilisés par une instance SQL :

  • Ouvrez la console SQL Server Configuration Manager et accédez à la propriété Log On du
    service en question :

SQL Server Configuration Manager

  • Dans la console de recherche, modifiez sélectionnez votre domaine puis l’Object types afin
    de faire apparaître les comptes de service :

Object types

  • Laissez le mot de passe en blanc et redémarrez votre service :

SQL Propriété - Account name

 

Virtual Service Account (VSA)

Présentation

Le VSA est un compte géré localement qui fournit des fonctionnalités permettant de faciliter l’administration des services. Son format est NT SERVICE\{SERVICE NAME}. Ce type de compte peut accéder aux ressources du réseau, mais il devra pour cela s’authentifier avec les credentials du compte ordinateur de type {DOMAIN}\{COMPUTER}$. Si un VSA est utilisé pour un service, le mot de passe devra être laissé en blanc.

Utilisation

Les VSA sont utilisés depuis IIS 7.0 (compte « IIS AppPool\DefaultAppPool » par exemple) et dans SQL Server 2012 si les paramètres par défaut sont utilisés.

 

Groupes de services administrés (gMSA)

Présentation

Les gMSAGroup Managed Service Accounts ») sont apparus avec Windows Server 2012 afin de pallier un des problèmes majeurs des comptes MSA, à savoir l’utilisation d’un compte sur un seul et unique ordinateur. De ce fait, il était par exemple impossible d’utiliser un même compte MSA sur un cluster SQL. Il fallait donc soit utiliser un compte de service pour chaque serveur, soit créer un ou plusieurs comptes de domaine pour la ferme de serveurs. Grâce au gMSA, cette restriction « 1:1 » a été supprimée et il est dorénavant possible d’utiliser un même compte sur plusieurs serveurs. On conviendra que cette nouveauté prend tout sens avec la technologie AAG introduite avec SQL Server 2012. Dans son fonctionnement, un gMSA est un compte de service associé à un groupe de sécurité dans lequel seront ajoutés les ordinateurs autorisés à utiliser ce compte.

Applications supportées

Suite à ces nouveautés, les gMSA peuvent désormais être utilisés :

  • Sur des hôtes multiples
  • Pour des tâches planifiées
  • Pour IIS, SQL Server 2012, …
  • Pour des services Windows

Prérequis

Pour mettre en place des gMSA, vous devez valider les prérequis suivants :

  • Disposer d’un DC avec un schéma en version supérieure ou égale à Server 2012
  • Créer une clef racine KDS (détaillé à la suite)
  • Installer le compte sur une version supérieure ou égale à Server 2012 ou Windows 8
  • Installation des commandes PowerShell pour Active Directory (point 5.1)

Clef KDS :

Les contrôleurs de domaine sous Windows Server 2012 requièrent une clef racine KDS pour la génération des mots de passes associées aux comptes gMSA. Après sa création, il est nécessaire d’attendre 10h afin que la réplication entre les DC converge. Il s’agit là d’une mesure de sécurité afin de s’assurer que tous les DC soient en mesure de répondre aux requêtes gMSA (source).

Mise en place

Configuration du KDS

Création d’un gMSA

Vous pouvez consulter ses propriétés via la commande suivante :
Get-AdServiceAccount –identity $MSAaccount

Ajout du compte ordinateur dans un groupe

Ajoutez l’ordinateur cible du point précédent ($TargetComputer) dans le groupe de gestion créé à cet égard ($gMSAGroup). Il faut ensuite redémarrer votre serveur cible pour prendre en compte cette nouvelle appartenance (ou « membership ») :

Installation du compte

Une fois l’ordinateur cible redémarré, installez le compte gMSA sur ce dernier :

Configuration du compte avec un service

Référez-vous au point 2.2.4 pour cette partie.

 

Outils

Outils PowerShell

L’ensemble des commandes utilisées pour la création des comptes de service requièrent l’installation du module Active Directory pour PowerShell sur votre serveur/station de travail :

Module Active Directory

En PowerShell :

Console GUI

Il existe également un outil gratuit baptisé Managed Service Accounts GUI permettant d’effectuer l’ensemble des actions décrites au préalable directement via une interface graphique (téléchargement).

Managed Service Accounts GUI

Conclusion

Les MSA apparus avec Server 2008 R2 et les gMSA apparus avec Server 2012 viennent donc combler un besoin important en termes de sécurité concernant l’exécution des services. Il ne vous désormais sera plus nécessaire de vous préoccuper de l’administration de ces comptes étant donné que les mots de passe seront automatiquement renouvelés. Et grâce au gMSA, les déploiements de fermes SQL (par exemple) seront simplifiés tout en vous garantissant une sécurité accrue. Le tableau ci-dessous résume les caractéristiques des trois types de comptes présentés dans ce tuto :

Tableau récapitulatif VSA, MSA et gMSA

N’hésitez pas à m’envoyer vos commentaires ou retours à l’adresse suivante :
m.decrevoisier A-R-0-B-A-5 outlook . com

Soyez-en d’ores et déjà remercié

SOURCES

Sécurité des comptes :

Groupes gMSA :

Share

Active Directory: reporting sur les groupes inutilisés

Traduction FR:
 IT-Central.fr
Auteur & Source :

Nous nous intéresserons aujourd’hui sur une des manières de procéder au nettoyage des groupes inutilisés dans une forêt AD. J’ai constaté ces dernières années une tendance croissante: les administrateurs ou les groupes d’identité créent des groupes qui ne sont jamais utilisés. Une fois ces groupes créés, il semble impossible de supprimer ces groupes pour des raisons inconnues. Cela pour plusieurs raisons comme; ils peuvent être simplement utilisés, mais vides, ou nous n’avons aucune idée de ce pour quoi il est utilisé. [As part of my continue discussions I started focusing on low hanging fruit (groups)]. Pour résoudre cela, j’ai commencé à me focaliser sur le fait que si  “Membre de” et “Membres” sont vides et que leur changement était supérieur à x, il ne doit pas être utilisé. Cela semble logique, mais il s’avère que ce n’était pas le cas, j’ai ensuite élargi ma recherche pour inclure si msDS-ReplValueMetaData est nul et si l’option créée est antérieure à x. Il existe de nombreux topiques autour de l’utilisation de msDS-ReplValueMetaData et pour quoi il peut-être utilisé. Pour faire cour, il s’agit d’un attribut qui contient toutes les métadonnées de réplication autour des valeurs liées (Use PowerShell and Repadmin to Check for Updates to High Privileged Groups). Si l’attribut est vide, il est plus que probable que le groupe n’ait jamais ajouté directement de Membres. J’ai trouvé qu’au moins un quart de tous les groupes dans la plupart des environnements Active Directory appartiennent à cette catégorie.

Voici le script que j’ai lancé sur l’ensemble de la forêt

Ce script traversera tous les domaines d’une forêt.

Lien vers la galerie Technet

Une fois que le script est terminé, ouvrez-le dans Excel et triiez les données de votre choix.

https://i2.wp.com/msdnshared.blob.core.windows.net/media/2017/04/image558.png?resize=665%2C446&ssl=1

Dans Insérer, sélectionnez Tableau Croisé Dynamique, cela fait apparaître les champs croisés de la table comme suit :

https://i0.wp.com/msdnshared.blob.core.windows.net/media/2017/04/image559.png?w=665&ssl=1

Vous devriez avoir une belle petite vue comme celle-ci :

https://i0.wp.com/msdnshared.blob.core.windows.net/media/2017/04/image560.png?w=665&ssl=1

* Envisager de filtrer les OU ou les conteneurs comme Builtin et Utilisateurs.

Faites en sorte que les champs du tableau croisé ressemblent à ceci :

https://i1.wp.com/msdnshared.blob.core.windows.net/media/2017/04/image561.png?w=665&ssl=1

Une belle vue de chaque OU et l’âge et le nombre des Groupes devraient être affichés :

https://i2.wp.com/msdnshared.blob.core.windows.net/media/2017/04/image562.png?w=665&ssl=1

Maintenant que vous avez ces données, espérons-le, il suffira de nettoyer certain dans eux dans Active Directory. Dans une prochaine publication sur le blog, nous aborderons la dernière modification de msDS-ReplValueMetaData pour déterminer la dernière fois qu’un objet a été ajouté ou supprimé. J’espère que vous trouvez cela utile. Je vous souhaite une bonne journée.

Chad

Share