none
Quali sono gli svantaggi nell'abilitare le policy utente in tutto il dominio mediante loopback policy? RRS feed

  • Domanda

  • Ciao,
    io credo che applicare la loopback policy di default sia una scelta strategicamente non corretta, e debba essere applicata solamente in quei casi previsti da best practice tipo nel caso dei terminal server presenti in OU dedicate in rami che non contengono gli utenti.

    Senza rimandarmi ai documenti ufficiali, potreste elencare tutti e proprio tutti i punti negativi che vi vengono in mente nell'applicare la loopback indicriminatamente a tutti gli utent/pc/server membri del dominio?

    qualcosa tipo;

    1)Le GPO utente non seguono più effettivamente l'utente che si collega, ma vengono applicate direttamente all'accensione della macchina. Si perde quindi la certezza che a un determinato utente venga applicata una certa policy indipendentemente dal pc al quale si collega

    2) ecc ecc.

    grazie per la collaborazione

    mercoledì 2 marzo 2016 12:34

Risposte

  • non capisco una parte del tuo ragionamento. perchè parli di "applicazione indiscriminata della loopback policy" ?

    la base è che la loopback policy va applicata in quei casi particolari in cui voglio applicare delle user policies su un client a prescindere dall'account utente che effettua il logon quindi la loopback policy va applicata solo su una OU che contiene Computers sui quali voglio  forzare le user policies per tutti gli users.

    stabilito questo, per la regola LSDOU (ordine di applicazione delle policy) la loopback policy andrà ad aggiungersi a tutte le altre salvo quelle eventualmente in conflitto diretto.


    Edoardo Benussi
    Microsoft MVP - Enterprise Mobility
    edo[at]mvps[dot]org


    • Contrassegnato come risposta Marco Guerzoni martedì 15 marzo 2016 11:23
    mercoledì 2 marzo 2016 16:06
    Moderatore
  • Dico la mia,

    se devi gestire anche gli utenti ma non hai accesso alla OU che li contiene a qualcuno dovrebbe essere chiaro che esiste un problema di design della struttura, non dovrebbe essere necessario dimostrare che GPO loopback presenta degli svantaggi in certe condizioni.


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    • Contrassegnato come risposta Marco Guerzoni martedì 15 marzo 2016 11:24
    giovedì 3 marzo 2016 09:30
  • Secondo me è difficile dire se la progettazione delle OU a livello superiore è "giusta" o "sbagliata", bisogna capire come è stato deciso di organizzare la gestione IT a livello di gruppo. Nel tuo caso si sta implementando un modello basato sul tipo, forse proprio con lo scopo di standardizzare le policy utente e delegare determinate operazioni ad altri. Se ritieni che sia meglio optare per un modello di tipo geografico devi confrontarti con i tuoi colleghi sul punto di vista organizzativo (ovvero su cosa un amministratore locale deve o non deve fare) piuttosto che tecnico. L'utilizzo continuo di loopback policy in realtà è solo una forzatura per adattare la struttura ad un concetto amministrativo differente...

    Se non lo hai ancora letto ti consiglio questo interessante articolo che parla dei diversi approcci nella progettazione delle OU: https://technet.microsoft.com/it-it/magazine/2008.05.oudesign.aspx




    giovedì 3 marzo 2016 10:01
    Moderatore
  • Non è esattamente la stessa cosa...diciamo che in modalità loopback le impostazioni utente vengono applicate in base alla posizione del solo oggetto computer (ovvero per tutti gli utenti che eseguono l'accesso a quel determinato computer). Potresti riuscire comunque ad ottenere un risultato simile, ma non ha senso gestire l'infrastruttura in quel modo....
    mercoledì 9 marzo 2016 18:11
    Moderatore
  • Come dicevo potrebbe anche funzionare, ma è una forzatura e secondo me non è così che andrebbero utilizzate le policy in modalità loopback.

    Quindi se ti è stato detto esplicitamente di utilizzare le policy in loopback per poter gestire gli utenti allora mi associo a quello che dicevano precedentemente gli altri: la scelta del modello potrebbe essere effettivamente non corretta.

    E' l'infrastruttura che dovrebbe adattarsi allo schema di gestione IT, non il contrario.

    • Contrassegnato come risposta Marco Guerzoni martedì 15 marzo 2016 11:25
    giovedì 10 marzo 2016 11:54
    Moderatore

Tutte le risposte

  • non capisco una parte del tuo ragionamento. perchè parli di "applicazione indiscriminata della loopback policy" ?

    la base è che la loopback policy va applicata in quei casi particolari in cui voglio applicare delle user policies su un client a prescindere dall'account utente che effettua il logon quindi la loopback policy va applicata solo su una OU che contiene Computers sui quali voglio  forzare le user policies per tutti gli users.

    stabilito questo, per la regola LSDOU (ordine di applicazione delle policy) la loopback policy andrà ad aggiungersi a tutte le altre salvo quelle eventualmente in conflitto diretto.


    Edoardo Benussi
    Microsoft MVP - Enterprise Mobility
    edo[at]mvps[dot]org


    • Contrassegnato come risposta Marco Guerzoni martedì 15 marzo 2016 11:23
    mercoledì 2 marzo 2016 16:06
    Moderatore
  • Volevo solo un aiuto ad elencare i lati negativi di una progettazione del genere, nella quale non posso applicare policy utente se non utilizzando la loopback.

    Nella OU che mi viene assegnata ci saranno non meno di 40000 computer stando agli ultimi rilevamenti, mentre gli utenti saranno tutti in una unica OU superiore in cui non posso fare nulla.

    Dominio

    OU UTENTI

    OU COMPUTER_DIPARTIMENTO1

    OU COMPUTER_DIPARTIMENTO2

    OU COMPUTER_MIODIPARTIMENTO

    Nella mia OU posso creare ulteriori OU ed assegnare diritti e policy per le varie città e sedi

    Io mirerei ad ottenere la possibilità di avere i miei utenti nella mia OU, che a livello progettuale mi sembra più adeguato per meglio andare incontro alle esigenze delle varie sedi e degli utenti che girano da una sede all'altra. Per avere più autonomia vorrei anche richiedere un mio sottodominio invece di una OU, e questo è un po' più difficile da giustificare progettualmente, anche se, per come sarà vasto il dominio assegnato ad un unico CED, temo avremo grossi rallentamenti nelle operazioni che certamente mi serviranno(tipo creazione di un DFS-N, replica ecc)

    mercoledì 2 marzo 2016 21:11
  • Dico la mia,

    se devi gestire anche gli utenti ma non hai accesso alla OU che li contiene a qualcuno dovrebbe essere chiaro che esiste un problema di design della struttura, non dovrebbe essere necessario dimostrare che GPO loopback presenta degli svantaggi in certe condizioni.


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    • Contrassegnato come risposta Marco Guerzoni martedì 15 marzo 2016 11:24
    giovedì 3 marzo 2016 09:30
  • Secondo me è difficile dire se la progettazione delle OU a livello superiore è "giusta" o "sbagliata", bisogna capire come è stato deciso di organizzare la gestione IT a livello di gruppo. Nel tuo caso si sta implementando un modello basato sul tipo, forse proprio con lo scopo di standardizzare le policy utente e delegare determinate operazioni ad altri. Se ritieni che sia meglio optare per un modello di tipo geografico devi confrontarti con i tuoi colleghi sul punto di vista organizzativo (ovvero su cosa un amministratore locale deve o non deve fare) piuttosto che tecnico. L'utilizzo continuo di loopback policy in realtà è solo una forzatura per adattare la struttura ad un concetto amministrativo differente...

    Se non lo hai ancora letto ti consiglio questo interessante articolo che parla dei diversi approcci nella progettazione delle OU: https://technet.microsoft.com/it-it/magazine/2008.05.oudesign.aspx




    giovedì 3 marzo 2016 10:01
    Moderatore
  • documento interessante e chiaro.

    mi potresti confermare o smentire che mediante l'applicazione delle policy utente in modalità loopback, posso ottenere lo stesso risultato che applicandole nel modo tradizionale(anche se con metodo diverso intendo)?


    mercoledì 9 marzo 2016 12:00
  • Non è esattamente la stessa cosa...diciamo che in modalità loopback le impostazioni utente vengono applicate in base alla posizione del solo oggetto computer (ovvero per tutti gli utenti che eseguono l'accesso a quel determinato computer). Potresti riuscire comunque ad ottenere un risultato simile, ma non ha senso gestire l'infrastruttura in quel modo....
    mercoledì 9 marzo 2016 18:11
    Moderatore
  • quel modo, come dici tu, è il caso di specie dei terminal server contenuti in OU separate...

    Quello che mi è stato detto è che per gestire più di centomila utenti - non tutti useranno postazioni ma è pur sempre un numero rilevante -, potrò usare la loopback, dove quando vorrò applicarla per singolo utente, dovrò filtrare mettendo domain computers e nome utente/gruppo a quale applicarla.

    Credevo di essere preparato, nel senso che riesco a stabilire (mediante buonsenso, e mediante preparazione per varie certificazioni conseguite) quale sia la strategia giusta da proporre, ma qui mi trovo in difficoltà perché per quanto mi sforzi, si limitano a farmi vedere che la policy, tramite filtri viene ugualmente applicata.

    Dubito che sia stata fatto uno studio accurato anche del modello da usare nella creazione delle OU. L'unica tipicizzazione la vedo per i server fortunatamente. Per gli utenti si rifà al modello piano. Credo di avere capito perché gli utenti vengono creati da FIM solo in quella OU.

    La cosa allarmante e per la quale spero di riuscire a farmi sentire è che tra le policy enforced ci sono cose da panico;

    Disabilitazione del firewall in una intranet sprovvista di firewall hardware tra le centinaia di sedi;

    Disabilitazione del UAC

    Obbligo ad usare il loro WSUS; che di per se non sarebbe una cattiva idea, se non per il fatto che non distribuisce le SP per windows e office perché sono troppo pesanti

    Praticamente stanno preparando una botnet in piena regola :(

    Più tanti altri errori grossolani che comporteranno però più lavoro al ced centrale e quindi non mi tangono

    In pratica tutti i dominii e sottodominii preesistenti dovranno essere migrati a questo unico dominio - e fin qui sarei d'accordo... peccato che molti dominii, rispondo alle esigenze dei dipendenti in maniera più efficace, senza bisogno di abbassare le sicurezze, anzi, adottando NAP e tanti altri begli accorgimenti, e sono certamente studiati meglio nel rispetto delle best practice - o per lo meno/almeno c'ho provato...

    è un annetto che per lentezze burocratiche siamo riusciti a non migrare, ma prima o poi mi toccherà, anche perché ne non migri - niente benefici della software assurance, niente licenze VDI ecc...


    mercoledì 9 marzo 2016 22:44
  • Come dicevo potrebbe anche funzionare, ma è una forzatura e secondo me non è così che andrebbero utilizzate le policy in modalità loopback.

    Quindi se ti è stato detto esplicitamente di utilizzare le policy in loopback per poter gestire gli utenti allora mi associo a quello che dicevano precedentemente gli altri: la scelta del modello potrebbe essere effettivamente non corretta.

    E' l'infrastruttura che dovrebbe adattarsi allo schema di gestione IT, non il contrario.

    • Contrassegnato come risposta Marco Guerzoni martedì 15 marzo 2016 11:25
    giovedì 10 marzo 2016 11:54
    Moderatore
  • sempre in argomento, cioè per capire le cose che non sono desiderabili;

    queste due policy equivalgono a disabilitare UAC sui desktop abbassando la sicurezza?

    Controllo account utente: comportamento della richiesta di elevazione dei privilegi per gli amministratori in modalità Approvazione amministratore Esegui con privilegi elevati senza chiedere conferma

    Controllo account utente: rileva installazione applicazioni e richiedi elevazione

    Disabilitato

    giovedì 10 marzo 2016 15:41
  • La prima policy secondo me potrebbe comportare una riduzione della sicurezza.

    Infatti in questa pagina:

    https://technet.microsoft.com/it-it/library/dd851609.aspx

    Viene specificato che la voce "Esegui con privilegi elevati senza chiedere conferma" andrebbe utilizzata solo "negli ambienti maggiormente vincolati".

    La seconda invece è standard per gli ambienti di dominio (ad esempio se si utilizzano installazioni tramite Group policy o System Center non è necessario che vengano richieste credenziali più elevate):

    https://technet.microsoft.com/en-us/library/dd851376.aspx

    giovedì 10 marzo 2016 19:35
    Moderatore
  • sì,

    da quello che ho potuto verificare l'UAC è abilitato per gli utenti e disabilitato per gli amministratori.

    In un dominio così vasto per me è deleterio come standard.

    grazie per i suggerimenti. apro un'altra discussione per FIM

    martedì 15 marzo 2016 11:22