Mise en oeuvre d'architectures Active Directory pour Windows 2003, 2008, 2019-22

Etude de mise en oeuvre avec qualification de nouveaux matériels ;

- Rôles et réplications,
- Mise en oeuvre des stratégies de sécurité et GPO,
- Déploiements et installations à distance,
- Installation d'Active Directory et services DNS sur Machine virtuelle
- Mise en oeuvre des services d'impressions et de partages,

Processus de délégation,
Services de messagerie,

Modélisation de l'architecture,
Prévision des matériels,
Mise en oeuvre de la topologie et des réplications,
Securité des utilisateurs et applications avec OU et GPO
Sécurisation du réseau et des protocoles (DNS, RADIUS, etc.)
Etude pour migration des serveurs,
Infrasctructure de messagerie,

Description des outils de fédération des identités :

La localisation des problèmes Active Directory n’est pas toujours simple, mais cette action permet d'éviter des catastrophes. Les sinistres AD peuvent servir d’exemple ou d’avertissement pour les administrateur ou les responsables sécurité.

Depuis l’introduction d’Active Directory dans Windows 2000, la reprise après sinistre a longtemps été associé à un sujet délicat. Une réplication ne suffisait pas toujours car cela dépendait surtout de la conception de votre architecture. Depuis, des outils et méthodes expliquent comment prévenir le crash d'un domaine ou d'une forêt de domaine. En effet, la reprise après sinistre a évolué au fil des années. Depuis l'implémentation de l'annuaire sur WS2K, de nombreuses améliorations ont été apportés à AD DS, les approbations, les réplications, la gestion des comptes ainsi que la relation avec Exchange serveur.

- Outils de migrations de comptes utilisateurs,
- Upgrade vers des versions toujours plus récentes,
- Architectures mieux équilibrées avec approbations multiples et réplications,
- Migration et refonte de domaines en forêts
- Utilisation de tunnel sécurisé pour relier les forêts entre elles via VPN. (MPLS)
- Intégration d'Exchange simplifiée ainsi que de nombreuses autres applications.
Ex; Groupware MOSS.

Lire le Glossaire sorti lors de l'intégration de l'annuaire sur WS2K...

UNE CONCEPTION MAL CONCUE PEUT ETRE AMELIOREE ET CORRIGEE

Prenons l'exemple d'une architecture AD avec topologie multi-niveaux. Cette topologie dispose de 2 sites centraux dans deux grandes villes, interconnectés par une liaison haut débit. Le niveau suivant comporte quatre sites régionaux. Chacune des régions est connectée à 2 sites sous-régionaux. Le but étant de créer trois niveaux. Central, régional et sous-régional. Cela afin de permettre la réplication des sous-régions vers les sites régionaux, lesquels doivent répliquer au niveau central. Les 2 sites centraux se répliquant évidement l'un vers l'autre sur une liaison dédiée.

Une des règles de la conception de réplication stipule que les liaisons doivent avoir des sites communs à répliquer... Cette conception peut fonctionner jusqu’à ce qu’un des DC d'un des sites centraux connaisse une défaillance. S'il s’agit d'un des sites central qui rattache les autres sites aux sites régionaux avec passerelle de liaison de sites, l’outil KCC (Knowledge Consistency Checker) peut être en mesure de rétablir les choses. Cependant, une fois le DC localisé, puis restauré, KCC peut ne pas sélectionner le bon DC (celui d'un site sous régional comme cible de la réplication) au lieu d'un site régionnal pour le second niveau. Cela entraine les DC d'un des 2 sites centraux à répliquer vers l'un des DC de sous régions au lieu de le faire au niveau régional puis sous régional, désorganisant la conception de réplication, basée sur la vitesse du réseau. La réplication de sites ne fonctionne donc plus à partir des sous régions vers les sites régionaux...

Exemple de topologie non fiable

Le seul moyen de rétablir les flux de réplication est de réinstaller le DC d'un des sites régional avec réplication vers un des DC de sous région. Si par malheur le DC d'un site de sous région tombe en panne le KCC pourra sélectionner le DC d'un autre site de sous région comme cible de réplication au lieu de le faire avec un des site régional. Encore une fois, le seul moyen de rétablir la réplication consiste à réinstaller le DC incriminé et de reconfigurer la réplication. Bien évidemment, il peut apparaître inquiétant de réinstaller un DC placé hors ligne pendant plusieurs heures voir plus. Mais certains DC d’autres régions ont commencé à répliquer vers tous les DC de la forêt entraînant des erreurs de réplication et créant des pics de trafic incontrôlables...

