• Mise en place du “Content Freshness protection” dans DFS-R

    Depuis Windows 2008 , DFS-R supporte un nouveau mécanisme appelé « Content Freshness ».

    Cette option se rapproche de l’option Strict Replication Consistency crée pour l’AD, afin éviter de propager les lingerings objects.

    Pour DFS-R, chaque élément supprimé d’un dossier répliqué est marqué en tombstone dans la base DFS-R, mais n’est pas supprimé physiquement.

    C’est après une période de 60 jours que le « DFS-R garbage collection » va supprimer physiquement ces éléments.

    Si un serveur n’a pas pu répliquer les données d’un dossier répliqué pendant plus de 60 jours, et que la réplication est de nouveau fonctionnelle, ses partenaires peuvent répliquer des anciennes demandes de suppressions qui sont pourtant « actives », ou répliquer des données anciennes, écrasant les plus récentes.

    Pour éviter cela, l’option Content freshness se base sur un enregistrement appelé CONTENT_SET_RECORD , présent dans la base de donnée DFS-R du serveur, pour chaque dossier répliqué.

    Cet enregistrement contient un timestamp appelé LastConnected.

    DFS-R va mettre à jour ce timestamp pour indiquer que la réplication s’est produite.

    Lors de la réplication entre membres, DFS-R compare alors l’heure de la dernière réplication et celle courante.

    Si la date de la dernière est inférieure à 60 jours (MaxOfflineTimeInDays ), la réplication est autorisée.

    Si elle est supérieure à 60 jours, elle est bloquée.

    Cela protège l’envoi de données divergentes pour le reste des partenaires.

     

    Activer l’option Content Freshness

    Cette option n’est pas activée par défaut.

    Elle est à activer sur chaque membre, dans le fichier DfsrMachineConfig.XML.

    Il faut modifier la valeur de MaxOfflineTimeInDays via la commande suivante :

    wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig set MaxOfflineTimeInDays=60 

    clip_image002

     

     

     

     

     

     

    Pour visualiser la valeur :

    wmic.exe /namespace:\\root\microsoftdfs path DfsrMachineConfig get MaxOfflineTimeInDays

    La valeur recommandée est : 60.

    Une fois en place, un event est retrouvé :

    Log Name:      DFS Replication
    Source:        DFSR
    Date:          1/1/2010 3:37:14 PM
    Event ID:      4012
    Task Category: None
    Level:         Error
    Keywords:      Classic
    User:          N/A
    Computer:     
    Description:
    The DFS Replication service stopped replication on the replicated folder at local path c:\xxx. It has been disconnected from other partners for 76 days, which is longer than the MaxOfflineTimeInDays parameter.

    Des informations sont retrouvées dans les logs DFS-R.

    L’état du dossier répliqué est en erreur, définie à 5.

    Pour voir l’état :

    wmic.exe /namespace:\\root\microsoftdfs path DfsrReplicatedFolderInfo get ReplicationGroupName,ReplicatedFolderName,State

    ReplicatedFolderName   ReplicationGroupName                 State
    nom_dossier_répliqué    nom_du_groupe_de_réplication      5

    MaxOfflineTimeInDays
    Data type: uint32
    Access type: Read/write
    Qualifiers: MinValue(0)
    The maximum number of days a replicated folder can be disconnected from other partners before it is put into an error state.
    Windows Server 2003 R2:  This property is not supported until Windows Vista.
    http://msdn.microsoft.com/en-us/library/bb540017(VS.85).aspx

     

    Rétablir la réplication

    Pour autoriser à nouveau la réplication, il est nécessaire de créer une sauvegarde de données.

    Ensuite, désactiver le membre impacté via la console dfsmgmt.msc.

    Attendre que la réplication AD entre DCS soit effectuée, puis sur ce membre, lancer la commande :

    DFSRDIAG POLLAD

    Vérifier la présence des events 4008 et 4114.

    Réactiver le membre dans la console.

    Il est à noter que ceci force une réplication initiale sur ce membre.

    Tous les fichiers présents sur ce serveur et non présents sur le membre primaire seront déplacés dans PreExisting.

    Tous les fichiers locaux perdront le conflit et seront retrouvés dans ConflictAndDeleted.

     

    Joseph Besançon
    Domain & Security Team

  • Suppression & désactivation des listes de révocation (CRL) en cache sous CAPI2

    Par défaut, Windows utilise la liste de révocation (CRL) en cache jusqu’à son expiration avant de tenter la récupération d’une nouvelle CRL publiée par l’Autorité de Certification.

    Avant la version Windows Vista, Microsoft ne supportait pas la suppression ou le renseignement manuel du cache de CRL (via la commande « certutil -URLCache CRL –delete » …, bien que cela soit souvent fonctionnel sous Windows XP et Windows 2003).

    Depuis Windows Vista CAPI2 et donc Windows Vista, Windows 7 et Windows 2008 /R2, il est maintenant supporté de supprimer le cache de CRL et même de procéder à son « invalidation » avec la commande suivante :

    Pour la suppression du cache de CRL sur le disque (a effectuer dans le contexte de sécurité approprié, SYSTEM ou utilisateur):

    certutil -URLCache CRL –delete

    NB: Utiliser Certutil –v –URLCache CRL pour lister le cache des CRL sur le disque.

    Pour l’obtention de la configuration actuelle ou visualiser quand le cache a été invalidé (avant cette date toutes les entrées sont invalides):

    certutil –getreg chain\ChainCacheResyncFiletime

    Nb : Si ce paramètre n’a jamais été utilisé vous obtiendrez le message ci-dessous ce qui est normal :

    CertUtil: -getreg command FAILED: 0x80070002 (WIN32: 2)

    CertUtil: The system cannot find the file specified.

    Pour informer le SYSTEM qu’à présent toutes les entrées dans le cache CRL /OCSP sont invalides vous pouvez utiliser la commande suivante :

    certutil -setreg chain\ChainCacheResyncFiletime @now

    Pour informer le SYSTEM qu’à présent toutes les entrées dans le cache CRL /OCSP sont invalides et cela jusque dans 3 jours et 6 heures, vous pouvez utiliser la commande suivante :

    certutil –setreg chain\ChainCacheResyncFiletime @now+3:6

              Par exemple, toutes les entrées en cache sont invalides jusqu’au 12/02/2010 16H42 :

    clip_image002

    Pour supprimer cette fonctionnalité vous pouvez simplement utiliser :

    certutil –delreg chain\ChainCacheResyncFiletime

    (ou mettre une date ancienne… dans ChainCacheResyncFiletime)

    CAPI utilise 2 caches de CRL et d’OCSP : Le cache sur disque et le cache en mémoire.

    - Le cache sur le disque contient les CRLs et les réponses OCSP récupérées lors du processus de contrôle de révocation et cela jusqu’à expiration.

    - Le cache en mémoire des CRL  est lié à une application spécifique, quand l’application est terminée, les informations de CRL en mémoire sont vidées.

    La commande “certutil –URLcache CRL delete” supprime le cache sur le disque mais pas en mémoire.

    Si vous  souhaitez invalider l’utilisation des CRL en cache dans la mémoire et sur le disque il faut utiliser la commande certutil –setreg chain\ChainCacheResyncFiletime @now (Sous Windows Vista et ultérieure). Cette commande ne supprime pas les CRL en cache mais indique au SYSTEM que toutes les CRL ajoutées au cache avant la date spécifiée dans la clé ChainCacheResyncFiletime sont invalides.

    Cette clé s’applique pour l’ensemble de la machine et pour tous les processus tournant sur cette machine.

    Aucun redémarrage n’est nécessaire pour la prise en compte de cette clé, les droits d’administrateur local sont nécessaires pour la modification de cette valeur.

    Hope this help!

    Daniel PASQUIER

    Sr Technical Lead

    Domain & Security Team