Come rimuovo un criterio di gruppo senza accesso al dominio (controller)?

8

Ho un controller di dominio (WS2012-R2) e un set di server (WS2012-R2) che sono membri del dominio. Ho accidentalmente aggiunto un gruppo a cui tutti gli amministratori fanno parte dei Criteri di gruppo "Nega accesso a livello locale", "Nega accesso come servizio", "Nega accesso remoto" e "Nega accesso alla rete". Ciò ha comportato il blocco di me e di tutti gli altri amministratori (incluso l'account integrato) dal controller di dominio.

C'è un modo per riottenere l'accesso al server rimuovendo l'oggetto Criteri di gruppo o rimuovendo un account amministratore dal gruppo che è stato negato?

active-directory group-policy windows-server-2012-r2

— shagrinar
fonte

3

Solo un pensiero, probabilmente accademico, ma come si fa per sbaglio ?

— Colyn1337,

@ Colyn1337 Probabilmente non è casualmente ma non è ben considerato. Gli account amministratore sono membri di un gruppo di cui ogni dipendente è membro e ho aggiunto questo gruppo ai suddetti oggetti Criteri di gruppo che ha comportato il blocco di ogni account. Non mi è venuto in mente che esiste effettivamente la possibilità di bloccare l'account amministratore incorporato ma eccoci qui ...

— shagrinar,

Questa politica si applica anche ad altri controller di dominio o solo a questo? (Puoi semplicemente costruire un nuovo DC e impadronirti con forza di tutti i ruoli che questo ha?)

— Katherine Villyard,

6

Mi vengono in mente due pensieri.

È possibile, presumibilmente, utilizzare un CD di avvio per accedere al controller di dominio mentre è offline e modificare o eliminare manualmente l'oggetto Criteri di gruppo offensivo: gli oggetti Criteri di gruppo di un dominio esistono nella SYSVOLcartella del file system sui controller di dominio e vengono applicati come impostazioni di registro, entrambi che sono accessibili da un CD di avvio; tuttavia, questo potrebbe essere annullato dalla replica o causerebbe errori di replica del dominio non appena il controller di dominio su cui lo hai fatto si è collegato agli altri controller di dominio nel dominio. (Sto assumendo qui che tu abbia più di un controller di dominio nel tuo dominio, come dovresti ... se ne avessi solo uno, questo non sarebbe un cattivo approccio).

L'altro approccio che viene in mente è quello di accedere alla modalità di ripristino dei servizi di directory ed eseguire un ripristino autorevole da un backup precedente a questo oggetto Criteri di gruppo. (E anche questo si basa sul presupposto che tu stia facendo come dovresti fare e abbia backup da cui ripristinare.)

— HopelessN00b
fonte

Se hai un piccolo numero di DC (2,3,4?) E riesci a perdere tutti tranne uno, la prima opzione potrebbe funzionare. Spegni, ritirati, distruggi tutti i DC tranne uno, jurry rig quello, cogli i ruoli di FSMO. Se vai così lontano, costruisci alcuni nuovi DC per sostituire quelli che dovevi distruggere.

— Clayton,

4

In realtà non ho provato questo. (Mi dispiace.) Suppongo anche che RSAT non funzionerà a causa di "nega l'accesso remoto / alla rete". (Se non l'hai provato, vale la pena provare, ma non sono ottimista.)

Forse potresti creare un nuovo account amministratore con un CD di avvio di Hiren e utilizzare quell'account per modificare la politica.

— Katherine Villyard
fonte

Grazie per la risposta, purtroppo non riesco a eseguire il CD di avvio di Hiren nella mia macchina virtuale in quanto è una macchina Hyper-V di seconda generazione. Esiste forse una versione alternativa del CD di avvio di Hiren?

— shagrinar,

ADUC utilizza le query LDAP, quindi non dovrebbe essere bloccato dalle restrizioni "nega accesso alla rete" ... ma dovresti effettivamente avviarlo utilizzando un account amministratore di dominio, che puoi fare solo se hai almeno un computer su cui l'oggetto Criteri di gruppo offensivo non viene applicato. Tuttavia, PowerShell potrebbe invece essere in grado di aiutare (vedere la mia risposta per i dettagli).

— Massimo

3

C'è un pensiero su questa risposta. Dato che abbiamo a che fare con un controller di dominio, che non ha account locali ... come si potrebbe creare un nuovo account amministratore tramite un CD di avvio su un controller di dominio? Sto disegnando uno spazio vuoto. Ho usato questa tecnica per ripristinare la password dell'amministratore / DSRM sui controller di dominio prima, ma dubito che sia possibile creare un nuovo utente con esso. Mi sto perdendo qualcosa?

— HopelessN00b

1

@KatherineVillyard FalconFour è una versione più avanzata / moderna / utile di HBCD ... Basta

@shagrinar Se riesci ad avviare PE - ho un'opzione PXE di PE solo per le emergenze e la diagnostica - anche questo potrebbe funzionare, anche se non avrai MMC senza contorsioni. Ma prova prima RSAT se non l'hai fatto. È l'opzione meno dolorosa.

— Katherine Villyard,

3

Dove viene applicata la politica di gruppo? Solo ai controller di dominio o all'intero dominio?

Se viene applicato solo ai controller di dominio, puoi comunque accedere a un altro computer membro utilizzando un account amministratore di dominio; è quindi possibile abilitare la console di gestione dei criteri di gruppo e / o tutti gli altri strumenti di amministrazione AD se ci si trova su un sistema operativo del server, oppure installare RSAT e fare lo stesso se si tratta di una workstation; con questi strumenti, sarai in grado di modificare l'oggetto Criteri di gruppo offensivo, o almeno utenti e gruppi (la console ADUC utilizza query LDAP, quindi non è soggetta a restrizioni di accesso).

Se la politica viene invece applicata all'intero dominio e non è possibile accedere effettivamente da nessuna parte utilizzando un account di amministratore di dominio, una possibile soluzione alternativa potrebbe essere l'utilizzo del modulo PowerShell Active Directory : quasi tutti i cmdlet hanno un -credentialparametro che consente di specificare le credenziali da utilizzare per eseguire il comando, anche quando PowerShell è effettivamente in esecuzione con un altro account utente ; questo include Remove-ADGroupMember . Pertanto, una possibile soluzione sarebbe:

Accedi a qualsiasi computer membro utilizzando qualsiasi account utente disponibile.
Assicurarsi che gli strumenti di amministrazione AD siano installati sul sistema (abilitarli su un server o installare RSAT su una workstation).
Avvia PowerShell.
Import-Module ActiveDirectory
$admincreds = Get-Credential (questo apre una finestra in cui è necessario inserire le credenziali per un account amministratore di dominio)
Remove-ADGroupMember <GroupName> <UserName> -Credentials $admincreds

Se funziona, <UserName>verrà rimosso da <GroupName>, e quindi la politica offensiva non lo bloccherà più.

— Massimo
fonte

4

Non si Deny network accessapplica all'accesso tramite RSAT (e PowerShell)? Non che sto per testare, o che abbia esperienza nel bloccare me stesso dai miei controller di dominio su cui ripiegare, ma credo che non funzionerà per questo motivo.

— HopelessN00b

ADUC utilizza query LDAP, questo dovrebbe essere al di fuori dell'area limitata da "negare l'accesso alla rete"; il problema è nel farlo funzionare usando un account amministratore di dominio. Non sono sicuro di PowerShell, ma non è necessario che sia effettivamente in esecuzione con lo stesso account utente utilizzato per eseguire il comando, quindi vale sicuramente la pena provare.

— Massimo

In modalità di ripristino degli annunci se cancella la cartella gpo o aggiunge un negare ntfs su di essa, sarebbe buono.

— yagmoth555

@Massimo Come ho detto, non posso dirlo con certezza, ma la documentazione su questo particolare GPO afferma, in Best practice: "Poiché tutti i programmi di Servizi di dominio Active Directory utilizzano un accesso di rete per l'accesso, prestare attenzione quando si assegna questo diritto utente sui controller di dominio ". Mi sembra un avvertimento che questa particolare configurazione si applica a "tutti i programmi di Servizi di dominio Active Directory".

— HopelessN00b

3

Ho provato entrambi i precedenti ma senza successo. L'accesso LDAP è disabilitato.

— Shagrinar,

3

Avvia il controller di dominio in modalità di ripristino della directory attiva, con l'account impostato al momento della creazione del dominio. (È semplicemente un account amministratore locale sul controller di dominio, denominato Administratore la password è stata impostata in dcpromo.)

Da lì, rimuovere tutte le autorizzazioni NTFS sul SYSVOLvolume, nella cartella ID oggetto Criteri di gruppo. (Controllare l'ultima cartella modificata per trovare l'ultimo oggetto Criteri di gruppo modificato).

In quella modalità, il database di Active Directory non è caricato, ma si ha accesso al filesystem.

Se non funziona nulla, in quella modalità puoi provare un gpofixcomando, ma tieni presente che rimuoverà TUTTI GPO.

— yagmoth555
fonte

Esiste un modo per eseguire il backup di tutti gli oggetti Criteri di gruppo in modo da poterli riposizionare (senza il GPO di blocco)?

— Shagrinar,

2

@shagrinar No ... ma rimuovere solo tutte le autorizzazioni NTFS sulla cartella GPO potrebbe essere migliore in quanto bloccherà l'oggetto Criteri di gruppo da applicare e farà sì che il tuo DC visualizzi che l'oggetto Criteri di gruppo è danneggiato nella MMC dell'oggetto Criteri di gruppo.

— yagmoth555

La rimozione di tutte le autorizzazioni NTFS su SYSVOL non ha alcun effetto, come la rimozione di tutti i file dalla directory. L'inserimento di DSRM è stato possibile e ho potuto accedere con l'account ma l'esecuzione di dcgpofix mi ha dato un messaggio di errore che diceva che dovevo accedere con un account membro di dominio ...

— shagrinar

Le impostazioni gpo sono ancora applicate, puoi cancellare la cache mentre sei in modalità DSRM? (consultare la posizione del registro; support.microsoft.com/en-us/kb/201453 )

— yagmoth555

Ho rimosso tutto dalla storia , purtroppo non ho avuto successo ad accedere.

— Shagrinar

2

Quando il dominio è stato originariamente creato, è stato creato un account "god". Scopri cos'è, la sua password e dovresti essere in grado di accedere al controller di dominio che ospita il catalogo globale. Da lì dovresti essere in grado di annullare ciò che hai fatto e dargli il tempo di propagarsi.

Se fallisce, ci sono alcune tecniche di hacker che puoi usare, ma non sarebbe appropriato per me dirlo qui. Contatta un esperto di sicurezza locale poiché di solito sono al passo con le tecniche degli hacker e possono aiutarti a riconquistare il dominio.

Naturalmente, se si tratta di pochi server e non è fondamentale, è possibile anche cancellare e ricominciare.

— Colyn1337
fonte

Puoi darmi un suggerimento su come scoprire quale account potrebbe essere? Conosco l'account dell'amministratore locale del controller di dominio, che si è trasformato in un account di dominio quando ho installato Active Directory, ma anche questo è interessato. Pulire i server sarebbe la mia ultima opzione da considerare.

— shagrinar,

Quando si crea un nuovo dominio, tramite script o procedura guidata, è necessario creare un singolo account principale e assegnargli una password. In genere viene utilizzato solo in tempi di ripristino di emergenza (come ora) e solo la persona che ha creato il dominio lo saprebbe. Se non sai chi ha creato il dominio, verifica con il tuo direttore, è probabile che a qualcuno nella catena di gestione siano state fornite queste informazioni.

— Colyn1337,

1

L'account di cui si sta parlando è l'account della modalità di ripristino dei servizi di directory; viene utilizzato solo per eseguire la manutenzione su controller di dominio offline, ma in realtà non è un amministratore di dominio; sarebbe completamente inutile in questo caso, a meno che non si desideri ripristinare AD da backup.

— Massimo

@Massimo Penso che le tue informazioni siano un po 'vecchie ... "puoi configurare un controller di dominio in modo da poter accedere ad esso con l'account amministratore DSRM se il controller di dominio è stato avviato normalmente ma il servizio Servizi di dominio Active Directory è stato arrestato per qualche ragione." technet.microsoft.com/en-us/library/cc816897(v=ws.10).aspx

— Colyn1337

1

@Massimo Sarebbe possibile rimuovere l'oggetto Criteri di gruppo dalla sua posizione nella cartella sysvol sul file system, nonché modificare il registro per modificare le impostazioni usando questa tecnica. Suppongo che sia ciò che viene suggerito in questa risposta.

— HopelessN00b

1

Innanzitutto, chiudere tutti i controller di dominio. In questo modo si eviteranno bizzarri problemi di replica.

Il primo passo è rimuovere l'impostazione di Criteri di gruppo errata. Le assegnazioni di privilegi sono archiviate nel GptTmpl.inffile in MACHINE\Microsoft\Windows NT\SecEditciascuna cartella dei criteri. Saprai di avere la politica giusta quando quel .inffile contiene una riga per SeDenyNetworkLogonRight, SeDenyInteractiveLogonRighteccetera. Elimina tuttoSeDeny...Right righe da esso.

Windows non applicherà le nuove impostazioni a meno che non rilevi che l'oggetto Criteri di gruppo è cambiato, cosa che determina consultando il versionNumber attributo su un oggetto Active Directory. Non proviamo a modificare AD offline. Rimuoveremo invece le impostazioni errate dal registro manualmente.

Montare l' \Windows\System32\config\SECURITYhive del controller di dominio nel registro di un altro sistema Windows con reg load. Apri l'Editor del Registro di sistema e vai Policy\Accountssotto l'hive montato. (Potrebbe essere necessario essere in esecuzione regeditcome SISTEMA per farlo funzionare. PsExec può farlo.) Ogni sottochiave corrisponde a un utente o gruppo, e la ActSysAcsottochiave di ognuna di esse detiene i "diritti". (I "privilegi" sono tutti nella Privilgssottochiave.) Trova quello con un ActSysAcvalore di C0 03 00 00, che corrisponde ai quattro diritti che hai negato. Elimina ActSysAco modifica il suo valore in 00 00 00 00. Chiudi l'Editor del Registro di sistema e smonta l'hive conreg unload .

Avvia il controller di dominio che hai modificato. Dovresti essere in grado di accedere ora. Utilizzare la Console di gestione dei criteri di gruppo per apportare qualsiasi modifica (non importa quanto banale) alle pertinenti politiche locali dell'oggetto Criteri di gruppo. Ciò aumenterà il numero di versione dell'oggetto Criteri di gruppo.

Avviare gli altri controller di dominio e lasciare replicare le modifiche.

— Ben N
fonte

Sembra molto promettente, purtroppo non posso confermare che funzioni. Ormai sto ricostruendo tutto. Se qualcuno può confermare che funziona, sono più che felice di contrassegnarlo come risposta!

— Shagrinar,

0

Puoi provare ad aprire in explorer \\ domain.controler \ c $ \ windows \ sysvol \ sysvol \ domain.local \ polices (Hai ancora accesso)

Lì troverai tutte le politiche. Sposta tutto questo dir in una destinazione temporanea e prova a riavviare il PC. Aiuterà.

— kgimpel
fonte

Il controller di dominio si chiama asgard e il dominio si chiama yggdrasil, quindi ho inserito: \\ asgard \ c $ \ windows \ sysvol \ sysvol \ yggdrasil \ politiche che ha provocato un messaggio di errore che mi dice che Windows non può accedere alla directory. Non sto provando ad accedervi dall'account dell'amministratore locale di un computer che si trova all'interno del dominio ma dal mio laptop privato - richiede ancora un accesso.

— shagrinar,

Controlla la directory, non sono sicuro dopo sysvol. Puoi accedere a \\\ domaincontroller \ c $ usando le credenziali di dominio? Oppure puoi provare a usare l'amministratore locale come "asgard \ admin" o "asgard \ tor" :)

— kgimpel

Ho provato questo inutilmente, ma poiché è una macchina virtuale in cui è in esecuzione il controller di dominio, ho appena montato il disco rigido virtuale. Ho trovato la directory C: \ sysvol \ sysvol \ fqdn_of_domain , il tentativo di accedervi ha provocato un errore (è una sorta di link simbolico?). Ho trovato un'altra cartella C: \ sysvol \ domain che contiene script e criteri. Ho spostato tutto da esso, ho smontato il disco rigido virtuale e acceso la macchina. Purtroppo non c'è cambiamento. Dove conduce questo link? Altre opzioni che posso prendere in considerazione quando si ha accesso al disco rigido?

— shagrinar,

3

@shagrinar Il riferimento diretto al controller di dominio tramite una condivisione SMB, consigliato da questa risposta, non funzionerà perché hai negato l'accesso alla rete da parte dell'oggetto Criteri di gruppo. Potresti essere in grado di fare \\domainname\sysvol\ e accedere alle politiche in quel modo, ma non avrei le mie speranze. La modifica di sysvol richiede i privilegi di amministratore di dominio e, se hai bloccato tutti gli amministratori di dominio, non sarai in grado di accedervi con i privilegi richiesti per farlo.

— HopelessN00b,

All'interno di SYSVOL \ Dominio \ Politiche È possibile ordinare, trovare e spostare solo le directory create il giorno scorso. Uno di questi sarà la tua politica di "problema".

— kgimpel,