Cómo desactivar las herramientas de administración local en Windows [PowerShell Script]

Atención, profesional de TI y proveedor de servicios gestionados (MSP): si te han encargado mantener la seguridad de la red y el acceso administrativo, debes saber que a menudo es más fácil decirlo que hacerlo. Un aspecto clave es la gestión de las herramientas de administración local a las que los usuarios no deberían tener libre acceso. Esto nos lleva a una pregunta frecuente: ¿cómo desactivo las herramientas de administración local a gran escala? 

Tenemos un script PowerShell completo que te permitirá desactivar las herramientas de administración de forma selectiva en un entorno Windows. 

El script PowerShell para desactivar las herramientas de administración local

#Requires -Version 5.1

    This will disable the selected administrator tools depending on your selection (Defaults to all). Can be given a comma separated list of users to exclude from this action.
    This will disable the selected administrator tools. The options are "All", the command prompt, the control panel, the microsoft management console,
    the registry editor, the run command window and task manager. You can give it a comma separated list of items if you want to disable some but not all.
    Exit 1 is usually an indicator of bad input but can also mean editing the registry is blocked.
    PS C:> .Disable-LocalAdminTools.ps1 -Tools "MMC,Cmd,TaskMgr,RegistryEditor"
    Disabling MMC...
    Set Registry::HKEY_USERSDefaultProfileSoftwarePoliciesMicrosoftMMCRestrictToPermittedSnapins to...
    Disabling Cmd...
    Set Registry::HKEY_USERSDefaultProfileSoftwarePoliciesMicrosoftWindowsDisableCMD to...
    Disabling TaskMgr...
    Set Registry::HKEY_USERSDefaultProfileSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemDisableTaskMgr to...
    Disabling RegistryEditor...
    Set Registry::HKEY_USERSDefaultProfileSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemDisableRegistryTools to...
    Minimum Supported OS: Windows 10, Windows Server 2016+
    Release Notes: Renamed script and added Script Variable support
By using this script, you indicate your acceptance of the following legal terms as well as our Terms of Use at https://www.ninjaone.com/terms-of-use.
    Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms. 
    Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party. 
    Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library or website belonging to or under the control of any other software provider. 
    Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations. 
    Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks. 
    Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script. 
    EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).

