Publié dimanche 12 septembre 2010 23:03 par Arnault Nouvel

SharePoint 2010 : Configuration de l’authentification par formulaire avec annuaire AD-LDS (partie 4 – haute disponibilité de l’annuaire AD-LDS)

Ce billet fait partie d’une série :

Nous allons voir dans ce billet comment répliquer l’instance AD-LDS sur un second serveur et comment configurer la répartition de charge réseau afin d’assurer une haute disponibilité sur l’annuaire AD-LDS.

Voici les étapes :

  • Répliquer l’instance AD-LDS sur un deuxième serveur
  • Créer un cluster de répartition de charge
  • Rediriger le nom de domaine annuaire.extranet.test vers l’adresse IP du cluster

1. Installation d’une réplique de l’instance AD-LDS

Avec le même compte que le compte administrateur spécifié lors de la création de l’instance installé EXTRANET-ADLDS, se connecter au serveur EXTRANET-ADLDS2.

Après avoir installé le rôle “Active Directory Lightweight Directory Services”, lancer l’assistant de création d’instance comme nous l’avons fait dans la partie 2.

Sur le premier écran, choisir la 2ème option pour indiquer que l’on souhaite créer une réplique d’une instance existante :

23-replicat-install-adlds

Indiquer le serveur sur lequel se trouve l’instance à répliquer :

24-replica-choose-source

Sélectionner la partition à répliquer :

25-replica-choose-partition

Dérouler l’assistant jusqu’à la ce que la réplique soit créée.

Avec ADSIEdit.msc, il est possible de vérifier que l’instance est fonctionnelle (comme expliqué dans la partie 2), on retrouvera d’ailleurs les utilisateurs et groupes créés sur l’autre serveur.

Il faut cependant bien comprendre qu’on a là 2 instances différentes qui se synchronisent à intervalles réguliers.

2. Planification de la réplication

Démarrer la console “Active Directory Sites and Services” : Start, Administrative Tools, Active Directory Sites and Services.

Par défaut la console se connecte au domaine Active Directory du serveur. Nous allons lui demander de se connecter à notre instance AD-LDS via un clic-droit sur le noeud racine, puis “Change Domain Controller…”

image

Indiquer alors le nom d’un des serveurs (le principal ou la réplique, au choix) comme sur la capture suivante :

29-change-directory-server

Une fois connecté, on sélectionne le site “Default-First-Site-Name” et on ouvre les propriétés “NTDS Site Settings” :

image

Note : l’écran de propriétés n’est disponible que si le package MS-ADLDS-DisplayContainer.ldf a été importé lors de l’installation de l’instance principale.

L’écran des propriétés nous propose notamment de modifier la fréquence de réplication grâce à cette interface :

34-schedule

Nos 2 instances étant opérationnelles et répliquées, nous allons maintenant mettre en place la répartition de charge avec Windows NLB.

3. Planification de la répartition de charge avec Windows Network Load Balancing (NLB)

Pour schématiser, nous allons créer un cluster NLB qui correspondra à une IP virtuelle, et y associer les cartes réseau de nos 2 serveurs (EXTRANET ADLDS et EXTRANET-ADLDS2). Ces cartes réseau seront configurées par Windows NLB pour écouter les paquets adressés à l’adresse IP virtuelle du cluster.

La mise en place de ce système nécessite une planification.

Premièrement, il nous faut une adresse IP libre pour le cluster NLB.

Nous utiliserons ici l’adresse IP 192.168.70.10 pour notre cluster NLB, en sachant que EXTRANET-ADLDS utilise 192.168.70.11 et que EXTRANET-ADLDS2 utilise 192.168.70.12.

Dans la partie 2 nous avons créé un alias DNS annuaire.extranet.test qui pointe sur EXTRANET-ADLDS. Une fois la répartition de charge mise en place, nous modifieront l’entrée DNS pour qu’elle pointe vers l’IP du cluster au lieu de l’IP du serveur AD-LDS principal.

Ensuite, choisir son mode de fonctionnement :

  • En mode multicast, une carte réseau répond à la fois à son IP et à celle du cluster. Attention, certains équipements réseau (de vieux switchs par exemple) ne supportent pas ce mode. Avant de s’orienter sur ce mode, il faut vérifier si il est supporté par tous les équipements réseau situés entre les clients (le serveur SharePoint par exemple) et les serveurs cibles (AD-LDS).
  • En mode unicast, une carte réseau ne pourra répondre qu’aux paquets adressés au cluster, il faudra donc 2 cartes réseau par serveur du cluster.

