PI Services

Un de nos clients utilise des cartes à puce pour s'authentifier sur les postes de travail et depuis quelques mois, un problème apparemment aléatoire se produit : lorsque certaines cartes sont associées à certains comptes Active Directory, l'authentification ne fonctionne pas (erreur "invalid credentials" lors d'une tentative d'ouverture de session Windows).

Les mêmes cartes associées à d'autres comptes ne posent cependant aucun problème, et réciproquement.

La seule autre indication dont nous disposons au moment de commencer les investigations est un évènement 4771 généré dans le journal Security des contrôleurs de domaine. Il indique une erreur 0x42, qui se traduit par KRB_ERR_CERTIFICATE_MISMATCH (et non pas KRB_AP_ERR_USER_TO_USER_REQUIRED comme une première recherche nous l'avait fait penser, nous entraînant sur une fausse piste!)

Dernière information pertinente : les certificats présents sur ces cartes à puce ne contiennent pas l'UPN du compte qui les utilise pour ouvrir une session. Il s'agit de certificats génériques, fournis par une entité tierce.

Il est donc nécessaire de peupler la propriété LDAP altSecurityIdentities pour lier le compte Active Directory d'un utilisateur à une smartcard.

Première vérification évidente : les comptes utilisateurs contiennent bien une référence au certificat présent dans la smartcard dans cette propriété altSecurityIdentities.

Il s'agit plus précisément de leur propriété RFC822, autrement dit un identifiant au format adresse email.

L'erreur "Certificate Mismatch" ne semble donc pas être pertinente ici, mais une nouvelle recherche permet de trouver une note récente de Microsoft ( https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-winerrata/85d75079-92de-47e6-a1c1-7e4fd7f27a10 ) qui indique que depuis la mise à jour mensuelle de Mai 2022, les informations utilisées pour remplir la propriété altSecurityIdentities sont divisées en deux catégories "forte" et "faible"; que l'adresse RFC822 fait partie des "faibles" et que lors de l'utilisation d'une information "faible", l'erreur Certificate Mismatch "peut" être présente.

On progresse donc, mais il nous reste à comprendre quelles sont les conditions exactes pour obtenir cette erreur puisque par ailleurs la majorité des comptes fonctionne avec la majorité des cartes à puce sans problème, en utilisant le même identifiant RFC822 "faible".

Un nouvel événement (id 40 dans le journal System des contrôleurs de domaine) nous met la puce à l'oreille :

The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a strong way (such as via explicit mapping, key trust mapping, or a SID). The certificate also predated the user it mapped to, so it was rejected

Il confirme clairement ce dont nous nous doutions déjà, à savoir que le certificat est valide mais pas associé au compte AD de façon sûre.

Mais il indique également un élément supplémentaire : s'il a été rejeté, c'est parce qu'en plus la date d'émission du certificat est antérieure à la date de création du compte.

Il s’agit d’un blocage destiné à permettre l’évolution progressive de la configuration de vos altSecurityIdentities : en effet, Microsoft indique que toutes les authentifications par certificat lié par une association « faible » échouera à partir de Mai 2023 (cf. KB5014754: Certificate-based authentication changes on Windows domain controllers - Microsoft Support ), et ce blocage permet donc d’éviter de créer des associations qui poseront problème après quelques mois seulement.

Deux solutions sont alors disponibles : 

· Regénérer le certificat de façon à ce qu’il contienne l’extension SID (introduite également lors de la mise à jour de Mai 2022), mais cette solution ne fonctionne que pour les certificats signés par une PKI Microsoft et dont les informations sont récupérées dans l’AD et non pas fournies dans la requête

· Changer les altSecurityIdentities de façon à établir une association forte.

Dans notre contexte, seule la seconde solution est possible puisque les certificats sont fournis par une entité tierce. 

Le format recommandé par Microsoft pour établir une liaison forte est le suivant : X509:<I>IssuerName<SR>1234567890

Il contient le nom de l’autorité de certification (au format Distinguished Name) ainsi que le numéro de série du certificat.

Attention : ces deux informations doivent être indiquées « à l’envers ». Par exemple, si le DN de l’autorité émettrice est CN=CONTOSO-DC-CA, DC=contoso, DC=com et le numéro de série du certificat est 2B 3C F4, alors le champ altSecurityIdentities doit contenir la chaine suivante : X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>F43C2B

Une fois cette modification effectuée, la connexion à l’aide de la smartcard fonctionne enfin !

Derrière le terme un peu technique "Coloration conditionnel" se cache simplement le fait, dans un dashboard PowerBI d'afficher un changement de couleur dans le champ d'un tableau, en fonction de condition.

En plus des fonctions natives de mise en forme dans PowerBI Desktop, il est possible de creer une mesure (code DAX) , avec des conditions, que l'on va utiliser pour afficher une valeur dans un champ. Et cette valeur peut etre un code couleur.

Dans l'exemple du code ci-dessous, on a une application "MyApp" pour laquelle, dans PowerBI nous avons trois datasets (deux correspondrait par exemple a deux tables de la base de donnée associée a "MyApp", et un troisième qui est une connexion vers un outil qui reference la criticité de mes machines (ex: outil de gestion des asset ou cmdb)):

- MyAppAgents, qui contiens des infos sur les agents de mon application

- MyAppVersions, qui contiens un historique des numeros de version de mon application

-  MyServers qui est donc la table qui liste la criticité des mes serveurs.

Objectif: On veux dans un dashboard, colorer un champ en rouge ou jaune (exemple, le nom du serveur), pour lequel la version ((MyAppAgents[MyApp_agent_version]) serai differente de la dernière version, ET dont le serveur serait un serveur de Production ou de test.

Color_MyApp_agent = 

   VAR Result1 = SELECTEDVALUE(MyAppAgents[MyApp_agent_version])
   VAR Result2 = SELECTEDVALUE(MyAppVersions[MyApp_Last_version_available])
   VAR Result3 = SELECTEDVALUE(MyServers[Server_Criticity])

-- SI MyApp_agent EST DIFFERENT DE MyApp_Last_version_available ET SI Server_Criticity = "PROD" alors on renvoi "CRITICAL"
   VAR Critical = IF(AND(Result1<>Result2, Result3="PROD"),"CRITICAL")
   
-- SI MyApp_agent EST DIFFERENT DE MyApp_Last_version_available ET SI Server_Criticity <> "TEST" alors on renvoi "WARNING"  
   VAR Warning = IF(AND(Result1<>Result2, Result3<>"TEST"),"WARNING")
   
-- SI MyApp_agent EST EGALE A MyApp_Last_version_available   
   VAR OK = IF(Result1=Result2,"OK")

   
 -- SELON LE CAS ON RENVOI UN CODE COULEUR DIFFERENT
RETURN
SWITCH(
True(),
 Critical="CRITICAL" , "#FEA19E",
Warning="WARNING" , "#F9FF28",
 OK="OK" , "#96FF93" 
)

On crée donc une mesure (measure) dans laquelle on va coller le code ci-dessus

Apres validation la mesure apparait dans le dataset ou elle a été crée

On selectionne ensuite le champ que l'on veut colorer puis Conditional formatting/Background color

On selectionne Format by "Field Value", et on va venir selectionner notre mesure (Color_MyApp_agent)

Apres validation, Les valeurs de la colonne seront formatée selon la condition rencontrée (Les code couleurs '#FEA19E' peuvent bien sur etre modifié dans le code pour choisir une autre coloration):

L'accès conditionnel d'Azure ou Conditional Access (CA) est un service Azure qui permet d'autoriser les connexions vers des applications ou services Azure selon des conditions tels que la plage IP publique d'accès, le type de device ou le niveau de risque de l'utilisateur. Avec la popularisation des VPN, il est difficile de réellement restreindre les connexions depuis un pays donné. Une fonctionnalité récente sortie en 2021 permet dorénavant de demander les coordonnés GPS d'un utilisateur lorsqu'une CA est configurée.

Prérequis pour utiliser la localisation GPS avec l'accès conditionnel Azure

• Chaque utilisateur qui utilise un accès conditionnel doit avoir une licence Azure AD Premium P1
• Le compte qui configure l'accès conditionnel doit avoir un de ces rôles : Security Administrator, Conditional Access Administrator ou Global Administrator
• Les utilisateurs doivent avoir l'application Microsoft Authenticator installée et configurée avec leur compte Azure AD

Créer un emplacement nommé basé sur la localisation GPS

Un emplacement nommé ou name location est un groupement d'IP ou de pays qui sera consommé par une CA pour appliquer une restriction d'accès.

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Named locations > + Countries location

3. Dans la blade (fenêtre Azure) qui s'est ouverte :

• Dans le champs Name choisir un nom à donner à cette named location
• Dans le deuxième champs dont la valeur par défaut est Determine location by IP address (IPv4 only) choisir Determine location by GPS coordinates

4. Il est possible de cocher l'option Include unknown countries/regions, cela permet d'inclure les plages IP qui n'appartiennent à aucun pays et les IPv6 qui ne sont pas incluses par défaut.

5. Dans cet exemple, on souhaite configurer la named location en France, scroller jusqu'à trouver France et cocher la checkbox associée puis cliquer sur Create

Créer un accès conditionnel basé sur la localisation GPS

1. Se connecter au tenant Azure AD via le lien portal.azure.com avec le compte qui a les privilèges requis pour configurer une CA

2. Cliquer sur Azure AD > Security > Conditional Access > Policies > + New policy

3. Dans le champs Name entrer le nom de la CA puis cliquer successivement sur Conditions > Locations > Configure > Include > Selected locations

4. Dans la blade qui est apparue à droite, entrer le nom de la named location précédemment entrée et cocher la checkox associé puis cliquer sur Select

5. Il est ensuite possible d'utiliser les différentes options pour choisir les éléments qui doivent être bloqués, par exemple :

• Users or workload identites permet de choisir si la CA doit s'appliquer à l'ensemble des utilisateur ou à un groupe d'utilisateur spécifique
• Cloud apps or actions permet de choisir l'application Azure à conditionner
• Grant permet de configurer la CA en tant qu'autorisation ou réfutation

6. Une fois les éléments de configuration de la CA choisis, il est possible de la configurer en Report-only pour ne pas qu'elle s'applique réellement, mais pour pouvoir avoir un aperçu de ses effets au travers des Sign-in logs des utilisateurs.

SecretStore est un module Powershell permettant de facilement stocker et gérér des Credentials.

Dans l’exemple ci-dessous nous le mettons en place et l’utilisons pour demander, dans cet exemple, un token d’acces au cloud de l’EDR Crowdstrike.

NB : Le module SecretStore requiert l’installation du module SecretManagement

Comme tout module Powershell, si ils ne peut pas être directement téléchargé en ligne sur un repository avec la commande Install-Module, il est possible de le(s) récupérer sur Github ou encore sur Powershell Galery

(https://www.powershellgallery.com/packages/Microsoft.PowerShell.SecretStore)

(https://www.powershellgallery.com/packages/Microsoft.PowerShell.SecretManagement)

Une fois les module décompressé et stocké dans un des dossier contenant en standard des modules (ex : «C:\Program Files\WindowsPowerShell\Modules»)

NB : Si le module n’est pas stocké dans un chemin déclaré dans la variable $env:PSModulePath, son chemin complet devra être renseigné lors de l’import. Ceci peut être problématique aussi après l’import, dans le cadre de certaines commandes du module. Pour cela il est préférable qu’il soit stocké dans un chemin reconnu par la variable $env:PSModulePath

NB : Pour qu’un module soit correctement reconnu par Powershell, le nom du dossier le contenant doit être identique au nom du fichier psd1 ou psm1 :

 C:\Program Files\WindowsPowerShell\Modules \microsoft.powershell.secretstore

Dans une fenêtre powershell, exécuter Import-module en spécifiant le chemin d’accès aux fichiers indiqué ci-dessous

*****

Import-module microsoft.powershell.secretmanagement

Import-module microsoft.powershell.secretstore

*****

Par défaut le module SecretStore requiert un password pour accéder a chaque au coffre-fort de mot passe. La commande suivante permet de spécifier que l’authentification ne sera pas demandée , uniquement pour l’utilisation actuel (CurrentUser)

Set-SecretStoreConfiguration -Scope CurrentUser -Authentication None -Interaction None

La commande demande un password qui ne sera pas redemandé

La commande suivante permet de créer le coffre-fort (vault). Indiquer un nom explicite pour l’usage de ce coffre. (La commande requiert d’indiquer le module SecretStore)

Register-SecretVault -ModuleName microsoft.powershell.secretstore -Name MyVault

A présent que le coffre est créé, nous allons y stocker les informations requise, dans cet exemple, pour récupérer un token Crowdstrike.

Dans une variable de type hashtable ($ApiClient) On renseigne le Client Id, Le Client Secret, et le Hostname (url de l’api). On ‘range’  ($ApiClient) dans le coffre MYVault. (Set-secret)

$ApiClient = @{
    ClientId     = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    ClientSecret = ' xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
    Hostname     = 'https://api.eu-1.crowdstrike.com'
}

Set-Secret -Name MyApiClient -Secret $ApiClient -Vault MyVault

On peut tester a présent que le credential peut être récupéré :

Get-Secret -Name MyApiClient -Vault MyVault -AsPlainText

Et dans notre exemple, on peut maintenant récupérer notre token Crowdstrike

Get-Secret -Name MyApiClient -Vault MyVault -AsPlainText | ForEach-Object { Request-FalconToken @_ }

Notre token doit etre valable

$(Test-FalconToken).token

Les cmdlets du module PSFalcon peuvent maintenant être exécutées, par exemple :

Get-FalconHost -All -Detailed

NB : Les modules powershell SecretStore et SecretManagement peuvent même etre supprimé (Remove-Module). Le coffre crée sera toujours accessible par le compte l’ayant crée.

Symptômes

Quand vous accédez aux dossiers d’une boîte aux lettres sur votre profil Outlook, vous pouvez rencontrer des problèmes de synchronisation aléatoires suivants :

• Lorsque vous affichez des éléments dans la boîte aux lettres partagée, les nouveaux éléments peuvent ne pas apparaître ou des éléments semblent manquants,

• Les éléments que vous avez supprimés apparaissent toujours,

• Performances d’Outlook lentes ou blocages aléatoires.

Résolution

Désactiver la mise en cache de tous les dossiers partagés (Pour Outlook 2010 et versions ultérieures):

1. Sous l’onglet Fichier, cliquez sur Paramètres du compte dans la liste Paramètres du compte.

2. Dans la boîte de dialogue Paramètres du compte, cliquez sur l’onglet Messagerie, puis double-cliquez sur votre compte Microsoft Exchange. Dans la boîte de dialogue Modifier le compte, cliquez sur Autres paramètres.

3. Dans la boîte de dialogue Microsoft Exchange, cliquez sur l’onglet Avancé puis désactivez la case à cocher Télécharger les dossiers partagés puis Cliquez deux fois sur OK.

4. Cliquez sur Suivant, sur Terminer, puis sur Fermer.

5. Redémarrez Outlook.

Problème

Supposons que vous utilisez Microsoft Outlook 2010 ou une version ultérieure et que vous êtes autorisé à envoyer des messages électroniques en tant qu’un autre utilisateur ou pour le compte d’un autre utilisateur à partir d’une boîte aux lettres partagée. Toutefois, lorsque vous envoyez un message pour cet utilisateur, ce message n’est pas enregistré dans le dossier Éléments envoyés de la boîte aux lettres partagée. En lieu et place, il est enregistré dans le dossier Éléments envoyés de votre boîte aux lettres.

Résolution

1. Cliquez sur Démarrer, puis sur Exécuter, tapez regedit, puis cliquez sur OK.
2. Recherchez la sous-clé de Registre suivante, puis cliquez dessus :

HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\Preferences

 Note: Lʼespace réservé x.0 représente la version dʼOffice (16.0 = Office 2016, Office 2019, 15.0 = Office 2013).

3. Dans le menu Edition, pointez sur Nouveau, puis cliquez sur Valeur DWORD.
4. Tapez « DelegateSentItemsStyle », puis appuyez sur Entrée.
5. Cliquez avec le bouton droit sur DelegateSentItemsStyle, puis cliquez sur Modifier.
6. Dans la zone Données de la valeur, tapez 1, puis cliquez sur OK.
7. Fermez l’Éditeur du Registre.

Note: Outlook doit être configuré en mode mis en cache pour que cette modification du clé de registre fonctionne correctement. 

Contexte

Une boîte aux lettres partagée est une boîte aux lettres que plusieurs utilisateurs peuvent utiliser pour lire et envoyer des e-mails ou encore partager un calendrier commun. Une boîte aux lettres partagée est un type de boîte aux lettres utilisateur qui n'a pas son propre nom d'utilisateur et mot de passe. Par conséquent, les utilisateurs ne peuvent pas s'y connecter directement

Pour accéder à une boîte aux lettres partagée, les utilisateurs doivent d'abord disposer des autorisations Envoyer en tant que ou Accès total à la boîte aux lettres et dans ce cas, le mappage automatique connecte la boîte aux lettres partagée aux utilisateurs associés. 

Si vous souhaitez partager la boîte aux lettres en lecture seule, ou mieux avec des autorisations "Relecteur", vous devez supprimer à l'utilisateur les autorisations d'accès total, puis utiliser PowerShell pour définir les autorisations correctes et dans ce cas, le mappage automatique ne fonctionnera pas.

1. Positionnez tout d'abord l'autorisation par défaut: 

Add-MailboxPermission -Identity SharedMailbox -User 'Username' -AccessRights ReadPermission 

2. Puis, définissez les autorisations "Relecteur" pour tout dossier que vous souhaitez partager en lecture seule 

Add-MailboxFolderPermission -Identity Support:\ -User upn@domain.com -AccessRights Reviewer

Add-MailboxFolderPermission -Identity Support:\Inbox -User upn@domain.com -AccessRights Reviewer

Add-MailboxFolderPermission -Identity Support:\Outbox -User upn@domain.com -AccessRights Reviewer 

Attention : vous devez appliquer l'autorisation à chaque dossier de boîte aux lettres, Support est le nom du dossier partagé.

• Pour supprimer l'autorisation, exécutez la commande

Remove-MailboxFolderPermission -Identity Support:\Outbox -User upn@domain.com   

L’EDR Crowdstrike integre bien sur une fonction de scan de machines cibles, a la demande ou planifiés.

Aller sur le lien Endpoint security/On-demand scans

Cliquer Create a scan

Sélectionner Now ou In the future pour planifier un scan

Laisser coché l’option «Limit how long this scan runs» pour limiter la durée du scan. NB : La durée de 2 heures par défaut pourra être adapté au vu de la durée observée en moyenne dans le résultat final du/des scans.

Sélectionner une ou plusieurs et/ou des groupes de machines (la selection dans le champs affiche automatiquement les éléments)

Inscrire un ou plusieurs chemin a scanner (1 par ligne)

Inscrire éventuellement un ou plusieurs chemin a exclure

Le champ «Exclusions to test against above pattern» peut être utilisé pour tester les exclusions.

Dans l’exemple ci-dessus, on veut scanner le lecteur D:\, en excluant tout le contenu (*) de D:\App1

(la coche et la couleur du test effectué  valide le fait que la syntaxe de l’exclusion est correcte. Au contraire, par exemple  ne sera pas exclu)

Le bouton  peut être utilisé pour charger une liste d’exclusion en respectant une ligne par exclusion.

Renseigner une description explicite

Laisser par défaut la niveau de détection et de prévention a Moderate

Pour information la description des niveau de détection est la suivante :

Selectionner un niveau maximum de consommation CPU a utiliser (par defaut Low up to 25%)

Décocher Show notifications to end user si vous ne voulez pas que l’utilisateur connecté sur la machine reçoive une notification de Scan (le paramètre Pause duration permet d’autoriser l’utilisateur connecté à reporter le scan pour une durée donnée)

Cliquer Create Scan

Le scan apparait dans la liste et passez en état Completed lorsque le scan est fini.

Un clic sur le scan permet d’avoir le détail

Cliquer sur See full details pour afficher les détails complets

Dans notre exemple, la machine cible est bien dans les «Hosts without detection»

Le lien  permet d’accéder si besoin a des éléments de diagnostique/remédiation, dans le cas d’une machine ou des détections ont été remontées :

Problématique: Nous voulons a travers une requete Dax compter un nombre de machines possedant une application 'MyApp' dans une table nommée MY_HOSTS_AND_APPS

Mais une partie des machines n'a pas cette info renseignée dans la colonne [AppName]. Cette info est inscrite sous la forme d'un texte libre dans une autre colonne [HostUsage]

Il est possible dans ce cas d'utiliser un OR (preferer l'alias '||') dans la clause FILTER.

On compte donc (DISTINCTCOUNT), les HostName où [AppName] est égale a "MyApp" ou bien (||) la chaine "MyApp" est presente dans [HostUsage]  (SEARCH)

WithMyApp = 
VAR Result = CALCULATE(
    DISTINCTCOUNT(MY_HOSTS_AND_APPS[HostName]),
        FILTER(MY_HOSTS_AND_APPS,MY_HOSTS_AND_APPS[AppName]="MyApp"
        ||
        SEARCH("MyApp",MY_HOSTS_AND_APPS[HostUsage],1,0)
        )               
)
RETURN(
    IF (Result=BLANK(),0,Result))

SYSVOL est un partage de fichier créé par défaut et partagé entre chaque contrôleur de domaines (DC) dans un Active Directory (AD). DFSR est le mécanisme en charge de la réplication du contenu du SYSVOL entre chaque DC. La santé de la réplication DFSR sysvol est essentielle, car certains services de l'AD en dépendent pour leur fonctionnement, tel que les GPO.

Prérequis pour identifier les problèmes de réplication DFSR sysvol et forcer la restauration

• Avoir un compte Domain Admin
• Avoir accès au DC qui a des problèmes de réplications
• Avoir accès à la commande Dfsrdiag depuis le DC qui a des problèmes de réplications, si la commande n'est pas accessible, elle peut être installée depuis Server Manager > Add Roles and Features > Features > Role Administration Tools > File Services Tools > DFS Management Tools

Identifier les problèmes de réplication DFSR sysvol

Pour les exemples qui vont suivre, le DC2 présente des problèmes de réplications DFSR sysvol depuis le DC1 qui est sain. 

Plusieurs éléments qui ne nécessitent pas d'investiguer des logs peuvent alerter d'un problème de réplication DFSR sysvol :

• Lorsqu'une GPO créée sur le DC1 n'est pas accessible depuis le DC2, exemple de message d'erreur dans la console Group Policy Management : The system cannot find the file specified.
• Lorsqu'un fichier est créé dans le SYSVOL du DC1 \\DC1.domain.intern\SYSVOL\domain.intern et qu'il n'est pas répliqué dans le SYSVOL du DC2 \\DC2.domain.intern\SYSVOL\domain.intern
• Lorsque le nombre de GPO du DC1 \\DC1.domain.intern\SYSVOL\domain.intern\Policies est différent du nombre de GPO du DC2 \\DC2.domain.intern\SYSVOL\domain.intern\Policies

Il est possible d'utiliser la console DFS Management pour faire des tests de réplication, mais ceux-ci ne sont pas assez granulaires.

Depuis le DC qui a des problèmes de réplications, dans une invite de commande PowerShell, la commande Dfsrdiag est utilisée pour avoir un état des lieux du statut des objets en attente de réplication.

PS C:\Windows\system32> Dfsrdiag replicationstate
Summary

  Active inbound connections: 0
  Updates received: 0

  Active outbound connections: 0
  Updates sent out: 0

Operation Succeeded

Le résultat de la commande précédente montre une réplication saine. Lorsque des objets sont en attente de réplication, la liste des objets non répliqués s'affiche.
La valeur de Sending member indique le DC (par exemple DC1) depuis lequel le DC actuel (par exemple DC2) essaye de répliquer les objets du SYSVOL.

Le paramètre syncnow de la commande Dfsrdiag peut être utilisé pour tenter de forcer la réplication des objets en attente.

Dfsrdiag syncnow /partner:DC1.domain.intern /time:5 /RGName:"Domain System Volume"

#synnow permet de forcer la réplication depuis le DC spécifié après le paramètre /partner. Le Sending member précédent peut être utilisé.

#/time est la durée en minutes pendant laquelle la réplication est forcée. 5 minutes sont choisies, car c'est suffisant pour répliquer une centaine d'objets si la réplication fonctionne.

#/RGName est le nom du partage DFS, pour sysvol il s'agit de Domain System Volume

Suite à cette commande, il faut revérifier le statut de la réplication avec la commande Dfsrdiag replicationstate.

Il est possible de tenter la réplication depuis un partenaire différent ou de laisser plus de temps à la réplication.
Si le nombre d'objets en attente de synchronisation ne varie pas, il faut procéder à une restauration du DFSR sysvol.

Forcer la restauration DFSR sysvol d'un contrôleur de domaine

La restauration du DFSR sysvol consiste à faire une synchronisation non authoritative depuis un DC sain. C'est-à-dire que le contenu SYSVOL du DC2 qui a des problèmes de synchronisation sera écrasé par le contenu du SYSVOL du DC1. Les méthodes utilisées précédemment : le fonctionnement par défaut de DFSR et la commande dfsrdiag syncnow tentent de faire des synchronisation avec gestion des conflits, mais certains conflits de versions ne peuvent être résolus par les algorithmes internes.

1. Se connecter au DC2 qui a des problèmes de réplications

2. Ouvrir la console ADSI Edit, faire un clique droit sur ADSI Edit et cliquer sur Connect to..

3. Dans Connection Point choisir Select a well known Naming Context puis choisir Default naming context, dans Computer choisir Select or type a domain or server puis entrer le nom du DC qui a des problèmes de réplication puis cliquer sur OK

4. Déplier les dossiers Default naming context > <Domain> > OU = Domain Controllers > CN=<Nom du DC qui a des problèmes de réplications> > CN =DFSR-LocalSettings > CN = Domain System Volume > faire un clic droit sur CN = SYSVOL Subscription > Properties

5. Dans l'onglet Attribute Editor chercher l'attribut msDFSR-Enabled, faire un clic droit sur cet attribut et changer la valeur de True à False. Cette action à permis de désactiver la réplication DFSR sysvol pour le DC2

6. Depuis le DC2 ouvrir une console PowerShell et entrer la commande

repadmin /syncall /AdP

Cette commande permet de forcer la synchronisation des AD du DC2

7. Depuis le PowerShell du DC2 entrer la commande

Dfsrdiag PollAD

Cette commande permet de récupérer la configuration DFSR sans attendre qu'une réplication AD s'exécute.

8. Il est possible de vérifier que la réplication DFSR a bien été arrêté en consultant l'Event Viewer du DC2 et notamment l'Event ID 4114 dans Applications and Services Logs > DFS Replication

9. Réactiver la synchronisation DFSR sysvol sur le DC2 en suivant les étapes 1 à 5. Cette fois passer la valeur de msDFSR-Enabled de False a True

10. Forcer la réplication AD et DfsrDiag depuis le DC2 avec les commandes des étapes 6 et 7

11. Vérifier le statut de la synchronisation non authoritative DFSR sysvol du DC2 en ouvrant l'Event Viewer depuis le DC2, depuis le dossier Applications and Services Logs > DFS Replication > consulter les logs et notamment la présence de l'Event ID 4614

12. Depuis le DC2 dans une console PowerShell, utiliser la commande Dfsrdiag replicationstate pour vérifier s'il existe toujours des objets non répliqués

13. Faire un test de réplication SYSVOL DFSR en crééant un fichier sur le DC1 (sain) \\DC1.domain.intern\SYSVOL\domain.intern puis se connecter sur le SYSVOL du DC2 (réparé) \\DC2.domain.intern\SYSVOL\domain.intern et vérifier que le fichier est présent

Pour aller plus loin

Documentation officielle Microsoft How to force authoritative and non-authoritative synchronization for DFSR-replicated sysvol replication