Bloc d'activités : Conception et modélisation de la solution

Concevoir ou modéliser une solution en termes de flux, de packages, de données, de séquence, de cas d'utilisation avec des outils professionnels

Entreprise : Office Français de la Biodiversité (OFB)

Client : ONCFS / AFB

Projet : Préfiguration fusion ONCFS-AFB

Dates/Durée : année 2019/ 10 jours

Réalisation : Modélisation d'une maquette permettant de valider les choix techniques pour la future fusion des environnements de production Active Directory

Source documentaire :

La réalisation majeure

Définition du projet ou de la réalisation

La fusion de deux établissements implique de mutualiser les moyens informatiques. Pour l'ONCFS et l'AFB une des tâches qui m'a été confié, en tant que pré-figurateur (référent), fut de traiter le chantier "annuaire d’entreprise" (Active Directory) par conséquent l’écosystème système et réseau Microsoft.

Remarque : j'ai aussi participé activement au chantier concernant la sécurité du SI.

Dans ce cadre j'ai du modéliser puis concevoir (cf.Bloc d'activités : Réalisation de maquettes ou preuves de concept) une maquette complète des 2 environnements de production afin de valider les choix techniques que nous serions amenés à faire dans le cadre de cette fusion.

Objectifs, contexte, enjeu, risques, opportunités

L’objectif de ce projet fut de permettre aux 2 établissements de pouvoir travailler ensemble au 1er janvier 2020, la préfiguration ayant débuté à la fin du premier trimestre de 2019.

Les enjeux, informatiquement parlant, identifiés furent :

  • de pouvoir continuer d'échanger par courriel sous le même nom : "ofb.gouv.fr",

  • d’assurer la continuité de services des nombreuses applications en production,

  • de partager des documents dans un espace commun et sécurisé,

  • de disposer d'un moyen d'authentification couvrant l'ensemble des personnes des deux établissements sous une seule et même interface.

