Exchange 2013 et AD

Source: Livre "Exchange Serveur 2013 - examen 70-341", Editions ENI (fev 2014) - p 33 à 74

Le conteneur "Organisation" indique les patches, et est créé lors de l'install Exchange 2013. Si l'attribut msExchProductId de cet objet (orga) est > 15.00.516.03 alors le cumulative update 1 a été passé.

AD sous Windows Server 2012 : voir dcpromo n'est plus.

Schéma, catalogue global AD

1 seul schéma pour la foret. On y trouve 2 types de definitions (qu'il est possible de créer ds ad): classes d'objects et attributs.
Le voir: regsv32 schmmgmt.dll  puis Win+R mmc Fichier/Ajouter/Supr un composant logiciel enfichable -> choix sch AD.

Catalogue global a une partie des attributs les plus utilisés + infos nécessaires pour trouver emplacement des objets ds annuaire. Srv de cata global: CD qui a copie du cata global et traite les requetes. Le 1er CD installé (foret) est srv de cata global par défaut.

Sites AD et replication

Si 1 seul site: les réplications sont propagées au fil de l'eau et depuis tous les CD du domaine.
Exchange 2010 est fortement lié aux sites pour le routage. Exhange 2013 l'est un peu moins, car, pour la majeur partie de ses paramètres, on peux s'appuyer ou non sur les sites AD.

Réplication intrasite

entre CD du meme site. Via RPC (Remote Procedure Call).
Le processus KCC (Knowledge Consistance Checker, le vérificateur de cohérence des connaissances) est executé sur chaque DC, en charge de la mise en place de la topologie locale, et maj (si add/del CD sur le site). KCC privilégie la topologie en anneau (entre les partenaires de réplication).
Si modif, tp latence de 5 sec (valeur par défaut) avant l'envoi du message de modif (envoyé aux autres partenaires de la réplication). Les partenairtes, qd ils recoivent ce message, récupèrent la modif depuis le CD qui a envoyé le message.

Réplication intersite, ISTG et cout des chemins

entre divers sites AD.

Si les sites ont été créés, et des sous-réseaux spécifiés, une topologie de réplication intersite est mise en place automatiquement par le processus ISTG (Intersite Topology Generator). ISTG s'execute sur les CD.
Pour chaque site, ISTG nomme un srv "tete de pont" (bridgehead server), chargé de propager la modif  via les liens établis (=> s'il recoit une maj depuis un autre site, il propage cette modif aux autres CD de son site, selon procédure classique de duplication intrasite).

Compression du traffic lié à répli approxvmnt 15%. Le srv tete de pont utilise RPC et parfois aussi SMTP pour certains éléments (ex: réplication des partitions de configuration et du schéma et partitions de domaines partielles stockées sur srv de cata global).

Par défaut le cout de chaque lien est de 100. Si l'on coupe une liaison (pour optimiser flux sur chemins qui ont débit suffisant: perte capacité de redondance et surtout l'ISTG pourrait la recréer plus tard (lors prochaine réévaluation de la topoolgie intersite) => utiliser les couts.

Le traffic de réplication passera par chemin ayant le cout le plus faible (en sommant des divers couts) -voir ex p49.

Outils du gestionnaire de serveur / Sites et services AD, section Sites/ Inter-Site Transports / IP -> clic droit sur lien du site / Propriétés.

Partitions d'annuaire

db AD sur chaque DC de la foret: fichier NTDS.DIT -> voir Partitionnement de la db d'AD

Les 5 roles Maitres d'opérations - FSMO

En général les modifs sur AD sont propagées sut tous les autres CD, en réplication multimaitre. Ceratines opérations critiques (pour foret/domaine) ne sont prises en charge que par certains CD (avec un ou n roles FSMO) et en mode de réplication monomaitre.

Il y a 5 roles FSMO = Flexible Signe Operations Master

Le Rôle Contrôleur de schéma

Gestion des modifs du schéma AD (schéma est commun à la foret)., mécanisme de réplication. Lors de la prépa d'AD (pour install exchange), toutes les modifs sont envoyées au controleur des schémas (pour propagation).

Role Maitre d'attribution des noms de domaine

Role chargé de définir l'appartenance d'un domaine à la foret (ajout ou retrait d'un domaine à foret). Il agit sur la partition de configuration et (est le seul à pouvoir modifier) la partition d'applications.

Unique pour la foret (idem controleur de schéma).

Maitre RID

Les entités de sécurité (user, ordi, groupe) ont un ID unique le SID (security IDentifier). Chaque SID est composé d'un ID de domaine et (au sein d'un meme domaine) une partie unique (le RID, Relatif). Ex: S-1-15-10-0123456789-1234567890-1001

Quand on crée un objet dans le domaine, l'objet est créé par le CD (où on est connecté) et le CD lui affecte un numéro relatif.
Pour éviter duplication de RID, le CD qui a le role maitre RID attribue à chaque DC des plages de RID.

Role unique dans un domaine.

Emulateur PDC

1. prend en charge modif pw et leur réplication (vers autres DC du domaine)
2. gère le verouillage des comptes
3. si un user tente de s'authentifier avec un bad pw, l'erreur est d'abord envoyée à émulateur PDC qui vérifie qu'il n'y a pas eu de modifs non répliquée vers le CD qui a transmis l'erreur.
4. les CD l'utilisent pour syncroniser leur horloge.

Ce role est apparu avec Win 2000 et garde trace de NT4 dans son nom (Primary Domain Controller).

Role Maitre d'infrastructure

Pour une foret à x domaines, ce role traduit des ID (SID et GUID) en leur nom distingué (pour le cas où des objets appartenant à un autre domaine seraient sollicités).

A ne pas installer sur un CD qui a de plus le role catalogue global (seul cas où ces 2 roles peuvent etre sure le meme srv: foret monodomaine).

Utilisation par Exchange du DNS

FQDN = Fully Qualified Domain Name.
Ex FQDN: ad-dc01.consulting.eni.fr   où on nomme:  "." racine   fr est TLD (Top Level Domain)   domaine second niveau est eni   et  ad-dc01 = nom hote.

Recherche directe: IP -> FQDN, stockage info dans fichier de zone directe ; inversée: FQDN -> IP (ex: pour limit spam, check IP d'un srv smtp).
Dans cas recherche inversée, l'id de la zone a un nom qui correspond aux sous-réseaux (ex pour sous-réseau 172.16.0.0./16 l'id sera 16.172.in-addr.arpa).

Zone principale

contient les enregistyrements pour l'espace de nom qu'elle controle (elle fait autorité sur le domaine en question).

En lecture/écriture, stocke l'ensemble des modifs apportées au sein de cette zone.
Sur un srv AD DNS, la zone principale correspondant au domaine est dite intégrée à AD (mécanismes de réplication).

Zone secondaire

copie en lecture seule de la zone prinipale. Fait autorité sur le domaine aussi.

Zone de stub

contient une copie partielle d'une zone.
Ne stocke que les enregistrements de ressources nécessaires à l'identification des srv DNS faisant autorité pour la zone en question.

Enregistrements DNS

DNS résout les noms d'hotes + permet de localiser certains types de ressources. Les principales types de ressources:

A (hotes): srv, routeur...
PTR (pointeur) dans zones de recherche inverses (trouver nom avec ip grace aux PTR)
SRV (services): par ex _TCP._LDAP.eni.lan sera résolu en ad-dc01.eni.lan
MX (Mail Exchanger) : srv emails pour domaine. Ex: eni.lan sera résolu en exch-srv1.eni.lan
CNAME (Canonical Name, ou alias): ajout alias à nom d'hote existant
NS (Name Server) srv dns pour une zone.
SOA (Start of Autority): 1er enregistrement contenu dans chaque zone, permet d'identifier le srv DNS principal de cette zone.

Indicateurs racines: sur son srv DNS, pour trouver les srv racines du TLD DNS internet (pour résoudre .com, .fr, .org...). Ex: notre DNS contacte le DNS TLD ".fr" qui lui renvoie l'IP du DNS gérant eni.fr

Redirecteurs / forwarders

Pour éviter que son DNS recherche lui-meme des enregistrmnt au travers des indicateurs racine. Ainsi, toutes les requetes effectuées sur une zone (sur laquelle son DNS ne fait pas autorité) seront transférées à ces redirecteurs. Voir sch p62.
Si le FAi communique les IP de ses DNS, les déclarer comme redirecteurs (pas besoin de mettre à jour les enrgt des indicateurs racine, réduction traffic).

Gestionnaire de srv / DNS, clic droit sur son srv / Propriétés puis onglet redirecteurs, bouton Modifier. Y spécifier nom ou IP de ses redirecteurs, choix ordre (le 2nd ne sera sollicité que si le 1er be répond pas).

DNS lors de l'envoi d'un email

Un client Exchange envoie un email à l'exterieur de son entreprise. Le srv Exch extrait le domaine de du destinataire, et fait recherche DNS:
a. où est DNS qui fait autorité sur domaine dest? b. il récup enrg MX pour trouver le SMTP dest.  c. il envoie le message au SMTP dest.

On peux déclarer plusieurs MX sur un meme domaine, pour équilibrage ou redondance. Le DNS envoie alors les MX avec leur priorité - plus cette valeur est faible, plus la priorité est élevée => le client prendra la valeur la plus faible (si pas de réponse, il contactera alors au srv smtp suivant).

DNS à réception d'un email

Pour recevoir des emails de l'exterieur, déclarer 1 (ou x) MX sur ses srv DNS faisant autorité pour le domaine DNS externe.

Voir les MX d'un domaine: nslookup   y préciser:    set type=mx   puis y saisir le srv DNS (qu'il revoie liste srv smtp)  ici c'est   editions-eni.fr

 

Vers Installer AD