Cuándo se necesita el privilegio de administrador en Windows - UAC, áreas protegidas y cómo distinguirlo por diseño

En las consultas relacionadas con Windows, hay un conjunto de temas que suelen mezclarse.

• En qué momentos hace falta “Ejecutar como administrador”
• Por qué sigue apareciendo el UAC aunque la cuenta sea de administrador
• Si la instalación siempre requiere administrador
• Si se quiere colocar la aplicación en Program Files, si también hace falta elevar en tiempo de ejecución
• Qué efecto tiene en la práctica la diferencia entre HKCU y HKLM
• Cómo diseñar una aplicación que solo necesita privilegios de administrador para “una parte del procesamiento”

Esta cuestión no se decide únicamente por si la persona es o no administrador. En la práctica, depende en buena medida de dónde se escribe, a quién afecta el cambio y qué objeto protegido del sistema operativo se toca.

En este artículo ordenamos, desde los fundamentos de UAC, los casos en los que Windows requiere privilegios de administrador, y resumimos de forma práctica hasta dónde basta con privilegios de usuario estándar y a partir de dónde entra en juego la elevación. El contenido se basa en la información oficial de Microsoft disponible a fecha de marzo de 2026.¹²³⁴⁵

1. Conclusión inicial

Antes de nada, dejamos aquí solo las conclusiones prácticas.

• Si Windows requiere privilegios de administrador depende, más que de si el procesamiento es “complejo”, de si afecta al sistema operativo o a toda la máquina.¹⁴
• El procesamiento que se limita solo al propio perfil, por ejemplo el que usa %AppData%, %LocalAppData%, HKCU o Documents, normalmente no necesita privilegios de administrador.⁶⁷
• Por el contrario, el procesamiento que toca toda la máquina, todos los usuarios o áreas protegidas, como Program Files, Windows, System32, la configuración machine-wide de HKLM o HKCR, los servicios de Windows, los controladores en modo kernel, el firewall o las tareas con el privilegio más alto, tiende a necesitar privilegios de administrador.⁴⁶⁸⁹¹⁰
• Lo importante aquí es que que el usuario pertenezca al grupo Administrators y que la aplicación se esté ejecutando ahora mismo con un token de acceso de administrador son dos cosas distintas. Con UAC activado, incluso un usuario administrador ejecuta los procesos normales con el equivalente a privilegios de usuario estándar, y solo eleva cuando es necesario.²⁶
• Instalación no equivale siempre a administrador. Con diseños como la instalación per-user, que parte de colocarse bajo %LocalAppData%, es posible distribuir y actualizar sin privilegios de administrador.¹¹¹²
• En las “aplicaciones que, por alguna razón, siempre necesitan privilegios de administrador”, lo habitual es que en realidad escriban datos en tiempo de ejecución en un área protegida, o que declaren requireAdministrator / highestAvailable en el manifiesto.⁴¹³
• En cuanto a la dirección futura, Windows se inclina cada vez más hacia elevar de forma explícita solo en el momento necesario. La función Administrator protection (preview) de Windows 11 muestra esta tendencia con bastante claridad.⁵

En resumen, la forma más práctica de verlo es que si se necesita privilegio de administrador no lo decide el cargo del usuario, sino el límite que toca la aplicación.

2. ¿Qué significa realmente “necesitar privilegios de administrador”?

Lo primero que conviene aclarar en esta cuestión es separar conceptualmente el usuario y el proceso.

El UAC de Windows es una función de seguridad diseñada para impedir cambios no autorizados en el sistema operativo. Microsoft Learn explica que UAC notifica cuando se realizan cambios que requieren permisos de nivel administrador.¹

Además, según la explicación oficial de UAC, las aplicaciones que necesitan un token de acceso de administrador solicitan el consentimiento del usuario final, y los procesos hijos heredan el token de acceso del proceso padre, de modo que padre e hijo se ejecutan con el mismo nivel de integridad.²

De esto se desprenden dos cosas.

2.1 Ser “usuario administrador” no significa ejecutarse siempre como administrador

Microsoft Learn explica que, con UAC activado, incluso los procesos que inicia un miembro del grupo Administrators se ejecutan con privilegios de usuario estándar, salvo que se eleven explícitamente.⁶