Nous utiliserons ici le mode multicast qui est plus simple à mettre en place puisqu’il ne nécessite qu’une carte réseau par serveur.

Enfin, déterminer le “client affinity” qui correspond à la manière dont le NLB répartie les paquets provenant d’une même source :

  • None : les paquets sont envoyer aléatoirement à un ou l’autre des noeuds du cluster (le noeud cible reste le même pendant la durée de la session, une session étant lié à un port précis)
  • Single : une fois qu’un client (SharePoint par exemple) aura établit une première connexion à un noeud du cluster, les paquets suivants seront redirigés vers le même, quelque soit le port cible
  • Network : Le routage est fonction du sous-réseau de provenance du paquet

Nous utiliserons ici le mode Single.

4. Création du cluster NLB

Sur chaque serveur AD-LDS, via la console Server Manager, installer la fonctionnalité Windows appelée “Network Load Balancing” :

40-add-nlb-feature

Ensuite, se connecter sur le premier serveur AD-LDS (EXTRANET-ADLDS).

Exécuter la console d’administration du NLB : Cliquer sur Start, Administrative Tools, “Network Load Balancing Manager”.

Clic-droit sur le noeud racine, puis “New Cluster” :

41-creer-cluster

Saisir le nom du premier serveur à ajouter au cluster

42-creer-cluster-2

La fenêtre Host Parameters qui vient ensuite nous permet de spécifier un paramétrage pour le serveur indiqué précédemment. On indique la priorité du serveur au sein du cluster (la plus basse reçoit les paquets en priorité) et la ou les adresses IP qui feront partie du le cluster (un serveur peut avoir plusieurs cartes réseau).

42-cluster-host-parameters

La fenêtre “Cluster IP Adresses” permet de saisir la ou les adresses IP du cluster.

Nous allons ici ajouter l’adresse 192.168.70.10 qui est celle de notre cluster:

44-cluster-add-ip

La fenêtre “Cluster Parameters” permet de définir le host name à prendre en compte ainsi que le mode dont nous avons parlé plus haut, et ce pour chaque adresse IP. Indiquer annuaire.extranet.test pour le host name, et sélectionner le mode multicast :

45-cluster-parameters

L’écran suivant permet de définir quels ports seront pris en compte par le cluster. Par défaut, ils le sont tous.
Supprimer cette plage de port et n’indiquer que les ports 389 et 636 utilisés par nos instances AD-LDS. Pour chacun, sélectionner le protocole TCP et le Filtering mode “Single” :

46-cluster-ports

47-cluster-ports2

Nous avons à ce stade un cluster de répartition de charge qui contient un seul serveur, le EXTRANET-ADLDS. Nous allons maintenant ajouter le serveur EXTRANET-ADLDS2 au cluster.

Faire un clic-droit sur le cluster, “add host to cluster”, puis re dérouler les étapes précédentes pour ajouter le serveur EXTRANET-ADLDS2 :

48-cluster-final

La répartition de charge étant prête, il ne reste plus qu’à rediriger le nom de domaine annuaire.extranet.test vers l’adresse IP de notre cluster.

5. Redirection DNS

Les requêtes LDAP émanant de la ferme SharePoint sont effectuées sur le nom de domaine annuaire.extranet.test, qui pointe sur le serveur EXTRANET-ADLDS. Nous allons maintenant modifier l’entrée DNS annuaire.extranet.test pour qu’elle corresponde à l’adresse IP du cluster.

Se connecter au controlleur de domaine EXTRANET-AD avec le compte administrateur du domaine.

Ouvrir la console de gestion DNS : Start, Administrative Tools, DNS.

Déplier l’arborescence jusqu’au noeud extranet.test.

Supprimer l’alias annuaire (clic-droit, remove)

Créer une entrée de type Host (clic-droit, new Host) nommée annuaire pointant sur l’adresse IP du cluster : 192.168.70.10

image

A cause de son cache, le serveur SharePoint continue d’associer annuaire.extranet.test au serveur EXTRANET-ADLDS. Pour vider le cache DNS du serveur SharePoint afin qu’il associe annuaire.extranet.test à l’adresse IP du cluster NLB, il faut se connecter dessus et exécuter la ligne de commande suivante : ipconfig /flushdns

SharePoint communique désormais avec un annuaire AD-LDS assurant une haute disponibilité. On peut s’amuser à éteindre et rallumer les serveurs AD-LDS un par un et vérifier que l’authentification fonctionne toujours.

 

Arnault Nouvel – Winwise

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01