L'explication à ce comportement vient certainement du fait que le KCC (Vérificateur de cohérence des connaissances) sélectionne le GUID (identificateur global unique ou en anglais Globally Unique IDentifier) le plus petit (un peu comme les VLAN et l'ID de l'adresse mac). Laisser trop de choix au KCC en plaçant plus de deux sites sur une liaison de site peut compliquer le problème. La solution consiste à supprimer toutes les liaisons de sites et à les récréer avec pas plus de deux sites par liaison. La liaison d'un des site central a été remplacée par la liaison d'un DC de région puis in autre DC de région s'est vu attribué la réplication vers tous les DC de sous région, un peu comme si au 2ème niveau avait été crée un soleil représenté en son centre par le DC de région et rayonnant vers tous les DC de sous région. En résumé la liaison a laissé la place à une liaison du site central vers le DC régional permettant de répliquer vers tous les sites de sous région, sans discrimination géographique. .

En cas de défaillance du DC Regional2 il est facile de rétablir les réplications vers tous les sites de sous région à partir du DC régional1.

Le plus simple est de reconfigurer qu’une seule région et un seul DC à la fois. Le reste de la forêt est reconfigurée afin que les problèmes de réplication disparaissent.

Exemple d'architecture Multi-niveaux

Soyez attentif à la conception de votre topologie et respectez les règles.

UTILISATION DE MACHINES VIRTUELLES

Dans une autre simulation, un plan de reprise après sinistre concerne 2 DC virtuels sur 4 implémentés et provoquant un sinistre. Dans ce cas, 2 serveurs physiques sont configurés avec chacun un DC virtuel (cf. figure 3). Par conséquent, le DC est en fait un disque dur virtuel (VHD), ou autrement dit, un fichier sur le disque physique.

Une configuration avec serveurs physiques, exécutant 4 DC virtuel.

Chaque nuit une sauvegarde est réalisée sur l’hôte physique. Comme les fichiers VHD peuvent être copiés et déplacés vers d’autres emplacements, il paraît légitime de penser qu’on puisse copier le fichier VHD d'un centre de données DC1 vers DC2 et le fichier VHD de DC2 vers DC1 et répéter cette stratégie pour le DC3 et le DC4. Ainsi, au final, en cas de défaillance de DC1, il paraît possible de restaurer ce dernier en copiant son fichier VHD à partir de DC2 (ou DC3 ou DC4) vers DC1 ou un nouveau serveur et restaurer l’activité de l’entreprise. Cependant une sauvegarde des DC au sein de leur propre OS, ainsi que de l’hôte physique est indispensable. Notez que la restauration du disque dur virtuel (VHD) varie en fonction de votre logiciel de virtualisation. Pour validiter la plan de reprise, il faut tester la reprise en reproduisant le scénario en laboratoire. En supprimant les VM/VHD existants de DC1 et en recréant de nouveaux au moyen de l’ensemble VM/VHD de DC1 stocké sur DC2 abouti à l'échec de l’opération, sans que cela puisse être visible d’emblée. La réplication semblait fonctionner, mais les mises à jour étaient absentes. Il fallait identifier d’autres anomalies et découvrir les effets d’un rollback d’USN, en restaurant Active Directory sur le DC1 au jour précédent. Cette approche n’est en rien erronée à condition de procéder correctement. Toutefois, dans cet exemple quelques règles importantes ne sont pas appliquées :

•Ne restaurez pas un DC à partir d’une image instantanée (snapshot). Le .VHD est une image instantanée, il existe d’autres approches possibles.

• Ne sauvegardez jamais un DC en image disque VHD sur l’ordinateur hôte. Sa restauration est impossible.

• Sauvegardez plutôt l’état système d’un DC virtuel (dans la VM proprement dite) au moyen d’un utilitaire de sauvegarde et de restauration "compatible avec Active Directory". Cela réinitialise l’ID de la base de données AD et conserve toutes les versions des bases synchronisées sur l’ensemble des DC.