Esto se debe a que, al iniciar sesión un usuario administrador, se crean dos tokens de acceso, y en el uso habitual solo se emplea el lado restringido. Esto se representa así en un diagrama.²

flowchart TD
    accTitle: Cómo UAC decide entre el token filtrado y el token de administrador completo
    accDescr: Diagrama de flujo que muestra que, al iniciar sesión el usuario administrador, Windows genera un token filtrado (usado por defecto) y un token de administrador completo (solo usado al elevar), y que la elevación solo ocurre cuando el proceso intenta tocar un área protegida o un servicio.
    L["El usuario administrador inicia sesión"] --> S["Windows prepara dos tokens"]
    S --> F["Token filtrado<br/>equivalente a usuario estándar"]
    S --> A["Token de administrador completo<br/>solo se usa al elevar"]
    F --> N["Inicio habitual de aplicaciones<br/>el Explorador de archivos también usa este token"]
    N --> C["El proceso hijo hereda el token del padre<br/>por eso también es equivalente a usuario estándar"]
    N --> Q{"¿Intenta acceder a un área protegida<br/>o a un servicio?"}
    Q -- "No" --> OK["Se ejecuta sin más"]
    Q -- "Sí" --> P["Aparece el aviso de consentimiento de UAC"]
    P --> A
    A --> E["Solo un proceso elevado<br/>puede modificar el área protegida"]

Que “aparezca el UAC cada vez pese a ser usuario administrador” se debe a que, mientras el proceso se ejecuta con el token filtrado, llega una operación que solo puede realizarse con el token de administrador completo. Como el token se determina en el momento de iniciar el proceso, de aquí también se desprende que la única forma de añadirlo después es iniciar un nuevo proceso.

Dicho de otro modo, es normal que:

• Su cuenta de Windows sea de administrador
• Pero la aplicación que acaba de iniciar con doble clic no esté elevada
• Y que, por eso, el UAC aparezca justo en el instante en que se necesita un privilegio de administrador

Que “siendo administrador, todavía falten permisos” es un comportamiento perfectamente natural en Windows.

2.2 No se puede elevar solo una parte de un mismo proceso

UAC no es una magia que actúe función por función, sino una cuestión de con qué token se ejecuta el proceso. Como los procesos hijos heredan el token, no es posible diseñar un sistema en el que, dentro de un proceso de interfaz no elevado, se conviertan en administrador solo algunos métodos de ese mismo proceso justo al pulsar un botón.²

Si hace falta, es necesario recurrir a otra unidad de ejecución, como:

• Extraerlo a un EXE independiente
• Usar un servicio
• Usar una tarea con el privilegio más alto
• Usar un objeto COM elevado

Se necesita este tipo de unidades independientes.¹⁴

Diseñar sin conocer esta premisa suele desembocar en una consulta un tanto complicada del tipo “queremos que solo este botón se ejecute como administrador”.

Cabe señalar que estos dos puntos también son un foco habitual de malentendidos, por lo que se retoman en forma de preguntas y respuestas en el apartado 9, “Errores comunes de interpretación”. Para explicarlo internamente en su organización, el apartado 9 resulta más breve y fácil de citar.

3. ¿De qué depende? Cómo distinguirlo primero

La forma más clara de distinguirlo se reduce a estos tres puntos:

1. Dónde se escribe
2. A quién afecta el cambio
3. Si se toca un objeto protegido del sistema operativo

3.1 Áreas representativas donde escribir requiere elevación

Como esto sirve de base para los apartados siguientes, primero enumeramos las áreas en las que “intentar escribir ahí requiere elevación”. Prácticamente todo lo que aparece a partir del apartado 4 corresponde a alguna fila de esta tabla.

Solo la última fila está claramente marcada como “no necesaria”; C:\ProgramData es condicional, y el resto pertenece al lado de la elevación. Dicho de otro modo, si se puede orientar el destino de escritura de la aplicación hacia esta última fila y hacia %ProgramData% es lo que determina, casi por completo, la necesidad de elevación.⁴⁶⁷

3.2 Tabla de decisión según lo que se quiera hacer

