Discussion :

[AGui_]

Bonjour,

Je travaille dans un bureau d'étude technique, nous sommes actuellement une petite dizaine, et on prévoit de continuer à grandir progressivement dans les années qui arrivent. J'ai hérité de la gestion du parc informatique car je suis le plus "geek" de la bande, j'ai des bonnes bases de programmation mais je n'ai aucune formation en administration réseau. Notre architecture réseau actuelle a été mise en place il y a plusieurs années par une personne qui a depuis quitté l'entreprise et nos besoins ont évolué depuis. Nous réfléchissions à faire évoluer cette architecture et j'aimerai avoir quelques conseils.

Voici notre architecture actuelle :

• Un routeur :
  
  • Nous avons deux connexions internet (Fibre + Adsl), il permet de faire la bascule de l'un vers l'autre en cas de perte de la fibre
  • Il gère le VPN
• Un serveur qui tourne sous Debian, avec plusieurs conteneur LXC qui gèrent différents service :
  
  • Controller de domaine Active Directory Samba4 + LDAP/DNS/DHCP
  • Un pare-feu
  • Un service de backup des postes de travail des membres de l'équipe
• Les ordinateurs de chaque membre de l'équipe
• Un ordinateur avec une application métier pour lequel nous avons une licence unique. Les membres de l'équipe peuvent se connecter en RDP sur ce poste avec leur compte Active Directory et utiliser l'application.
• Une imprimante partagée
• Des téléphones IP

Cette architecture a été mise en place il y a plusieurs années, à une époque où on avait des besoins différents :

