none
Nuove politiche aziendali - da dominio a semplice OU RRS feed

  • Discussione generale

  • Ciao,

    sto facendo da consulente per un'azienda piuttosto grossa, che secondo me sta facendo una scelta sbagliata per un ramo aziendale. Questo 'ramo' conta più di 10500 computer e almeno 15000 utenti, ma si vuole gestire tutto con OU contenenti le varie filiali.

    Non discuto il fatto che non sia stato concesso un dominio child, anche se i numeri sono elevati siamo ben lontani dai limiti fisici di una AD 2008, e così facendo risulterà più semplice per il ced amministrare backup di AD ed altre cose.

    - Discuto sul fatto gli le OU di questo ramo conterranno solo oggetti computer. Le impostazioni utente verranno applicate solo grazie al loopback attivo come gpo per tutto il dominio. Alcuni utenti, anch'essi non presenti nella OU del ramo, avranno delega di Creazione e link GPO, ma ritengo questa soluzione molto limitante. è stato detto che grazie al loopback si riuscirà a fare qualsiasi cosa, ma per esempio i filtri su gpo utente non saprei più come applicarli. Forse potranno venirmi in aiuto le preference con igli item-level targeting, ma le preference non sostituiscono in toto le GPO.

    - Discuto sul fatto che pur consentendo per delega l'utilizzo di ruoli server come DFS, WDS ecc. non vogliono concedere nemmeno un RODC. E' vero che il dfs di dominio funzionerebbe lo stesso, ma ha strettamente bisogno di un DC e di un DNS per consentire agli utenti di accedere. Se dovesse cadere la linea dati di una sede senza RODC, i client non riuscirebbero più a risolvere il nome del namespace e nessuno sarebbe più in grado di ricevere ticket kerberos per l'accesso...

    Secondo me dovrebbero consentire lo spostamento degli utenti di pertinenza di ogni sede nella rispettiva OU, in modo da consentire all'admin delegato di amministrare meglio con l'uso di GPO, e in più dovrebbero consentire il deploy di un RODC per ogni sede.

    Cosa ne pensate, qualsiasi opinione è davvero gradita

    giovedì 5 marzo 2015 22:16