Si se organiza esto para poder consultarlo desde el lado de “lo que se quiere hacer”, queda así. El criterio se unificó en tres valores: Obligatorio / Según el caso / No necesario.

Resumiendo de forma bastante simplificada:

• Si el cambio es para uno mismo, suele bastar con usuario estándar
• Si el cambio es para todos, suele estar implicado el administrador
• Si se toca el límite de seguridad del sistema operativo, hace falta administrador

Con solo revisar estos tres puntos de antemano, resulta mucho más fácil explicar “por qué aparece el UAC”.

4. Ejemplos típicos donde suele necesitarse privilegio de administrador

4.1 Instalación, actualización y desinstalación para todos los usuarios

Según la explicación de la arquitectura de UAC en Microsoft Learn, muchos instaladores escriben en directorios del sistema o en claves del Registro, por lo que un usuario estándar no dispone de acceso suficiente, y Windows detecta los programas de instalación y solicita la elevación.³

Lo importante aquí es que no se necesita elevación porque el instalador “tenga un estatus especial por ser instalador”, sino porque el destino de escritura es un área protegida.

Los casos típicos son estos:

• Colocarse en Program Files
• Escribir información machine-wide en HKLM
• Realizar registros o integraciones COM para todos los usuarios
• Instalar servicios o controladores
• Contar con una ruta de actualización para toda la máquina

Este tipo de casos suele necesitar privilegios de administrador.³⁸

4.2 Escribir datos en tiempo de ejecución en Program Files o HKLM

Este caso también es bastante frecuente. La guía de diseño de UAC de Microsoft explica que deben eliminarse las elevaciones innecesarias, y que buena parte del software antiguo necesita privilegios de administrador de forma innecesaria por escribir en HKLM / HKCR o en Program Files / las carpetas del sistema de Windows.⁴

Además, en la explicación sobre el usuario estándar se indica expresamente que no puede escribir en la carpeta Program Files ni en HKEY_LOCAL_MACHINE, ni tampoco realizar operaciones que modifiquen el sistema.⁶

Es decir, si datos que cambian en tiempo de ejecución, como:

• Archivos de configuración
• Registros
• Caché
• Estado propio de cada usuario
• Historial reciente

se colocan en la carpeta de instalación o en HKLM, eso por sí solo suele convertir la aplicación en algo que “no funciona si no se inicia como administrador”.

Y esto no ocurre porque la aplicación esté realmente pensada para administradores, sino que no es raro que se deba únicamente a una mala elección del lugar de almacenamiento.

4.3 Registro o cambio de configuración de servicios de Windows

Los servicios son objetos que administra el sistema operativo, así que, como es lógico, no se pueden tocar a la ligera.

La documentación oficial sobre los derechos de acceso del Administrador de control de servicios explica que para llamar a CreateService se necesita SC_MANAGER_CREATE_SERVICE, y que solo un proceso con Administrator privileges puede abrir el handle utilizable para CreateService.⁸

Además, se indica que SERVICE_CHANGE_CONFIG, necesario para ChangeServiceConfig / ChangeServiceConfig2, permite modificar el EXE que ejecuta el sistema, por lo que solo debería concederse a administradores.⁸

Por lo tanto, operaciones como:

• Registrar un servicio
• Cambiar el ejecutable o el tipo de inicio de un servicio
• Eliminar un servicio
• Cambiar el descriptor de seguridad de un servicio

presuponen privilegios de administrador.

4.4 Instalación de controladores en modo kernel

Microsoft Learn explica que un usuario estándar no puede ejecutar tareas que modifiquen el sistema, como la instalación de un controlador en modo kernel.⁶

Este es un límite bastante claro. Como los controladores se ejecutan en el lado del kernel, no pueden tratarse al mismo nivel que el simple “guardado de configuración de una aplicación de usuario”.

• Instalar un controlador de dispositivo
• Instalar un controlador virtual o de filtro
• Modificar componentes relacionados con el arranque o la E/S

Puede darse por hecho que este tipo de operaciones necesita privilegios de administrador.

4.5 Configuración del firewall o de tareas con privilegios elevados

