none
Security per gli oggetti nel tree di ActiveDirectory. RRS feed

  • Domanda

  •  Buongiorno.

     Mi è stato chiesto di revisionare la nostra AD (Windows 2012 R2) per ristrutturare la gestione degli accessi amministrativi e inserirvi una rigidissima policy di gestione.

     Per non dover intervenire troppo sui security group predefiniti ed evitare di incappare nelle grinfie di "ADMINSDHOLDER", in un  dominio di test ho creato dello O.U. dedicate contenenti i gruppi cui saranno definiti ruoli amministrativi e gli utenti che saranno membri di questi gruppi.

     Sulle O.U., sui gruppi e sugli account utente così creati ho poi agito sulla "Security" degli oggetti per rimuovere le grant non desiderate (ad esempio, non voglio che i membri del gruppo builtin "Account operators" possano gestire gli account che avranno un ruolo amministrativo quindi ho messo esplicitamente "Deny" le grant sull'oggetto "OU", "gruppo" e "utente") e sistemare l'ereditarietà delle grant in queste O.U.

     Sistemate tutte le cose come ritenevo corretto, eseguiti i test di "Effective Access" per verificare che tutto girasse come mi aspettavo, ho lasciato macerare per una notte e stamattina mi sono trovato di nuovo tutte le "security" reimpostate a default, come se fosse interventuto ADMINSDHOLDER a ripristinare il template predefinito. Avevo però capito che questo strumento agisse solo su oggetti ben definiti, in cui non dovrebbero rientrare gruppi e O.U. custom.

     Cosa ho sbagliato?

    martedì 6 novembre 2018 11:22

Tutte le risposte

  • Hai rimosso l'ereditarietà dei permessi del livello superiore?
    Le OU sono state create esternamente (cioè nella root del dominio) rispetto ai percorsi predefiniti Users, Computers, ecc... ?
    mercoledì 7 novembre 2018 16:04
    Moderatore
  •  Ciao, grazie per la risposta.

     Sì ma rileggendo meglio la documentazione ho scoperto che il meccanismo di funzionamento dell'oggetto AdminSDHolder è leggermente diverso da quello che avevo capito: Purtroppo il meccanismo opera ricorsivamente su tutti i membri dei gruppi protetti, esplodendo anche i nested group anche indipendentemente dal valore di adminCount presente tra gli attributi dell'oggetto gruppo/utente.

     Pertanto non è possibile impostare una security custom su gruppi che risultino "memberOf" di uno dei gruppi protetti da AdminSDHolder.

     Ci sono, temo, solo due alternative:

    1. Modificare il comportamento di "AdminSDHolder" per escludere dal controllo i gruppi protetti (molto male, temo);
    2. Riprodurre i permessi associati ai gruppi protetti (ad esempio "Server Operators") su un gruppo custom che non risulti coperto da "AdminSDHolder" (preferibile ma molto più complicato).




    martedì 13 novembre 2018 13:51