Progettazione OU di Active Directory per <500 utenti, 4 posizioni

Stiamo cercando di aggiungere una struttura logica alla nostra gerarchia AD (Win 2003). Abbiamo un solo dominio e circa 500 utenti. Tutti gli utenti e i computer sono attualmente organizzati in un'unità organizzativa. Tutti i gruppi di sicurezza e distribuzione si trovano in una seconda unità organizzativa. L'appartenenza al gruppo è essenzialmente su base utente individuale senza nidificazione di gruppi.

Le mie domande:

1. Per un'organizzazione di queste dimensioni vale la pena progettare una gerarchia di unità organizzative in base al reparto, alla geografia e / o alla classe di oggetti (ovvero computer, utenti, gruppi) e spostare utenti, computer e gruppi nelle unità organizzative pertinenti?
2. In tal caso, come struttureresti la gerarchia, ad esempio dipartimento-> posizione-> classe oggetto?
3. Dovremmo nidificare i gruppi, ove appropriato, per una migliore mappatura ai ruoli delle applicazioni aziendali e alle voci degli indirizzi di Exchange?

Ecco i principi fondamentali della raccomandazione di Microsoft per la progettazione logica di annunci pubblicitari:

• Progettare innanzitutto per la delega del controllo, poiché si basa su autorizzazioni AD ed è l'asse più flessibile da modificare. Se non stai delegando il controllo, non preoccuparti di questo (ma lo pianificherei comunque - anche in un'organizzazione così piccola potrebbe essere necessario che gli utenti designati nelle filiali siano in grado di reimpostare le password, eccetera).

• Secondo progetto per l'applicazione di criteri di gruppo. Il filtro dell'applicazione dei criteri di gruppo in base all'appartenenza al gruppo di sicurezza consente a un oggetto Criteri di gruppo di applicare solo a un sottoinsieme dell'utente o degli oggetti del computer al di sotto del punto in cui è collegato nella directory, quindi questo asse ha una maggiore flessibilità rispetto alle autorizzazioni AD.

• Progettare infine per l'organizzazione e la facilità d'uso. Rendi facile trovare cose per te e per gli altri amministratori.

Pensa a ciascuna di queste considerazioni mentre progetti, dando la priorità come raccomandato. È facile cambiare le cose in un secondo momento (comparativamente), e al primo tentativo non "riuscirai mai". Prima ancora di DCPROMO, il mio primo controller di dominio, in genere disegno la struttura proposta su carta o lavagna e percorro potenziali scenari di utilizzo per vedere se il mio progetto "regge". È un ottimo modo per scovare i problemi in un progetto.

(Non dimenticare l'applicazione di criteri di gruppo sugli oggetti del sito. Devi fare attenzione all'applicazione GPO tra domini quando colleghi gli oggetti Criteri di gruppo ai siti, ma se sei un singolo ambiente di dominio puoi ottenere molto funzionalità al di fuori del collegamento degli oggetti Criteri di gruppo ai siti. Lavora con alcuni scenari di esempio con esso-- Trovo che sia ottimo per caricare software con impostazioni "site specific" o fornire script di accesso specifici agli utenti quando accedono a computer in determinati posizioni fisiche, mediante elaborazione di criteri di gruppo di loopback.)

Dividevo sempre utenti, computer e gruppi in unità organizzative separate, per la semplice ragione che semplifica la gestione.

Se non si hanno motivi validi per una struttura AD specifica, progettare l'AD da un punto di vista amministrativo. Pensa a dove stai applicando le politiche.

Se stai applicando la maggior parte delle tue politiche a livello di dipartimento, usa Dipartimento \ Posizione \ Oggetto

Se stai applicando la maggior parte delle tue politiche a livello di posizione, usa Posizione \ Dipartimento \ Oggetto

Se lo facessi nell'altro modo, significherebbe che dovresti collegare i tuoi criteri a più unità organizzative, il che comporta un lavoro non necessario.

I gruppi di nidificazione vanno benissimo e, ancora una volta, rendono molto più semplice la gestione dell'AD.

Tendo a progettare strutture AD pensando a "semplificare la gestione", piuttosto che riflettere la struttura fisica dell'azienda, tuttavia entrambe sono spesso uguali.

Penso che se dovessi riprogettare nuovamente il mio annuncio, ci sono alcune cose che farei diversamente, ma ho scoperto che:

Utenti: suddividere le tesi in dipartimenti, ma anche con un'area / e per il personale temporaneo o di agenzia. La posizione per questi non sarà così importante come senza dubbio le persone si muoveranno.

Computer: suddividili in posizione e posizioni secondarie. Vale a dire OfficeComputers / LondonOffice / Room103 (Finanza). Ciò significa che è possibile applicare le impostazioni a una posizione o a un ufficio - ad esempio un server proxy diverso o impostazioni antivirus diverse (ovviamente solo se il programma di gestione AV utilizza AD) - senza riorganizzarsi e, si spera, non sarà necessario aprire il lattina di worm che sta elaborando il loopback.

Ho anche trovato utile non utilizzare gli utenti o i gruppi di computer integrati, non problemi tecnici, ma solo per vedere facilmente dove non dovrebbero essere le cose.

Infine, ho diviso anche i tuoi server, sono andato per posizione / ruolo che sembra aver funzionato abbastanza bene.

Dato che ha già risposto, ecco la mia opinione per un piccolo esempio, ti dispiace che non ci sia giusto o sbagliato tutto dipende dalle esigenze - cioè l'organizzazione o la posizione prima? Preferisco il ruolo organizzativo prima anche per i ruoli di computer / server. Mi piace anche la possibilità di indicare una singola unità organizzativa per ottenere tutti i dipendenti e nessuna immondizia per popolare gli elenchi dei dipendenti della Intranet. Sentiti libero di modificare!

• Persone (utenti / tipo = persona)
  • Interno
    • Dipartimento A
      • Posizione X
      • Posizione Y
    • Dipartimento B
    • Dipartimento C
  • Esterno
    • Azienda 1
    • Azienda 2
• Macchina (utenti / tipo = qualsiasi computer incluso)
  • Cliente
    • Laptop
    • Desktops
  • server
    • Applicazione
      • Posizione T
      • Posizione V
    • Infrastruttura
    • Banca dati
  • Servizio
  • Account amministrativi (se utilizzati)
• Elenchi (gruppi e contatti)
  • Contatto
  • Distribuzione
  • Sicurezza

In questo caso li avrei divisi per posizione. La struttura OU risultante sarebbe simile a questa:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

eccetera.

Non vedo davvero alcuna necessità di ulteriori divisioni qui, ad esempio per Dipartimento, in quanto genererebbe un sovraccarico amministrativo aggiuntivo senza dare davvero molto in cambio. La suddivisione per posizione consente tuttavia di implementare la delega in ciascun sito.

Una linea guida che uso è: Utenti; organizzare secondo i gruppi di flusso grafico delle risorse umane; organizzare in base al flusso di lavoro Computer; organizzare in base alla posizione geografica

Anche le altre risposte in questo thread sono molto buone.