El firewall también forma parte del límite de seguridad del sistema operativo. El procedimiento de configuración del firewall en Microsoft Learn especifica que para operar Windows Firewall with Advanced Security en un solo dispositivo se necesitan administrative rights en ese dispositivo.⁹

Además, sobre el Programador de tareas se define que TASK_RUNLEVEL_LUA se ejecuta con el privilegio mínimo y TASK_RUNLEVEL_HIGHEST con el privilegio más alto, y la documentación de schtasks indica que para programar, ver o cambiar todas las tareas del equipo local es necesario pertenecer al grupo Administrators.¹⁰

En resumen, configuraciones como:

• Añadir o modificar reglas de Windows Firewall
• Registrar un procesamiento concreto como tarea con el privilegio más alto
• Ejecutar un trabajo con otro usuario o con SYSTEM

se sitúan del lado de las que necesitan privilegios de administrador.

5. Ejemplos típicos donde, en realidad, no suele hacer falta el privilegio de administrador

Puede dar la impresión de que “Windows exige administrador enseguida”, pero en realidad hay bastantes más partes de las que se piensa en las que se puede diseñar sin necesidad de privilegios de administrador.

5.1 Configuración, caché y registros propios del usuario

Microsoft Learn explica que, en lugar de depender de la virtualización pensada para la compatibilidad, la aplicación debería guardar los datos en una ubicación per-user o en una ubicación de equipo dentro de %alluserprofile% con la ACL correctamente configurada.⁷

En la práctica, resulta más claro separarlo así:

• Específico del usuario: %AppData%, %LocalAppData%, HKCU
• Compartido pero actualizado en tiempo de ejecución: %ProgramData% + diseño de ACL
• El propio ejecutable: áreas protegidas como Program Files

Si se logra esta separación, es posible que la instalación de la propia aplicación requiera administrador, pero el uso habitual no.

5.2 Instalación y actualización per-user

Incluso en la documentación oficial de Microsoft aparecen con normalidad ejemplos de colocación per-user.

Por ejemplo, la documentación del cliente de Escritorio remoto explica que la instalación per-user se realiza bajo LocalAppData de cada perfil de usuario, y el usuario puede actualizarla sin privilegios de administrador.¹¹

Asimismo, la documentación de OneDrive indica que de forma predeterminada la instalación es per-user, y que la instalación per-machine se ejecuta añadiendo /allusers al comando, lo que hace que aparezca el aviso de UAC. Además, la versión per-user se instala bajo %localappdata% y la per-machine bajo Program Files.¹²

De aquí se desprende que la sola palabra “instalación” no determina si hace falta o no el privilegio de administrador.

• Si cada usuario la coloca en su propia área, en algunos casos basta sin administrador
• Si se coloca en un área común a todos los usuarios, suele hacer falta administrador

Lo importante es decidir primero si será per-user o per-machine.

5.3 Operaciones habituales de interfaz y lógica de negocio

Dicho de otro modo, operaciones como las siguientes no requieren, en sí mismas, privilegios de administrador:

• Abrir documentos o imágenes
• Editar archivos dentro del propio perfil
• Realizar comunicación HTTP o con una base de datos
• Ejecutar la lógica de negocio
• Mostrar resultados en pantalla
• Leer y escribir la configuración propia

Si, a pesar de eso, resulta necesario “ejecutar toda la aplicación como administrador”, la causa no suele estar en la funcionalidad principal de la aplicación, sino en que alguna parte periférica del procesamiento toca un área protegida.

6. ¿Por qué se pide “ejecutar esta aplicación como administrador”?

6.1 Se declara requireAdministrator en el manifiesto

En el manifiesto de la aplicación, requestedExecutionLevel permite declarar el nivel de privilegio necesario. Microsoft Learn define estos tres valores:¹³

• asInvoker: se ejecuta con el mismo privilegio que el proceso que lo inició
• highestAvailable: se ejecuta con el privilegio más alto disponible
• requireAdministrator: se ejecuta con privilegio de administrador

Si la aplicación tiene requireAdministrator, la elevación se presupone cada vez que se inicia. Incluso con highestAvailable, según el entorno puede estar implicada la elevación.¹³

Por lo tanto, la respuesta más directa a “por qué aparece el UAC cada vez” es que la propia aplicación lo declara así.