param (
    [String]$Tools = "All",

begin {
    if ($env:excludeUsers -and $env:excludeUsers -notlike "null") { $ExcludedUsers = $env:excludeUsers }
    # Lets double check that this script is being run appropriately
    function Test-IsElevated {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        $p = New-Object System.Security.Principal.WindowsPrincipal($id)

    function Test-IsSystem {
        $id = [System.Security.Principal.WindowsIdentity]::GetCurrent()
        return $id.Name -like "NT AUTHORITY*" -or $id.IsSystem

    if (!(Test-IsElevated) -and !(Test-IsSystem)) {
        Write-Error -Message "[Error] Access Denied. Please run with Administrator privileges."
        exit 1

    # Setting up some functions to be used later.
    function Set-HKProperty {
        param (
            [ValidateSet('DWord', 'QWord', 'String', 'ExpandedString', 'Binary', 'MultiString', 'Unknown')]
            $PropertyType = 'DWord'
        if (-not $(Test-Path -Path $Path)) {
            # Check if path does not exist and create the path
            New-Item -Path $Path -Force | Out-Null
        if ((Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore)) {
            # Update property and print out what it was changed from and changed to
            $CurrentValue = Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore
            try {
                Set-ItemProperty -Path $Path -Name $Name -Value $Value -Force -Confirm:$false -ErrorAction Stop | Out-Null
            catch {
                Write-Error "[Error] Unable to Set registry key for $Name please see below error!"
                Write-Error $_
                exit 1
            Write-Host "$Path$Name changed from $CurrentValue to $(Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore)"
        else {
            # Create property with value
            try {
                New-ItemProperty -Path $Path -Name $Name -Value $Value -PropertyType $PropertyType -Force -Confirm:$false -ErrorAction Stop | Out-Null
            catch {
                Write-Error "[Error] Unable to Set registry key for $Name please see below error!"
                Write-Error $_
                exit 1
            Write-Host "Set $Path$Name to $(Get-ItemProperty -Path $Path -Name $Name -ErrorAction Ignore)"

    # This will get all the registry path's for all actual users (not system or network service account but actual users.)
    function Get-UserHives {
        param (
            [ValidateSet('AzureAD', 'DomainAndLocal', 'All')]
            [String]$Type = "All",

        # User account SID's follow a particular patter depending on if they're azure AD or a Domain account or a local "workgroup" account.
        $Patterns = switch ($Type) {
            "AzureAD" { "S-1-12-1-(d+-?){4}$" }
            "DomainAndLocal" { "S-1-5-21-(d+-?){4}$" }
            "All" { "S-1-12-1-(d+-?){4}$" ; "S-1-5-21-(d+-?){4}$" } 

        # We'll need the NTuser.dat file to load each users registry hive. So we grab it if their account sid matches the above pattern. 
        $UserProfiles = Foreach ($Pattern in $Patterns) { 
            Get-ItemProperty "HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionProfileList*" |
                Where-Object { $_.PSChildName -match $Pattern } | 
                Select-Object @{Name = "SID"; Expression = { $_.PSChildName } }, 
                @{Name = "UserHive"; Expression = { "$($_.ProfileImagePath)NTuser.dat" } }, 
                @{Name = "UserName"; Expression = { "$($_.ProfileImagePath | Split-Path -Leaf)" } }

        # There are some situations where grabbing the .Default user's info is needed.
        switch ($IncludeDefault) {
            $True {
                $DefaultProfile = "" | Select-Object UserName, SID, UserHive
                $DefaultProfile.UserName = "Default"
                $DefaultProfile.SID = "DefaultProfile"
                $DefaultProfile.Userhive = "$env:SystemDriveUsersDefaultNTUSER.DAT"

                # It was easier to write-output twice than combine the two objects.
                $DefaultProfile | Where-Object { $ExcludedUsers -notcontains $_.UserName } | Write-Output

        $UserProfiles | Where-Object { $ExcludedUsers -notcontains $_.UserName } | Write-Output

    function Set-Tool {
            [ValidateSet("All", "Cmd", "ControlPanel", "theControlPanel", "MMC", "RegistryEditor", "theRegistryEditor", "Run", "TaskMgr", "taskManager")]
        process {
            # Each option has a different registry key to change. Since this function only supports 1 item at a time I can check which option and set the regkey individually.
            Write-Host "Disabling $Tool..."
            switch ($Tool) {
                "Cmd" { Set-HKProperty -Path $keySoftwarePoliciesMicrosoftWindowsSystem -Name DisableCMD -Value 1 }
                "ControlPanel" { Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer -Name NoControlPanel -Value 1 }
                "theControlPanel" { Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer -Name NoControlPanel -Value 1 }
                "MMC" { Set-HKProperty -Path $keySoftwarePoliciesMicrosoftMMC -Name RestrictToPermittedSnapins -Value 1 }
                "RegistryEditor" { Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesSystem -Name DisableRegistryTools -Value 1 }
                "theRegistryEditor" { Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesSystem -Name DisableRegistryTools -Value 1 }
                "Run" { Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer -Name NoRun -Value 1 }
                "TaskMgr" { Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesSystem -Name DisableTaskMgr -Value 1 }
                "taskManager" { Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesSystem -Name DisableTaskMgr -Value 1 }
                "All" {
                    Set-HKProperty -Path $keySoftwarePoliciesMicrosoftWindowsSystem -Name DisableCMD -Value 1
                    Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesSystem -Name NoDispCPL -Value 1
                    Set-HKProperty -Path $keySoftwarePoliciesMicrosoftMMC -Name RestrictToPermittedSnapins -Value 1
                    Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesSystem -Name DisableRegistryTools -Value 1
                    Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer -Name NoRun -Value 1
                    Set-HKProperty -Path $keySoftwareMicrosoftWindowsCurrentVersionPoliciesSystem -Name DisableTaskMgr -Value 1
process {

    # Get each user profile SID and Path to the profile. If there are any exclusions we'll have to take them into account.
    if ($ExcludedUsers) {
        $ToBeExcluded = New-Object System.Collections.Generic.List[string]
        $ExcludedUsers.split(",").trim() | ForEach-Object { if ($_) { $ToBeExcluded.Add($_) } }
        Write-Warning "The Following Users will not have your selected tools disabled. $ToBeExcluded"
        $UserProfiles = Get-UserHives -IncludeDefault -ExcludedUsers $ToBeExcluded
    else {
        $UserProfiles = Get-UserHives -IncludeDefault

    # Loop through each profile on the machine
    Foreach ($UserProfile in $UserProfiles) {
        # Load each user's registry hive if not already loaded. Backticked "UserProfile.UserHive" so that it accounts for spaces in the username.
        If (($ProfileWasLoaded = Test-Path Registry::HKEY_USERS$($UserProfile.SID)) -eq $false) {
            Start-Process -FilePath "cmd.exe" -ArgumentList "/C reg.exe LOAD HKU$($UserProfile.SID) `"$($UserProfile.UserHive)`"" -Wait -WindowStyle Hidden
        # The path is different for each individual user. This is the base path.
        $key = "Registry::HKEY_USERS$($UserProfile.SID)"

        # List of checkbox items
        $CheckboxItems = "cmd", "theControlPanel", "mmc", "theRegistryEditor", "run", "taskManager"
        # Checkboxes come in as environmental variables. This'll grab the ones that were selected (if any)
        $EnvItems = Get-ChildItem env:* | Where-Object { $CheckboxItems -contains $_.Name -and $_.Value -notlike "false" }

        # This will grab the tool selections from the parameter field. Since it comes in as a string we'll have to split it up.
        $Tool = $Tools.split(",").trim()

        # If the checkbox for all was selected I can just run the function once instead of running it repeatedly for the same thing.
        if ($env:allTools -and $env:allTools -notlike "false") {
            Set-Tool -Tool "All" -Key $key
        elseif ($EnvItems) {
            # If checkboxes were used we should just use those.
            $EnvItems | ForEach-Object { Set-Tool -Tool $_.Name -Key $key }
        else {
            $Tool | ForEach-Object { Set-Tool -Tool $_ -Key $key }

        # Unload NTuser.dat for user's we loaded previously.
        If ($ProfileWasLoaded -eq $false) {
            Start-Sleep -Seconds 1
            Start-Process -FilePath "cmd.exe" -ArgumentList "/C reg.exe UNLOAD HKU$($UserProfile.SID)" -Wait -WindowStyle Hidden | Out-Null
end {


Accede a más de 700 scripts en el Dojo de NinjaOne


Cómo funciona el script

El script en cuestión está escrito en PowerShell y está diseñado para desactivar herramientas administrativas específicas en máquinas locales. Se ha optimizado para funcionar con PowerShell 5.1 y cuenta con varias opciones seleccionables como Símbolo del sistema, Panel de control, Consola de administración de Microsoft (MMC), Editor del registro, Ventana de ejecución de comandos y Administrador de tareas. Puedes desactivar todas estas herramientas o elegir de una lista separada por comas para desactivar sólo algunas. 

Además, el script ofrece la posibilidad de excluir de esta acción a determinados perfiles de usuario. Si necesitas asegurarte de que algunos usuarios conservan sus capacidades de administrador, puedes hacerlo fácilmente. 

Este script PowerShell realiza tres comprobaciones importantes: 

  1. Comprueba si el script se está ejecutando con privilegios administrativos. 
  2. Carga las claves de registro de cada perfil de usuario, excepto las excluidas explícitamente. 
  3. Modifica o establece claves de registro para desactivar las herramientas administrativas seleccionadas. 

No se trata sólo de desactivar; se trata de control y especificidad, lo que hace que este script sea muy versátil para los administradores de TI y MSP. 

Por qué los profesionales de TI y los MSP deberían interesarse

Control centralizado 

Mediante este script de PowerShell, los profesionales de TI pueden desactivar las herramientas de administración local de forma centralizada, lo que reduce significativamente el tiempo que se tardaría en hacerlo manualmente para cada usuario. 


Desactivar estas herramientas mejora la seguridad al limitar la capacidad de los usuarios para realizar cambios a nivel de sistema. Esto resulta especialmente útil en entornos en los que se desea minimizar los posibles riesgos de seguridad desde dentro. 


La capacidad del script para desactivar herramientas de forma selectiva y excluir a usuarios concretos le confiere una flexibilidad perfecta para diversos entornos informáticos. No va a ser una solución que le valga a todo el mundo, pero sí que puede ser adaptada según las necesidades. 

Automatización y escalabilidad 

Para los MSP, el script puede integrarse en procesos de despliegue automatizados, lo que lo hace escalable para grandes redes. Imagínate la comodidad de poder desplegarlo en miles de máquinas con unos pocos clics. 

Cómo desplegarlo

Es suficiente con descargar el script Disable-LocalAdminTools.ps1 y ejecutarlo a través de PowerShell en los equipos de destino. El script admite varias opciones de línea de comandos para ajustar lo que deseas desactivar. 

PS C:>.Disable-LocalAdminTools.ps1 -Tools «MMC,Cmd,TaskMgr,RegistryEditor»

Reflexiones finales

Tanto si eres un profesional de TI que busca una solución para deshabilitar las herramientas de administración local como si eres un MSP que busca un script de deshabilitación de herramientas de administración fácil de implementar, este script de PowerShell proporciona una solución sólida, flexible y eficaz. Un script que transforma lo complejo en simple, dándote más control sobre la configuración de seguridad de tu red. 

Mantente a la vanguardia utilizando este enfoque eficaz y específico al acceso administrativo. ¡Feliz scripting! 

Próximos pasos

La creación de un equipo de TI próspero y eficaz requiere contar con una solución centralizada que se convierta en tu principal herramienta de prestación de servicios. NinjaOne permite a los equipos de TI supervisar, gestionar, proteger y dar soporte a todos sus dispositivos, estén donde estén, sin necesidad de complejas infraestructuras locales.

Obtén más información sobre NinjaOne Endpoint Management, echa un vistazo a un tour en vivoo tu prueba gratuita de la plataforma NinjaOne.

Quizá también te interese…

Ver demo×

¡Vean a NinjaOne en acción!

Al enviar este formulario, acepto la política de privacidad de NinjaOne.

Términos y condiciones de NinjaOne

Al hacer clic en el botón «Acepto» que aparece a continuación, estás aceptando los siguientes términos legales, así como nuestras Condiciones de uso:

  • Derechos de propiedad: NinjaOne posee y seguirá poseyendo todos los derechos, títulos e intereses sobre el script (incluidos los derechos de autor). NinjaOne concede al usuario una licencia limitada para utilizar el script de acuerdo con estos términos legales.
  • Limitación de uso: solo podrás utilizar el script para tus legítimos fines personales o comerciales internos, y no podrás compartirlo con terceros.
  • Prohibición de republicación: bajo ninguna circunstancia está permitido volver a publicar el script en ninguna biblioteca de scripts que pertenezca o esté bajo el control de cualquier otro proveedor de software.
  • Exclusión de garantía: el script se proporciona «tal cual» y «según disponibilidad», sin garantía de ningún tipo. NinjaOne no promete ni garantiza que el script esté libre de defectos o que satisfaga las necesidades o expectativas específicas del usuario.
  • Asunción de riesgos: el uso que el usuario haga del script corre por su cuenta y riesgo. El usuario reconoce que existen ciertos riesgos inherentes al uso del script, y entiende y asume cada uno de esos riesgos.
  • Renuncia y exención: el usuario no hará responsable a NinjaOne de cualquier consecuencia adversa o no deseada que resulte del uso del script y renuncia a cualquier derecho o recurso legal o equitativo que pueda tener contra NinjaOne en relación con su uso del script.
  • CLUF: si el usuario es cliente de NinjaOne, su uso del script está sujeto al Contrato de Licencia para el Usuario Final (CLUF).