Tutte le risposte

  • ho letto abbastanza attentamente quello che hai scritto ma non mi è chiaro quale tipo di risposta o di conforto stai cercando forse perchè non ho ben capito a cosa ti riferisci quando parli di "ramo". cos'è? una sede remota ? più sedi remote ? una società controllata ?

    e non riesco neanche a cogliere il tuo dissenso sulle loopback policies

    http://support.microsoft.com/kb/231287/it

    che sono nate solo per fornire un elemento in più e poter impiegare policy di tipo user discriminando per computer su cui avviene il logon.

    certamente saprai motivare meglio il tuo pensiero.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org


    martedì 10 marzo 2015 13:01
    Moderatore
  • mancano alcune informazioni come ad esempio la struttura di rete (banda, locations), quante branch sono e quanti utenti ci sono per branch, quanti DC nell' HQ...difficile esprimere un'opinione
    giovedì 12 marzo 2015 16:26
  • ho letto abbastanza attentamente quello che hai scritto ma non mi è chiaro quale tipo di risposta o di conforto stai cercando forse perchè non ho ben capito a cosa ti riferisci quando parli di "ramo". cos'è? una sede remota ? più sedi remote ? una società controllata ?

    e non riesco neanche a cogliere il tuo dissenso sulle loopback policies

    http://support.microsoft.com/kb/231287/it

    che sono nate solo per fornire un elemento in più e poter impiegare policy di tipo user discriminando per computer su cui avviene il logon.

    certamente saprai motivare meglio il tuo pensiero.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org


    Ok, chiedo scusa. Integro:

    Ramo = società controllata

    Dissenso sulle loopback policies: ritengo che debbano essere utilizzate come strumento per gestire l'eccezione, e non debbano essere la regola. Qui intendono rendere il loopback l'unico modo per applicare politiche utente poiché l'OU a noi assegnata NON conterrà utenti. 15000 da gestire solo con il loopback mi mettono molto in difficoltà. Non mi era mai successo, per cui i miei dubbi possono anche essere solo dovuti ad inesperienza, ma io solitamente faccio molto uso di filtri per applicare le GPO e qui devo addirittura capire se sia fattibile come soluzione. 15000 utenti secondo me avranno bisogno di tante eccezioni e filtri.

    Non avere gli utenti mi limiterà

    lunedì 16 marzo 2015 22:09
  • mancano alcune informazioni come ad esempio la struttura di rete (banda, locations), quante branch sono e quanti utenti ci sono per branch, quanti DC nell' HQ...difficile esprimere un'opinione

    Banda : simmetriche dai 4 agli 8 Mbit  per ogni sede - Roma 100Mbit??? devo informarmi

    locations : presenti in ogni regione italiana. alcune regioni sono piccole ed hanno poche sedi, altre regioni come l'emilia ne ha 22. in ogni regione c'è una filiale principale. le sedi minori riescono a vedere solo la filiale principale e la sede centrale a Roma.

    Una OU principale conterrà una OU per ogni regione. Nella regione una OU per ogni sede - le OU conterranno solo oggetti computer e nessun utente

    Per inciso -> i numeri precisi di quante workstations e quanti utenti non li ho nemmeno io. La mia è stata una botta di conti fatta in una riunione in cui appunto di è deciso di assegnare a questo "ramo" solo una OU, senza concedere un dominio child. I numeri temo potranno solo aumentare.

    Quanti DC in quella che sarà l'unica HQ non lo so. Sicuramente avranno dimensionato bene.

    Anche se i dati non sono ancora precisi, io ritengo ugualmente che la soluzione loopback per tutti e nessun RODC per sede sia inappropriata. A dirla tutta preferirei un child, ma quest'ultima soluzione non verrà mai concessa...

    Stato attuale del ramo: Abbandono... Qualche regione ha creato una propria foresta ed un proprio dominio, altre regioni non hanno nulla.


    lunedì 16 marzo 2015 22:42
  • concordo con te che le loopback policies servono per gestire l'eccezione e non la regola ma non capisco chi stabilisce che le OU debbano contenere solo computers e non users o se vi sia una necessità specifica che obbliga a fare questa scelta.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    martedì 17 marzo 2015 10:25
    Moderatore

  • Anche se i dati non sono ancora precisi, io ritengo ugualmente che la soluzione loopback per tutti e nessun RODC per sede sia inappropriata. A dirla tutta preferirei un child, ma quest'ultima soluzione non verrà mai concessa...


    se può consolarti, sul fatto di mettere almeno un RODC per sede concordo pienamente altrimenti significa affidarsi completamente alla connettività pregando che la rete non vada mai giù

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org


    martedì 17 marzo 2015 10:28
    Moderatore
  • Anche se i dati non sono ancora precisi, io ritengo ugualmente che la soluzione loopback per tutti e nessun RODC per sede sia inappropriata. A dirla tutta preferirei un child, ma quest'ultima soluzione non verrà mai concessa...

    Stato attuale del ramo: Abbandono... Qualche regione ha creato una propria foresta ed un proprio dominio, altre regioni non hanno nulla.


    Situazione complicata direi. Un dominio child sarebbe la configurazione ideale, posso solo dire la mia, presenta al cliente una comparazione tra le due soluzioni (OU e child) sperando che alla fine convenga sulla soluzione migliore.

    martedì 17 marzo 2015 14:52
  • Sono d'accordo con te che in un'infrastruttura del genere servirebbe almeno un RODC per sede (almeno per quelle con più di 3-5 computer), però per quanto riguarda l'utilizzo di domini child non è sempre una pratica consigliata. Secondo me va bene se ogni "sede" è così grande da avere quasi una sua autonomia rispetto alla sede centrale oppure se ogni sede è addirittura una società acquisita dal gruppo, altrimenti puoi gestire tutto anche con un unico dominio, senza complicare troppo la struttura informatica rispetto a quella organizzativa.

    Per quanto riguarda l'utilizzo delle loopback policies credo anch'io che dovrebbero essere l'eccezione, ma l'organizzazione delle OU per oggetti computer potrebbe avere una motivazione precisa. Ad esempio se numerosi utenti si spostano da una sede all'altra e in ogni sede devono esserci dei criteri differenti, può essere più complicato spostare ogni volta gli oggetti utente. Sicuramente è un approccio atipico, perché solitamente i criteri vengono applicati in base al ruolo di un utente e non in base alla posizione geografica in cui esegue l'accesso, ma dipende molto anche dalle esigenze aziendali come diceva anche Edoardo Benussi qualche post fa. 


    martedì 17 marzo 2015 17:32
    Moderatore
  • Dal mio punto di vista il child aiuterebbe a semplificare l'amministrazione degli account che si vuole mettere in una OU, tra l'altro faciliterebbe anche futuri cambiamenti. Poi concordo sui RODC.
    martedì 17 marzo 2015 17:38
  • Si, non è che i domini figlio li stavo sconsigliando nel suo caso specifico, dicevo solo che la scelta deve essere fatta comunque in base a come è strutturata a livello organizzativo l'azienda e che la scelta di utilizzare un singolo dominio potrebbe anche avere delle ragioni.

    Si potrebbe sicuramente valutare l'utilizzo di domini figlio almeno per le regioni maggiori e magari unificare le regioni minori per ridurre il numero di domini. Tuttavia bisogna capire se questo tipo di gestione è compatibile con tutto il resto.

    A mio parere una pianificazione di questo tipo non è possibile farla qui, bisognerebbe avere una panoramica completa.

    martedì 17 marzo 2015 23:28
    Moderatore
  • concordo con te che le loopback policies servono per gestire l'eccezione e non la regola ma non capisco chi stabilisce che le OU debbano contenere solo computers e non users o se vi sia una necessità specifica che obbliga a fare questa scelta.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    L'unica motivazione, a mio avviso, è che l'active directory è di tipo enterprise, ovvero funge da database per le informazioni dei dipendenti. Dall'assunzione alla quiescenza, tutti i dipendenti sono gestiti da SAP che popola appunto gli attributi utente. Avranno una OU in cui SAP ha diritti di scrittura ,e non so se per spesa o prassi consolidate, mi sono sembrati poco propensi ai cambiamenti. Eppure, secondo me, basterebbe semplicemente una buona progettazione delle ACL relative agli utenti e agli attributi. Una volta che non possiamo cancellare utenti e non possiamo vedere/modificare gli attributi, magari filtrando gli attributi replicabili verso i nostri RODC (che manco ci concedono) che problema c’è a mettere i nostri utenti in una OU a noi accessibile?

    L'unica cosa su cui mi trovavo d'accordo (anche se avrei ovviamente preferito un child) è la volontà di gestire tutto con un unico dominio evitando un aggravio nella migrazione utenti

    Sul chi decida cosa mettere nelle OU, scopriamo le carte, si tratta del dominio che raggruppa tutti i tribunali, i giudici di pace, le magistrature ecc. e che ora vuole mettere, secondo un progetto partito tanti anni fa, anche gli istituti penali (noi, per intenderci)

    Io ho già un dominio in gestione che però riunisce solamente l'Emilia Romagna. Non nascondo che ci sono particolarmente legato perché è il primo dominio che ho curato e abbiamo attraversato assieme le varie ere da NT fino a 2008r2. Volgarmente 'usato' a beneficio del datore, per ottenere i vari gradi di MCSE e MCITP EA, per questo motivo, ha in essere tutti quei tecnicismi da esame che non sono mai riuscito ad implementare, almeno tutti assieme, in nessun altro dominio. Con tanti anni a disposizione ci sarebbe riuscito chiunque, intendiamoci, ma questo cambiamento prevederebbe il decommissionamento di ogni dominio per offrire come alternativa un dominio adatto solo all’autenticazione, intesa come solo accesso al proprio computer

    Il nuovo dominio nazionale non offrirebbe nulla se non l’autenticazione, i classici servizi exchange, lync, proxy. Le poche GPO attive sono relative al loopback, al WSUS e… penso poco altro.

    Io ci andrei certamente a perdere e l’idea di ‘migrare’ anche solo servizi semplici ma indispensabili come DFS-n/r e stampa mi mette in difficoltà senza un RODC in nessuna sede.

    Io sono stato chiamato in causa solo perché ho un po’ di esperienza grazie a questo dominio che gestisco, con la richiesta, ove possibile di mantenere i servizi in essere ed esportarli a livello Italia anziché regione, ma come mi giro mi giro non trovo soluzione.

    Quello che mi stupisce è che a lavorare nel team che deve ‘inglobarci’ ci sono dipendentienti microsoft, certamente anche loro certificati e che do per scontato essere molto più ferrati di me. Per questo motivo mi sento un po’ in difficoltà a controbattere, ma credo che l’unica cosa che mi rimanga da fare è presentare una relazione tecnica in cui dovrò mettere in evidenza errori progettuali- e che Dio me la mandi buona.

    Intanto grazie a tutti voi per il conforto tecnico che mi è stato di estremo aiuto morale.

    Marco


    mercoledì 18 marzo 2015 23:49