6.2 Se activa la detección de instaladores (installer detection) de Windows

En la explicación de la arquitectura de UAC se indica que Windows cuenta con installer detection technology, y que muchos programas de instalación escriben en protected system locations, por lo que se necesita elevación.³

Y esto no ocurre simplemente porque el archivo se llame setup.exe, sino que Windows aplica hasta cierto punto una heurística para determinar que “esto parece un instalador”. La documentación oficial menciona las siguientes condiciones:³

• Ejecutable de 32 bits
• Ausencia del atributo requestedExecutionLevel
• Proceso interactivo de un usuario estándar con UAC activado
• El nombre del archivo contiene palabras como install, setup o update, entre otras

Por eso no es nada extraño, desde el diseño de Windows, que SetupLauncher.exe o Updater.exe soliciten elevación de repente.

6.3 Aplicaciones antiguas que “funcionaban por casualidad” gracias a la virtualización

Este es un punto bastante propenso a malentendidos.

Microsoft Learn explica que UAC ofrece virtualización de archivos y del Registro para las aplicaciones no conformes que intentan escribir en un área protegida. Al mismo tiempo, se especifica que se trata de una medida de compatibilidad a corto plazo, no de una solución a largo plazo.³⁷

Además, la virtualización tiene limitaciones. Se aplican estas condiciones:

• No se aplica a las aplicaciones ya elevadas
• Solo se aplica a aplicaciones de 32 bits
• Se desactiva si el manifiesto incluye requestedExecutionLevel
• Lo correcto es corregir la aplicación para que escriba en el destino adecuado³⁷

Es decir, puede parecer que una antigua aplicación de 32 bits “lograba escribir en Program Files incluso sin administrador”, pero quizá no estuviera escribiendo correctamente, sino que se estaba desviando a VirtualStore.

Por eso, en momentos como:

• Al pasar a 64 bits
• Al añadir un manifiesto
• Al cambiar el método de compilación
• Al avanzar en la conformidad con UAC

puede salir a la luz de repente un “error de diseño en el destino de guardado” que antes no se manifestaba.

6.4 El lugar donde se escribe en tiempo de ejecución no es el adecuado

En la práctica, esto termina siendo, con diferencia, lo más frecuente:

• Guardar la configuración junto al EXE
• Volcar los registros en la carpeta de instalación
• Crear archivos temporales bajo Program Files
• Escribir el estado propio de cada usuario en HKLM

Con este tipo de configuración se llega a una situación bastante incómoda: la aplicación en sí es una interfaz normal, pero su inicio requiere privilegio de administrador.⁴⁶

Los casos en los que se necesita administrador no porque el procesamiento sea avanzado, sino porque el destino de guardado es incorrecto, son realmente numerosos.

6.5 Procedimiento para averiguar a cuál de estos casos corresponde su aplicación

Los apartados 6.1 a 6.4 son “patrones de causa”, pero en una investigación real hace falta comprobar a cuál de ellos corresponde su propia aplicación. Basta con estos dos pasos, en este orden.

Paso 1: Revisar el requestedExecutionLevel del manifiesto

Primero se comprueba si la aplicación declara la elevación por sí misma. El manifiesto incrustado en el EXE puede extraerse con mt.exe del Windows SDK.

mt.exe -inputresource:MyApp.exe;#1 -out:MyApp.manifest

#1 es el ID de recurso del manifiesto incrustado en el ejecutable. Se revisa si en el XML extraído aparece una línea como esta:

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />

Si es requireAdministrator, la causa queda confirmada como la del apartado 6.1. Si es asInvoker, el origen no está en la declaración, así que se pasa al paso 2. También puede darse el caso de que no exista un manifiesto incrustado. Esto también es información relevante: un ejecutable de 32 bits sin requestedExecutionLevel puede corresponder tanto a la detección de instaladores del apartado 6.2 como a la virtualización del apartado 6.3.³

Paso 2: Comprobar si se creó una copia en VirtualStore

A continuación se comprueba si un archivo que se creía escrito en un área protegida está, en realidad, virtualizado. El destino de la redirección está predeterminado.

dir /s /a "%LocalAppData%\VirtualStore"

