Un de mes contrôleurs de domaine a rencontré un problème qui causait des erreurs de réplication sur les autres DCs. Dans l’observateur d’événements de mes deux autres contrôleurs j’obtenais l’erreur suivante toutes les quelques minutes :

Type de l’événement :    Erreur
Source de l’événement :    NTDS Replication
Catégorie de l’événement :    Réplication
ID de l’événement :    1699
Utilisateur :    CORP\DC01$
Ordinateur :    DC02
Description :
Le contrôleur de domaine local n’a pas pu récupérer les modifications demandées pour la partition d’annuaire suivante. En conséquence, il n’a pas pu envoyer les demandes de modification au contrôleur de domaine à l’adresse réseau suivante.

Partition d’annuaire :
DC=corp,DC=local,DC=com
Adresse réseau :
0c03a47c-75e2-4745-b632-6a0671731f28._msdcs.corp.local.com
Code de requête étendue :
0

Données supplémentaires
Valeur de l’erreur :
8453 L’accès à la réplication a été refusé.

System Center Operations Manager 2007 me remontait également des erreurs, indiquant que la réplication était lente ou ne fonctionnait pas sur certains contrôleurs de domaine.

Lorsque je tentais de forcer la réplication à partir de DC01 dans Sites et Services Active Directory j’obtenais une erreur « L’opération de réplication a échoué en raison d’une correspondance de schémas incorrecte entre les serveurs impliqués ». A partir de DC02 ou DC03 j’obtenais un message de succès « Active Directory a répliqué les connexions« .
Continuer à lire "Erreur de réplication 1699 sous Windows 2003"

Dans un domaine il est important que les horloges de l’ensemble des machines soient synchronisées. En effet le protocole d’authentification Kerberos requiert par défaut une différence maximale de 5 minutes entres les horloges afin de prévenir les attaques.

Si l’authentification se basait uniquement sur un nom d’utilisateur et un mot de passe il serait théoriquement possible pour une personne mal intentionnée d’enregistrer le trafic réseau, d’en extraire ces données et de les rejouer au serveur. Les clés de sessions Kerberos sont uniques et basées sur l’heure du client, ce qui permet d’éviter ces attaques si la différence maximale tolérée est relativement faible.

Afin d’être certain que les horloges sont toutes synchronisées entre elles il est nécessaire de définir une source de temps faisant autorité. Il est ainsi possible de configurer le contrôleur de domaine maître d’opération PDC afin qu’il devienne une source de temps de strate 2 se synchronisant sur une source de temps de strate 1 (en général un serveur de temps basé sur une horloge atomique).

Continuer à lire "Configurer un serveur de temps faisant autorité sous Windows 2003"

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.

Continuer à lire "Problème de réplication des partages SYSVOL et NETLOGON"