Le rollback d’USN accidentel est difficile à détecter et il n’existe qu’un remède à cette situation : recréer le DC. Cette approche crée un vide dans les transactions de base de données sur le DC restauré. Par conséquent, d’autres DC pensent que les transactions (ajout, modification et suppression d'objets) ont été répliquées vers le DC problématique mais il ne les réplique plus. Le DC interrompu ne possède pas les objets et ne recevra aucune notification pour les obtenir, ce qui aboutit à une impasse.

Pour prévenir ce sinistre, lire l’article de la Bases de connaissances Microsoft KB 875495. D'une part, vérifiez que vous comprenez bien les causes et effets d’un rollback d’USN accidentel et comment identifier la situation. D’autre part, suivez les règles exposées dans la Base de connaissances pour éviter la survenue d'une telle situation. Elle n'est pas des plus communes, mais peut se produire engendrant une situation désastreuse. Cela entraîne la perte de toutes les stratégies de groupe sur tous les DC. Autrement dit, une situation désastreuse...

Dans une grande majorité convaincus de la futilité de parvenir à un fonctionnement fiable du service FRS (File Replication Service) si vous êtes passés à 2008 évitez de migrer vers DFSR (Distributed File System Replication). Pour les malchanceux qui utilisent encore FRS, voici la méthode pour réparer les dégâts.

Comme FRS s’appuie sur la réplication multimaîtres (il repose en fait sur la réplication AD), il est très facile de répliquer rapidement une erreur. Il n'est pas rare le nombre de cas où FRS a été mis à mal. Dans certain cas, l’administrateur ayant peur de perdre ses stratégies de groupe suite à la disparition de dossiers FRS, recopie l’arborescence SYSVOL vers le bureau de son DC. Cela a pour effet de créer un nouveau point de jonction. Cependant cela réplique les deux arborescences SYSVOL sur cette machine, comme s’il y avait deux DC en un seul. Pour résoudre ce cas, il faut supprimer précautionneusement ce point de jonction (pas le dossier). La suppression des dossiers SYSVOL répliquera et supprimera ceux-ci sur tous les DC !

Il est probable de voir des cas où « la structure SYSVOL a été d’une manière ou d’une autre supprimée (Une erreur humaine est à l’origine de ce type de situation, peut être en essayant de mettre un peu d’ordre). Outre le risque de perdre toutes les stratégies de groupe vous avez certainement eu la bonne idée de sauvegarder vos GPO. N’oubliez pas de le faire au moyen de la console GPMC (Group Policy Management Console) ou de tout autre outil tierce partie, ou encore simplement en les copiant de l’arborescence SYSVOL vers un autre emplacement extérieur à celle-ci.

Si un dossier SYSVOL est corrompu ou si, pour une raison ou une autre, un seul DC ne peut pas se synchroniser, il est possible d’effectuer la restauration non-authoritative ou authoritative, ou de vous synchroniser la machine incriminée avec un DC sain. L’article de Base de connaissances Microsoft KB 315457 y fait une référence.

Toutefois, la restauration de la structure de fichiers complète est un tout autre problème. L’article de Base de connaissances KB 315457 est en grande partie approprié pour ce scénario, mais il existe quelques pièges liés à la commande linkd. Bien évidemment, une rétrogradation (demoting) manuelle si nécessaire, suivie d’une nouvelle promotion constitue la réponse la plus courte, mais si ce n’est pas envisageable, voici une procédure qui permettra de restaurer correctement les points de jonction.

Procédure permettant de restaurer les points de jonction de SYSVOL.

Structure SYSVOL, à titre d'exemple:

SYSVOL/Domain/Staging Areas/mydomain.com
et SYSVOL/SYSVOL/mydomain.com

sont les points de jonction pointant respectivement vers les répertoires réels de SYSVOL/Domain/Staging/Domain
et
SYSVOL/Domain

SOLUTIONS :

1. Comment recréer SYSVOL et les points de jonction lorsque SYSVOL a été supprimé sur tous les DC :

a. Arrêtez le service FRS sur tous les DC.
b. Créez manuellement l’arborescence de dossiers SYSVOL (il s’agit du FQDN de votre domaine) :

SYSVOL
     Domain
          DO_NOT_REMOVE_NtFrs_PreInstall_Directory
                Policies
                Staging Areas
                Staging\Domain
SYSVOL
     Mydomain.com

c. Paramétrez les ACL sur « DO_NOT_REMOVE_NtFrs_PreInstall_Directory » :
    1. Administrators (admins du domaine) et System configurés comme les SEULS à avoir des « permissions spéciales ».
    2. Paramétrez le répertoire « DO_NOT_REMOVE... » comme Hidden (masqué) et Read only (en lecture seule).

d. Créez les points de jonction. Assurez-vous que le service FRS est arrêté sur le DC cible de l’exécution :

linkd "%systemroot%\SYSVOL\SYSVOL\mydomain.com"
%SYSTEMROOT\SYSVOL\DOMAIN
linkd "%systemroot%\Sysvol\staging areas\mydomain.com"
%systemroot\sysvol\Staging\Domain

REMARQUE : Si SYSVOL n’est pas stocké sur le disque système Windows, remplacez C:\Windows dans la commande linkd afin de refléter le chemin vers SYSVOL.

Créer un domaine Active Directory sous WS2K19 avec Hyper-V

Installer un Windows serveur 2019 avec Active directory sous VMWare

Installer et configurer le cluster de basculement dans Windows Server 2022

Comment créer la stratégie de domaine et la stratégie de contrôleur de domaine par défaut :

Si vous n’avez pas de sauvegardes de la stratégie de contrôleur de domaine par défaut ou de la stratégie de domaine par défaut, à partir de la ligne de commande du contrôleur principal de domaine, exécutez l’outil DCGPOFIX de Microsoft.
Voir l’article de la Base de connaissances KB 833783.

AVERTISSEMENT : Cet outil crée une stratégie de domaine par défaut et une stratégie de contrôleur de domaine par défaut vierge. Ne l’utilisez pas si vous avez une copie de ces stratégies et disposez de sauvegardes. Il suffit de les restaurer à l’endroit approprié au niveau de SYSVOL.

Il vous invitera à restaurer la stratégie de domaine par défaut et vous demandera si vous souhaitez restaurer la stratégie de contrôleur de domaine par défaut. Répondez « oui » aux deux questions.

Répliquez SYSVOL pour ce DC en démarrant FRS :

C:>net Start “File Replication Service”

REMARQUE : N’UTILISEZ PAS la procédure Burflags. Elle peut provoquer la disparition du répertoire SYSVOL

1-Vérifiez que le service FRS fonctionne.

ASTUCE : Créez un fichier texte tel que DC1.txt (sur DC1) dans le répertoire SYSVOL\SYSVOL (afin de le localiser facilement). Lancez la réplication. Ce fichier doit aboutir à cet emplacement sur tous les DC. Si un DC ne possède pas ce fichier, il ne peut pas répliquer FRS correctement. Ayez à l’esprit que cela pourrait être aussi dû au défaut de réplication d’AD.

2-Comment recréer les points de jonction si l’arborescence SYSVOL existe, mais pas les points de jonction
Arrêtez FRS :C:>Net Stop "File Replication Service"

Créez les points de jonction. Assurez-vous que FRS est arrêté sur le DC :
linkd"%systemroot%\SYSVOL\SYSVOL\mydomain.com" %SYSTEMROOT\SYSVOL\DOMAIN linkd "%systemroot%\Sysvol\staging areas\mydomain.com" %systemroot \sysvol\Staging\Domain

REMARQUE : Si SYSVOL n’est pas stocké sur le disque système Windows, remplacez C:\Windows dans la commande linkd afin de refléter le chemin vers SYSVOL.

Aucune discussion sur les reprises après sinistre d’AD ne serait complète sans une section sur les objets persistants ou LO (Lingering Objects). Ces objets sont plus une conséquence d’un sinistre, mais peuvent aussi donner du fil à retordre. Un certain nombre d’environnements dans lesquels il existe ou il a existé des objets persistants ne sont jamais nettoyé. C’est probablement dû au fait que Active Directory continue de fonctionner, hormis quelques anomalies telles que la présence d’objets dans un domaine, alors qu’ils sont absents d’un autre. Il est difficile de les néttoyer et cela s’applique à de multiples forêts de domaines. Les objets persistants résultent d’un DC qui est devenu inaccessible à d’autres DC plus longtemps que la durée de vie des objets fantômes (TSL) avant d’être replacé en ligne. Les valeurs par défaut de TSL varient en fonction de la version de Windows que vous employez et elles sont personnalisables. Si le DC est placé en ligne après la purge des objets supprimés par le système de récupération de mémoire (GC), après l’expiration du TSL, il peut répliquer ces objets sur des DC sains et les réactiver. En général, cela pose problème sur les GC lorsque des objets en lecture seule sont répliqués.

Les événements 1864, 2042 et 1988 dans le journal d’événements Directory Services constituent de bons indicateurs en matière d’objets persistants. Vous pouvez voir des messages dans les journaux d’événements et la sortie :

Repadmin/showrepl

Lors de tentatives de réplications des objets persistants, cela peut provoquer un arrêt de la réplication entre deux DC. Si la très importante de clé de Registre "StrictReplicationConsistency" a la valeur (1), ce qui signifie un comportement Strict et si un partenaire de réplication souhaite modifier un objet qui n’existe pas sur le DC, toute réplication sera interrompue.

Un message très utile à cet effet s’affichera lors de l’exécution de la commande Repadmin/Showrepl, du journal d’événements DirSvcs, de Repadmin/Replsum et d’autres rapports et journaux : The Active Directory cannot replicate with this server because the time since the last replication with this server has exceeded the tombstone lifetime.

Il existe d’autres messages particulièrement évidents. Cela permet d’isoler la machine problématique et vous n’avez pas besoin de faire le ménage sur tous les DC. Dans de nombreux environnements, cette clé de Registre est définie sur "loose" (0). Autrement dit, tous les DC vont répliquer les objets persistants et ce n’est pas souhaitable. Si vous avez un environnement qui a démarré avec Windows 2000 et si vous avez effectué une mise à niveau (à la différence d’une installation toute neuve de la forêt complète) vers Windows 2003, 2008, etc., ce paramètre est probablement défini sur « loose », puisque c’était la valeur par défaut à Windows 2000. La clé est située à l’emplacement suivant :

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters   ValueName = Strict Replication Consistency

Grâce aux efforts de Microsoft, les objets persistants sont passés d’un cauchemar dans Windows 2000 à une situation relativement facile à éliminer dans 2003 et 2008 ainsi que sur les versions suivantes.

L’outil clé est Repadmin et le commutateur RemoveLingeringObjects.
Vous ne trouvez pas cette option dans l’aide en ligne de Repadmin ?
Essayez "Repadmin /ExpertHelp"

Si vous avez des serveurs dans votre environnement et s’ils contiennent des objets persistants, la solution consiste à les remplacer par et non à les mettre à niveau vers des DC Windows 2008 ou 2012 (en supposant que Windows 2016-19 ne soit pas disponible).

Pour Windows 2003 et les versions suivantes, la réponse rapide est la suivante :

1.   Paramétrez tous les DC sur
StrictReplicationConsistency = 1

Dans le cas contraire, la réplication des objets persistants continuera. Utilisez la commande Repadmin pour effectuer rapidement ce paramétrage sur tous les DC (ajoutez tous les DC dans DC_LIST ; consultez l’aide en ligne pour des détails sur Repadmin) :
repadmin /regkey DC_LIST +strict

2. Utilisez la commande Repadmin/removeLingeringObject :
Repadmin /removelingeringobjects <Dest_DC_LIST> <Source DC GUID> <NC> [/ADVISORY_MODE]

a. Dest_DC_List – liste des DC à utilises

b.   Source DC GUID – le GUID DSA d’un DC fiable (de préférence le PDC)

c.   NC - contexte de nommage du domaine sur lequel les objets persistants existent

d.   /ADVISORY_MODE – détermine ce qu’il se passe lorsque vous exécutez réellement la commande.

Voici un exemple de commande :

C:\>Repadmin /removeLingeringObjects wtec-dc1 f5cc63b8-cdc1-4d43-8709-22b0e07b48d1 dc=wtec,dc=adapps,dc=hp,dc=com

Cela doit être effectué sur tous les DC de la forêt et il est assez facile d’écrire un script à cet effet.

Récupération d’une forêt lorsque le domaine racine est supprimé sans sauvegarde.

Le domaine racine a un seul DC. Lorsque l’unique DC du domaine racine tombe en panne et que le personnel informatique de l’entreprise n’a pu le récupérer le sinsitre est annoncé. Avec des disques en RAID 5, il existe une tolérance aux pannes mais, si 2 disques de la baie tombent en panne et que la sauvegarde n'est plus fiable la situation est carrément désastreuse !

Le domaine enfant détient tous les comptes utilisateur et il n’y a pas eu de pannes pour les utilisateurs. Il est normal de penser à des objets persistants, mais comme il n’y a pas d’autres DC, il ne peut pas y avoir d’objets persistants sur le domaine. En revanche, il peut y avoir des GC sur le domaine enfant.

SOLUTION :

1.   Définissez la durée de vie d’objets fantômes (TSL) sur 365 jours afin de ne pas courir le risque d’ajouter des objets persistants. Pour ce faire, utilisez l’outil ADSIEdit et modifiez l’attribut TSL à l’emplacement suivant:
cn=DirectoryService,cn=WindowsNT,cn=Services,cn=Configuration, dc=mydomain,dc=com

2. Restaurez la sauvegarde sur le DC du domaine racine.

3. Paramétrez l’heure système sur le DC du domaine de forêt à la date/heure actuelle.

4. Définissez la valeur 1 pour StrictReplicationConsistency sur tous les DC.

5. « Rétrogradez » (demote) le GC sur le domaine enfant vers un DC.

6. Effectuez un contrôle d’état :
    a. Journaux d’événements.
    b. Validez la confiance.
    c. Connectez-vous à partir d’une machine du domaine racine au moyen d’un compte du domaine enfant et vise versa.
    d.   Ajoutez des utilisateurs et sites tests sur chaque domaine et vérifiez s’ils sont répliqués vers tous les DC.

7. « Rétrogradez » (demote) le GC sur le domaine enfant vers un DC.

8. Laissez la réplication se dérouler et mettre à jour le DC racine.

9. Effectuez la promotion d’au moins un DC en GC.

10. Vérifiez la présence d’erreurs au niveau des journaux d’événements.

11. Créez un deuxième DC pour le domaine racine.

12. Définissez la valeur 180 jours pour le TSL (minimum).

13. Sauvegardez tous les DC.

En utilisant les sauvegardes courantes des DC de domaine enfant et l’ancienne sauvegarde du DC de domaine racine, il est possible de reproduire l’environnement. Ensuite, il convient d'exécuter la procédure décrite ci-dessus. Le contrôle d’état a remonté quelques erreurs DNS (non liées à cette procédure), qu'il faut corriger ainsi que d’autres problèmes dans l’environnement de production.

Il est assez facile de provoquer des sinistres AD, mais il n’est pas toujours aisé de les résoudre. Tout administrateur AD doit voir venir les signes avant-coureurs par un suivi des journaux et rapports.

Pour plus d’informations sur la sauvegarde et la récupération d’un contrôleur de domaine, voir le Guide pas à pas de sauvegarde et de récupération des services de domaine Active Directory:
http://go.microsoft.com/fwlink/?LinkId=93077

Lire: 5 raisons de migrer vers 2016 serveur

Guide ADMT: Migration-restructuration d'un domaine et comptes Active Directory

Liste des commandes utiles de 2008 serveur

Voir: les ports utiles TCP et UDP pour clients et serveurs Windows

Lire: dépannage des ports alloués aux services sur serveurs Windows

Lire: Ports utilisés dans Configuration Manager

Port(s) client(s) Port serveur et services

1024-65535/TCP vers port 135 /TCP [- Mappeur de point de terminaison RPC -]
1024-65535/TCP vers ports 1024 - 65535 /TCP [- RPC pour LSA, SAM, NetLogon (*) - ]
1024-65535/TCP/UDP vers port 389 /TCP/UDP [- LDAP -]
1024-65535/TCP vers port 636 /TCP [ - LDAP SSL- ]
1024-65535/TCP vers port 3268 /TCP [ - LDAP GC - ]
1024-65535/TCP vers port 3269 /TCP [ - LDAP GC SSL - ]
53,1024-65535/TCP/UDP vers port 53 /TCP/UDP [ - DNS - ]
1024-65535/TCP/UDP vers port 88 /TCP/UDP [ - Kerberos - ]
1024-65535/TCP vers port 445 /TCP [ - SMB - ]
1024-65535/TCP vers ports 1024-65535 /TCP [ - FRS RPC (*) - ]

Synchronisation entre Azure AD et AD DS Windows 2019

Migrer un serveur Windows Active directory 2008 R2 vers un serveur 2022

MASTERISATION SERVEURS

Déploiement classique

Installer Windows server 2022 avec SysPrep et Powershell

Créer des packages applicatifs portables avec VMware Thin App

Migrer un serveur AD 2003 vers 2008

Masterisation d'un serveur 2019

Serveur WDS

Déploiement de systèmes d'exploitation avec WDS

BMC Remedy -introduction au déploiement d'applications

Création d'une ISO d'installation de Windows 10 personnalisée.

Installer et configuration d'une autorité de certification sur Windows 2019

Desktop central création d'images systèmes et déploiement

Active Directory Migration Tool (ADMT)

Déploiement d'applications via GPO

Migrer AD DS de WS2K12 ver 2K19

Installation d’un DC Windows 2022

Avant de promouvoir un nouveau contrôleur de domaine, il faut généralement mettre à jour le schéma Active Directory.

Depuis 2012 et la fin de « dcpromo.exe », l'assistant de configuration des services Active Directory effectue la mise à jour automatiquement lors de la promotion.

La cmdlet suivante permet de connaître la version du schéma :

Get-ADObject (Get-ADRootDSE).schemaNamingContext -Property objectVersion

Vous pouvez retrouver toutes les mises à jour de l'AD depuis le support d'installation de Windows Server 2022 dans le dossier support\adpprep.

Windows Server 2019 est la première version sur laquelle il n'existe pas de nouveau niveau fonctionnel lié à la version de l'OS. Windows 2022 est la première version sur laquelle il n'y a pas de mise à jour de schéma.

Le niveau fonctionnel maximum avec Windows 2022 reste Windows 2016.

En ce qui concerne l'installation, la procédure reste identique. Nous installons un nouveau serveur avec Windows Server 2022. Au niveau de l'interface réseau, nous configurons ensuite une IP fixe et nous utilisons des DCs existants en tant que DNS.

Nous renommons le serveur et l'intégrons en tant que membre du domaine existant.

Depuis une session avec des droits d'administrateur sur le domaine, nous procédons à l'installation du rôle AD DS depuis le gestionnaire de serveur :

Il est possible d'utiliser la commande PowerShell :

Install-windowsfeature -name AD-Domain-Services –IncludeManagementTools

Au niveau de l'assistant de configuration des services Active Directory, pas de nouveauté non plus.  

La commande PowerShell suivante permet l'ajout d'un contrôleur de domaine dans le domaine existant. Les variables sont à personnaliser en fonction de votre environnement.

Import-Module ADDSDeployment
Install-ADDSDomainController `
-NoGlobalCatalog:$false `
-CreateDnsDelegation:$false `
-CriticalReplicationOnly:$false `
-DatabasePath "C:\Windows\NTDS" `
-DomainName "htrab.lan" `
-InstallDns:$true `
-LogPath "C:\Windows\NTDS" `
-NoRebootOnCompletion:$false `
-SiteName "Site1" `
-SysvolPath "C:\Windows\SYSVOL" `
-Force:$true

Network Access Protection de Microsoft permet de répondre aux besoins de sécurisation des postes de travail sur un réseau privé d'entreprise. NAP permet de s'assurer de la sécurité ou de la "santé des postes" sous XP et Vista en appliquant des politiques de sécurité auxquelles ces postes doivent répondre via l'agent System Health (SHA). Il devient possible de sécuriser les flux d'informations en isolant les postes n'appartenant pas à l'entreprise et en définissant des droits d'accès de manière centralisée. Les ordinateurs qui se connectent doivent subir une mise en conformité, validée par NAP pour l'accès au réseau et à ses ressources. A défaut de validation immédiate, l'accès à un segment du réseau restreint est possible avant d'effectuer la mise en conformité du poste (mises à jour avec WSUS, vérification de la sécurité des postes, téléchargement des certificats nécessaires aux connexions sécurisées, etc).

La gestion des Identités

La plupart des applications informatiques nécessitent une gestion des utilisateurs à des fins d’allocation des ressources de sécurité et de droits d’accès, ainsi que de personnalisation des services en fonction du profil et du rôle de l'utilisateur dans l'Entreprise. Il en va ainsi pour gérer les utilisateurs d’un réseau local avec les allocations d'espace disque, les comptes applicatifs, mais aussi les clients d’un site de commerce électronique, d'un portail collaboratif, d'un progiciel de gestion intégrés (PGI), de gestion de la relation client (CRM), ou aux applications décisionnelles, etc. La multitude des applications, des référentiels utilisateurs et des outils d’administration associés nuit souvent à la sécurité d'un système d’information ainsi qu'à l’efficacité des opérations d’administration. En effet, le retour d’expérience de ces dernières années a mis en évidence de nouveaux enjeux, qui sont devenus majeurs pour l’entreprise :

La sécurité dont les menaces ont été favorisées par la prolifération des services en ligne et les réseaux de télécommunications mondiaux.

L’efficacité des opérations dont la complexité augmente considérablement avec le nombre d’utilisateurs et de services. Des gains de performances sont liés à un meilleur usage de l’information.

L’accessibilité à l’information, gage d’adoption de la multitude de services offerts par l’entreprise et ceci de façon ciblée par rapport aux attentes de chacun.

Pour tous ces aspects, il est apparu durant ces dernières années des technologies, des standards et des outils qui apportent des solutions à l’ensemble des ces questions.

Qu’est ce que la gestion des identités

Lorsqu’on parle de «gestion des identités», on entend, celle des utilisateurs d’un système d’information. Ces applications sont diverses et concernent aussi bien l’individu en tant qu’employé d’une entreprise, que client d’une autre. Un même individu pourra avoir plusieurs identités en fonction du rôle qu’il joue. Cependant la synchronisation des mots de passe pour l'accès aux différents services fournis pose toujours des problèmes.

Le référentiel des identités

Tout d’abord, il est nécessaire de constituer un référentiel qui va contenir l’ensemble des informations partagées entre différentes applications. Ces informations vont être associées à un individu et vont contenir un ou plusieurs identifiants qui serviront d’index pour y accéder. La constitution de ce référentiel nécessite généralement un annuaire, basé sur la technologie LDAP. Le référentiel des identités est généralement accompagné d’outils, comme les méta-annuaires, permettant de synchroniser l’ensemble des informations concernant les utilisateurs entre l’annuaire central (ou le référentiel) et celles qui se trouvent éparpillées dans le système d’information de l’entreprise. Ces outils permettent, soit de synchroniser les données avec un référentiel centralisé (par exemple, Microsoft IIS, Novell Identity Manager, etc.), soit de rediriger en temps réel les requêtes vers la bonne source de données, constituant ainsi une sorte de référentiel virtuel (par exemple, Maxware Virtual Directory, Radiant Logic Virtual Directory Server, etc.).On parle alors d’annuaire ou de méta-annuaire « virtuel ».

La gestion du contenu du référentiel des identités

Ce référentiel doit être accompagné d’outils qui vont permettre aux utilisateurs de consulter eux-mêmes les données qui les concernent et de les mettre à jour si nécessaire, en respectant les processus organisationnel de l’entreprise. Ces outils offrent des interfaces de saisie et de consultation des données de l’annuaire, à l’aide de formulaires qu’il est possible de créer et de modifier via des fichiers de paramétrage, voire d’une interface d’administration de l’outil.

Les outils savent généralement prendre en compte les règles de confidentialité de l’annuaire afin de protéger les données personnelles des utilisateurs lors de la consultation et de la saisie. Ils offrent, pour cela, des mécanismes de workflow permettant d’associer chaque étape d’un processus à un ensemble d’acteurs. Par exemple, la mise à jour du mot de passe peut se faire par l’utilisateur lui-même, mais celle du nom de son responsable hiérarchique ou de sa fonction doit être validée par une personne faisant partie des Ressources Humaines ou Informatiques. Avec ces outils Il y a la base de données qui constituera le moteur d’annuaire LDAP, mais aussi les outils d’administration et de gestion, de synchronisation et de développement d’applications s’appuyant sur l’annuaire.

Lire sur RDR-IT: DNS et configuration d’un redirecteur pour plusieurs sites

WDS Installation et configuration

Utilisation de Powershell pour vérifier la réplication de DC sous 2012

Le Script qui utilise la commande Get-ADReplicationPartnerMetadata est disponible à partir de Windows 2012. Le script ne fonctionne pas sur DC Windows 2008R2.

La commande retourne entre autre tourne les valeurs " lastreplicationsuccess" indiquant la date de la dernière réussite et « lastreplicationresult » indiquant le résultat de la dernière tentative.

function replresult
{
param ( [string]$Serv, [string]$partner, [string]$result,
[string]$lastsuccess )
$ReplResult =New-Object PSObject
$ReplResult | Add-Member -Name Serveur
-MemberType NoteProperty -Value "$serv"
$ReplResult | Add-Member -Name Partenaire 
-MemberType NoteProperty -Value "$partner"
$ReplResult | Add-Member -Name resultat 
-MemberType NoteProperty -Value "$result"
$ReplResult | Add-Member -Name DernierOK 
-MemberType NoteProperty -Value "$lastsuccess"

return $ReplResult
}
$MaListe=@()
$dcs= Get-addomaincontroller -filter *
foreach ($dc in $dcs)
{
$b=Get-ADReplicationPartnerMetadata -target $dc.name
foreach ($a in $b)
{
IF ($($a.lastreplicationresult) -ne "0")
{
write-host "Replication HS"
$MaListe+=repli-result -serv $a.server -partner $a.partner
-result "ERREUR" -lastsuccess $($a.lastreplicationsuccess)
}

Installation d'un DC sous Windows 2012