Si aquí aparecen los archivos de configuración o los registros de su aplicación, significa que la aplicación no estaba escribiendo en Program Files, sino que se estaba desviando a una copia propia de cada usuario. Por ejemplo, una escritura en C:\Program Files\Contoso\Settings.ini se redirige a %LocalAppData%\VirtualStore\Program Files\Contoso\Settings.ini.³

El destino de la virtualización en el Registro funciona igual: una escritura en HKEY_LOCAL_MACHINE\Software se redirige a HKEY_USERS\<SID del usuario>_Classes\VirtualStore\Machine\Software. Visto desde el usuario actual, se puede ver lo mismo abriendo HKEY_CURRENT_USER\Software\Classes\VirtualStore\Machine\Software en el Editor del Registro.⁷

Revisando estos dos puntos queda claro si la causa de “necesitar privilegio de administrador” es la declaración o el destino de guardado. Si la causa es el destino de guardado, lo correcto es corregir la ubicación tal como se indica en el apartado 7.3; añadir elevación no es una solución real.

7. Cómo diseñar la aplicación para reducir elevaciones innecesarias

7.1 La base es asInvoker

A menos que la aplicación entera sea realmente una herramienta de administración del sistema, la línea base es ejecutar la aplicación de interfaz habitual sin elevar. En cuanto al significado del manifiesto, asInvoker es la declaración de que “se ejecuta con el mismo privilegio que quien la inició”.¹³

Si se ejecuta como administrador incluso la operación habitual de pantalla, la lógica de negocio y el guardado de la configuración de cada usuario, aumentan problemas como:

• Se amplía la superficie de ataque
• Se vuelve difícil explicar la operación
• El UAC aparece cada vez
• Deja de verse con claridad “qué procesamiento realmente necesita administrador”

La guía de diseño de UAC de Microsoft también explica que deben eliminarse las elevaciones innecesarias, y que el privilegio de administrador debe reservarse solo para las tareas que de verdad lo necesitan.⁴

7.2 Separar solo los procesos que requieren administrador en otra unidad de ejecución

Microsoft Learn describe explícitamente modelos para que, incluso una aplicación con procesamiento que requiere privilegio de administrador, se ejecute como aplicación de usuario estándar y separe únicamente la parte necesaria.¹⁴

Los representativos son estos cuatro:

• Administrator Broker Model Aplicación de interfaz de usuario estándar + EXE auxiliar (helper) de administrador
• Operating System Service Model Interfaz de usuario estándar + servicio residente
• Elevated Task Model Interfaz de usuario estándar + tarea programada con el privilegio más alto
• Administrator COM Object Model Interfaz de usuario estándar + COM elevado

A grandes rasgos, la elección sería así:

• Si solo se necesita una operación de administrador de forma ocasional, un EXE auxiliar
• Si es constante, desatendida y frecuente, un servicio
• Si es un trabajo corto y repetitivo, una tarea con el privilegio más alto
• Si se parte de una integración COM ya existente, un COM elevado

Cómo concretar este diseño en una aplicación Windows se trata en detalle en otro artículo: Cómo separar en la práctica “solo el procesamiento que requiere privilegios de administrador” en una aplicación Windows

7.3 Corregir la ubicación de los datos en tiempo de ejecución

El principio del destino de guardado es bastante simple:

• Datos específicos del usuario: HKCU o %AppData%
• Caché exclusiva local: %LocalAppData%
• Datos compartidos pero que cambian en tiempo de ejecución: %ProgramData% + ACL
• El propio ejecutable: Program Files

Microsoft Learn también explica que la aplicación debería guardar los datos en una ubicación per-user o en %alluserprofile% (que en realidad es ProgramData) con la ACL correctamente configurada.⁷

Con esta organización resulta más fácil lograr que solo el instalador eleve, y que la aplicación en ejecución no lo haga.

7.4 Decidir primero entre per-user y per-machine

Este es un punto que sorprendentemente se pasa por alto con facilidad:

• ¿Debería cada usuario poder instalar la aplicación por sí mismo?
• ¿Debería instalarse en un único lugar común a todos los usuarios?
• ¿Quién se responsabiliza de las actualizaciones?
• ¿Es aceptable ejecutar el archivo ejecutable desde el perfil del usuario?

