Conception d'unité d'organisation Active Directory pour <500 utilisateurs, 4 emplacements

Nous cherchons à ajouter une structure logique à notre hiérarchie (Win 2003) AD. Nous avons un seul domaine et environ 500 utilisateurs. Tous les utilisateurs et ordinateurs sont actuellement organisés en une seule unité d'organisation. Tous les groupes de sécurité et de distribution se trouvent dans une deuxième unité d'organisation. L'appartenance à un groupe est essentiellement basée sur un utilisateur individuel sans imbrication de groupes.

Mes questions:

1. Pour une organisation de cette taille, vaut-il la peine de définir une hiérarchie des unités d'organisation basée sur le département, la géographie et / ou la classe d'objets (c.-à-d. Ordinateurs, utilisateurs, groupes) et de déplacer les utilisateurs, ordinateurs et groupes dans les unités d'organisation pertinentes?
2. Si oui, comment structureriez-vous la hiérarchie, par exemple département-> emplacement-> classe d'objets?
3. Devrions-nous imbriquer des groupes, le cas échéant, pour un meilleur mappage avec les rôles d'application d'entreprise et les entrées d'adresse Exchange?

Voici les principes fondamentaux de la recommandation de Microsoft pour la conception logique AD:

• Concevez d'abord pour la délégation de contrôle, car il est basé sur les autorisations AD et est l'axe le plus rigide à modifier. Si vous ne faites pas de délégation de contrôle, ne vous inquiétez pas (mais je le planifierais quand même - même dans une organisation aussi petite, vous aurez peut-être besoin d'utilisateurs désignés dans les succursales pour pouvoir réinitialiser les mots de passe, etc).

• Concevez second pour l'application de la stratégie de groupe. Le filtrage de l'application de stratégie de groupe par appartenance à un groupe de sécurité permet à un objet de stratégie de groupe de ne s'appliquer qu'à un sous-ensemble des objets utilisateur ou ordinateur en dessous du point auquel il est lié dans l'annuaire, de sorte que cet axe a une plus grande flexibilité que les autorisations AD.

• Concevoir enfin pour l'organisation et la facilité d'utilisation. Rendez-vous facile de trouver des choses pour vous et les autres administrateurs.

Pensez à chacune de ces considérations lors de la conception, en les priorisant comme recommandé. Il est facile de changer les choses plus tard (comparativement) et vous ne réussirez jamais du premier coup. Avant même de DCPROMO mon premier contrôleur de domaine, je dessine généralement la structure proposée sur papier ou un tableau blanc et je passe en revue les scénarios d'utilisation potentiels pour voir si ma conception "tient". C'est un excellent moyen de résoudre les problèmes dans une conception.

(N'oubliez pas non plus l'application de stratégie de groupe sur les objets de site. Vous devez faire attention à l'application de GPO interdomaine lorsque vous liez des GPO sur des sites, mais si vous êtes un environnement de domaine unique, vous pouvez obtenir beaucoup de Fonctionnalité de la liaison des objets de stratégie de groupe aux sites. Travaillez avec certains exemples de scénarios avec elle. emplacements physiques, au moyen du traitement de la stratégie de groupe de bouclage.

Je divisais toujours les utilisateurs, les ordinateurs et les groupes en unités d'organisation distinctes, pour la simple raison que cela facilite la gestion.

Si vous n'avez aucune raison impérieuse pour une structure AD spécifique, alors concevez votre AD d'un point de vue administratif. Pensez à l'endroit où vous allez appliquer les politiques.

Si vous appliquez la plupart de vos stratégies au niveau du service, utilisez Department \ Location \ Object

Si vous appliquez la plupart de vos stratégies au niveau de l'emplacement, utilisez Location \ Department \ Object

Si vous le faisiez dans l'autre sens, cela signifierait que vous devriez lier vos politiques à plusieurs unités d'organisation, ce qui implique un travail inutile.

L'imbrication de groupes est parfaitement correcte et, encore une fois, facilite la gestion de la DA.

J'ai tendance à concevoir des structures AD en pensant à «faciliter la gestion» plutôt qu'à refléter la structure physique de l'entreprise, mais les deux sont souvent les mêmes.

Je pense que si je devais repenser mon AD, il y aurait quelques choses que je ferais différemment, mais j'ai constaté que:

Utilisateurs - Répartir les thèses en départements, mais aussi avec un / des espace (s) pour le personnel intérimaire ou d'agence L'emplacement de ceux-ci ne sera pas aussi important que les gens se déplaceront sans aucun doute.

Ordinateurs - Divisez-les en emplacement et sous-emplacements. Ie OfficeComputers / LondonOffice / Room103 (Finance). Cela signifie que vous pouvez appliquer des paramètres à un emplacement ou à un bureau - par exemple, un serveur proxy différent ou des paramètres antivirus différents (bien sûr uniquement si le programme de gestion AV utilise AD) - sans réorganisation, et nous espérons que vous n'aurez pas à ouvrir le peut de vers qui est un traitement de bouclage.

J'ai également trouvé utile de ne pas utiliser les groupes d'utilisateurs ou d'ordinateurs intégrés, pas de problèmes techniques, mais juste pour que vous puissiez facilement voir où les choses ne devraient pas être.

Enfin, divisez également vos serveurs, j'ai opté pour un emplacement / rôle qui semble avoir assez bien fonctionné.

Comme il a déjà été répondu, voici ma prise pour un petit exemple, sachez qu'il n'y a pas de bien ou de mal, tout dépend des besoins - c'est-à-dire l'organisation ou l'emplacement en premier? Je préfère le rôle organisationnel d'abord, même pour les rôles ordinateurs / serveurs. J'aime également la possibilité de signaler une seule unité d'organisation pour obtenir tous les employés et pas de déchets pour remplir les listes d'employés intranet. N'hésitez pas à éditer!

• Personnes (utilisateurs / type = personne)
  • Interne
    • Département A
      • Emplacement X
      • Emplacement Y
    • Département B
    • Département C
  • Externe
    • Entreprise 1
    • Entreprise 2
• Machine (utilisateurs / type = tout ordinateur compris)
  • Client
    • Portables
    • PC de bureau
  • Serveur
    • Application
      • Emplacement T
      • Emplacement V
    • Infrastructure
    • Base de données
  • Un service
  • Comptes administratifs (si utilisés)
• Listes (groupes et contacts)
  • Contact
  • Distribution
  • Sécurité

Je les diviserais simplement par emplacement dans ce cas. La structure OU résultante ressemblerait à ceci:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

etc.

Je ne vois pas vraiment le besoin de divisions supplémentaires ici, par exemple par département, car cela générerait des frais administratifs supplémentaires sans vraiment donner beaucoup en retour. Cependant, la répartition par emplacement vous permettrait de mettre en œuvre la délégation sur chaque site.

Un guide que j'utilise est: les utilisateurs; organiser selon les groupes de flux de graphiques RH; organiser selon le flux de travail Ordinateurs; organiser selon la situation géographique

Les autres réponses dans ce fil sont également très bonnes.