Les risques étant :

  • de se retrouver avec des interruptions ou arrêts de service au moment de raccorder les réseaux à différents niveau modèle OSI,

  • d'avoir des conflits d'annuaire au moment des inter-connexions (relation d'approbation etc.) des domaines Active Directory,

  • de rencontrer des soucis d'accès aux différents systèmes de fichiers hébergés sur la flotte de 600 serveurs (Microsoft ou GNU/Linux) des 2 établissements.

Étapes

Pour réaliser la modélisation de la solution j'ai du d'abord passer par une importante phase de récolte des informations système et réseau concernant les 2 établissements à fusionner que furent l'AFB et l'ONCFS, je précise que je faisais partie de l'ONCFS à ce moment là.

Cette récolte d'information s'est déroulée, non sans mal, durant les réunions et divers échanges de courriels durant toute l'année 2019.

Enfin j'ai pu réaliser :

En parallèle de ces étapes j'ai pu modéliser l'architecture système et réseaux à l'aide du logiciel Microsoft Visio.

Ci-dessous la modélisation complète de la maquette de test (simplifiée) de l'environnement des 2 établissements :

Mes actions

J'ai réaliser la totalité des actions décrites dans les étapes.

Acteurs et interactions au sein du projet

J'ai du assister à un certains nombre de réunion de lancement, de suivi, de pilotage de ce chantier "Annuaire Active Directory".

Les principaux acteurs avec lesquels j'ai pu échanger, furent :

  • Thierry Thomas (DSI ONCFS, préfigurateur « OFB », contrib. chantier « sécurité »)

  • Marie-Odile PATIN (DSI AFB, adjointe au préfigurateur « OFB »,contrib. chantier « sécurité »),

  • Fabrice MORIZUR (Resp. pôle infra AFB, référent « Interconnexion de Réseaux», contrib. chantier « sécurité », « messagerie » et « Active directory « ),

  • Trung-hien PHAM (Resp. pôle infra ONCFS, contrib. « Interconnexion de Réseaux»),

  • Antoine DINAHET (Resp. application métier ONCFS, contrib. « chantier messagerie »),

  • Frédéric DEJ (Resp. pôle Support ONCFS, contrib. « chantier AD », « messagerie »),

  • Mourthy TETCHANA (Resp. pôle Support AFB, référent « chantier messagerie », contrib. « chantier AD », contrib. chantier « sécurité »).

Résultats (pour moi, pour l'entreprise)

Notre DSI Thierry Thomas a insisté sur le fait que la migration devrait s'effectuer sans perturbation pour l'utilisateur final et sans courir le risque de coupure de service.

L'objectif fixé fut atteint.

Lendemains du projet

Un fois cette modélisation effectuée, j'ai du m'assurer que les authentifications pour les applications stratégiques de notre futur établissement publique de la biodiversité, notamment pour la messagerie Zimbra, étaient opérationnelles.

J'ai appris courant octobre 2019 (soit 2 mois avant la fusion) que nous basculions notre messagerie Microsoft Exchange Server (ONCFS, intégré Active Directory) vers la solution Zimbra (AFB), et que cette dernière ne pouvait s'appuyer que sur un seul annuaire LDAP/AD.

J'ai donc du trouver le moyen de "concaténer " 2 annuaires en un seul en un temps record (seulement quelques jours de mise en place et de test). Pour se faire j'ai mis en œuvre un proxy LDAP en utilisant le mode "meta-annuaire" de openLDAP.

Cette solution de transition a assuré l'intérim avec un taux de disponibilité de plus de 99% pendant plus de 1 an et demi (cf. Méta annuaire proxy LDAP Annexe : Littérature fusion ONCFS - AFB vers OFB)

Mon regard critique sur le projet ou la réalisation

Au vu des délais imposés et des informations dont je pouvait disposer, j’estime avoir rempli les objectifs de cette fusion d’établissement, je m'attendais à vraiment rencontrer plus de souci d’ordre technique.

En effet la partie que je pense avoir mal estimée concerne le facteur humain, essentiellement à propos :

  • des compétences techniques des membres des équipes entrant en jeu,

  • du manque complet de coopération (orchestré ?) de certaines parties des équipes (AFB )à mon égart (ONCFS).

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

Concernant la modélisation de solution, j'ai toujours eu l’habitude de documenter les solutions techniques que je mettait en place, donc je dirai que je suis d'un bon niveau dans ce domaine. Je précise que je ne modélise pas toujours avec Visio, mais me sert de Powerpoint ou encore Libre Office Impress pour créer des schémas clairs et lisibles.

J'ai aussi eu l’habitude de travailler avec des outils de modélisation UML quand j'étais développeur J2EE (Java) au sein du ministère de la défense.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Cette compétence occupe une place importante dans mes fonctions actuelles d'architecte système et administrateur système/réseau car il me semble primordial d'expliquer et former mes collègues aux solutions système que je met en place dans notre SI.

Mon évolution

Je souhaiterai connaître d'autre outil plus complexe afin de modélisation plus finement les briques systèmes et dans une moindre mesure les éléments réseau : Ex. GNS3.

Place de la compétence dans mon projet personnel

Aucune à priori.

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Je ne connais pas les classifications, donc niveau, pour cette compétence, donc il m'est difficile de viser un "niveau".

Formation ou autoformation en cours ou à venir, sur cette compétence

Aucune de prévue actuellement.

Argumenter le choix d'une configuration ou implémentation

Entreprise : Office Français de la Biodiversité (OFB)

Client : idem

Projet : Préfiguration fusion ONCFS / AFB

Dates/Durée : Année 2019 / 7 jours

Réalisation : Architecture DNS du futur opérateur de la biodiversité (OFB)

Source documentaire :

La réalisation majeure

Définition du projet ou de la réalisation

La fusion de deux établissements implique de mutualiser les moyens informatiques. Pour l'ONCFS et AFB une des tâches qui m'a été confié fut de traiter la partie annuaire d'entreprise (Active Directory).

Dans ce cadre j'ai du argumenter concernant le choix des noms de domaine de l'annuaire Active Directory et externe de l'établissement.

Objectifs, contexte, enjeu, risques, opportunités

Le choix d'un nom de domaine, entendu par le RFC 1034, est une étape cruciale dans la mise en place d'une architecture système. Entre autre, elle impacte directement la partie annuaire d'entreprise, dans notre cas Active Directory mais aussi toute l'infrastructure système et réseau future.

Un mauvais choix peut être impactant pour toute la durée de vie de l'annuaire mais aussi pour le niveau de sécurité du SI ainsi que pour les mises en œuvre des applications métiers, des serveurs, des stations de travail ....

Étapes

Pour cette partie du projet j'ai du mettre en place des réunions avec les décideurs et les administrateurs système et réseau des 2 établissements devant être fusionnés, l'objectif étant de prendre en compte les avis de tous.

J'ai également fait appel à une connaissance du monde du logiciel libre, expert reconnu et contributeur des RFC concernant le DNS (membre de l'AFNIC) : Stéphane Bortzmeyer.

En plus de m'appuyer sur mon expérience professionnelle je me suis documenté sur les meilleurs pratiques quand au choix d'un nom de domaine interne pour un nouvel Active Directory.

Nous, DSI et DG (Direction générale), avons aussi pris en compte le fait que notre établissement public aurait probablement dans un futur proche à absorber d'autres établissements publiques : de ce fait un nom de domaine type , "nom_etablissement_actuel.fr" ("ofb.fr") n'était tout simplement pas envisageable, sous peine d'être obsolète à moyen terme (renommer un domaine AD est fortement déconseillé).

J'ai aussi du prendre en compte le fait que l'AFB était déjà en cours de migration d'annuaire, donc avec des SIDHistory (par conséquent des jetons Kerberos) déjà très volumineux et (cf. nom de domaine : "afbiodiversite.fr") ... lesquels pouvaient bloquer les connexions des utilisateurs à notre réseau.

J'ai donc fait en sorte que "ad.intra" soit choisit pour le nom de domaine de notre futur annuaire Active Directory, et que "ofb.fr" soit notre nom de domaine DNS exposé sur internet (déposé chez un opérateur de registre et gérer en externe par des prestataires français).

Ce choix a permis également d'éviter d'avoir recours à des pirouettes style "SPLIT DNS" (cf. figure ci-dessous) pour pouvoir gérer toutes les zones DNS sous le contrôle de la DSI OFB.

En terme de sécurité cela permet également de bien cloisonner les résolutions DNS locales de celles émanant d'internet. Sans compter le fait que nos serveurs DNS n'ont pas à être exposé sur internet ou dans une quelconque DMZ.

Pour plus de détail technique se reporter à Annexe : Littérature fusion ONCFS - AFB vers OFB , partie "Choix nom de domaine Active Directory OFB".

Mes actions

J'ai réaliser la totalité des actions décrites dans les étapes ci-dessus.

Acteurs et interactions au sein du projet

Les principaux acteurs avec lesquels j'ai pu échanger, furent :

  • Thierry Thomas (DSI ONCFS, préfigurateur « OFB », contrib. chantier « sécurité »)

  • Marie-Odile PATIN (DSI AFB, adjointe au préfigurateur « OFB »,contrib. chantier « sécurité »),

  • Fabrice MORIZUR (Resp. pôle infra AFB, référent « Interconnexion de Réseaux», contrib. chantier « sécurité », « messagerie » et « Active directory « ),

  • Trung-hien PHAM (Resp. pôle infra ONCFS, contrib. « Interconnexion de Réseaux»),

  • Antoine DINAHET (Resp. application métier ONCFS, contrib. « chantier messagerie »),

  • Frédéric DEJ (Tech. Info, Resp. pôle Support ONCFS, contrib. « chantier AD », « messagerie »),

  • Mourthy TETCHANA (Resp. pôle Support AFB, référent « chantier messagerie », contrib. « chantier AD », contrib. chantier « sécurité »).

Résultats (pour moi, pour l'entreprise)

Avec un recul de maintenant presque 2 ans j'ai la certitude que ce choix fût le bon, car en effet il est déjà prévu de nouvelles absorptions d'établissements ... avec des noms de domaine DNS bien différents du notre (ofb.fr)

De plus le fait d'avoir un nom de domaine non rattaché à un nom d'établissement (ad.intra) permet d'assigner de façon neutre des noms d'utilisateur, au sens Active Directory , à nos prestataires extérieurs.

Enfin la gestion de nos enregistrements DNS est plus simple et surtout mieux sécurisée.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

Cette expérience m'a permis de conforter mes acquis concernant mon argumentation dans le choix d'une solution.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

Dans mon poste actuel je suis souvent confronté à des choix pour lesquels je dois convaincre, en argumentant , mes collègues et responsables.

Je dirai donc que cette réalisation à ajoutée de l'expérience à mon parcours m'a conforté dans la démarche que j'utilise pour convaincre de choisir telle ou telle solution.

Mon évolution

Peut-être me serait-il utile de m’entraîner à être plus pédagogique, mais je suis malheureusement assez mauvais dans ce domaine.

Place de la compétence dans mon projet personnel

Aucune.

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Je ne connais pas les classifications, donc niveau, pour cette compétence, donc il m'est difficile de viser un "niveau" atteindre.

Formation ou autoformation en cours ou à venir, sur cette compétence

Je n'envisage pour l'instant aucune formation concernant l'art de l’argumentation.

Formaliser et rédiger un document de spécifications techniques comprenant l'architecture cible, les différentes briques de la solution et les interactions entre elles

Entreprise : Office Français de la Biodiversité (OFB)

Client : idem

Projet : Migration annuaire Active Directory

Dates/Durée : janvier 2020 / 10 jours

Réalisation : Rédaction de la nomenclature de l’architecture système du domaine Active Directory « AD.INTRA »

Source documentaire :

La réalisation majeure

Définition du projet ou de la réalisation

Une fois la fusion des 2 établissements ONCFS et AFB démarrée, une des tâches qui m'a été confié fût de concevoir l’architecture Active Directory et son écosystème système et réseau Microsoft.

J'ai de fortes compétences en la matière car je suis MCSE (Microsoft Certified System Engineer) et j'ai un grande expérience sur de grandes infrastructures Microsoft (EDF, SHELL, MICHELIN, MINDEF, CG78... )

A l'OFB nous commençons à être sur un environnement de taille moyenne : 3200 stations de travail et 300 serveurs Microsoft Windows sur des réseaux hétérogènes.

Ainsi j'ai eu à formaliser et rédiger un document de spécifications techniques décrivant l'architecture cible Microsoft Active Directory, les différentes briques de la solution et les interactions entre elles.

C'est ainsi que fut rédigé, par mes soins, le document de "nomenclature" du SI de l'OFB.

Objectifs, contexte, enjeu, risques, opportunités

L'objectif d'un tel document, dans le cas de l'OFB, fut de normaliser et formaliser :

  • les choix techniques,

  • les règles de nommage des ressources,

  • les choix d'architectures (AD,DFS,DNS,SMB etc.),

  • les gestes des administrateurs système et réseau.

... concernant une nouvelle infrastructure système et réseau (Réseau : mais ce n'est pas l'objet de cette partie, car raccordement d'une classe B avec une classe A sur plus de 360 sites ...)

L'enjeu fût de rendre compréhensible à des administrateurs système et réseau, de niveau hétérogène, une nouvelle infrastructure et manière de fonctionner pour l'écosystème Microsoft Active Directory.

Le principal risque a été que ce document soit :

  • mal compris ou interprété,

  • non compulser donc non suivi,

  • in finé : mal mis en œuvre,

Étapes

J'ai rédigé cette nomenclature en abordant les point suivants :

  • Utilisateurs et ordinateurs (Objets AD)

    • OU (Organizational Unit) : structuration de l'annuaire,

    • Groupes de sécurité / distribution : sécurisation des accès,

    • Utilisateurs : nommage et bons usages,

    • Ordinateurs :nommage et classement.

  • Sites et services (Objets AD)

    • Sites : définition de la réalité physique de l’établissement,

    • Sous-réseaux : définition de l'environnement réseau exploité,

    • Topology replicator (IP inter-sites) : optimisation des accès réseau,

    • Stratégies de groupes (GPO) : paramétrage des hôtes.

  • Ressources

    • Hyperviseur : description de l'existant en terme de virtualisation,

    • Serveur Microsoft : modèle de base,

    • Serveur GNU/Linux (abordé dans un autre document) : nomenclature,

    • Bases de données : TODO équipe DBA (DataBase Administrator)

  • seau : nommage divers, hôtes, bornes WI-FI, commutateurs, configurations.

  • Solution de sauvegarde : stratégie de sécurité (RSSI) et PRA

  • Solution de stockage (SAN) : TODO (existant sur baies SAN classiques, cuivre et fibre optique) équipe exploitation

Mes actions

J'ai réalisé quasi-toutes les étapes de rédaction du document.

J'ai néanmoins délégué les 3 dernières parties à des administrateurs système et réseau de mon service.

Acteurs et interactions au sein du projet

J'ai travaillé avec ma structure hiérarchique pour la partie relecture et approbation du document, à savoir :

  • Thierry Thomas (DSI OFB),

  • Fabrice MORIZUR (Chef adjoint du service infrastructure OFB),

  • Trung-hien PHAM (Chef du service infrastructure OFB).

En général j'ai carte blanche dès le départ, avec une latitude quasi complète, ce qui est très confortable pour ce genre de projet.

Résultats (pour moi, pour l'entreprise)

La plupart des objectifs ont été atteint donc c'est une bonne expérience pour moi et notre DSI.

Ce document sert toujours de référence en 2022, il a guidé et guide la plupart les migrations Windows (compte Active Directory, relations d'approbation, jonction inter-domaine, authentification, gestion des ACL , sécurisation, GPO, migration des serveurs de fichiers, serveur de déploiement, etc).

Mon regard critique sur le projet ou la réalisation

Avec le recul je m'aperçois que je n'ai pas assez communiqué, ou plutôt que j'aurais du mieux communiquer à savoir :

  • expliquer, présenter plusieurs fois ce document aux autres services de la DSI,

  • insister pour demander à mes supérieurs hiérarchique de diffuser l'information (pas que pour le pôle infrastructure),

  • être force de vente sur ce document.

La compétence : autocritique et évolution

Mon niveau de maîtrise de la compétence

Je pense avoir un niveau confirmé dans cette compétence.

Place, importance, priorité de cette compétence dans mon profil d'Expert en Ingénierie ou dans mon métier actuel

La rédaction de documents de spécifications techniques comprenant l'architecture cible, les différentes briques de la solution etc. jalonne chacun des projets auxquels je prends part ou que je conduis, c'est donc une compétence essentiel pour mon profil actuel.

Mon évolution

En arrivant en 2013 à l'ONCFS, j'ai du rédiger un tel document mais je m'aperçois avec le recul que ce dernier était peu abordable pour des techniciens.

Je pense donc avoir bien évolué durant ces 7 dernières années concernant la rédaction de DAT (Document d'Architecture Technique), lesquels sont, à mon avis, nettement plus abordables pour des personnels moins qualifiés que moi dans le domaine de l'administration système et réseau (où sur le sujet traité).

Ci-dessous exemple de document rédigé courant 2013 :

Niveau que je souhaite atteindre dans cette compétence à moyen terme

Je ne fais pas que de la documentation mais aussi beaucoup de veille technologique ou des POC, donc je souhaite m'investir modérément dans cette compétence à moyen terme. Je préfère être à jour sur les technologies orientées "cloud" hybride.

Formation ou autoformation en cours ou à venir, sur cette compétence

Aucune de prévue pour l'instant.