• Le serveur avait un conteneur pour héberger une application web pour des clients (d'où la redondance de connexion internet). Nous n'offrons plus ce type de service, le conteneur est actuellement désactivé.
• Les postes de travail des membres de l'équipe étaient des postes fixes connectés en permanence en LAN, et un disque réseau commun était monté à la connexion. On est maintenant tous passés sur des portables, qui sont souvent utilisés en télétravail, et nous n'utilisons plus le disque réseau, tout passe par Dropbox.
• De la même manière, le backup ne sert plus à rien : nous mettons tout sur Dropbox.
• Je suppose qu'initialement, l'ancien responsable ne donnait que des droits limités aux différents utilisateurs. Actuellement, chaque utilisateur est administrateur sur sa machine. On sensibilise à la sécurité informatique quand un nouveau arrive, une suite de sécurité est activée sur chaque machine, mais on est plutôt dans la confiance.

Jusqu'à présent cette architecture fonctionne, mais elle est compliquée et nous avons un nouveau besoin :

• Nous grandissons et nous avons besoin d'un second poste avec l'application métier. Pour pouvoir l'installer sur 2 postes, il faut passer en architecture client + serveur :
  
  • Nous devons installer une application serveur qui contient une base de données, qui doit être accessible en permanence. Cette application serveur n'existe qu'en version Windows, donc impossible de l'installer sur Debian. Une machine assez puissante avec un SSD est recommandée.
  • Malheureusement, le logiciel métier n'a pas de licences "dynamiques" qui permettrait à chacun d'installer un client sur sa propre machine. Il faut donc deux postes de travail sous Windows sur lesquels installer deux clients de l'application métier. Les membres de l'équipe pourront se connecter en RDP sur ces postes pour travailler.
  • Si on conserve notre architecture réseau actuelle, on a donc besoin d'acheter 2 nouvelles machines : une pour le serveur d'application, qui doit être connectée en permanence sur sa session en plus du serveur existant, et une autre pour le second client.
• Le serveur Debian n'est plus mis à jour, je ne maitrise pas bien la gestion des conteneurs et je ne sais pas bien le gérer :
  
  • Actuellement, cette machine ne sert que pour le contrôleur de domaine Active Directory et pour le pare-feu. C'est une machine relativement puissante, et elle n'est donc pas vraiment exploitée à son plein potentiel.
  • La fonction pare-feu / DNS / DHCP pourrait être assurée par notre routeur, mais visiblement le fait d'avoir le contrôleur de domaine Samba demande une configuration particulière et on a pas réussi à faire fonctionner Samba lorsque le DHCP est assuré par le routeur, donc on a restauré la configuration initiale et limité le routeur à la fonction VPN.

Nos besoins actuels en terme de réseau sont les suivants :

1. Permettre à chacun d'accéder à Internet quand il est sur site !
2. Permettre à chacun d'utiliser l'imprimante / scanner
3. Permettre à chacun de se connecter sur un des postes de travail avec l'application métier depuis sa propre machine, y compris via VPN.

Le problème étant posé, voici mes questions :

• Selon vous, est-ce que nos besoins actuels justifient l'utilisation d'un controleur de domaine local ? Nous n'avons pas vraiment besoin que n'importe qui puisse se connecter sur n'importe quelle machine, nous n'utilisons plus de partage réseau, et chaque utilisateur est administrateur de sa machine. J'ai l'impression que rien ne justifie l'utilisation d'un domaine.
• Nous avons un abonnement Microsoft 365, et j'ai vu qu'il incluait Azure Active Directory. Je n'arrive pas bien à comprendre les possibilités que ça offre. J'ai pas l'impression que ça permette de se passer d'un contrôleur de domaine en local, mais ce serait plus simple si c'était le cas.
• Est-ce qu'une architecture de réseau local plus simple, sans domaine, pourrait permettre de répondre à ces 3 besoins ? Je me demande si la connexion RDP sera possible sans domaine. Voilà ce que j'ai en tête :
  
  • Passage de tous les sercices réseau actuellement gérés par le serveur Debian sur le routeur (DNS/DCHP)
  • Suppression du domaine. Passage de tous les ordinateurs sur un groupe de travail commun, avec un utilisateur local unique sur chaque machine.
  • Formatage du serveur Samba actuel, installation de Windows à la place, avec l'application serveur métier.
  • Création d'utilisateurs locaux spécifiques sur chacune des 2 machines métiers, avec des droits utilisateurs limités. Les identifiants de ces utilisateurs sont donnés aux membres de l'équipe.
• Est-ce que vous avez une autre proposition d'architecture qui permettrait de répondre à ces 3 besoins tout en exploitant mieux le matériel dont on dispose ?

Merci d'avance pour votre aide !

[JML19]

Bonsoir

Tu n'as pas besoin de domaine si tu n'utilises pas d'application Windows Serveur.

Sinon RDP doit fonctionner sans domaine.

Si tu fais du client/serveur il vaut mieux utiliser un domaine AD.

[becket]

Salut,

Petite parenthèse à propos de la sécurité informatique. Confiance et sécurité informatique sont incompatible.

Ceci étant dit :

Le problème étant posé, voici mes questions :
[*]Selon vous, est-ce que nos besoins actuels justifient l'utilisation d'un controleur de domaine local ? Nous n'avons pas vraiment besoin que n'importe qui puisse se connecter sur n'importe quelle machine, nous n'utilisons plus de partage réseau, et chaque utilisateur est administrateur de sa machine. J'ai l'impression que rien ne justifie l'utilisation d'un domaine.

[*]Nous avons un abonnement Microsoft 365, et j'ai vu qu'il incluait Azure Active Directory. Je n'arrive pas bien à comprendre les possibilités que ça offre. J'ai pas l'impression que ça permette de se passer d'un contrôleur de domaine en local, mais ce serait plus simple si c'était le cas.

[*]Est-ce qu'une architecture de réseau local plus simple, sans domaine, pourrait permettre de répondre à ces 3 besoins ? Je me demande si la connexion RDP sera possible sans domaine. Voilà ce que

Tu expliques que l'entreprise est en train de grandir, un plus grand nombre d'utilisateur un plus grand besoin de centralisation de la gestion ( par soucis de simplification, d'efficacité et d’efficience ).
RDP fonctionne sans domaine. Par contre avec quel utilisateur ?

- Un utilisateur partagé entre plusieurs personnes ? Mauvaise idée !
- Un utilisateur crée spécifiquement sur la machine pour chaque utilisateur sur cette machine ? Mauvaise idée !


j'ai en tête :

[*]Passage de tous les sercices réseau actuellement gérés par le serveur Debian sur le routeur (DNS/DCHP)

Tu peux l'envisager si tu peux mettre à jour dns et dhcp depuis le client.

[*]Suppression du domaine. Passage de tous les ordinateurs sur un groupe de travail commun, avec un utilisateur local unique sur chaque machine.

Mauvaise idée.

[*]Formatage du serveur Samba actuel, installation de Windows à la place, avec l'application serveur métier.

Eventuellement. I

[*]Création d'utilisateurs locaux spécifiques sur chacune des 2 machines métiers, avec des droits utilisateurs limités. Les identifiants de ces utilisateurs sont donnés aux membres de l'équipe.

Un beau bordel de gestion en perspective !

[*]Est-ce que vous avez une autre proposition d'architecture qui permettrait de répondre à ces 3 besoins tout en exploitant mieux le matériel dont on dispose ?[/LIST]

Si même tu nous à fait une tartine pour la présentation, on sait assez peu de choses. Le seul truc évident, serait de faire du p2v et d'installation une solution de virtualisation sur ton "gros" serveur.

[chrtophe]

Actuellement, chaque utilisateur est administrateur sur sa machine. On sensibilise à la sécurité informatique quand un nouveau arrive, une suite de sécurité est activée sur chaque machine, mais on est plutôt dans la confiance.

Comme disait Lénine je crois, la confiance n'exclut pas le contrôle. Que tu responsabilise tes utilisateurs et leur fasse confiance, ok, mais j'espère qu'il ne travaillent pas depuis un compte administrateur, et qu'ils ont le code administrateur si ils veulent changer quelque chose. sur une petite équipe, ça reste globalement gérable, mais si tu grandit de façon significative ... et surtout de ce que je comprends, l’infogérance n'est pas ton activité principale dans l'entreprise.

Je suis pas sûr qu'Azure AD soit la solution pour toi, je connais pas bien le truc, mais je pense que c’est de l'AD bridé, donc autant garder ton AD déjà existant.

Attention aussi, si ton appli métier s’appuie sur AD, tu peux avoir des problèmes avec Samba 4 qui aura un shéma 2008R2 et pourra avoir un niveau fonctionnel 2012R2 je crois.

Le serveur Debian n'est plus mis à jour, je ne maitrise pas bien la gestion des conteneurs et je ne sais pas bien le gérer

C'est le premier point à gérer. Gérer un AD correctement nécessite un minimum de compétences. Un AD SAMBA4 n'est pas un AD Microsoft, ça peut te rajouter une couche de complexité/prob.
Si tu ne maitrises pas la gestion des conteneurs, il est toujours envisageable de "sortir" ton AD Samba de ce conteneur pour l'installer directement sur le serveur Debian, vu que tu n'as plus besoin du cloisonnement suite à arrêt de l'application web pour les clients, ce n'est pas une mince affaire. Idem pour le pare-feu, voire peut-être possible de déporter celui-ci sur le routeur si il le permet.
Si je comprends bien, actuellement si ton serveur crash, tu es dans la m...

Dans l'optique d'exploiter au maximum le serveur Debian, il serait peut-être aussi envisageable d'y installer un hyperviseur comme KVM voire un frontend comme Proxmox, qui gère les VM et les conteneurs LXC. Ceci à des fins d'installer une VM Windows dedans (ou plusieurs) pour ton serveur d'applications. Tu pourras peut-être plus facilement gérer tes conteneurs, mais ça t'aideras à peine si tu n'as pas un minimum de connaissances sur les conteneurs. Mais ça t'aidera quand-même dans l'optique d'une transition. Et si tu transformes tes conteneurs en VM, ce sera plus facile pour toi à administrer, je trouve au détriment des perfs, une VM qui virtualise un OS complet sera plus consommateur en ressources qu'un conteneur, qui lui virtualise un service (au sens démon)/une application.

Ne fait surtout pas ça sur le serveur en prod, mais ça reste envisageable si tu le dupliques sur une machine à des fins de simuler une migration.

Le plus simple pour toi étant peut-être de refaire un serveur sous Windows Server. Le virtualiser, que ce soit via le monde Linux ou VMWare ou via le monde Windows va t'apporter une couche de complexité, mais aussi de flexibilité.

[JML19]

Bonjour

Je crois que son problème est un manque de compétence en administration réseau.

L'administration réseau avec Active Directory ne s'invente pas.

Je n'ai pas aussi ces compétences.

J'ai arrêté l'administration réseau en 2006 où je travaillais sous Unix Aix et sous Windows NT4 Serveur.

Il y avait un contrôleur de Domaine Principal et un contrôleur Secondaire.

Le système client/serveur était géré par NT4 Serveur et les machines étaient gérées par le fichier lmhosts ou un serveur WINS.

[chrtophe]

Je crois que son problème est un manque de compétence en administration réseau.

Oui, c'est pour ça qu'il nous demande si il a intérêt à garder un AD.

Ce à quoi je résumerais que :
- si l'appli métier qu'il utilise le nécessite, il n'a pas le choix.
- si ce n'est pas le cas, et que le nombre d'utilisateurs reste limité, il est envisageable de ne pas utiliser d'AD, d'autant plus si on a pas les compétences pour le gérer, mais si le nombre de postes monte significativement, il en aura besoin pour centraliser l'administration du parc informatique, d'autant plus si il doit générer du multi-accès sur session RDP, il lui faudra un serveur RDS, qui se gère avec un AD, ou utiliser un produit tiers comme Citrix.

[AGui_]

Toutes ces réponses en une journée ! Merci beaucoup, c'est vraiment une super communauté ici !

Je confirme que je n'ai actuellement pas toutes les compétences pour l'administration réseau, que la gestion informatique n'est pas mon rôle principal dans l'entreprise et que mes besoins sont bien limités aux 3 que j'ai listés. En particulier, l'application métier serveur ne nécessite pas Active Directory ou Windows Server, il suffit d'une machine sous Windows Famille ou Pro qui dispose d'une adresse IP fixe sur le réseau. On est en croissance, mais on va pas non plus être 50 tout de suite. Le plus probable est qu'on dépassera pas la 20aine de personnes, dans plusieurs années. Et on a tous des formations scientifiques Bac+5 minimum, ce qui n'empêche évidemment pas les problèmes d'interface chaise/clavier, mais je veux dire par là qu'il n'y a personne qui ne comprends absolument rien du tout à ce qu'il fait avec un ordinateur. Et toutes nos données sont déjà hébergées dans le cloud sous Dropbox, la seule fonction du réseau local est d'accéder à l'application métier depuis sa machine.

Je ne maitrise pas bien l'architecture actuelle, le Debian n'est plus à jour et j'aimerai donc en profiter pour tout remettre à plat et repartir de zéro. Je cherche donc la solution la plus simple à mettre en place et à maintenir. C'est pour ça que ma première intuition a été de regarder si je pouvais pas gérer les utilisateurs du domaine au même endroit que les utilisateurs Microsoft365 (donc dans le cloud), étant donné que chacun a forcément un compte Microsoft. Mais visiblement ce n'est pas une solution.

Actuellement, le serveur s'administre uniquement en ligne de commande, à l'exception de la gestion des utilisateurs Active Directory qui peut être faite depuis un poste Windows via l'interface de gestion. C'est ça qui est le plus compliqué pour moi. J'ai compris le fonctionnement des conteneurs LXC, mais je dois avoir la documentation à côté sur mon portable pour savoir quelles commandes taper dès que je veux administrer la machine. Et en effet, si elle tombe en panne demain, je ne suis pas en mesure de le remettre en fonctionnement rapidement. Avoir une interface graphique pour faire l'administration serait déjà une grande avancée.

Merci pour les conseils sur la virtualisation, j'avais pas pensé à ça ! Donc si je résume les solutions que j'ai comprises par rapport à vos propositions :

1. La solution sans domaine que je propose : moins sécurisée que les autres, pas recommandée par beaucoup, mais pas bien pire que ce qu'on fait déjà actuellement en pratique.
2. Acheter une licence Windows Server, l'installer sur le serveur, créer un nouveau domaine Active Directory dessus, et installer mon serveur métier dessus. C'est la solution la plus chère (500$ pour une licence Windows Server 2019), mais si ça peut me faire gagner du temps et me simplifier la vie, pourquoi pas. Mais est-ce qu'un domaine sera plus simple à mettre en place depuis Windows Server vu mes compétences ? Pas dit.
3. Installer un hyperviseur sur le serveur, puis une machine virtuelle avec un Linux+Samba et une autre avec Windows Pro et le serveur d'application. Pas d'investissement à faire, mais pas sûr que j'ai les compétences pour mettre tout ça en place sans passer une semaine à m'autoformer... Et niveau performance ? On risque pas de trop y perdre ?

Sinon il y a aussi la solution d'engager quelqu'un pour la mise en place de l'infrastructure. Une idée du temps de travail que ça pourrait représenter pour une personne expérimentée de mettre en place ce type d'architecture ?

[chrtophe]

L'idée d'installer un hyperviseur, c'est car pour moi ça reste plus facile qu’utiliser qu'un conteneur. Au niveau perf, tu perdras mais tout dépend du nombre de VM et de la capacité du serveur, ce sera quand-même moins performant qu’avec des conteneurs. Mais migrer des conteneurs vers VM risque pour toi de ne pas être une mince affaire, avec un éventuel bénéfice pour l'administration, mais moins de perfs.

Si tu passes sous Windows 2019, tu ne perdras pas forcément le domaine, mais j'ai jamais fait une migration Samba->vers AD Windows, donc je sais pas le résultat. Dans la situation actuelle, pour moi le seul intérêt est si tu as besoin plus tard d'un serveur RDS pour avoir plusieurs connexions RDP simultanés pour plusieurs clients sur ton appli métier, sinon autant rester sur le principe actuel. Pour 10 postes, ça reste quand-même pertinent d'utiliser AD mais pas forcément indispensable. La virtualisation te permettra de créer ce serveur Windows virtualisé sur le serveur Linux existant. Et il faut prendre en compte que 2019 sera plus lourd que Samba.

Engager quelqu’un peut être la solution, mais tu vas devoir trouver quelqu’un qui ai des compétences Windows Server, Linux, AD avec Samba, et en gestion de conteneurs LXC, pas forcément facile. Le faire toi-même, tu risque d'y passer pas mal de temps.

[becket]

Forcément, la solution qui consiste à externaliser sera effectivement la plus rapide en terme de mise en place MAIS il est impossible de juger objectivement du temps nécessaire sans avoir un cahier de charge très précis et une vue beaucoup plus précise de l'infra à modifier.

Bon ... En ce qui concerne la partie virtualisation, à partir du moment ou tu utilises une virtualisation de type 1 ( kvm, xen, vmware, hyper-v ) tu ne devrais pas trop y laisser des plumes au niveau performance. J'ai évidemment une préférence pour xcp-ng ( xen ) que je connaît et proxmox (kvm) que je ne connaît encore que de nom car ils sont tous les deux libres et gratuits.

Concernant l'installation d'un domaine AD, il est évident que tout peut être compliqué lorsque l'on parle d'informatique professionnelle même cela peut paraître simple lorsque l'on sait de quoi on parle.


Par contre rien ne t’empêche de faire un laboratoire de virtualisation en installant un hyperviseur de type 2 ( genre virtualbox ) sur un pc et en y "nestant" ( faire tourner un hyperviseur dans un hyperviseur ) les virtualiseurs de type 1. Tu pourras constater qu'il n'y a rien de compliqué

[becket]

j'ai jamais fait une migration Samba->vers AD Windows, donc je sais pas le résultat.

Si j'ai bien compris, il comptait repartir d'une feuille blanche mais effectivement comme tu le laisses supposer un migration pourrait faire gagner du temps.

[chrtophe]

un migration pourrait faire gagner du temps.

Récupérer les confs users, partages etc. de l'AD oui, gagner du temps ça reste à démontrer, ça dépend comment la migration se passe.

Pour Promox, j'ai fait un tutoriel dessus.

Dans l'absolu, ça pourrait être une solution intéressante en l'installant par dessus l'install courante. Bien sûr à ne pas faire directement dans le serveur en prod, mais si tu clone ton serveur, tu pourrais envisager un plan de migration et tester depuis une restauration du clone dans une VM. Ca te laisse le temps de tester la migration de ton AD Samba vers une VM ou directement à la racine de ton serveur, pas forcément besoin d'une VM. Mais peut-être que l'interface Proxmox te sera suffisante pour administrer tes conteneurs.

[AGui_]

Ok merci pour toutes ces infos, j'y vois un peu plus clair sur les différentes options qu'on a. Je vais en discuter avec mon chef et on va voir quelle est la solution la plus adaptée pour nous. Vu ma charge de travail actuel, je pense que je vais avoir du mal à dégager suffisamment de temps pour mettre tout ça en place. Donc si certains d'entre vous proposent ce genre de service et serraient intéressés, n'hésitez pas à me contacter en MP pour qu'on échange en privé (on est localisés à Paris).

Bonne continuation à tous,