Comment supprimer une stratégie de groupe sans accès au domaine (contrôleur)?

8

J'ai un contrôleur de domaine (WS2012-R2) et un ensemble de serveurs (WS2012-R2) qui sont membres du domaine. J'ai accidentellement ajouté un groupe dont tous les administrateurs sont membres à la stratégie de groupe "Refuser l'accès à la connexion localement", "Refuser la connexion en tant que service", "Refuser l'accès à distance" et "Refuser l'accès au réseau". Cela a entraîné le verrouillage de moi et de tous les autres administrateurs (même le compte intégré) du contrôleur de domaine.

Existe-t-il un moyen de retrouver l'accès au serveur en supprimant l'objet de stratégie de groupe ou en supprimant un compte administrateur du groupe qui a été refusé?

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

— shagrinar
source

3

Juste une pensée, probablement académique, mais comment faites-vous cela accidentellement ?

— Colyn1337

@ Colyn1337 Ce n'est probablement pas accidentel mais pas bien considéré. Les comptes d'administrateur sont membres d'un groupe dont chaque employé est membre et j'ai ajouté ce groupe aux GPO mentionnés ci-dessus, ce qui a entraîné le verrouillage de chaque compte. Je ne me suis pas dit qu'il y avait en fait la possibilité de verrouiller le compte administrateur intégré mais nous y sommes ...

— shagrinar

Cette politique s'applique-t-elle également à d'autres contrôleurs de domaine ou seulement à celui-ci? (Pouvez-vous simplement construire un nouveau DC et saisir de force tous les rôles que celui-ci a?)

— Katherine Villyard

6

Deux pensées me viennent à l'esprit.

Vous pouvez, en théorie, utiliser un CD de démarrage pour accéder au contrôleur de domaine lorsqu'il est hors ligne et modifier ou supprimer manuellement l'objet de stratégie de groupe incriminé - les objets de stratégie de groupe d'un domaine existent sous le SYSVOLdossier dans le système de fichiers sur les contrôleurs de domaine, et sont appliqués en tant que paramètres de registre, les deux de qui sont accessibles à partir d'un CD de démarrage - cependant, cela serait annulé par la réplication ou entraînerait des erreurs de réplication de domaine dès que le contrôleur de domaine sur lequel vous l'avez fait s'est connecté aux autres contrôleurs de domaine du domaine. (Je fais l'hypothèse ici que vous avez plus d'un contrôleur de domaine dans votre domaine, comme vous devriez ... si vous n'en avez qu'un, ce ne serait pas une mauvaise approche).

L'autre approche qui vient à l'esprit consiste à passer en mode de restauration des services d'annuaire et à effectuer une restauration faisant autorité à partir d'une sauvegarde antérieure à cet objet de stratégie de groupe. (Et cela aussi, repose sur l'hypothèse que vous faites comme vous devriez le faire et que vous avez des sauvegardes à restaurer.)

— HopelessN00b
source

Si vous avez un petit nombre de DC (2,3,4?) Et pouvez réussir à en perdre tous sauf un, la première option peut fonctionner. Arrêtez, retirez-vous, détruisez tous sauf un DC, jurry rig celui-là, saisissez les rôles FSMO. Si vous arrivez jusque-là, construisez de nouveaux DC pour remplacer ceux que vous avez dû détruire.

— Clayton

4

Je n'ai pas vraiment essayé ça. (Désolé.) Je suppose également que RSAT ne fonctionnera pas en raison de "refuser l'accès distant / réseau". (Si vous n'avez pas essayé cela, ça vaut le coup, mais je ne suis pas optimiste.)

Vous pourriez peut-être créer un nouveau compte administrateur avec un CD de démarrage Hiren et utiliser ce compte pour modifier la politique.

— Katherine Villyard
source

Merci pour votre réponse, malheureusement, je ne peux pas exécuter le CD Hiren's Boot sur ma machine virtuelle car il s'agit d'une machine Hyper-V de génération 2. Existe-t-il peut-être une version alternative du CD de démarrage d'Hiren?

— shagrinar

ADUC utilise des requêtes LDAP, donc il ne devrait pas être bloqué par des restrictions de "refus d'accès au réseau" ... mais vous devrez le lancer en utilisant un compte d'administrateur de domaine, ce que vous ne pouvez faire que si vous avez au moins une machine sur laquelle l'objet de stratégie de groupe incriminé n'est pas appliqué. Cependant, PowerShell pourrait plutôt vous aider (voir ma réponse pour plus de détails).

— Massimo

3

Une réflexion se produit sur cette réponse. Puisque nous avons affaire à un contrôleur de domaine, qui n'a pas de comptes locaux ... comment créer un nouveau compte administrateur via un CD de démarrage sur un contrôleur de domaine? Je dessine un blanc. J'ai déjà utilisé cette technique pour réinitialiser le mot de passe Administrateur / DSRM sur les contrôleurs de domaine, mais je doute qu'il soit possible de créer un nouvel utilisateur avec. Suis-je en train de manquer quelque chose?

— HopelessN00b

1

@KatherineVillyard FalconFour est une version plus avancée / moderne / utile de HBCD ... Just sayin '

@shagrinar Si vous pouvez démarrer en PE - j'ai une option PXE de PE uniquement pour les urgences et les diagnostics - cela pourrait aussi fonctionner, bien que vous n'ayez pas de MMC sans contorsions. Mais essayez d'abord RSAT si vous ne l'avez pas fait. C'est l'option la moins douloureuse.

— Katherine Villyard

3

Où la stratégie de groupe est-elle appliquée? Uniquement aux DC ou à l'ensemble du domaine?

S'il n'est appliqué qu'aux contrôleurs de domaine, vous pouvez toujours vous connecter à un autre ordinateur membre à l'aide d'un compte d'administrateur de domaine; vous pouvez ensuite activer la console de gestion des stratégies de groupe et / ou tous les autres outils d'administration AD si vous êtes sur un système d'exploitation serveur, ou installer RSAT et faire de même s'il s'agit d'un poste de travail; avec ces outils, vous pourrez modifier le GPO incriminé, ou au moins les utilisateurs et les groupes (la console ADUC utilise des requêtes LDAP, elle n'est donc pas soumise à des restrictions de connexion).

