4 liens privés
Un outils pour déployer des serveurs de jeux facilement sous Linux
(via https://korben.info/linuxgsm-installer-serveur-jeu-linux.html)
Active Directory: meilleures pratiques pour la structure de l'unité d'organisation | faq-o-matic.net
Il n'y a pas de structure d'UO «correcte» ou «meilleure» pour un domaine Active Directory. Pourtant, il y a beaucoup de choses à faire «pas très bien». Après une longue hésitation, je vous présente donc un exemple de structure qui peut servir de base à vos propres créations.
Il y a eu une erreur fondamentale dans de nombreux environnements AD depuis que Microsoft a rendu public les premiers exemples et cours de formation à la fin des années 1990: depuis, de nombreux administrateurs ont essayé de mapper l'organigramme de l'entreprise avec les unités d'organisation du domaine. Ils découvrent rapidement que c'est assez compliqué pour l'administrateur. Et peu de temps après, on se rend compte que l'organigramme a déjà changé à nouveau, mais que personne n'a informé les administrateurs.
La réalisation: La structure OU dans l'AD n'est pas là pour l'organigramme, mais pour l'administration. L'administration informatique a généralement des critères complètement différents de ceux des entreprises, et c'est une bonne chose. La structure AD devrait aider les administrateurs, pas les employés. De toute façon, les employés ne voient pratiquement jamais les UO, pas plus que les gestionnaires. Ici, cependant, se pose le problème des «meilleures pratiques»: comme l'administration informatique est également très différente d'une entreprise à l'autre, il n'y aura pas de modèle qui convienne à tout le monde. Comme indiqué ci-dessus, il existe quelques concepts qui ont fait leurs preuves dans de nombreuses situations et à partir desquels vous pouvez ensuite vous planifier.
L'idée de base la plus importante que suivent de nombreux modèles est l'orientation de l'objet. C'est un mot gros et en fait inapproprié, mais il est utilisé par beaucoup. Ce que cela signifie est: La structure de base au niveau «supérieur» est basée sur les classes d'objets typiques qui sont importantes pour l'administration: utilisateurs, groupes et ordinateurs. Étant donné que l'administration de ces classes est très différente les unes des autres, elles conviennent comme critère principal. D'autres subdivisions sont ensuite introduites dans les classes, bien que certaines choses se soient également avérées utiles pour le sous-niveau suivant.
Deuxième réflexion importante qu'il convient de retrouver dans la structure «au sommet»: L'administration d'un réseau est fondamentalement différente de son utilisation. Les objets administratifs (comptes utilisateurs administrateurs, groupes d'administrateurs et également ordinateurs administrateurs) doivent donc être clairement séparés des objets de production normaux. Ici, les choses peuvent devenir un peu plus complexes, car dans les grandes entreprises, il y a souvent une administration centrale qui est prise en charge par des administrateurs décentralisés. Cela peut être mappé de différentes manières.
Dans les ateliers de conception, de nombreux administrateurs AD demandent où les départements et les emplacements entrent en jeu. Cela dépend de l'importance réelle de ces constructions pour l'administration. Cela fait-il une grande différence pour les administrateurs si un utilisateur travaille en production ou en vente? Des processus différents s'appliquent-ils aux ordinateurs à Hambourg et à Munich? Ensuite, ce sont des critères importants. Mais si cela ne joue pas un rôle important, d'autres points peuvent être pertinents, comme la distinction entre un ordinateur portable et un ordinateur de bureau. Dans certaines entreprises, le département informatique dans lequel travaille un utilisateur n'a pas non plus d'importance - à une exception près, à savoir la comptabilité financière. Des sous-structures appropriées peuvent également être construites pour cela.
Questions clés possibles pour la structure:
Qui est responsable de la gestion de certains objets dans les affaires quotidiennes?
Sont-ils toujours les mêmes personnes (alors vous avez tendance à ne pas subdiviser), ou certaines personnes sont-elles responsables de certaines parties (alors vous diviseriez la structure pour que chacun ait ses objets sous contrôle)?
Faut-il diviser les autorisations et les responsabilités administratives?
Si, par exemple, un service d'assistance utilisateur est responsable de certains comptes utilisateur, ces comptes doivent être situés dans une structure UO commune afin que le service d'assistance puisse facilement se voir attribuer des autorisations pour eux.
Existe-t-il des processus adaptés à des parties spécifiques de l'infrastructure?
Les automatisations, les stratégies de groupe, les scripts, etc. peuvent être configurés plus facilement s'ils ne doivent accéder qu'à une seule branche OU (ou à quelques-uns seulement).
Quels critères forment la base de l'organisation au sein du département informatique?
En fait, ces critères sont également les plus importants pour la MA. S'il existe une équipe distincte pour les serveurs SQL, ceux-ci doivent trouver leurs objets dans un emplacement central. Si tous les administrateurs sont responsables de tous les serveurs, il est alors moins logique de diviser les serveurs en plusieurs unités d'organisation.
Voici un exemple de conception qui a fait ses preuves comme point de départ pour les ateliers de conception AD. Nota bene: comme point de départ. J'ai conseillé de nombreux clients avec ce modèle, qui est ensuite devenu la base d'un design individuel. Mais il n'y a pas un seul client qui a mis en œuvre exactement ce modèle sans changements.
dom2.dom1.de
Administration
(comptes d'utilisateurs pour les administrateurs, quelle que soit la tâche spécifique. Autorisation AD uniquement pour les groupes d'administrateurs sélectionnés.)
Central
Décentralisé
Externe
Comptes de service ( comptes d'
utilisateurs pour les connexions au service. Autorisation AD uniquement pour les groupes d'administrateurs sélectionnés.)
Utilisateur
(comptes d'utilisateur standard sans droits d'administrateur. Droits AD uniquement pour certains groupes d'administrateurs; centre de services avec peu de droits.)
<Critère 1>
<Critère 2>
Externe
...
Groupes
(conteneur pour tous les groupes)
Administration
(groupes qui autorisent l'administration. Autorisation AD uniquement pour les groupes d'administrateurs sélectionnés.)
Administrateurs du serveur
(un groupe par serveur ajouté aux administrateurs locaux.)
Rôles fonctionnels
(groupes qui reçoivent des autorisations directes dans l'AD ou sur les systèmes. Les membres ne sont généralement que des groupes d'administrateurs, et non des utilisateurs administrateurs.)
Rôles organisationnels
(groupes que les administrateurs combinent en fonction de critères organisationnels, par exemple les administrateurs Exchange.)
Autorisations
(groupes qui accordent aux utilisateurs l'accès aux données et aux systèmes. Les membres ne sont généralement que des groupes et non des utilisateurs.)
Système de fichiers
Applications
Organisationnel
(groupes qui récapitulent les utilisateurs selon des critères organisationnels, par exemple le service des ressources humaines.)
Mise en quarantaine de l'ordinateur
(conteneur pour les ordinateurs nouvellement ajoutés qui ne sont pas encore dans l'unité d'organisation cible.
Objet de stratégie de groupe: certaines connexions sont possibles, aucune connexion utilisateur)
Serveur
(À partir de là, par exemple, les droits de connexion et d'administration pour les serveurs sont accordés et les paramètres de sécurité sont définis via GPO.)
<Groupe de serveurs 1>
<Groupe de serveurs 2>
Emplacement local
<Emplacement 1>
<Emplacement 2>
Clients
(À partir de là, par exemple, les droits de connexion et d'administration pour les clients sont accordés via GPO et les paramètres de sécurité sont définis.)
<Critère administratif 1>
(par ex. PC avec des exigences de sécurité plus élevées)
<éventuellement Emplacement 1>
<éventuellement Emplacement 2>
<Critère administratif 2>
(par exemple, PC avec des exigences de sécurité normales)
<éventuellement Emplacement 1>
<éventuellement Emplacement 2>
Ressources
https://www.faq-o-matic.net/2020/11/16/active-directory-best-practice-zur-ou-struktur/