Si esta decisión queda ambigua, más adelante es fácil que la situación se vuelva confusa, con una mezcla de:

• Solo la instalación requiere administrador
• La ejecución también requiere administrador
• La actualización también requiere administrador
• Solo una parte se ejecuta en el contexto de usuario

La diferencia entre per-user y per-machine no es solo una cuestión de método de distribución, sino el propio diseño de privilegios.

8. ¿Hacia dónde se dirige Windows a partir de ahora?

A fecha de marzo de 2026, Windows 11 cuenta con una función llamada Administrator protection (preview). Microsoft Learn describe esta función como algo que mantiene un deprivileged state en condiciones normales y concede admin rights de forma just-in-time solo cuando es necesario.⁵

Además, Microsoft explica que, antes de operaciones que requieren privilegio de administrador —como instalar software, modificar configuraciones del sistema como la hora o el Registro, o acceder a datos sensibles—, se solicita una autenticación explícita.⁵

Esta función sigue en preview, y su implantación general también es gradual.⁵

Conviene tener presente aquí el significado práctico de que se trate de una preview. Las funciones marcadas como preview pueden cambiar de comportamiento y de opciones de configuración antes de su disponibilidad general, y ni siquiera está garantizado que puedan activarse en todos los entornos. Por eso, de momento es más seguro evitar usos como:

• Desplegarla en toda la organización como configuración estándar de producción
• Dar por sentado que esta función está activa y omitir el diseño de elevación en la propia aplicación
• Exigirla como requisito de funcionamiento en el entorno del cliente

La postura realista es comprobar el comportamiento en un entorno de pruebas y alinear solo el diseño con la premisa de que “en el futuro se avanzará en esta dirección”. Dicho de otro modo, si ya ahora se toma asInvoker como base y se minimiza la elevación, no habrá que apresurarse cuando esta función pase a disponibilidad general.

Aun así, la dirección general es bastante clara:

• No mantener siempre un token de administrador activo
• Elevar solo en el momento necesario
• Separar la sesión elevada
• Dejar más claro “cuándo, qué aplicación y por qué se convirtió en administrador”

En definitiva, puede darse por hecho que el diseño de “por ahora, ejecutarlo todo como administrador” será cada vez más incompatible con esta dirección.

9. Errores comunes de interpretación

9.1 “Soy usuario administrador, así que el UAC no debería aparecer”

Sí aparece. Con UAC activado, incluso un miembro del grupo Administrators ejecuta los procesos normales sin elevar, y solo eleva cuando es necesario.⁶²

9.2 “Toda instalación requiere administrador”

No necesariamente. Existen diseños que pueden distribuirse sin privilegio de administrador, como la instalación per-user en %LocalAppData%.¹¹¹²

9.3 “Como se instala en Program Files, la configuración también puede guardarse ahí”

No es correcto. El destino del ejecutable y el destino de los datos que cambian en tiempo de ejecución deben mantenerse separados. Microsoft también cita la escritura en tiempo de ejecución en Program Files o en HKLM como un ejemplo típico de elevación innecesaria.⁴⁷

9.4 “Basta con ejecutar como administrador para resolver todos los problemas de diseño”

No se resuelven. Aunque puede que funcione temporalmente, suelen empeorar la superficie de ataque, la operabilidad, la distribución y la facilidad de soporte. Además, tampoco es posible elevar de forma selectiva solo una parte dentro del mismo proceso.²¹⁴

9.5 “Antes funcionaba, así que sigue siendo correcto”

No siempre es así. Si una aplicación antigua de 32 bits simplemente “funcionaba por casualidad” gracias a la virtualización, el problema saldrá a la luz al pasar a 64 bits o al añadir un manifiesto. La virtualización es una medida provisional para la compatibilidad, no una solución a largo plazo.³⁷

10. Resumen

Si Windows requiere o no privilegio de administrador se decide, en una frase, por “a dónde se va a cambiar qué”.

• Si el cambio es para uno mismo, suele bastar con usuario estándar
• Si el cambio es para todos los usuarios o para toda la máquina, suele hacer falta administrador
• Si se toca un área protegida o un límite de seguridad del sistema operativo, se necesita privilegio de administrador