Si la stratégie est plutôt appliquée à l'ensemble du domaine et que vous ne pouvez pas réellement vous connecter n'importe où à l' aide d'un compte d'administrateur de domaine, une solution de contournement possible pourrait être d'utiliser le module PowerShell Active Directory : presque toutes les applets de commande ont un -credentialparamètre qui vous permet de spécifier les informations d'identification à utiliser pour exécuter la commande, même lorsque PowerShell s'exécute réellement sous un autre compte d'utilisateur ; cela inclut Remove-ADGroupMember . Ainsi, une solution possible serait:

Connectez-vous à n'importe quel ordinateur membre en utilisant n'importe quel compte d'utilisateur disponible.
Assurez-vous que les outils d'administration AD sont installés sur le système (activez-les sur un serveur ou installez RSAT sur un poste de travail).
Lancez PowerShell.
Import-Module ActiveDirectory
$admincreds = Get-Credential (cela ouvre une fenêtre dans laquelle vous devez saisir les informations d'identification d'un compte d'administrateur de domaine)
Remove-ADGroupMember <GroupName> <UserName> -Credentials $admincreds

Si cela fonctionne, <UserName>sera supprimé de <GroupName>, et donc la politique incriminée ne le bloquera plus.

— Massimo
source

4

Ne Deny network accesss'applique pas à l'accès via RSAT (et PowerShell)? Non pas que je sois sur le point de tester, ou que j'ai de l'expérience en m'isolant de mes contrôleurs de domaine pour retomber, mais je pense que cela ne fonctionnera pas pour cette raison.

— HopelessN00b

ADUC utilise des requêtes LDAP, cela devrait être en dehors de la zone restreinte par "refuser l'accès au réseau"; le problème est de le faire fonctionner à l'aide d'un compte d'administrateur de domaine. Je ne suis pas sûr de PowerShell, mais il n'a pas besoin d'être exécuté sous le même compte d'utilisateur que celui que vous utilisez pour exécuter la commande, donc ça vaut vraiment le coup.

— Massimo

En mode de restauration publicitaire, s'il efface le dossier gpo ou ajoute un refus ntfs dessus, ce serait bien.

— yagmoth555

@Massimo Comme je l'ai dit, je ne peux pas le dire avec certitude, mais la documentation sur cet objet de stratégie de groupe particulier indique, sous Meilleures pratiques: "Parce que tous les programmes des services de domaine Active Directory utilisent une connexion réseau pour l'accès, soyez prudent lorsque vous attribuez ce droit d'utilisateur sur les contrôleurs de domaine. " Cela me semble être un avertissement que cette configuration particulière s'applique à «tous les programmes des services de domaine Active Directory».

— HopelessN00b

3

J'ai essayé les deux ci-dessus mais sans succès. L'accès LDAP est désactivé.

— shagrinar

3

Démarrez votre contrôleur de domaine en mode de restauration Active Directory, avec le compte que vous avez configuré lors de la création de votre domaine. (Il s'agit simplement d'un compte d'administrateur local sur le DC, nommé Administrator, et le mot de passe a été configuré dans dcpromo.)

À partir de là, supprimez toutes les autorisations NTFS sur votre SYSVOLvolume, dans le dossier GPO ID. (Vérifiez le dernier dossier modifié pour trouver le dernier objet de stratégie de groupe modifié).

Dans ce mode, la base de données Active Directory n'est pas chargée, mais vous avez accès au système de fichiers.

Si rien ne fonctionne, dans ce mode, vous pouvez essayer une gpofixcommande, mais sachez qu'elle supprimera TOUS les GPO.

— yagmoth555
source

Existe-t-il un moyen de sauvegarder tous les GPO pour que je puisse les remettre à nouveau (sans le GPO de verrouillage)?

— shagrinar

2

@shagrinar Non ... mais la suppression de toutes les autorisations NTFS sur le dossier GPO pourrait être meilleure car cela bloquerait le GPO à appliquer et ne ferait que montrer à votre contrôleur de domaine que votre GPO est corrompu dans la MMC du GPO.

— yagmoth555

La suppression de toutes les autorisations NTFS sur SYSVOL n'a aucun effet, tout comme la suppression de tous les fichiers du répertoire. La saisie de DSRM était possible et je pouvais me connecter avec le compte mais l'exécution de dcgpofix m'a donné un message d'erreur disant que je dois être connecté avec un compte membre de domaine ...

— shagrinar

Les paramètres gpo sont toujours appliqués, pouvez-vous effacer le cache en mode DSRM? (voir là pour l'emplacement du registre; support.microsoft.com/en-us/kb/201453 )

— yagmoth555

J'ai tout supprimé dans l' Histoire , malheureusement aucun succès pour se connecter.

— shagrinar

2

Lorsque le domaine a été créé à l'origine, un compte "dieu" a été créé. Découvrez ce que c'était, son mot de passe et vous devriez pouvoir vous connecter au DC hébergeant le catalogue global. À partir de là, vous devriez pouvoir annuler ce que vous avez fait et lui donner le temps de se propager.

Si cela échoue, vous pouvez utiliser certaines techniques de piratage, mais il ne serait pas approprié pour moi de relayer cela ici. Contactez un expert en sécurité local car ils sont généralement au courant des techniques de piratage et peuvent vous aider à retrouver le domaine.

Bien sûr, s'il ne s'agit que de quelques serveurs et que ce n'est pas critique, vous pouvez tout aussi bien effacer et recommencer.

— Colyn1337
source

Pouvez-vous me donner un indice sur la façon de savoir de quel compte il s'agit? Je connais le compte d'administrateur local du contrôleur de domaine, qui s'est transformé en compte de domaine lorsque j'ai installé Active Directory, mais cela est également affecté. Essuyer les serveurs serait ma dernière option à considérer.

— shagrinar

Lors de la création d'un tout nouveau domaine, que ce soit par script ou par assistant, vous devez créer un seul compte maître et lui donner un mot de passe. Il n'est généralement utilisé qu'en période de reprise après sinistre (comme maintenant) et seule la personne qui a créé le domaine le saurait. Si vous ne savez pas qui a créé le domaine, vérifiez auprès de votre directeur, les chances sont que quelqu'un dans la chaîne de gestion ait reçu cette information.

— Colyn1337

1

Le compte dont vous parlez est le compte du mode de restauration des services d'annuaire; il n'est utilisé que pour effectuer la maintenance sur les contrôleurs de domaine hors ligne, mais ce n'est pas en fait un administrateur de domaine; ce serait complètement inutile dans ce cas, à moins que vous ne vouliez restaurer AD à partir de sauvegardes.

— Massimo

@Massimo Je pense que vos informations sont un peu anciennes ... "vous pouvez configurer un contrôleur de domaine afin de pouvoir vous y connecter avec le compte Administrateur DSRM si le contrôleur de domaine a été démarré normalement mais que le service AD DS est arrêté pour quelque raison." technet.microsoft.com/en-us/library/cc816897(v=ws.10).aspx

— Colyn1337

1

@Massimo Il serait possible de supprimer le GPO de son emplacement dans le dossier sysvol du système de fichiers, ainsi que de modifier le registre pour modifier les paramètres à l'aide de cette technique. Je suppose que c'est ce qui est suggéré dans cette réponse.

— HopelessN00b

1

Tout d'abord, arrêtez tous les contrôleurs de domaine. Cela évitera des problèmes de réplication bizarres.

La première étape consiste à supprimer le paramètre de stratégie de groupe incorrect. Les attributions de privilèges sont stockées dans le GptTmpl.inffichier MACHINE\Microsoft\Windows NT\SecEditsous chaque dossier de stratégie. Vous savez que vous avez la bonne politique lorsque ce .inffichier contient une ligne SeDenyNetworkLogonRight, SeDenyInteractiveLogonRightet ainsi de suite. Supprimez-en toutes les SeDeny...Rightlignes.

Windows n'appliquera pas les nouveaux paramètres sauf s'il constate que l'objet de stratégie de groupe a changé, ce qu'il détermine en consultant l' versionNumberattribut sur un objet Active Directory. N'essayons pas de modifier AD hors ligne. Au lieu de cela, nous supprimerons manuellement les paramètres incorrects du Registre.

Montez la \Windows\System32\config\SECURITYruche du contrôleur de domaine dans le registre d'un autre système Windows avec reg load. Ouvrez l'Éditeur du Registre et accédez à Policy\Accountssous la ruche montée. (Vous devrez peut-être exécuter en regedittant que SYSTEM pour que cela fonctionne. PsExec peut le faire.) Chaque sous-clé de cela correspond à un utilisateur ou un groupe, et la ActSysAcsous - clé de chacun de ceux-ci détient les «droits». (Les "privilèges" sont tous dans la Privilgssous - clé.) Trouvez celui avec une ActSysAcvaleur de C0 03 00 00, qui correspond aux quatre droits que vous avez refusés. Supprimez ActSysAcou modifiez sa valeur en 00 00 00 00. Fermez l'Éditeur du Registre et démontez la ruche avec reg unload.

Démarrez le contrôleur de domaine que vous avez modifié. Vous devriez pouvoir vous connecter maintenant. Utilisez la console de gestion des stratégies de groupe pour apporter des modifications (aussi triviales soient-elles) aux stratégies locales de l'objet de stratégie de groupe concerné. Cela augmentera le numéro de version du GPO.

Démarrez les autres contrôleurs de domaine et laissez les modifications se répliquer.

— Ben N
source

Cela semble très prometteur, malheureusement je ne peux pas confirmer que cela fonctionne. Maintenant, je reconstruis tout. Si quelqu'un peut confirmer que cela fonctionne, je suis plus qu'heureux de marquer cela comme la réponse!

— shagrinar

0

Vous pouvez essayer d'ouvrir dans l'explorateur \\ domain.controler \ c $ \ windows \ sysvol \ sysvol \ domain.local \ policies (vous avez toujours accès)

Vous y trouverez toutes les politiques. Déplacez tout ce répertoire vers une destination temporaire et essayez de redémarrer le PC. Ça va aider.

— kgimpel
source

Le contrôleur de domaine s'appelle asgard et le domaine s'appelle yggdrasil , j'ai donc entré: \\ asgard \ c $ \ windows \ sysvol \ sysvol \ yggdrasil \ policies qui a généré un message d'erreur me disant que Windows ne peut pas accéder au répertoire. Je n'essaie pas d'accéder à cela à partir du compte d'administrateur local d'un ordinateur qui se trouve dans le domaine, mais à partir de mon ordinateur portable privé - cela nécessite toujours une connexion.

— shagrinar

Vérifiez le répertoire, je ne suis pas sûr après sysvol. Pouvez-vous vous connecter à \\\ domaincontroller \ c $ à l'aide des informations d'identification de domaine? Ou vous pouvez essayer d'utiliser l'administrateur local comme "asgard \ admin" ou "asgard \ tor" :)

— kgimpel

J'ai essayé cela en vain, mais comme il s'agit d'une machine virtuelle sur laquelle le DC fonctionne, je viens de monter le disque dur virtuel. J'ai trouvé le répertoire C: \ sysvol \ sysvol \ fqdn_of_domain , essayer d'y accéder a entraîné une erreur (c'est une sorte de lien symbolique?). J'ai trouvé un autre dossier C: \ sysvol \ domain qui contient des scripts et des politiques. J'en ai tout retiré, démonté le VHD et mis le feu à la machine. Malheureusement, il n'y a aucun changement. Où mène ce lien? Y a-t-il d'autres options que je peux considérer lors de l'accès au disque dur?

— shagrinar

3

@shagrinar Référencer le contrôleur de domaine directement via un partage SMB, ce que cette réponse conseille, ne fonctionnera pas car vous avez refusé l'accès au réseau par GPO. Vous pourriez être en mesure de le faire \\domainname\sysvol\ et d'accéder aux politiques de cette façon, mais je n'obtiendrais pas mes espoirs. La modification de sysvol nécessite des privilèges d'administrateur de domaine, et si vous avez verrouillé tous les administrateurs de domaine, vous ne pourrez pas y accéder avec les privilèges requis pour ce faire.

— HopelessN00b

A l'intérieur de SYSVOL \ Domain \ Policies Vous pouvez trier, rechercher et déplacer uniquement les répertoires créés au cours de la dernière journée. L'un d'eux sera votre politique "problème".

— kgimpel