Y lo verdaderamente importante en la práctica es distinguir entre el procesamiento que realmente necesita privilegio de administrador y el procesamiento que termina necesitándolo solo por la elección del destino de guardado.

En particular, en el desarrollo de aplicaciones Windows resultan bastante eficaces las siguientes líneas:

• Tomar como base que la interfaz no eleve
• Separar el procesamiento de administrador en un EXE, servicio o tarea independiente
• Orientar los datos en tiempo de ejecución hacia AppData, HKCU o ProgramData
• Decidir primero entre per-user y per-machine

“Si hace falta privilegio de administrador” no es una cuestión de lo sofisticada que sea la aplicación. Es una cuestión de qué límite del sistema operativo se está tocando.

Adoptar esta perspectiva desde el principio aclara considerablemente el comportamiento de UAC, la elección del método de instalación y el diseño de la aplicación.

11. Artículos relacionados

• Cómo separar en la práctica “solo el procesamiento que requiere privilegios de administrador” en una aplicación Windows
• Lista de comprobación de seguridad mínima para el desarrollo de aplicaciones Windows
• Cómo elegir el método de distribución de una aplicación Windows - MSI/MSIX/ClickOnce/xcopy/actualizador propio

12. Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Por qué aparece el mensaje "La operación solicitada requiere privilegios de administrador"?

Aparece porque la aplicación intenta tocar un límite que afecta al sistema operativo o a toda la máquina. Los casos típicos son escribir en áreas protegidas como Program Files, Windows, System32 o HKLM, registrar o modificar la configuración de un servicio de Windows, instalar un controlador en modo kernel o cambiar reglas del firewall. También se solicita la elevación cuando el manifiesto de la aplicación declara requireAdministrator, o cuando el nombre del archivo contiene términos como install, setup o update y activa la detección de instaladores (installer detection) de Windows. Con mucha frecuencia esto no ocurre porque el procesamiento sea especialmente avanzado, sino simplemente porque la configuración o los registros se guardan en un área protegida.

¿Por qué aparece el UAC si mi cuenta es de administrador?

Porque, con UAC activado, incluso los procesos iniciados por un miembro del grupo Administrators se ejecutan con privilegios de usuario estándar salvo que se eleven de forma explícita. Aunque su cuenta de Windows sea de administrador, la aplicación que acaba de iniciar se ejecuta sin elevar, y que el UAC aparezca justo en el momento en que se necesita un privilegio de administrador es un comportamiento perfectamente normal en Windows. Conviene tratar como dos cuestiones distintas que el usuario pertenezca al grupo Administrators y que la aplicación se esté ejecutando con un token de acceso de administrador.

¿Instalar una aplicación siempre requiere privilegios de administrador?

No necesariamente. Existen diseños de instalación per-user, que se colocan bajo %LocalAppData%, capaces de distribuirse y actualizarse sin privilegios de administrador. Como ejemplo real, la instalación per-user del cliente de Escritorio remoto se coloca bajo la carpeta LocalAppData de cada perfil de usuario y puede actualizarse sin privilegios de administrador, y OneDrive también se instala de forma per-user de manera predeterminada. Es más probable que se necesite administrador en las instalaciones per-machine, orientadas a todos los usuarios, que escriben en Program Files o en HKLM. La elección entre per-user y per-machine no es una cuestión de método de distribución, sino el propio diseño de privilegios, por lo que debe decidirse desde el principio.

¿Se puede ejecutar solo una parte del procesamiento de una aplicación con privilegios de administrador?

No es posible convertir en administrador solo algunos métodos dentro del mismo proceso justo en el instante en que se pulsa un botón. El UAC depende del token con el que se ejecuta el proceso, y los procesos hijos heredan el token del padre. Si se necesita, hay que separar esa parte en otra unidad de ejecución. Los modelos representativos son cuatro: el Administrator Broker Model, que combina una interfaz de usuario estándar con un EXE auxiliar (helper) de administrador; el Operating System Service Model, que usa un servicio residente; el Elevated Task Model, que usa una tarea programada con el nivel de privilegio más alto; y el Administrator COM Object Model, que usa un objeto COM elevado.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.