Requisitos de desarrollo de aplicaciones de Windows Vista para la compatibilidad del control de cuentas de usuario

 

Jennifer Allen

Actualizado junio de 2007

Resumen: Estas notas del producto están diseñadas para ayudar a los desarrolladores de aplicaciones a diseñar aplicaciones compatibles con Windows Vista compatibles con el control de cuentas de usuario. Se incluyen pasos detallados sobre el proceso de diseño, junto con ejemplos de código, requisitos y procedimientos recomendados. En este documento también se detallan las actualizaciones técnicas y los cambios en la experiencia del usuario en Windows Vista. (71 páginas impresas).

Contenido

¿Por qué el control de cuentas de usuario?
Windows Vista Novedades
Nuevas tecnologías para Windows Vista
Arquitectura de UAC
¿Afectará UAC a la aplicación?
Diseño de aplicaciones para Windows Vista
Implementación y aplicación de revisiones para usuarios estándar
Solucionar los problemas comunes
Referencias

¿Por qué el control de cuentas de usuario?

Los desarrolladores de aplicaciones han creado de forma coherente aplicaciones de Windows que requieren derechos de usuario excesivos y privilegios de Windows, a menudo que requieren que el usuario en ejecución sea administrador. Como resultado, pocos usuarios de Windows se ejecutan con los derechos de usuario mínimos y los privilegios de Windows necesarios. Muchas empresas, que buscan equilibrar la facilidad de implementación y facilidad de uso con la seguridad, a menudo han recurrido a implementar sus escritorios como administrador debido a problemas de compatibilidad de aplicaciones de usuario estándar.

En la lista siguiente se detallan otros motivos por los que es difícil ejecutarse como usuario estándar en equipos anteriores a Microsoft Windows Vista:

1. Muchas aplicaciones de Windows requieren que el usuario que ha iniciado sesión sea administrador, pero que realmente no requiera acceso de nivel de administrador. Estas aplicaciones realizan diversas comprobaciones de acceso de administrador antes de poder ejecutarse, entre las que se incluyen:
   • Comprobación del token de acceso de administrador.
   • Solicitudes de acceso "Todo el acceso" en ubicaciones protegidas por el sistema.
   • Escriba datos en ubicaciones protegidas, como %ProgramFiles%, %WinDir%y HKLM\Software.
2. Muchas aplicaciones de Windows no están diseñadas con el concepto de privilegios mínimos y no separan la funcionalidad de usuario y administrador en dos procesos independientes.
3. Windows 2000 y Windows XP crean cada nueva cuenta de usuario como administrador de forma predeterminada; por lo tanto, los componentes clave de Windows, como la fecha y la hora y los paneles de control de administración de energía no funcionan bien para un usuario estándar.
4. Los administradores de Windows 2000 y Windows XP deben crear dos cuentas de usuario independientes: una para tareas administrativas y una cuenta de usuario estándar para realizar tareas diarias. Por lo tanto, los usuarios deben cerrar sesión en sus cuentas de usuario estándar y volver a iniciar sesión como administrador o usar Run As para realizar cualquier tarea administrativa.

Con el Control de cuentas de usuario (UAC), Microsoft proporciona una tecnología para simplificar la implementación de escritorios de usuario estándar, en la empresa y en casa.

La creación a partir de la arquitectura de seguridad de Windows como se diseñó originalmente en el sistema operativo Microsoft Windows NT 3.1, el equipo de UAC buscaba implementar un modelo de usuario estándar que era flexible y más seguro. En versiones anteriores de Windows, se crea un token de acceso para un administrador durante el proceso de inicio de sesión. El token de acceso del administrador incluye la mayoría de los privilegios de Windows y la mayoría de los identificadores de seguridad administrativos (SID). Este token de acceso garantiza que un administrador pueda instalar aplicaciones, configurar el sistema operativo y acceder a cualquier recurso.

El equipo de UAC tomó un enfoque drásticamente diferente para el proceso de creación de tokens de acceso en Windows Vista. Cuando un usuario administrador inicia sesión en un equipo con Windows Vista, se crean dos tokens de acceso: un token de acceso de usuario estándar filtrado y un token de acceso de administrador completo. En lugar de iniciar el escritorio (Explorer.exe) con el token de acceso del administrador, se usa el token de acceso de usuario estándar. Todos los procesos secundarios heredan de este inicio inicial del escritorio (el proceso de explorer.exe), lo que ayuda a limitar la superficie expuesta a ataques de Windows Vistas. De forma predeterminada, todos los usuarios, incluidos los administradores, inician sesión en un equipo con Windows Vista como usuarios estándar.

Nota Hay una excepción a la instrucción anterior: los invitados inician sesión en el equipo con menos derechos de usuario y privilegios que los usuarios estándar.

Cuando un administrador intenta realizar una tarea administrativa, como instalar una aplicación, UAC solicita al usuario que apruebe la acción. Cuando el usuario aprueba la acción, se inicia la tarea con el token de acceso de administrador completo del administrador. Este es el comportamiento predeterminado del mensaje de administrador y se puede configurar en el complemento administrador de directivas de seguridad local (secpol.msc) y con directiva de grupo (gpedit.msc).

Nota Una cuenta de administrador en un equipo windows Vista con UAC habilitado también se denomina cuenta de administrador en Administración modo de aprobación. Administración modo de aprobación identifica la experiencia de usuario predeterminada para los administradores.

Cada elevación administrativa también es específica del proceso, lo que impide que otros procesos usen el token de acceso sin pedir al usuario su aprobación. Como resultado, los usuarios administradores tienen un control más pormenorizado sobre qué aplicaciones se instalan, mientras que afectan considerablemente al software malintencionado que espera que el usuario que haya iniciado sesión se ejecute con un token de acceso de administrador completo.

Los usuarios estándar también tienen la oportunidad de elevar en flujo y realizar tareas administrativas mediante la infraestructura de UAC. Cuando un usuario estándar intenta realizar una tarea administrativa, UAC solicita al usuario que escriba credenciales válidas para una cuenta de administrador. Este es el comportamiento predeterminado de la solicitud de usuario estándar y se puede configurar en el complemento del Administrador de directivas de seguridad local (secpol.msc) y con directiva de grupo (gpedit.msc).

Windows Vista Novedades

Las siguientes actualizaciones reflejan los cambios principales acumulativos en la funcionalidad que se han producido en Windows Vista.

UAC está habilitado de forma predeterminada

Como resultado, es posible que encuentre algunos problemas de compatibilidad con diferentes aplicaciones que aún no se han actualizado para el componente UAC de Windows Vista. Si una aplicación requiere un token de acceso de administrador (esto indica que se devuelve un error de "acceso denegado" al intentar ejecutar la aplicación), puede ejecutar el programa como administrador mediante la opción Ejecutar como administrador en el menú contextual (haga clic con el botón derecho). Cómo hacerlo se documenta más adelante en este documento en la sección Programas en ejecución como administrador.

Todas las cuentas de usuario posteriores se crean como usuarios estándar

Tanto las cuentas de usuario estándar como las cuentas de usuario administrador pueden aprovechar la seguridad mejorada de UAC. En las nuevas instalaciones, de forma predeterminada, la primera cuenta de usuario creada es una cuenta de administrador local en Administración modo de aprobación (UAC habilitado). A continuación, todas las cuentas posteriores se crean como usuarios estándar.

Las solicitudes de elevación se muestran en el escritorio seguro de forma predeterminada

Las solicitudes de consentimiento y credenciales se muestran en el escritorio seguro de forma predeterminada en Windows Vista.

Las solicitudes de elevación para las aplicaciones en segundo plano se minimizan en la barra de tareas.

Las aplicaciones en segundo plano solicitarán automáticamente al usuario la elevación en la barra de tareas, en lugar de ir automáticamente al escritorio seguro para la elevación. El mensaje de elevación aparecerá minimizado en la barra de tareas y parpadeará para notificar al usuario que una aplicación ha solicitado elevación. Un ejemplo de elevación en segundo plano se produce cuando un usuario navega a un sitio web y comienza a descargar un archivo de instalación. A continuación, el usuario va a comprobar el correo electrónico mientras la instalación se descarga en segundo plano. Una vez completada la descarga en segundo plano y comienza la instalación, la elevación se detecta como una tarea en segundo plano en lugar de una tarea en primer plano. Esta detección impide que la instalación robe abruptamente el foco de la pantalla del usuario mientras el usuario realiza otra tarea, leyendo el correo electrónico. Este comportamiento crea una mejor experiencia de usuario para el mensaje de elevación. Información sobre cómo los desarrolladores de aplicaciones pueden asegurarse de que sus aplicaciones no se minimizan en la barra de tareas cuando solicitan elevación está disponible más adelante en este documento.

Las elevaciones se bloquean en la ruta de acceso de inicio de sesión del usuario

Las aplicaciones que comienzan cuando el usuario inicia sesión y requieren elevación ahora se bloquean en la ruta de acceso de inicio de sesión. Sin bloquear que las aplicaciones pidan elevación en la ruta de acceso de inicio de sesión del usuario, tanto los usuarios estándar como los administradores tendrán que responder a un cuadro de diálogo Control de cuentas de usuario en cada inicio de sesión. Windows Vista notifica al usuario si se ha bloqueado una aplicación colocando un icono en la bandeja del sistema. A continuación, el usuario puede hacer clic con el botón derecho en este icono para ejecutar aplicaciones que se bloquearon para solicitar la elevación cuando el usuario inició sesión. El usuario puede administrar qué aplicaciones de inicio se deshabilitan o quitan de esta lista haciendo doble clic en el icono de la bandeja.

La cuenta de administrador integrada está deshabilitada de forma predeterminada en nuevas instalaciones

La cuenta de administrador integrada está deshabilitada de forma predeterminada en Windows Vista. Si Windows Vista determina durante una actualización de Windows XP que el administrador integrado es la única cuenta de administrador local activa, Windows Vista deja habilitada la cuenta y coloca la cuenta en modo de aprobación Administración. La cuenta de administrador integrada, de forma predeterminada, no puede iniciar sesión en el equipo en modo seguro. Consulte las secciones siguientes para obtener más información. La cuenta de administrador integrada se crea durante la instalación con el nombre de usuario Administrador.

No unido a un dominio

Cuando haya al menos una cuenta de administrador local habilitada, el modo seguro no permitirá iniciar sesión con la cuenta de administrador integrada deshabilitada. En su lugar, se puede usar cualquier cuenta de administrador local para iniciar sesión. Si la última cuenta de administrador local se degrada, deshabilita o elimina accidentalmente, el modo seguro permitirá que la cuenta de administrador integrada deshabilitada inicie sesión para la recuperación ante desastres.

Unido a dominio

La cuenta de administrador integrada deshabilitada en todos los casos no puede iniciar sesión en modo seguro. Una cuenta de usuario que sea miembro del grupo Administradores de dominio puede iniciar sesión en el equipo para crear un administrador local si no existe ninguno.

Nota Si la cuenta administrativa de dominio nunca había iniciado sesión antes, el equipo debe iniciarse en modo seguro con redes, ya que las credenciales no se habrán almacenado en caché.

Nota Una vez que se desenlace la máquina, se revertirá al comportamiento no unido a un dominio descrito anteriormente.

Control de cuentas de usuario y escenarios remotos

Cuando un administrador inicia sesión en un equipo con Windows Vista de forma remota, a través de Escritorio remoto, por ejemplo, el usuario inicia sesión en el equipo como un usuario estándar de forma predeterminada. La administración remota se ha modificado para que sea restrictiva en la conexión. Esto ayuda a evitar que el software malintencionado realice "bucles invertidos" de la aplicación si un usuario se ejecuta con potencial administrativo.

cuentas de usuario local

Cuando un usuario con una cuenta de administrador en la base de datos local del Administrador de cuentas de seguridad (SAM) del equipo Windows Vista se conecta de forma remota a un equipo de Windows Vista, el usuario no tiene ningún potencial de elevación en el equipo remoto y no puede realizar tareas administrativas. Si el usuario quiere administrar la estación de trabajo con una cuenta SAM, el usuario debe iniciar sesión interactivamente en el equipo que se va a administrar.

Cuentas de usuario de dominio

Cuando un usuario con una cuenta de usuario de dominio inicia sesión en un equipo de Windows Vista de forma remota donde el usuario es miembro del grupo Administradores, el usuario del dominio se ejecutará con un token de acceso de administrador completo en el equipo remoto y UAC no estará en vigor.

Nueva configuración predeterminada de lista de Access Control (ACL)

Las ACL de determinados directorios de Windows se han cambiado para permitir el uso compartido de datos y la colaboración en directorios de datos y fuera de los directorios protegidos de los usuarios. El directorio protegido de un usuario es su perfil de usuario (por ejemplo, C:\Users\Denise\Pictures\), mientras que un ejemplo de directorio de datos está situado fuera de la partición del sistema operativo en una unidad de datos (por ejemplo, D:\Pictures\). Dado que el directorio raíz, C en este caso, está protegido por ACL más restrictivas, los usuarios no pudieron usar directorios de datos en versiones anteriores de Windows Vista.

Estos cambios de ACL garantizan que los usuarios puedan compartir y editar archivos sin tener que proporcionar aprobación a un cuadro de diálogo Control de cuentas de usuario. Además, los usuarios ahora pueden hacer que una carpeta sea privada. Este cambio garantiza que los usuarios puedan mantener fácilmente la confidencialidad y la integridad de los datos en las unidades de datos. Otros administradores seguirán leyendo estas carpetas privadas si elevan y deben usarse para mantener los datos privados de los usuarios estándar.

A continuación se muestran las opciones de ACL predeterminadas en %systemroot% y la unidad de datos en Windows XP.

Configuración de ACL de %systemroot% y unidad de datos de Windows XP

Usuario o grupo	entrada de Access Control
BUILTIN\Administrators	Control total
NT AUTHORITY\SYSTEM	Control total
CREATOR OWNER	Control total
BUILTIN\Users	Lectura Acceso especial: FILE_APPEND_DATA Acceso especial: FILE_WRITE_DATA
Todos	Lectura

En la tabla siguiente se detalla la nueva configuración de ACL de la unidad de datos de Windows Vista para las unidades de datos creadas con format.exe.

Configuración de la ACL de la unidad de datos de Windows Vista

Usuario o grupo	entrada de Access Control
BUILTIN\Administrators	Control total
NT AUTHORITY\SYSTEM	Control total
NT AUTHORITY\Authenticated Users	Modificar
BUILTIN\Users	Leer y ejecutar Lectura genérica, ejecución genérica

En la tabla siguiente se detalla la nueva configuración de ACL de la raíz del sistema operativo Windows Vista (%systemroot%) .

Configuración de ACL de %systemroot% de Windows Vista

Usuario o grupo	entrada de Access Control
BUILTIN\Administrators	Control total
NT AUTHORITY\SYSTEM	Control total
BUILTIN\Users	Leer y ejecutar
NT AUTHORITY\Authenticated Users	Modificar Anexión de datos
Etiqueta obligatoria\Alto nivel obligatorio	Sin escritura

Nuevos cambios en la configuración de seguridad de UAC y el nombre de la configuración de seguridad

Las nuevas actualizaciones de configuración de seguridad y nombre de configuración de seguridad se detallan en la sección Referencias de este documento.

Nuevas tecnologías para Windows Vista

En las secciones siguientes se detallan nuevas tecnologías para Windows Vista, incluida la detección de instaladores, la aplicación de revisiones de usuario estándar con Windows Installer 4.0, el aislamiento de privilegios de la interfaz de usuario y la virtualización.

Servicio del instalador de ActiveX

El servicio de instalador de ActiveX permite a las empresas delegar la instalación del control ActiveX para los usuarios estándar. Este servicio garantiza que las tareas empresariales rutinarias no se ven impedidas por las actualizaciones y las instalaciones de control ActiveX con errores. Windows Vista también incluye directiva de grupo configuración que permite a los profesionales de TI definir direcciones URL de host desde las que los usuarios estándar pueden instalar controles ActiveX. El servicio de instalador de ActiveX consta de un servicio de Windows, una plantilla administrativa de directiva de grupo y algunos cambios en Internet Explorer y es un componente opcional que solo se habilitará en los clientes en los que está instalado.

Detección del instalador

Los programas de instalación son aplicaciones diseñadas para implementar software y la mayoría de escritura en directorios del sistema y claves del Registro. Estas ubicaciones protegidas del sistema suelen ser grabables solo por los usuarios administradores; esto significa que los usuarios estándar no tienen acceso suficiente para instalar programas. Windows Vista detecta heurísticamente los programas de instalación y solicita credenciales de administrador o aprobación del usuario administrador para ejecutar con privilegios de acceso. Windows Vista también detecta heurísticamente los programas de actualización y desinstalación. Tenga en cuenta que un objetivo de diseño de UAC es evitar que las instalaciones se ejecuten sin el conocimiento y el consentimiento del usuario, ya que escriben en áreas protegidas del sistema de archivos y el registro.

Importante Al desarrollar nuevos programas de instalación, al igual que desarrollar programas para Windows Vista, asegúrese de insertar un manifiesto de aplicación con un elemento requestedExecutionLevel adecuado (vea la sección Step Six: Create and Embed an Application Manifest with Your Application). Cuando requestedExecutionLevel está presente en el manifiesto de aplicación incrustado, invalida la detección del instalador.

La detección del instalador solo se aplica a:

• Ejecutables de 32 bits
• Aplicaciones sin requestedExecutionLevel
• Procesos interactivos que se ejecutan como un usuario estándar con LUA habilitado

Antes de crear un proceso de 32 bits, se comprueban los siguientes atributos para determinar si es un instalador:

• El nombre de archivo incluye palabras clave como "install", "setup", "update", etc.
• Palabras clave en los siguientes campos de recursos de control de versiones: Proveedor, Nombre de empresa, Nombre de producto, Descripción del archivo, Nombre de archivo original, Nombre interno y Nombre de exportación.
• Palabras clave en el manifiesto en paralelo incrustado en el archivo ejecutable.
• Palabras clave en entradas de StringTable específicas vinculadas en el archivo ejecutable.
• Atributos clave de los datos rc vinculados en el archivo ejecutable.
• Secuencias de destino de bytes dentro del ejecutable.

Nota Las palabras clave y secuencias de bytes se derivaron de características comunes observadas a partir de diversas tecnologías del instalador.

Asegúrese de revisar exhaustivamente la totalidad de este documento, incluida la sección Step Six: Create and Embed an Application Manifest with Your Application (Paso seis: crear e insertar un manifiesto de aplicación con la aplicación).

Nota El control de cuentas de usuario: detectar instalaciones de aplicaciones y solicitar la configuración de elevación debe estar habilitada para que la detección del instalador detecte programas de instalación. Esta configuración está habilitada de forma predeterminada y se puede configurar con el complemento Administrador de directivas de seguridad (secpol.msc) o con directiva de grupo (gpedit.msc).

Puede encontrar información general y información general sobre Microsoft Windows Installer en MSDN Library.

Aplicación de revisiones en un entorno UAC

Microsoft Windows Installer 4.0 se diseñó teniendo en cuenta UAC para facilitar las instalaciones de aplicaciones y la aplicación de revisiones. Con la introducción de Windows Installer 4.0, las revisiones se pueden aplicar a las aplicaciones sin volver a instalar una versión más reciente de la aplicación. Este método es ideal cuando un usuario debe implementar una aplicación en una instalación por equipo y es necesario implementar revisiones sin necesidad de un token de acceso administrativo. Para obtener información sobre cómo crear y aplicar revisiones a las aplicaciones, consulte Aplicación de revisiones Per-User aplicaciones administradas.

Integración en Security Center

Cuando UAC está deshabilitado en un equipo con Windows Vista, Security Center crea una alerta y solicita al usuario que vuelva a habilitar UAC. Security Center muestra esta alerta una vez que el equipo se ha reiniciado después de cambiar la configuración de UAC.

Aislamiento de privilegios de la interfaz de usuario

El aislamiento de privilegios de la interfaz de usuario (UIPI) es uno de los mecanismos que ayudan a aislar las aplicaciones que se ejecutan como un administrador completo de los procesos que se ejecutan como una cuenta inferior a un administrador en el mismo escritorio interactivo. UIPI es específico del subsistema de ventanas y gráficos conocido como USER que admite controles de interfaz de usuario y ventanas. UIPI impide que una aplicación con privilegios inferiores use mensajes de Windows para enviar la entrada de un proceso a un proceso de privilegios más alto. El envío de entradas de un proceso a otro permite que un proceso inserte entradas en otro proceso sin que el usuario proporcione acciones de teclado o mouse.

El concepto detrás de UIPI es sencillo. Windows Vista define un conjunto de niveles de privilegios de interfaz de usuario de forma jerárquica. La naturaleza de los niveles es tal que los niveles de privilegios superiores pueden enviar mensajes de ventana a las aplicaciones que se ejecutan en niveles inferiores. Sin embargo, los niveles inferiores no pueden enviar mensajes de ventana a ventanas de aplicación en niveles superiores.

El nivel de privilegios de la interfaz de usuario está en el nivel de proceso. Cuando se inicializa un proceso, el subsistema de usuario llama al subsistema de seguridad para determinar el nivel de integridad de escritorio asignado en el token de acceso de seguridad del proceso. El subsistema de seguridad establece el nivel de integridad de escritorio cuando se crea el proceso y no cambia. Por lo tanto, el subsistema de usuario también establece el nivel de privilegio de la interfaz de usuario cuando se crea el proceso y no cambia.

Todas las aplicaciones ejecutadas por un usuario estándar tienen el mismo nivel de privilegio de interfaz de usuario. Como usuario estándar, las aplicaciones se ejecutan en un nivel de privilegio único. UIPI no interfiere ni cambia el comportamiento de la mensajería de ventana entre las aplicaciones en el mismo nivel de privilegios. UIPI entra en vigor para un usuario que es miembro del grupo de administradores y puede ejecutar aplicaciones como un usuario estándar (a veces denominado proceso con un token de acceso filtrado) y también procesos que se ejecutan con un token de acceso de administrador completo en el mismo escritorio. UIPI impide que los procesos de privilegios inferiores accedan a procesos de privilegios más elevados bloqueando el siguiente comportamiento.

Un proceso de privilegios inferiores no puede:

• Realice una validación de identificador de ventana de privilegios de proceso más altos.
• SendMessage o PostMessage a ventanas de aplicación con privilegios más elevados. Estas interfaces de programación de aplicaciones (API) devuelven éxito, pero quitan silenciosamente el mensaje de la ventana.
• Use enlaces de subprocesos para asociar a un proceso de privilegios más alto.
• Use enlaces de diario para supervisar un proceso de privilegios más alto.
• Realice la inserción dinámica de la biblioteca de vínculos (DLL) en un proceso de privilegios más alto.

Con UIPI habilitado, los siguientes recursos de USUARIO compartidos se siguen compartiendo entre procesos en distintos niveles de privilegios:

• Ventana de escritorio, que posee realmente la superficie de pantalla
• Memoria compartida de solo lectura del montón de escritorio
• Tabla atom global
• Portapapeles

Pintar en la pantalla es otra acción que no está bloqueada por UIPI. Pintar en la pantalla hace referencia al proceso de usar el método Paint para mostrar contenido en una salida externa, por ejemplo, un monitor. El modelo de interfaz de dispositivo USER/graphics (GDI) no permite el control sobre superficies de pintura; por lo tanto, es posible que una aplicación con privilegios inferiores pinte sobre la región expuesta de una ventana de aplicación con privilegios más elevados.

Nota Dado que el Shell de Windows (Explorador) se ejecuta como un proceso de usuario estándar, cualquier otro proceso que se ejecute como usuario estándar todavía puede enviarlo pulsaciones de teclas. Esta es la razón principal por la que se solicita un consentimiento de elevación a una cuenta de administrador en Administración modo de aprobación cuando inicia una acción administrativa, como hacer doble clic en un Setup.exe o hacer clic en un icono de escudo de elevación.

Virtualización

Importante La virtualización se implementa para mejorar los problemas de compatibilidad de aplicaciones para las aplicaciones que se ejecutan como usuario estándar en Windows Vista. Los desarrolladores no deben confiar en que la virtualización esté presente en versiones posteriores de Windows.

Antes de Windows Vista, muchas aplicaciones se ejecutaban normalmente por los administradores. Como resultado, las aplicaciones podrían leer y escribir libremente archivos del sistema y claves del Registro. Si un usuario estándar ejecutara estas aplicaciones, se produciría un error debido a un acceso insuficiente. Windows Vista mejora la compatibilidad de las aplicaciones para estos usuarios redirigiendo escrituras (y operaciones posteriores de archivo o registro) a una ubicación por usuario dentro del perfil del usuario. Por ejemplo, si una aplicación intenta escribir en C:\Program Files\Contoso\Settings.ini y el usuario no tiene permisos para escribir en ese directorio, la escritura se redirigirá a C:\Users\<user name>\AppData\Local\VirtualStore\Program Files\contoso\settings.ini. En el registro, si una aplicación intenta escribir en HKEY_LOCAL_MACHINE\Software\Contoso\ se le redirigirá automáticamente a HKEY_CURRENT_USER\Software\Classes\VirtualStore\MACHINE\Software\Contoso o HKEY_USERS\< SID >de usuario _Classes\VirtualStore\Machine\Software\Contoso.

En la ilustración siguiente se detalla el proceso de virtualización en Windows Vista. En este ejemplo, Denise es un administrador en Administración modo de aprobación y Brian es un usuario estándar. La virtualización se compone de dos componentes: virtualización de archivos y virtualización del registro.

Figura 1. Proceso de virtualización

Importante Al desarrollar programas de Windows Vista, para reducir la complejidad de los archivos virtualizados y las claves del Registro, asegúrese de insertar un manifiesto de aplicación con un valor requestedExecutionLevel adecuado para desactivar la virtualización de archivos y registros.

La virtualización solo está habilitada para:

• Procesos interactivos de 32 bits
• Claves del Registro y archivos y carpetas que se pueden escribir por el administrador

La virtualización está deshabilitada para:

• Procesos de 64 bits
• Procesos no interactivos
• Procesos que suplantan
• Llamadores de modo kernel
• Ejecutables que tienen un objeto requestedExecutionLevel

Virtualización y itinerancia:

• Los archivos o carpetas de virtualización y las claves del Registro no se mueven (consulte perfiles móviles)
• Asociado a objetos globales que no se mueven

Virtualización de archivos

La virtualización de archivos aborda la situación en la que una aplicación depende de la capacidad de almacenar un archivo, como un archivo de configuración, en una ubicación del sistema que normalmente solo los administradores pueden escribir. La ejecución de programas como usuario estándar en esta situación podría provocar errores de programa debido a niveles de acceso insuficientes.

Cuando una aplicación escribe en una ubicación del sistema solo se puede escribir por parte de los administradores, Windows escribe todas las operaciones de archivo posteriores en una ruta de acceso específica del usuario en el directorio de la Tienda virtual, que se encuentra en %LOCALAPPDATA%\VirtualStore. Más adelante, cuando la aplicación lee este archivo, el sistema proporcionará el que se encuentra en la Tienda virtual. Dado que la infraestructura de seguridad de Windows procesa la virtualización sin la asistencia de la aplicación, la aplicación cree que pudo leer y escribir correctamente en archivos de programa. La transparencia de la virtualización de archivos permite a las aplicaciones la percepción de que están escribiendo y leyendo desde el recurso protegido, cuando, de hecho, acceden a la versión virtualizada.

Nota Al enumerar los recursos en carpetas y en el Registro, Windows Vista combinará las claves del Registro o archivo globales en una sola lista. En esta vista combinada, el recurso global (protegido) aparece junto con el recurso virtualizado.

Importante La copia virtual siempre estará presente en la aplicación en primer lugar. Por ejemplo, config.ini está disponible en \PF\App\config.ini y %LOCALAPPDATA%\VirtualStore\config.ini, y el config.ini en el almacén virtual siempre será el que se lee, incluso si se actualiza \PF\App\config.ini.

En la ilustración siguiente se detalla cómo se muestran las vistas globales y combinadas de los recursos virtualizados para distintos usuarios.

Ilustración 2. Recursos y vistas virtualizados

A continuación se muestra un ejemplo del proceso de virtualización de archivos:

Syed Maze, representante de ventas de Woodgrove Bank, se está ejecutando con una cuenta de usuario estándar en un equipo que comparte con otros representantes de ventas. Syed suele usar una aplicación de hoja de cálculo para actualizar y guardar un archivo en el directorio Archivos de programa\SalesV1\: \Program Files\SalesV1\SalesData.txt. Aunque Archivos de programa\SalesV1\ está protegido, el archivo se guardará correctamente desde el punto de vista de la aplicación de hoja de cálculo debido a la virtualización de archivos de Windows Vista. Para ello, la escritura del archivo se redirige a Users\username\appdata\Virtual Store\Program Files\SalesV1\SalesData.txt. Cuando Syed abra el Explorador de Windows y vaya al directorio Archivos de programa, verá la vista global del archivo SalesData.txt.

Nota Para que Syed detecte sus archivos virtualizados, debe ir al almacén virtual con el botón Archivos de compatibilidad de la barra de herramientas del Explorador.

Sin embargo, después de Stuart Munson, otro representante de ventas, inicia sesión en la estación de trabajo, no verá el archivo SalesData.txt en el directorio Archivos de programa\SalesV1\. Si otro usuario usa el equipo y escribe el archivo \Program files\SalesV1\SalesData.txt, esa escritura también se virtualizará en el almacén virtual de ese usuario. Los archivos Actualizaciones y guardados de Syed permanecerán independientes de los demás archivos virtualizados en el sistema.

Virtualización del registro

La virtualización del Registro es similar a la virtualización de archivos, pero se aplica a las claves del Registro en HKEY_LOCAL_MACHINE\SOFTWARE. Esta característica permite a las aplicaciones que dependen de la capacidad de almacenar información de configuración en HKEY_LOCAL_MACHINE\SOFTWARE continuar cuando se ejecutan en una cuenta de usuario estándar. Las claves y los datos se redirigen a HKEY_CLASSES_ROOT\VirtualStore\SOFTWARE. Como en el caso de virtualización de archivos, cada usuario tiene una copia virtualizada de los valores almacenados en HKLM.

Detalles de virtualización del Registro

• Se puede activar o desactivar en claves individuales en el subárbol de software
• Nueva opción FLAGS en reg.exe para el control de virtualización de nivel de clave: permite habilitar o deshabilitar recursivamente la virtualización y el control de la "directiva de acceso abierto"
• ZwQueryKey: consulta mediante programación las marcas de virtualización de una clave.
• La virtualización se produce sobre el redireccionamiento de WoW64
• Habilitado en las vistas del Registro de 64 y 32 bits: HKU\{SID}_Classes\VirtualStore\Machine\Software y HKU\{SID}_Classes\VirtualStore\Machine\Software\SYSWOW3264
• La mayoría de las aplicaciones de 32 bits heredadas usarán la vista de 32 bits

La virtualización solo está pensada para ayudar en la compatibilidad de aplicaciones con programas existentes. Las aplicaciones diseñadas para Windows Vista NO deben realizar escrituras en áreas del sistema confidenciales, ni deben depender de la virtualización para proporcionar reparación para un comportamiento incorrecto de la aplicación. Al actualizar el código existente para que se ejecute en Windows Vista, los desarrolladores deben asegurarse de que, durante el tiempo de ejecución, las aplicaciones solo almacenan datos en ubicaciones por usuario o en ubicaciones de equipos dentro de %alluserprofile% (CSIDL_COMMON_APPDATA) que tengan correctamente establecida la configuración de la lista de control de acceso (ACL).

Importante Microsoft pretende quitar la virtualización de versiones futuras del sistema operativo Windows a medida que se migran más aplicaciones a Windows Vista. Por ejemplo, la virtualización está deshabilitada en aplicaciones de 64 bits.

Recomendaciones de virtualización

La virtualización solo está pensada para ayudar en la compatibilidad de aplicaciones con programas existentes. Las aplicaciones diseñadas para Windows Vista NO deben realizar escrituras en áreas del sistema confidenciales, ni deben depender de la virtualización para proporcionar reparación para un comportamiento incorrecto de la aplicación. Al actualizar el código existente para que se ejecute en Windows Vista, los desarrolladores deben asegurarse de que, durante el tiempo de ejecución, las aplicaciones solo almacenan datos en ubicaciones por usuario o en ubicaciones de equipos dentro de %alluserprofile% que tengan correctamente establecida la configuración de la lista de control de acceso (ACL).

Importante Microsoft pretende quitar la virtualización de versiones futuras del sistema operativo Windows a medida que se migran más aplicaciones a Windows Vista. Por ejemplo, la virtualización está deshabilitada en aplicaciones de 64 bits.

• Agregue un manifiesto de aplicación con un valor requestedExecutionLevel adecuado para las aplicaciones interactivas. Esto desactivará la virtualización para la aplicación manifiesto.
• No use el Registro como mecanismo de comunicación entre procesos. Los servicios y las aplicaciones de usuario tendrán vistas diferentes de la clave.
• Probar la aplicación en Windows Vista: asegúrese de que los procesos que se ejecutan como usuario estándar no escriben en espacios de nombres globales como %systemroot%.
• Para desarrolladores de controladores de filtros: compruebe el intervalo de altitud. Consulte Filtros del sistema de archivos. Deben ser mayores que la virtualización de FSFilter.
• Recuerde que los recursos virtualizados son copias por usuario de los recursos globales.

Cambios en el token de acceso

Cuando un usuario inicia sesión en un equipo con Windows Vista, Windows examina los privilegios administrativos de Windows e identificadores relativos (RID) que posee la cuenta de usuario para determinar si el usuario debe recibir dos tokens de acceso (un token de acceso filtrado y un token de acceso completo). Windows creará dos tokens de acceso para el usuario si se cumple alguna de las siguientes condiciones:

1. La cuenta del usuario contiene cualquiera de los siguientes RID.
   • DOMAIN_GROUP_RID_ADMINS
   • DOMAIN_GROUP_RID_CONTROLLERS
   • DOMAIN_GROUP_RID_CERT_ADMINS
   • DOMAIN_GROUP_RID_SCHEMA_ADMINS
   • DOMAIN_GROUP_RID_ENTERPRISE_ADMINS
   • DOMAIN_GROUP_RID_POLICY_ADMINS
   • DOMAIN_ALIAS_RID_ADMINS
   • DOMAIN_ALIAS_RID_POWER_USERS
   • DOMAIN_ALIAS_RID_ACCOUNT_OPS
   • DOMAIN_ALIAS_RID_SYSTEM_OPS
   • DOMAIN_ALIAS_RID_PRINT_OPS
   • DOMAIN_ALIAS_RID_BACKUP_OPS
   • DOMAIN_ALIAS_RID_RAS_SERVERS
   • DOMAIN_ALIAS_RID_PREW2KCOMPACCESS
   • DOMAIN_ALIAS_RID_NETWORK_CONFIGURATION_OPS
   • DOMAIN_ALIAS_RID_CRYPTO_OPERATORS
2. La cuenta del usuario contiene privilegios distintos de los de una cuenta de usuario estándar. Una cuenta de usuario estándar contiene solo los siguientes privilegios.
   • SeChangeNotifyPrivilege
   • SeShutdownPrivilege
   • SeUndockPrivilege
   • SeIncreaseWorkingSetPrivilege
   • SeTimeZonePrivilege

Los privilegios que contiene el token filtrado se basan en si el token original contenía cualquiera de los RIDS restringidos enumerados anteriormente. Si alguno de los RID restringidos se encontraba en el token, se quitan todos los privilegios excepto:

• SeChangeNotifyPrivilege
• SeShutdownPrivilege
• SeUndockPrivilege
• SeReserveProcessorPrivilege
• SeTimeZonePrivilege

Si no hay RID restringidos en el token, solo se quitan los siguientes privilegios:

• SeCreateTokenPrivilege
• SeTcbPrivilege
• SeTakeOwnershipPrivilege
• SeBackupPrivilege
• SeRestorePrivilege
• SeDebugPrivilege
• SeImpersonatePrivilege
• SeRelabelPrivilege

El primer token de acceso, denominado token de acceso filtrado, tiene los RID anteriores (si están presentes) marcados como USE_FOR_DENY_ONLY en el token de acceso y los privilegios administrativos de Windows, no enumerados anteriormente, quitados. El token de acceso filtrado se usará de forma predeterminada cuando el usuario inicie aplicaciones. El token de acceso completo sin modificar, denominado token de acceso vinculado, se adjunta al token de acceso filtrado y se usa cuando se realizan solicitudes para iniciar aplicaciones con un token de acceso administrativo completo.

Puede encontrar más información sobre los RID en el artículo cadenas de SID de MSDN Library [Seguridad].

Puede encontrar más información sobre los privilegios de Windows en el artículo de MSDN Library Constantes de autorización [Seguridad].

Arquitectura de UAC

El diagrama siguiente representa el flujo de proceso para los inicios ejecutables en Windows Vista.

Figura 3. Arquitectura de UAC

A continuación se muestra una descripción del flujo de proceso que se muestra en el diagrama de arquitectura de UAC y cómo se implementa UAC cuando un ejecutable intenta iniciarse.

Ruta de inicio del usuario estándar

La ruta de inicio del usuario estándar de Windows Vista es similar a la ruta de inicio de Windows XP, pero incluye algunas modificaciones.

• ShellExecute() llama a CreateProcess().
• CreateProcess() llama a AppCompat, Fusion y Detección del instalador para evaluar si la aplicación requiere elevación. A continuación, se inspecciona el archivo ejecutable para determinar su requestedExecutionLevel, que se almacena en el manifiesto de aplicación del ejecutable. La base de datos AppCompat almacena información para las entradas de corrección de compatibilidad de aplicaciones de una aplicación. Detección del instalador detecta los ejecutables de instalación.
• CreateProcess() devuelve un código de error win32 que indica ERROR_ELEVATION_REQUIRED.
• ShellExecute() busca específicamente este nuevo error y, al recibirlo, llama a través del servicio de información de la aplicación (AIS) para intentar el inicio elevado.

Ruta de acceso de inicio con privilegios elevados

La ruta de inicio con privilegios elevados de Windows Vista es una nueva ruta de inicio de Windows.

• AIS recibe la llamada de ShellExecute() y vuelve a evaluar el nivel de ejecución solicitado y directiva de grupo para determinar si se permite la elevación y definir la experiencia del usuario de elevación.
• Si el nivel de ejecución solicitado requiere elevación, el servicio inicia la solicitud de elevación en el escritorio interactivo del autor de la llamada (basado en directiva de grupo), mediante el HWND pasado desde ShellExecute().
• Una vez que el usuario haya dado su consentimiento o credenciales válidas, AIS recuperará el token de acceso correspondiente asociado al usuario adecuado, si es necesario. Por ejemplo, una aplicación que solicita un valor requestedExecutionLevel de highestAvailable recuperará diferentes tokens de acceso para un usuario que solo sea miembro del grupo Operadores de copia de seguridad que para un miembro del grupo administradores local.
• AIS vuelve a generar una llamada CreateProcessAsUser(), proporcionando el token de acceso de administrador y especificando el escritorio interactivo del autor de la llamada.

¿Afectará UAC a la aplicación?

Si la aplicación se verá afectada o no por UAC depende del estado actual de la aplicación. En varios casos, no será necesario realizar ningún cambio para cumplir con los requisitos de Microsoft Seguridad de Windows. Sin embargo, algunas aplicaciones, incluidas las aplicaciones de línea de negocio (LOB), pueden requerir cambios en sus procesos de instalación, función y actualización para que funcionen correctamente en un entorno de Windows Vista UAC.

Nota Si una aplicación funciona bien como usuario estándar en Windows XP, funcionará así como un usuario estándar en Windows Vista.

¿Por qué necesito quitar las dependencias administrativas de mi aplicación?

Un paso fundamental para aumentar la seguridad del entorno informático general es permitir que los usuarios se ejecuten sin usar su token de acceso administrativo. Si una aplicación solo funciona o se instala cuando el usuario es administrador, los usuarios se ven obligados a ejecutar aplicaciones con acceso elevado innecesario. El problema fundamental es que cuando los usuarios siempre se ven obligados a ejecutar aplicaciones con tokens de acceso elevados, código engañoso o malintencionado puede modificar fácilmente el sistema operativo, o peor, afectar a otros usuarios.

El objetivo de Microsoft es que los clientes comprendan que las aplicaciones no se deben ejecutar innecesariamente como administrador y que se les pregunte cada vez que se les pida que aprueben la solicitud de una aplicación para que se ejecute como administrador. UAC es un componente fundamental para ayudar a lograr este objetivo y avanzará mucho hacia la restauración de un entorno informático más seguro para todos los usuarios.

Reducción del costo total de propiedad de la aplicación

La cuenta de usuario estándar es muy atractiva para los administradores de TI interesados en aumentar la seguridad y el control sobre sus máquinas administradas, al tiempo que reduce el costo total de propiedad (TCO). Dado que una cuenta de usuario estándar no puede realizar cambios en el sistema, existe una relación directa con la reducción del TCO y un mejor control de la instalación de aplicaciones y modificaciones en todo el sistema. La cuenta de usuario estándar también es atractiva para los usuarios domésticos donde los padres comparten un equipo con niños. Microsoft Windows Vista incluye controles parentales integrados, que solo se implementan correctamente mediante la creación de cuentas de usuario secundarias como usuarios estándar. Las cuentas de usuario estándar tampoco pueden cambiar ni eliminar archivos creados por otros usuarios. No pueden leer archivos en los perfiles de otros usuarios, infectar archivos del sistema ni modificar ejecutables compartidos por el sistema, ya sea accidental o deliberadamente. Las cuentas de usuario estándar dan lugar a una mejora general en la seguridad de los equipos y los controles parentales.

Protección de forma predeterminada

En Microsoft, los principios de la Iniciativa informática de confianza de Microsoft se han integrado en el desarrollo de software. Por lo tanto, la seguridad mejorada ha sido una parte integral del proceso de desarrollo de Windows Vista.

El pilar de seguridad de Trustworthy Computing abarca tres aspectos básicos: proteger por diseño, proteger de forma predeterminada y proteger en la implementación. La forma en que usted y otros ISV desarrollan sus aplicaciones para contribuir a la seguridad general del sistema operativo será un factor clave de éxito para lograr la computación confiable en Windows Vista.

El objetivo del resto de esta guía es ayudar a los desarrolladores a enseñar a los desarrolladores a:

• Escritura de aplicaciones que no requieren que el usuario sea administrador para realizar tareas rutinarias
• Cree paquetes de instalación con tecnologías de aplicación de revisiones para UAC de Windows® Installer 4.0 que se implementen bien en el escritorio de usuario estándar en empresas y que también se actualicen correctamente en el hogar.
• Identificar la funcionalidad administrativa y del usuario estándar y extrapolar las tareas administrativas para la compatibilidad con UAC
• Escritura de interfaces de usuario de aplicación que usan la funcionalidad de UAC

Es esencial para el éxito de UAC que los desarrolladores de aplicaciones adoptan la filosofía de privilegios mínimos y diseñan sus aplicaciones para funcionar correctamente cuando se ejecutan con una cuenta de usuario estándar.

Uno de los objetivos de la versión de Windows Vista es evangelizar y fomentar el principio de diseño para usuarios y administradores estándar en Administración modo de aprobación a todos los desarrolladores. Alcanzar este objetivo ayudará a la prevención de varios ataques contra aplicaciones individuales y mitigará la posibilidad de que dichos ataques pongan en peligro la seguridad del sistema. Aunque estos objetivos se pueden lograr en algún momento al requerir que los administradores usen dos cuentas, tiende a producir errores por los siguientes motivos:

• Es casi imposible controlar un usuario que tenga un token de acceso de administrador completo. Los administradores pueden instalar aplicaciones y ejecutar cualquier aplicación o script que deseen. Los administradores de TI siempre buscan formas de crear "escritorios estándar" en los que los usuarios inicien sesión como usuarios estándar. Los escritorios estándar reducen considerablemente los costos del departamento de soporte técnico y reducen la sobrecarga de TI.
• Hay una sobrecarga sustancial al cambiar entre cuentas siempre que el usuario desea realizar una operación administrativa.
• Después de realizar una operación administrativa, los usuarios pueden olvidar volver a su cuenta de usuario estándar o decidir que es demasiado esfuerzo para volver a cambiar.

Como resultado, los usuarios pueden decidir iniciar sesión siempre en sus cuentas administrativas, lo que anula las medidas de seguridad. Para ayudar a mitigar esto, UAC presenta el concepto de Administración modo de aprobación. Una cuenta de usuario Administración modo de aprobación es una cuenta de usuario que es miembro del grupo de administradores locales en un sistema con UAC habilitado.

En la empresa, Administración modo de aprobación se usará como tecnología de puente para la migración a Windows Vista. Idealmente, las empresas ejecutarán a todos los usuarios como usuarios estándar y deshabilitarán la petición de elevación para los usuarios estándar. Esta configuración habilita un escritorio estándar administrado en el que las instalaciones se implementan con una tecnología de implementación de software, como Microsoft Systems Management Server (SMS).

Importante Microsoft recomienda que los miembros del grupo Administradores de dominio sigan manteniendo dos cuentas de usuario independientes en Windows Vista: una cuenta de usuario estándar y una cuenta de usuario de administrador de dominio. Toda la administración de dominios debe realizarse con la cuenta de administrador de dominio. Para mejorar aún más la seguridad, considere la posibilidad de implementar una solución de tarjeta inteligente en entornos de dominio. Consulte la Guía de planeación de acceso seguro mediante tarjetas inteligentes para obtener más información.

A continuación se muestran los objetivos de diseño de Windows Vista para Administración modo de aprobación:

• Elimine la necesidad de dos cuentas independientes para los usuarios que son miembros del grupo de administradores: este objetivo se logra ejecutando programas solo con un token de acceso de usuario estándar a menos que el usuario proporcione aprobación para usar el token de acceso administrativo completo.
• Proteja los procesos que se ejecutan con un token de acceso administrativo completo de los que esos procesos se ejecutan como usuario estándar o los modifican.
• Proporcione una transición sin problemas entre las áreas de trabajo de administrador y de usuario estándar.

Actualmente, la mayoría de las aplicaciones de Windows se deben ejecutar como administrador, pero no realizar realmente operaciones administrativas. Estas aplicaciones son un producto derivado de la filosofía de los sistemas operativos Microsoft Windows 9x: "todos son administradores".

A continuación se muestran ejemplos de aplicaciones problemáticas:

• Aplicaciones que escriben innecesariamente en HKEY_LOCAL_MACHINE (HKLM) o en archivos del sistema dentro del sistema.
• Una instalación de ActiveX para facilitar una aplicación de línea de negocio con una interfaz web.
• Aplicaciones que solicitan innecesariamente acceso a los recursos que requieren un token de acceso administrativo completo.

En la sección siguiente se presentan nuevas tecnologías para Windows Vista que afectan a los ISV.

¿Cómo puedo determinar si mi aplicación tiene dependencias administrativas?

Para ayudar a los desarrolladores, los ISV y las organizaciones a evaluar sus aplicaciones, Microsoft proporciona el Analizador de usuarios estándar de Microsoft. El Analizador de usuarios estándar se puede usar para ayudar a identificar el comportamiento no compatible con UAC de una aplicación. Microsoft recomienda que los desarrolladores ejecuten esta herramienta para identificar problemas con la ejecución de la aplicación en una cuenta de usuario estándar. Estas pruebas deben realizarse, incluso si la aplicación ya se instala y se ejecuta correctamente en una cuenta de usuario estándar en Windows XP. La aplicación puede realizar operaciones, como intentar escribir en ubicaciones del Registro del sistema y tomar decisiones basadas en el comportamiento del sistema, como buscar una respuesta de error. Windows Vista puede comportarse de forma diferente a las versiones anteriores del sistema operativo Windows debido a la adición de compatibilidad de aplicaciones nuevas. Por lo tanto, se recomienda que todas las aplicaciones se prueben con la nueva versión del Analizador de usuarios estándar.

El Analizador de usuarios estándar registrará todas las operaciones administrativas detectadas por una aplicación, incluido el acceso al sistema de archivos o al registro y las llamadas API con privilegios elevados. Estos datos se almacenan en un archivo de registro y se muestran dentro de la herramienta. El Analizador de usuarios estándar identifica las siguientes dependencias comunes, además de muchas otras:

• Dependencia de objetos que restringen el acceso solicitado solo a los usuarios de confianza.

  Por ejemplo, HKEY_LOCAL_MACHINE solo concede KEY_WRITE a los administradores y SYSTEM, una aplicación que solicita KEY_WRITE a HKEY_LOCAL_MACHINE no funcionará con UAC habilitado.

• Uso de privilegios de Windows que tienen ramificaciones de seguridad, como SE_DEBUG_PRIVILEGE, que permite la depuración de los procesos de otros usuarios y solo se concede a los administradores.

¿Cuáles son los requisitos si tengo una aplicación de administrador legítima?

En el caso de las aplicaciones que, por diseño, realizan operaciones administrativas legítimas, Microsoft ha implementado una extensión en la sección trustInfo del esquema actual del manifiesto de aplicación de Windows XP. Puede usar estos nuevos atributos para indicar al sistema que tiene una aplicación administrativa legítima; el sistema solicitará automáticamente la aprobación del usuario para iniciar la aplicación con un token de acceso administrativo completo. Para obtener información sobre cómo extender el manifiesto de aplicación, consulte la sección Crear e insertar un manifiesto de aplicación con la aplicación en este documento.

Diseño de aplicaciones para Windows Vista

La lista siguiente representa un flujo de trabajo para diseñar la aplicación para Windows Vista:

1. Prueba de la compatibilidad de aplicaciones de Windows Vista
2. Clasificación de la aplicación como usuario estándar, administrador o aplicación de usuario mixto
3. Rediseñar la funcionalidad de la aplicación para la compatibilidad con UAC
4. Rediseñar la interfaz de usuario de la aplicación
5. Rediseñar el instalador de la aplicación
6. Creación e inserción de un manifiesto de aplicación con las aplicaciones administrativas
7. Prueba de la aplicación
8. Firmar la aplicación
9. Determinar si se debe seguir el programa logotipo de Windows Vista

1. Probar la aplicación para la compatibilidad de aplicaciones

Las pruebas de compatibilidad de aplicaciones con UAC se pueden realizar fácilmente mediante la instalación del Analizador de usuarios estándar.

Para usar la presentación gráfica del registro del Analizador de usuarios estándar, debe instalar el comprobador de aplicaciones de Microsoft. Application Verifier es una descarga gratuita en el sitio web de Microsoft.

En el procedimiento siguiente se muestra cómo identificar las aplicaciones administrativas anteriores a Windows Vista que no se ejecutan correctamente en Windows Vista mediante el Analizador de usuarios estándar.

Hay dos enfoques que puede tomar para usar el Analizador de usuarios estándar: iniciar la aplicación como usuario estándar o iniciar la aplicación con privilegios elevados como administrador:

Inicie la aplicación como usuario estándar.

En este caso, el Analizador de usuarios estándar se ejecuta en modo de diagnóstico. Se producirá un error en la aplicación en el primer error que encuentre y el Analizador de usuarios estándar notificará por qué se produjo un error.

Inicie la aplicación con privilegios elevados como administrador.

En este caso, el Analizador de usuarios estándar se ejecuta en modo de predicción. La aplicación podrá ejecutarse a través de su curso y el Analizador de usuarios estándar predecirá y proporcionará una visión general de los errores que podría encontrar la aplicación si se ejecuta como usuario estándar.

Una vez corregidos y resueltos los errores, realice este procedimiento una vez más como un usuario estándar sin el Analizador de usuarios estándar para asegurarse de que la aplicación funciona según lo previsto en Windows Vista.

Para identificar problemas de compatibilidad de aplicaciones para aplicaciones anteriores a Windows Vista

1. Inicie sesión en un equipo de Windows Vista como administrador en Administración modo de aprobación.
2. Haga clic en Inicio, en Todos los programas y, a continuación, en Analizador de usuarios estándar.
3. En el Analizador de usuarios estándar, para Aplicación de destino, especifique la ruta de acceso completa del directorio para que una aplicación pruebe o haga clic en el botón Examinar para buscar el archivo ejecutable de programas con el Explorador de Windows.
4. Haga clic en Iniciar y, a continuación, haga clic en Continuar en el cuadro de diálogo Control de cuentas de usuario.
5. Una vez que se inicie la aplicación de prueba, realice tareas administrativas estándar en la aplicación y cierre la aplicación cuando haya finalizado.
6. En el Analizador de usuarios estándar, examine la salida en cada pestaña. Use estos datos para identificar los problemas de compatibilidad que podría tener el programa.

2. Clasificar la aplicación como usuario estándar, administrador o aplicación de usuario mixto

Las aplicaciones administrativas de Windows Vista suelen tener una combinación de funcionalidades administrativas y de usuario estándar. Como resultado, se deben tener en cuenta varias opciones al decidir cómo funcionará la aplicación en Windows Vista. La funcionalidad administrativa se puede quitar completamente o separar de la funcionalidad de la cuenta de usuario estándar mediante la solicitud de aprobación al usuario.

Preguntas para ayudar a clasificar la aplicación

Responda a las siguientes preguntas para determinar si la aplicación requerirá algún rediseño para la compatibilidad con Windows Vista:

• ¿La aplicación se ejecuta como un usuario estándar?
• ¿Se puede corregir la funcionalidad administrativa para que ya no requiera un token de acceso de administrador?
• ¿Se pueden quitar las secciones administrativas de la funcionalidad del programa?

¿La aplicación se ejecuta como usuario estándar?

Para responder a esta pregunta, asegúrese de que los usuarios estándar usen completamente la aplicación o la característica. Si alguna parte de la característica requiere que el usuario sea administrador, la respuesta a esta pregunta es "No".

Cómo comprobar que los usuarios estándar pueden usar la aplicación o el panel de control:

• Pruebe exhaustivamente la aplicación o el panel de control como un usuario estándar y como administrador. Compruebe que las interacciones del usuario son exactamente las mismas para los usuarios y administradores estándar.
• Compruebe dónde se almacenan los valores en el Registro. Si alguna configuración se almacena en HKLM, lo más probable es que la aplicación o el panel de control requieran un token de acceso de administrador.
• Si alguna de las opciones de configuración es por equipo, la aplicación o el panel de control requerirán un token de acceso de administrador.
• Si alguna de las opciones de configuración hace algo en los perfiles de otros usuarios, la aplicación o el panel de control requerirán un token de acceso de administrador.

¿Se puede corregir la funcionalidad administrativa para que ya no requiera un token de acceso de administrador?

Si la aplicación o el panel de control tiene configuraciones o interacciones que requieren un token de acceso de administrador completo, ¿se puede cambiar para que funcione correctamente como usuario estándar? En concreto, ¿el programa puede almacenar información en la configuración por usuario en su lugar? Si no es posible, la respuesta a esta pregunta es "No".

Un buen ejemplo del tipo de característica o configuración que se puede corregir es Calc.exe (la calculadora de Windows). En Windows XP, la configuración de "Scientific" frente a "Standard" era una configuración por equipo, lo que significaba que se necesitaba un token de acceso administrativo completo para cambiar la configuración. En Windows Vista, esta configuración se almacena en el perfil del usuario.

Cómo comprobar que las secciones administrativas se pueden quitar de la funcionalidad del programa:

• Pruebe exhaustivamente la aplicación o el panel de control como un usuario estándar y como administrador. ¿La experiencia puede ser la misma para ambos tipos de usuarios?

• ¿Es posible reducir las listas de control de acceso (ACL) necesarias para escribir en la clave HKLM?

  Nota Este curso no debe tomarse ligeramente. Tenga cuidado de no poner en peligro la seguridad general del sistema al reducir el control que proporciona la ACL.

• ¿Es posible cambiar la interfaz de usuario para establecer el estado por usuario en lugar de un estado global (y no exponer la modificación del estado global a través de la interfaz de usuario)?

¿Se pueden quitar las secciones administrativas de la funcionalidad del programa?

¿Su característica tiene absolutamente que tener esta funcionalidad? Si no puede cortar las características o funcionalidades administrativas, la respuesta a esta pregunta es "No".

Para determinar si las secciones administrativas se pueden quitar de la funcionalidad del programa, haga lo siguiente:

• Pruebe el panel de control como un usuario estándar, así como un administrador. ¿Cuál es el escenario de usuario para conservar esta característica?
• ¿Esta configuración o característica se expone en otro lugar? Quizás la funcionalidad del panel de control sea redundante.

Análisis de las respuestas para clasificar la aplicación

Si respondió "Sí" a cualquiera de las preguntas anteriores

Realice los cambios necesarios en la aplicación o el panel de control (si existe) para eliminar los elementos que requieren que el usuario tenga un token de acceso administrativo completo.

En la lista siguiente se detallan las ventajas de tener una aplicación de usuario estándar verdadera:

• La característica es igualmente utilizable para todos los usuarios. Este es el estado ideal, ya que la mayoría de las características no deben requerir un token de acceso de administrador completo.
• Los usuarios nunca verán un aviso de elevación con sus características.
• Las características son mucho más seguras, ya que nunca requieren el token de acceso de administrador.

Si respondió "No" a todas las preguntas anteriores

La aplicación o el panel de control deben modificarse para que la característica funcione con UAC.

Compruebe la aplicación o Panel de control funciona con UAC:

Por último, pruebe la aplicación o el panel de control como un usuario estándar, así como un administrador. Asegúrese de que no se pueden usar otras opciones (las preguntas anteriores) para esta aplicación o panel de control concretos.

3. Rediseñar la funcionalidad de la aplicación para la compatibilidad con UAC

Use la información de esta sección una vez que haya clasificado la aplicación y determinado si se debe rediseñar para UAC.

Un gran componente de rediseño de la aplicación para Windows Vista examinará el modelo de acceso de usuario de la aplicación en su núcleo.

Requisitos para todas las aplicaciones de Windows Vista

Especificar requestedExecutionLevel

Para que UAC funcione correctamente, el sistema operativo debe ser capaz de identificar qué código necesita privilegios elevados y qué código no.

En Windows Vista, estos cambios requieren que las aplicaciones se marquen con información que permita al sistema operativo determinar en qué contexto se debe iniciar la aplicación. Por ejemplo, las aplicaciones de usuario estándar deben marcarse para ejecutarse como invocador y el sistema debe identificar las aplicaciones habilitadas para accesibilidad.

No registrar componentes con Rundll32

Algunas aplicaciones usan los ejecutables de Windows Rundll32 para ejecutar componentes. Sin embargo, este método no es compatible con los requisitos de desarrollo de Windows Vista. Llamar directamente a Rundll32 da como resultado problemas de compatibilidad de UAC. Cuando una aplicación se basa en los ejecutables de Rundll32 para realizar su ejecución, Rundll32 llama a Application Information Service (AIS) en nombre de la aplicación para iniciar el símbolo del sistema de elevación de UAC. Como resultado, el símbolo del sistema de elevación de UAC no tiene conocimiento de la aplicación original y muestra la aplicación que solicita elevación como "Proceso de host de Windows(Rundll32)." Sin una descripción clara e icono para la aplicación que solicita elevación, los usuarios no tienen forma de identificar la aplicación y determinar si es seguro elevarla.

Si la aplicación llama a Rundll32 para ejecutar componentes, use el siguiente flujo de trabajo para rediseñar la llamada de ejecución.

1. Cree un nuevo archivo ejecutable independiente para la aplicación.
2. En el nuevo archivo ejecutable, llame a la función exportada en el archivo DLL que habría especificado con Rundll32. Es posible que tenga que cargarlibrary el archivo DLL si no tiene un archivo .lib.
3. En un archivo de recursos, cree y agregue un nuevo icono para el ejecutable. Este icono se mostrará en el aviso de elevación control de cuentas de usuario cuando la aplicación solicite la elevación.
4. Proporcione un nombre corto y descriptivo para el archivo ejecutable. Este nombre se mostrará en el mensaje de elevación control de cuentas de usuario cuando la aplicación solicite la elevación.
5. Cree e inserte un archivo de manifiesto de aplicación para el ejecutable y guícelo con el nivel de ejecución solicitado de requireAdministrator. Este proceso se detalla en la sección Crear e insertar un manifiesto de aplicación con la aplicación.
6. Authenticode firma el nuevo ejecutable. Este proceso se detalla en la sección Authenticode Sign Your Application (Firmar la aplicación).

Después de la desinstalación de una aplicación, el usuario debe poder reinstalarla sin errores.

Requisitos para aplicaciones de usuario estándar

Este es un resumen de las cosas que se deben recordar al diseñar aplicaciones que funcionan correctamente con una cuenta de usuario estándar. Los desarrolladores deben tener en cuenta estos requisitos durante la fase de diseño de sus aplicaciones.

Configuración

• Nunca realice acciones administrativas (como completar el proceso de instalación) en la primera ejecución; debe realizarse como parte del proceso de instalación inicial.
• Nunca escriba directamente en el directorio o subdirectorios de Windows. Use los métodos correctos para instalar archivos como fuentes.
• Si necesita actualizar automáticamente la aplicación, use un mecanismo adecuado para su uso por parte de los usuarios estándar, como la aplicación de revisiones de control de cuentas de usuario de Windows Installer 4.0 para realizar la actualización.

Guardar estado

• No escriba información por usuario ni información grabable por usuario en archivos de programa o directorios de programa.
• No use rutas de acceso codificadas de forma rígida en el sistema de archivos. Aproveche las ventajas de knownFolders API y ShGetFolder para encontrar dónde escribir datos.

Ejecutar y probar en una cuenta de usuario estándar

Si estás escribiendo una aplicación no administrativa, como una aplicación loB o una aplicación de usuario como un juego, siempre debes escribir datos de aplicación en una ubicación a la que el usuario estándar tenga acceso. Estos son algunos de los requisitos recomendados.

• Escribir datos por usuario en el perfil de usuario: CSIDL_APPDATA.
• Escriba datos por equipo en Usuarios\Todos los usuarios\Datos de la aplicación: CSIDL_COMMON_APPDATA.
• La aplicación no puede depender de ninguna API administrativa. Por ejemplo, un programa que espera llamar correctamente a la función de Windows SetTokenInformation() producirá un error en una cuenta de usuario estándar.

Ser compatible con el cambio rápido de usuario (FUS)

Las aplicaciones se instalarán con más frecuencia por un usuario que no sea el usuario que ejecutará la aplicación. Por ejemplo, en el hogar, esto significa que un elemento primario instalará la aplicación para el elemento secundario. En la empresa, un sistema de implementación, como SMS o directiva de grupo anuncio, instalará la aplicación mediante una cuenta de administrador.

Si la configuración por usuario no existe en la primera ejecución, vuelva a generarla. No suponga que el proceso de configuración se encarga de la configuración.

Requisitos para aplicaciones de administrador

Usar la propiedad HWND para que se confirme como una aplicación en primer plano

Las aplicaciones en segundo plano solicitarán automáticamente al usuario la elevación en la barra de tareas, en lugar de ir automáticamente al escritorio seguro para la elevación. El mensaje de elevación aparecerá minimizado en la barra de tareas y parpadeará para notificar al usuario que una aplicación ha solicitado elevación. Un ejemplo de elevación en segundo plano se produce cuando un usuario navega a un sitio web y comienza a descargar un archivo de instalación. A continuación, el usuario va a comprobar el correo electrónico mientras la instalación se descarga en segundo plano. Una vez completada la descarga en segundo plano y comienza la instalación, la elevación se detecta como una tarea en segundo plano en lugar de una tarea en primer plano. Esta detección impide que la instalación robe abruptamente el foco de la pantalla del usuario mientras el usuario realiza otro correo electrónico de lectura de tareas. Este comportamiento crea una mejor experiencia de usuario para el mensaje de elevación.

Sin embargo, algunas aplicaciones en primer plano se solicitan actualmente como aplicaciones en segundo plano en Windows Vista. Este comportamiento es el resultado de un HWND primario ausente. Para asegurarse de que Windows Vista reconoce la aplicación como una aplicación en primer plano, debe pasar un HWND primario con un ShellExecute, CreateElevatedComObject (COM) o una llamada de código administrado.

El mecanismo de elevación UAC usa el HWND como parte de la determinación de si la elevación es un fondo o una elevación en primer plano. Si la aplicación se determina como una aplicación en segundo plano, la elevación se coloca en la barra de tareas como un botón parpadeante. El usuario debe hacer clic en el botón, como con cualquier aplicación que solicite acceso en primer plano, antes de que continúe la elevación. Si no se pasa el HWND, esto se producirá aunque la aplicación pueda tener realmente primer plano.

En el ejemplo de código siguiente se muestra cómo pasar HWND con ShellExecute:

BOOL RunAsAdmin( HWND hWnd, LPTSTR lpFile, LPTSTR lpParameters )
{
    SHELLEXECUTEINFO   sei;
    ZeroMemory ( &sei, sizeof(sei) );

    sei.cbSize          = sizeof(SHELLEXECUTEINFOW);
    sei.hwnd            = hWnd;
    sei.fMask           = SEE_MASK_FLAG_DDEWAIT | SEE_MASK_FLAG_NO_UI;
    sei.lpVerb          = _TEXT("runas");
    sei.lpFile          = lpFile;
    sei.lpParameters    = lpParameters;
    sei.nShow           = SW_SHOWNORMAL;

    if ( ! ShellExecuteEx ( &sei ) )
    {
        printf( "Error: ShellExecuteEx failed 0x%x\n", GetLastError() );
        return FALSE;
    }
    return TRUE;
}

En el ejemplo de código siguiente se muestra cómo pasar HWND con CreateElevatedComObject mediante el moniker de elevación. Se supone que ya ha inicializado COM en el subproceso actual. Puede encontrar más información sobre el moniker de elevación en el paso Cuatro de este documento.

HRESULT CreateElevatedComObject(HWND hwnd, REFCLSID rclsid, REFIID riid, __out void ** ppv)
{
    BIND_OPTS3 bo;
    WCHAR  wszCLSID[50];
    WCHAR  wszMonikerName[300];

    StringFromGUID2(rclsid, wszCLSID, sizeof(wszCLSID)/sizeof(wszCLSID[0])); 
    HRESULT hr = StringCchPrintf(wszMonikerName, sizeof(wszMonikerName)/sizeof(wszMonikerName[0]), L"Elevation:Administrator!new:%s", wszCLSID);
    if (FAILED(hr))
        return hr;
    memset(&bo, 0, sizeof(bo));
    bo.cbStruct = sizeof(bo);
    bo.hwnd = hwnd;
    bo.dwClassContext  = CLSCTX_LOCAL_SERVER;
    return CoGetObject(wszMonikerName, &bo, riid, ppv);

BIND_OPTS3 es nuevo en Windows Vista. Se deriva de BIND_OPTS2. Se define de la manera siguiente:

typedef struct tagBIND_OPTS3 : tagBIND_OPTS2
{
    HWND hwnd;
} BIND_OPTS3, * LPBIND_OPTS3;

La única adición es un campo HWND, hwnd. Este identificador representa una ventana que se convierte en el propietario de la interfaz de usuario de elevación cuando se habilita la solicitud de escritorio seguro.

En el ejemplo de código siguiente se muestra cómo pasar HWND en código administrado para asegurarse de que los diálogos primarios son conscientes de HWND y su uso.

System.Diagnostics.Process newProcess = new System.Diagnostics.Process();
System.Diagnostics.ProcessStartInfo info = new System.Diagnostics.ProcessStartInfo("D:\SomeProgram.exe");
info.UseShellExecute = true;
info.ErrorDialog = true;
info.ErrorDialogParentHandle = this.Handle;
newProcess.StartInfo = info;
newProcess.Start();

No solicitar elevación en la ruta de inicio de sesión del usuario

Las aplicaciones que comienzan cuando el usuario inicia sesión y requieren elevación ahora se bloquean en la ruta de acceso de inicio de sesión. Sin bloquear que las aplicaciones pidan elevación en la ruta de acceso de inicio de sesión del usuario, tanto los usuarios estándar como los administradores tendrán que responder a un cuadro de diálogo Control de cuentas de usuario en cada inicio de sesión. Windows Vista notifica al usuario si se ha bloqueado una aplicación colocando un icono en la bandeja del sistema. A continuación, el usuario puede hacer clic con el botón derecho en este icono para ejecutar aplicaciones que se bloquearon para solicitar la elevación cuando el usuario inició sesión. El usuario puede administrar qué aplicaciones de inicio se deshabilitan o quitan de esta lista haciendo doble clic en el icono de la bandeja.

Un ejemplo de código de C++ que ilustra cómo usar el Programador de tareas para realizar la elevación del usuario está disponible en la sección Referencias de este documento.

No usar Runas para iniciar un proceso con privilegios elevados

La opción Ejecutar como... de Windows XP y Windows Server 2003 se ha reemplazado por Ejecutar como administrador en el menú contextual (disponible cuando se hace clic con el botón derecho en un ejecutable) en Windows Vista. Cuando un usuario estándar selecciona la opción Ejecutar como administrador , se presenta al usuario una lista de administradores activos en el equipo local. También se muestran los usuarios estándar con privilegios más altos, como los miembros del grupo Operadores de copia de seguridad. Cuando un administrador selecciona la opción Ejecutar como administrador , un cuadro de diálogo Control de cuentas de usuario solicita inmediatamente al usuario que continúe antes de ejecutar la aplicación.

Los usuarios deben usar el comando runas en el símbolo del sistema para ejecutar una aplicación como otro usuario.

Importante Tenga en cuenta que runas no proporciona la capacidad de iniciar una aplicación con un token de acceso con privilegios elevados, independientemente de si es un usuario estándar con privilegios como un operador de copia de seguridad o un administrador. El comando runas concede al usuario la capacidad de iniciar una aplicación con credenciales diferentes. El mejor método para iniciar una aplicación con una cuenta diferente es realizar la acción mediante programación mediante un servicio y no confiar en que el usuario ejecute el componente como un usuario diferente. Si el programa usa el comando runas mediante programación, asegúrese de que no está pensado para iniciar un proceso con privilegios elevados.

Si la aplicación requerirá que el usuario ejecute partes de la aplicación con una cuenta de usuario diferente, asegúrese de que el comando runas con la opción del símbolo del sistema esté expuesto. En la tabla siguiente se detallan los parámetros disponibles para el comando runas .

Parámetros runas

Parámetro	Descripción
/noprofile	Especifica que el perfil del usuario no debe cargarse. Esto permite que la aplicación se cargue más rápidamente, pero puede hacer que algunas aplicaciones no funcionen correctamente.
/Perfil	Especifica que se debe cargar el perfil del usuario. Esta es la configuración predeterminada.
/Env	Use el entorno actual en lugar del del usuario.
/netonly	Use este parámetro si las credenciales especificadas son solo para el acceso remoto.
/savecred	Use las credenciales guardadas anteriormente por el usuario. Esta opción no está disponible en Windows XP, Home Edition y se omitirá.
/smartcard	Use este parámetro si las credenciales que se van a proporcionar son de una tarjeta inteligente.
/user	Nombre de usuario del usuario. El nombre de usuario debe proporcionarse en forma de USER\DOMAIN o USER@DOMAIN.
/showtrustlevels	Muestra los niveles de confianza que se pueden usar como argumentos para el parámetro /trustlevel.
/trustlevel	Uno de los niveles enumerados en /showtrustlevels.
Programa	Línea de comandos para un archivo ejecutable.

Ejemplo:

runas /noprofile /user:mymachine\Denise cmd

Notas:

• Escriba la contraseña del usuario solo cuando se le solicite.
• El parámetro /profile no es compatible con el parámetro /netonly.
• El parámetro /savecred no es compatible con el parámetro /smartcard.

Requisitos para aplicaciones de consola

Una aplicación de consola presenta su salida en la ventana de consola y no con una interfaz de usuario independiente. Si una aplicación necesita un token de acceso de administrador completo para ejecutarse, esa aplicación debe iniciarse desde una ventana de consola con privilegios elevados.

Debe hacer lo siguiente para las aplicaciones de consola:

Marque que la aplicación "asInvoker"

Para ello, cree el manifiesto de la aplicación en la que establezca RequestedExecutionLevel == asInvoker. Esta configuración permite a los autores de llamadas de contextos no elevados crear el proceso, lo que les permite continuar con el paso 2.

Proporcione un mensaje de error si la aplicación se ejecuta sin un token de acceso de administrador completo.

Si la aplicación se inicia en una consola sin privilegios elevados, la aplicación debe proporcionar un breve mensaje y salir. El mensaje recomendado es:

"Acceso denegado. Se necesitan permisos de administrador para usar las opciones seleccionadas. Use un símbolo del sistema del administrador para completar estas tareas".

La aplicación también debe devolver el código de error ERROR_ELEVATION_REQUIRED al no iniciarse para facilitar el scripting.

Requisitos para scripts

Los scripts se pueden considerar como un grupo de aplicaciones que se ejecutan en un orden predefinido y los resultados de un canalización en otro.

Para que los scripts sean compatibles con UAC, examine la lógica de los scripts y agregue "pruebas" para asegurarse de que antes de realizar una acción en el script, usted (o la persona que ejecuta el script) tiene privilegios suficientes para realizar esa tarea.

Requisitos para las operaciones masivas

Si una tarea realizada por la aplicación consta de acciones en varios objetos y algunas de ellas podrían requerir el token de acceso administrativo del usuario, muestre la solicitud de elevación la primera vez que sea necesaria. Si el usuario aprueba la elevación, realice el resto de las tareas. De lo contrario, finalice la operación por lotes. Este comportamiento sería coherente con la operación actual de selección múltiple, copia y eliminación.

API que ayudan a identificar a un administrador

• IsUserAnAdmin()
• GetTokenInformation()

Registro o control de permisos de acceso que son inherentemente diferentes entre administradores y usuarios estándar

• MAXIMUM_ALLOWED
• KEY_WRITE
• DELETE (cuando se aplica a las claves del Registro)
• Otras palabras clave similares a HKLM (abiertas con MAXIMUM_ALLOWED en XP):
• SHELLKEY_HKLM_EXPLORER
• SHELLKEY_HKLM_SHELL

Se aplicarán otras API que se vuelvan a dirigir a los valores del Registro HKLM y la virtualización.

• WritePrivateProfileString(,,,"system.ini");
• CheckSectionAccess("system.ini",...);

4. Rediseñar la interfaz de usuario de la aplicación para la compatibilidad con UAC

Use las instrucciones de esta sección para desarrollar la interfaz de usuario de la aplicación para la compatibilidad con UAC. Cumplir estrechamente estas directrices en el desarrollo de la aplicación garantizará que la aplicación tenga una experiencia de usuario coherente y predecible en Windows Vista.

• Impacto de UAC en la experiencia del usuario de Windows
• Objetivos de la experiencia del usuario de UAC
• Petición de elevación
• Flujo de proceso de experiencia del usuario
• Puntos de entrada de elevación
• Implementación de la interfaz de usuario
• Cuándo agregar un icono de escudo a la interfaz de usuario de la aplicación
• Decisiones clave para aplicaciones solo de administrador

Importante Simplemente la refracción de la interfaz de usuario de la aplicación no cumplirá los requisitos de compatibilidad con UAC. La funcionalidad principal de la aplicación debe cumplir los requisitos del modelo de usuario estándar de Windows Vista. Estos requisitos se detallaron en el paso anterior, Paso tres: Rediseñar la funcionalidad de la aplicación para la compatibilidad con UAC.

Impacto de UAC en la experiencia del usuario de Windows

Los administradores sentirán el mayor y más inmediato impacto en la experiencia del usuario. Los usuarios administradores ahora tendrán que proporcionar permiso para realizar tareas administrativas. Junto con eso, los usuarios estándar ahora obtendrán la capacidad de pedir a los administradores permiso para determinadas tareas administrativas dentro de la sesión que se ha iniciado sesión actualmente.

Objetivos de la experiencia del usuario de UAC

El objetivo general de la experiencia del usuario de UAC es proporcionar previsibilidad en la experiencia del usuario:

• Para un administrador, esto significa que el usuario siempre sabe cuándo tendrá que conceder permiso para ejecutar una tarea con privilegios elevados.

Este es el acto de solicitar el propio token de acceso de administrador del usuario para que pueda realizar cambios necesarios para el administrador.

• Para los usuarios estándar, esto significa que sabrán cuándo:
  • Tendrá que proporcionar la aprobación del administrador (entornos principales y no administrados) para las tareas administrativas.
  • O bien, cuando no se puede completar una tarea (entornos administrados en los que la elevación no se permite explícitamente) y debe ponerse en contacto con el departamento de soporte técnico.

Objetivos de diseño

La siguiente lista comprende los objetivos de diseño de UAC.

Eliminar elevación innecesaria

Los usuarios deben tener que elevarse solo para realizar tareas que requieran un token de acceso de administrador. Todas las demás tareas deben diseñarse para eliminar la necesidad de elevación. El software anterior a Windows Vista a menudo requiere un token de acceso de administrador innecesariamente escribiendo en las secciones del registro HKLM o HKCR o en las carpetas del sistema de Windows o archivos de programa.

Ser predecible

Los administradores deben saber qué tareas requieren elevación. Si no pueden predecir la necesidad de elevación con precisión, es más probable que den su consentimiento para las tareas administrativas cuando no deban hacerlo. Los usuarios estándar deben saber qué tareas requieren que un administrador realice o no se pueda realizar en todos los entornos administrados.

Requerir un esfuerzo mínimo

Las tareas que requieren un token de acceso con privilegios más elevados deben diseñarse para requerir una única elevación. Las tareas que requieren varias elevaciones se vuelven tediosas rápidamente.

Revertir al usuario estándar

Una vez completada una tarea que requiere un nivel superior de token de acceso, el programa debe revertir al estado de usuario estándar.

Petición de elevación

La petición de elevación se basa en una interfaz de usuario de Windows existente. El símbolo del sistema de elevación muestra información contextual sobre el archivo ejecutable que solicita elevación y el contexto es diferente en función de si la aplicación está firmada o no. La solicitud de elevación se ve en dos variaciones: la solicitud de consentimiento y la solicitud de credenciales.

Solicitud de consentimiento

La solicitud de consentimiento se muestra a los administradores en Administración modo de aprobación cuando intentan realizar una tarea administrativa. Esta es la experiencia de usuario predeterminada para los administradores en Administración modo de aprobación y se puede configurar en el complemento administrador de directivas de seguridad local (secpol.msc) y con directiva de grupo.

La ilustración siguiente es un ejemplo de solicitud de consentimiento de Control de cuentas de usuario.

Figura 4. Petición de consentimiento del control de cuentas de usuario

Solicitud de credenciales

La solicitud de credenciales se muestra a los usuarios estándar cuando intentan realizar una tarea administrativa. Esta es la experiencia de usuario predeterminada para los usuarios estándar y se puede configurar en el complemento administrador de directivas de seguridad local (secpol.msc) y con directiva de grupo.

La ilustración siguiente es un ejemplo de un símbolo del sistema de credenciales de Control de cuentas de usuario.

Figura 5. Petición de credenciales del control de cuentas de usuario

Directiva de consentimiento de petición de elevación predeterminada para Windows Vista

En la tabla siguiente se describe el estilo de solicitud predeterminado para cada tipo de cuenta de usuario en Windows Vista.

Comportamiento predeterminado de la petición de elevación

Tipo de cuenta de usuario	Configuración del símbolo del sistema de elevación
Usuario estándar	Se piden credenciales
Cuenta de administrador en modo de aprobación de Administración	Pedir consentimiento

Flujo de proceso de experiencia del usuario

El flujo de proceso de experiencia del usuario de UAC consta de tres componentes distintos:

1. Punto de entrada de elevación (por ejemplo, un control o vínculo que muestra el icono de escudo UAC).
2. Petición de elevación (solicitud de consentimiento o credenciales de administrador).
3. Proceso con privilegios elevados.

En el flujo de trabajo de ejemplo siguiente se resume cómo se relacionan los componentes anteriores:

1. Un administrador en Administración modo de aprobación inicia sesión en un equipo Con Windows Vista.
2. A continuación, el usuario decide agregar otro usuario administrador para el equipo.
3. El usuario hace clic en Inicio, hace clic en Panel de control y, a continuación, hace clic en el vínculo de la sección Seguridad titulada Permitir un programa a través del Firewall de Windows, que se muestra en línea con un icono de escudo.
4. Aparece una solicitud de consentimiento que solicita al usuario su aprobación.
5. El usuario hace clic en Continuar y se crea el proceso con privilegios elevados.
6. En Configuración del Firewall de Windows, el usuario modifica la configuración del Firewall de Windows y, a continuación, hace clic en Aceptar, lo que finaliza el proceso con privilegios elevados.
7. El usuario sigue trabajando en el equipo como usuario estándar.

Nota Los puntos de entrada de elevación no recuerdan el estado (por ejemplo, al volver desde una ubicación blindada o tarea), así como el punto de entrada no recordará que se ha producido la elevación. Como resultado, el usuario tendrá que volver a elevar para volver a escribir la tarea, vínculo o botón.

Puntos de entrada de elevación

En el caso de los puntos de entrada, el icono de escudo se adjuntará a determinados controles (por ejemplo, botones, vínculos de comandos, hipervínculos) para indicar que el siguiente paso inmediato requiere elevación.

Icono de escudo

El icono de escudo es la decoración de la interfaz de usuario principal para un punto de elevación UAC. Este icono significa actividades relacionadas con la seguridad en Windows Vista y versiones anteriores de Windows, y esta relación continúa en Windows Vista.

La ilustración siguiente es un ejemplo del icono de escudo.

Figura 6. Icono de escudo

El icono de escudo desempeñará una parte fundamental en los tres componentes de la experiencia del usuario UAC.

Al ver el sistema con el Explorador de Windows, cualquier aplicación que esté marcada para solicitar un token de acceso de administrador cuando se inicie se decorará automáticamente con un glifo de escudo sobre su icono. Esto permite a los usuarios saber qué aplicaciones, cuando se inician, solicitarán elevación.

Propiedades del icono de escudo:

• Apariencia coherente en toda la experiencia del usuario de UAC.
• No refleja ningún estado visual (por ejemplo, activo, mantener el puntero, deshabilitar, etc.).
• No recuerda el estado.

Hay tres estilos de control coherentes que un punto de entrada marcado con un icono de escudo puede tomar dentro de la experiencia del usuario:

• Botón UAC
• Hipervínculo UAC
• Vínculo de comando UAC

Estos estilos se aplican a todos los escenarios en los que estos elementos de la interfaz de usuario pueden aparecer como asistentes, páginas de propiedades, Panel de control Framework, exploradores, etc. Cada uno de los estilos implica que una solicitud de elevación se mostrará inmediatamente después de que el usuario haga clic en un control de interfaz de usuario de UAC.

En esta sección también se describe un cuarto punto de entrada de la interfaz de usuario de UAC, la superposición del icono de UAC. Si un ejecutable recibe una superposición de iconos o no está controlada por el desarrollador de aplicaciones. Windows Vista superpone un icono de escudo en los iconos de las aplicaciones para los ejecutables que han solicitadoExecutionLevel establecido en requireAdministrator.

Botón de escudo UAC

El botón de escudo UAC debe usarse en cualquier botón de interfaz de usuario que, cuando se presione, requerirá la petición de elevación para solicitar al usuario la aprobación o las credenciales.

Los botones de escudo UAC se pueden usar como botones de confirmación (por ejemplo , Siguiente en un Asistente) o como un botón para mostrar una interfaz de usuario de configuración adicional (por ejemplo, Cambiar configuración en un cuadro de diálogo de propiedades).

El botón de escudo UAC consta de dos componentes de la interfaz de usuario:

• Icono de escudo
• Etiqueta de texto

El botón de escudo UAC se empaqueta de forma que los desarrolladores puedan usarlo en lugar de un botón normal. El botón UAC también admite la representación del icono de escudo en el lado izquierdo o derecho de la etiqueta de texto. Además, los desarrolladores tendrán la opción de ocultar o mostrar el icono de escudo mientras se muestra el botón UAC.

La captura de pantalla siguiente es un ejemplo de un botón de escudo UAC.

Ilustración 7. Botón de escudo UAC

Hipervínculo UAC

El hipervínculo UAC debe usarse en cualquier hipervínculo de interfaz de usuario que, al hacer clic, requerirá la petición de elevación para solicitar al usuario la aprobación o las credenciales.

Un hipervínculo UAC consta de los siguientes componentes:

• Icono de escudo
• Control Hyperlink

El hipervínculo UAC no se empaqueta con el icono de escudo para que lo use un desarrollador. Los desarrolladores deberán obtener el recurso de icono de escudo y representarlo junto al hipervínculo.

La captura de pantalla siguiente es un ejemplo de un hipervínculo UAC.

Figura 8. Hipervínculo UAC

Vínculo de comando UAC

El vínculo de comando UAC debe usarse en cualquier botón de interfaz de usuario que, al hacer clic, requerirá la petición de elevación para solicitar al usuario la aprobación o las credenciales.

Los vínculos de comandos UAC solo se deben usar como botones de confirmación (por ejemplo, "Hacer esta opción" en un cuadro de diálogo).

El vínculo de comando UAC consta de los siguientes componentes:

• Icono de escudo
• Componentes de vínculo de comandos estándar
• Texto del vínculo
• Texto de la nota

El vínculo de comando UAC se empaqueta de forma que un desarrollador pueda usar un vínculo de comando UAC en lugar de un vínculo de comando normal. El vínculo de comando UAC admite la representación del icono de escudo en el lado izquierdo o derecho del vínculo de comando.

A continuación se muestra un ejemplo de un vínculo de comando UAC.

Figura 9. Vínculo de comando UAC

Superposiciones de icono

En Windows Vista, si un archivo ejecutable requiere elevación para iniciarse, el icono del ejecutable debe "marcarse" con un icono de escudo para indicar este hecho. El manifiesto de aplicación del ejecutable debe marcar "requireAdministrator" para designar el ejecutable como que requiere un token de acceso administrativo completo. La superposición del icono de escudo también se colocará automáticamente en los ejecutables que se consideran que requieren elevación según la heurística de detección del instalador. Por ejemplo, un archivo denominado setup.exe recibirá automáticamente una superposición de icono de escudo incluso si el ejecutable no tiene un manifiesto de aplicación incrustado.

La ilustración siguiente es un ejemplo de superposición de icono UAC.

Figura 10. Superposición de icono UAC

Nota En la sección Crear e insertar un manifiesto de aplicación con un ejecutable se proporcionan instrucciones sobre cómo crear e insertar un manifiesto de aplicación con la aplicación de este documento.

Implementación de la interfaz de usuario

Implementación y API de iconos de escudo

En esta sección se proporciona información preliminar sobre los iconos y las API disponibles para los desarrolladores a medida que migran o implementan una nueva funcionalidad de aplicación administrativa.

Implementación de iconos de escudo y API

Iconos	API
Escudo	Recurso de usuario: IDI_SHIELD
Botón	Button_SetElevationRequired(hwndButton)
Syslink/Hyperlink	Diseño IDI_SHIELD junto a syslink
Vínculo de comando	Cargar IDI_SHIELD y establecer como icono de vínculo de comando
Menú contextual	Compatibilidad con iconos en DefCM para comandos estáticos

Agregar un icono de escudo a la interfaz de usuario

Agregue un icono pequeño:

#include <shellapi.h>
SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_SMALLICON, &sii);
hiconShield  = sii.hIcon;

Agregar un icono grande:

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICON | SHGSI_LARGEICON, &sii);
hiconShield  = sii.hIcon;

Agregue un icono de tamaño personalizado:

SHSTOCKICONINFO sii;
sii.cbSize = sizeof(sii);
SHGetStockIconInfo(SIID_SHIELD, SHGSI_ICONLOCATION, &sii);
hiconShield  = ExtractIconEx(sii. ...);

Nota Por lo general, no debe agregar el icono de escudo directamente a la interfaz de usuario. Se recomienda usar uno de los métodos de procedimiento para incrustar el icono de escudo en un control. Además, simplemente agregar un icono de escudo en la interfaz de usuario no garantizará la compatibilidad con UAC. También debe refracción la totalidad de la experiencia del usuario de la aplicación (agregue un valor requestedExecutionLevel, corrija los errores de usuario estándar y asegúrese de que la interfaz de usuario sea fácil de usar y compatible con UAC).

Agregar un icono de escudo a un botón

El control de botón estándar (PUSHBUTTON, DEFPUSHBUTTON) se ha mejorado para permitirle agregar un icono junto con el texto mostrado, sin necesidad de establecer los estilos BS_ICON o BS_BITMAP.

Para mostrar el icono de escudo, llame a la macro siguiente (definida en commctrl.h):

Button_SetElevationRequiredState(hwndButton, fRequired);

Nota hwndButton es el HWND del botón; fRequired determina si se debe mostrar (TRUE) u ocultar (FALSE) el icono de escudo UAC.

Agregar un icono de escudo a un botón de Windows Installer

Los cuadros de diálogo de Windows Installer creados mediante la compatibilidad con tablas internas pueden agregar un escudo al último botón de la secuencia de diálogo de la interfaz de usuario estableciendo el atributo ElevationShield en el control.

Agregar un icono de escudo a un botón "Siguiente" en un asistente

Importante Al mostrar el icono de escudo UAC, el botón "Siguiente" solo se admite en AeroWizards (PSH_AEROWIZARD).

Para mostrar el icono de escudo en el botón "Siguiente" para una página específica de AeroWizard, use el código siguiente:

case WM_NOTIFY:
    if (reinterpret_cast<NMHDR*>(lParam)->code == PSN_SETACTIVE)
    {
        // Show next button
        //
        // Note new wParam flag -- when PSWIZBF_ELEVATIONREQUIRED flag
        // is specified, it indicates that the next page will require
        // elevation, so if the next button is being shown, show it as
        // a shield button.

        SendMessage(GetParent(hwndDlg), 
                    PSM_SETWIZBUTTONS, 
                    PSWIZBF_ELEVATIONREQUIRED, 
                    PSWIZBF_NEXT);

        // return 0 to accept the activation
        SetWindowLong(hwndDlg, DWLP_MSGRESULT, 0); 
    }
    break;

Agregar un icono de escudo a un botón de diálogo de tarea

Precaución Un botón de diálogo de tarea nunca debe requerir un icono de escudo UAC. Se espera que la acción "presionar" en un botón de diálogo de tarea confirme o cancele y descarte el cuadro de diálogo de la tarea. Sería extraño que ese botón muestre el mensaje de elevación al usuario.

Elevar un cuadro de diálogo modal

Use el moniker de elevación para elevar el objeto COM que representa el cuadro de diálogo modal.

Tareas:

• Mueva el cuadro de diálogo a un objeto COM.
• Exponga un método ShowDialog().
• Use la API CreateElevatedComObject() para crear el objeto COM y llamar a ShowDialog().

Esta API ejecutará una instancia del objeto COM como administrador después de pasar por el proceso de elevación.

Nota Hay disponible una versión de esta API que es más complicada de llamar. Una versión simplificada estará disponible en una versión posterior de Windows Vista.

Directrices de educación y asistencia para usuarios

Cuando se ha vuelto a factorizar una interfaz de usuario y se coloca detrás de un botón, los ISV deben evaluar si se garantiza un cambio en el nombre del botón. Microsoft recomienda encarecidamente usar Advanced como una etiqueta de botón para las tareas de elevación. En su lugar, use etiquetas más descriptivas y comprensibles, como Cambiar configuración o un término que sugiere lo que está detrás del botón.

Directrices para la interfaz de usuario solo administrador

Si un administrador siempre iniciará una aplicación, no es necesario agregar escudos adicionales dentro de la interfaz de usuario de la aplicación. Esto se debe a que la aplicación se elevará y todo lo que hace será elevado y, por lo tanto, no necesita más elevación.

Nota Si tiene vínculos a otra interfaz de usuario de administrador en la experiencia de usuario solo de administrador, la interfaz de usuario iniciará su destino con privilegios elevados. Por lo tanto, no es necesario colocar ningún escudo en una aplicación que sea únicamente administrativa.

Cuándo agregar el icono de escudo a la interfaz de usuario de la aplicación

Una aplicación de elección administrativa

Un proceso con privilegios elevados o un objeto COM

La aplicación inicial se inicia sin necesidad de elevación. Esos elementos de la interfaz de usuario que requerirían un token de acceso administrativo están decorados con un icono de escudo como identificación. Esta decoración indica al usuario que el uso de esa característica requerirá la aprobación del administrador. Cuando la aplicación detecta que se ha seleccionado uno de estos botones, tiene las dos opciones siguientes.

• La aplicación inicia un segundo programa mediante ShellExeucute() para realizar la tarea administrativa. Este segundo programa se marcaría con un requestedExecutionLevel de requireAdministrator, lo que provocaba que el usuario se solicitara su aprobación. Este segundo programa se ejecutaría con un token de acceso administrativo completo y podría realizar la tarea deseada.
• La aplicación inicia un objeto COM mediante CreateElevatedComObject(). Esta API iniciaría el objeto COM con un token de acceso administrativo completo después de la aprobación y este objeto COM podría realizar la tarea deseada.

Este método proporciona la experiencia de usuario más rica y es el método preferido para tratar con la funcionalidad administrativa.

En la lista siguiente se detallan los requisitos de un proceso con privilegios elevados o un objeto COM:

• El panel de control debe implementar la decoración del escudo y su arquitectura necesaria.
• El desarrollador debe determinar dónde debe ir el escudo en la interfaz de usuario.
• El desarrollador debe realizar el trabajo arquitectónico para separar la lógica de negocios en un objeto COM del objeto de la interfaz de usuario.
• El desarrollador debe llamar al proceso de elevación de UAC cuando se detecte el evento OnClick para el icono de escudo.

En la lista siguiente se detallan las ventajas de diseñar correctamente un proceso con privilegios elevados o un objeto COM:

• Esta es la mejor experiencia general del usuario para ambos tipos de usuario. La interfaz de usuario se iniciará, podrá ver a todos y todas las funciones de UAC en esa interfaz de usuario serán accesibles para todos. Solo cuando se requiere una tarea de administrador, el usuario intenta elevar para completar la tarea.
• Al realizar este trabajo, ahora podrá seguir adelante totalmente compatible con UAC.
• La separación de la interfaz de usuario/COM es una buena práctica arquitectónica.

Al hacer clic en un icono de escudo, la aplicación inicia un programa con privilegios elevados o un objeto COM con privilegios elevados para realizar la tarea.

Aplicación solo administrador

En este caso, el inicio inicial de la aplicación requiere la aprobación del administrador. Este método se denomina "prompt before launch". Una vez iniciada, la aplicación se ejecuta con un token de acceso administrativo completo y, por tanto, puede realizar las tareas administrativas deseadas. Este método es el menos trabajo para el desarrollador. El manifiesto de la aplicación se marca con un requestedExecutionLevel de requireAdministrator.

Importante Aunque esto requiere la menor cantidad de trabajo para el desarrollador, tenga en cuenta que, al igual que otras aplicaciones administrativas de Windows Vista, los administradores tendrán que elevar para poder usar esta aplicación y que los usuarios estándar no podrán usar la aplicación.

En la lista siguiente se detallan los requisitos de las aplicaciones solo de administrador:

• El manifiesto de aplicación debe contener un marcado requestedExecutionLevel establecido en requireAdministrator.
• Se solicita al usuario la aprobación del administrador antes de que Windows inicie la aplicación con un token de acceso administrativo completo.

En la lista siguiente se detallan las ventajas de diseñar correctamente una aplicación solo de administrador:

• El sistema operativo no tiene que "adivinar" si la aplicación de instalación es una aplicación administrativa.
• A los usuarios estándar se les proporcionará automáticamente una sugerencia de que la operación es una operación administrativa. Por ejemplo, cuando vea el icono de una aplicación marcada como requireAdministrator, el icono tiene un escudo incrustado en el icono.
• En Windows Vista, si marca la aplicación como requireAdministrator sabe que, una vez iniciada, se ejecutará con un token de acceso de administrador completo. Los usuarios deben elevar para ejecutar la aplicación (ya sea como administrador en modo de aprobación Administración o mediante Ejecutar como administrador).

Nota Marcar una aplicación requireAdministrator no eleva silenciosamente la aplicación. El usuario seguirá teniendo que dar su consentimiento de elevación para iniciar la aplicación. No hay ninguna manera de marcar una aplicación en Windows Vista para elevar silenciosamente.

En la lista siguiente se detallan los puntos de consideración para diseñar una aplicación solo de administrador:

• Esta experiencia de usuario significa que todos los usuarios verán una solicitud de elevación (ya sea la solicitud de credenciales o la solicitud de consentimiento) antes de que la interfaz de usuario sea visible. Esto también significa que nadie puede simplemente ver la configuración actual hasta después de autenticarse con credenciales de administrador.
• Si está marcando requireAdministrator en una aplicación de instalación, debe tener en cuenta que el usuario que ejecuta la instalación es diferente del usuario que puede usar la aplicación. Por lo tanto, no debe modificar HKEY_CURRENT_USER (HKCU) y otras configuraciones por usuario, como escribir en el perfil de usuario, durante la configuración administrativa.

Importante Debe suponer que el usuario que ejecuta la aplicación administrativa es diferente del usuario normal en el equipo.

Los ejecutables que requieren un token de acceso de administrador se marcan con una superposición de icono de escudo.

Aplicación mixta

Una aplicación mixta es una que los usuarios pueden ejecutar, todos los usuarios del sistema (usuarios estándar, administradores en modo de aprobación Administración y los que se encuentran entre operadores de copia de seguridad). También es una aplicación "prompt before launch". La aplicación se ejecutará con el token de acceso del invocador y se iniciará normalmente para los usuarios estándar (sin petición de elevación). A continuación, el programa debe modificar su comportamiento en tiempo de ejecución para deshabilitar esas características que no estarían disponibles para el usuario en función del token de acceso administrativo obtenido.

Una aplicación mixta no tiene la capacidad de obtener privilegios administrativos adicionales una vez iniciada; por lo tanto, no proporciona la flexibilidad del proceso con privilegios elevados ni del método de objeto COM descrito anteriormente. Esto es más útil para las aplicaciones que requieren un token de acceso por encima del de un usuario estándar, pero menor que un administrador completo.

Por ejemplo, Microsoft Management Console (MMC) está marcado como highestAvailable. Si un usuario estándar verdadero ejecuta MMC, MMC se iniciará como una aplicación de usuario estándar sin ningún intento de elevación o solicitud. Si el usuario es un usuario de "token dividido", como un administrador en Administración modo de aprobación o un operador de copia de seguridad, el sistema operativo pedirá al usuario que obtenga el consentimiento para iniciar MMC con el privilegio "más alto" disponible del usuario. En el caso de un usuario estándar que tenga privilegios de operador de copia de seguridad, después de la elevación, MMC se iniciará con el usuario estándar + Operador de copia de seguridad, pero nada más. Si un administrador inicia MMC, después de la elevación, MMC se ejecutará como una aplicación de administrador completa.

La ventaja de diseñar correctamente una aplicación mixta es que la aplicación está disponible para todos los usuarios del sistema, aunque se pueda deshabilitar alguna funcionalidad.

En la lista siguiente se detallan los puntos de consideración para diseñar aplicaciones mixtas:

• El desarrollador debe cambiar dinámicamente el comportamiento de la aplicación en función de los privilegios administrativos de Windows y los derechos de usuario disponibles del usuario.
• Se impide que el usuario estándar pueda actuar en las funciones de nivel administrativo en la interfaz de usuario. No hay ninguna posibilidad de elevación de petición una vez que el programa se esté ejecutando (los administradores deben elevar antes de abrir la interfaz de usuario).

Nota Hay una solución alternativa para el punto de viñeta anterior. Un administrador puede iniciar un símbolo del sistema con privilegios elevados en el equipo del usuario estándar y ejecutar la aplicación desde el símbolo del sistema. Por ejemplo, haga clic con el botón derecho en el símbolo del sistema, seleccione Ejecutar como administrador y escriba "applicationname.exe" en el símbolo del sistema.

La experiencia del usuario se bifurca entre el usuario estándar y el administrador en Administración modo de aprobación.

Aplicación mixta de ejemplo: Aplicación de copia de seguridad

Un miembro del grupo Operadores de copia de seguridad podría iniciar la aplicación. A continuación, el programa comprobaría que el nivel más alto de privilegios administrativos de Windows y derechos de usuario disponibles para el usuario es suficiente para el funcionamiento del programa. Para obtener más información sobre el comportamiento del inicio del programa, vea la sección Marcado del manifiesto de aplicación y Comportamiento de inicio de la aplicación de este documento.

Decisiones clave para diseñar aplicaciones de Administrator-Only

Objetos de negocio de back-end

En esta sección se proporciona información general sobre los tres modelos que un desarrollador puede elegir al desarrollar una aplicación administrativa que proporcione la mejor experiencia de usuario.

• Modelo de Agente de Administración
• Modelo de servicio de Back-End
• Modelo de objetos COM de Administración

modelo de Agente de Administración

En el modelo de agente de Administración, la aplicación se divide en dos ejecutables independientes: un ejecutable de usuario estándar y un ejecutable administrativo. El desarrollador, con un manifiesto de aplicación, marca el programa de usuario estándar con un requestedExecutionLevel de asInvoker y marca el programa administrativo con un requestedExecutionLevel de requireAdministrator. Un usuario iniciará primero el programa de usuario estándar. Cuando el usuario intenta realizar una operación que el programa de usuario estándar conoce requiere un token de acceso de administrador completo, realiza un ShellExecute() e inicia el programa administrativo. La API ShellExecute() de Windows examina el manifiesto y solicita la aprobación del usuario antes de ejecutar la aplicación con el token de acceso administrativo completo del usuario. Después, el programa administrativo puede realizar las tareas administrativas.

Nota El programa ejecutable administrativo puede habilitar la comunicación entre procesos con un ejecutable de usuario estándar mediante memoria compartida, RPC local o canalizaciones con nombre. Si el programa administrativo habilita la comunicación con el ejecutable de usuario estándar, el desarrollador debe usar una buena práctica de seguridad para validar todas las entradas del programa con privilegios inferiores.

Nota No hay ningún canal de comunicación entre los dos programas una vez que se inicia el segundo programa

En la lista siguiente se usan los detalles del modelo de agente de administración:

• Asistentes: cuando el Asistente para hardware se da cuenta de que el controlador necesario no está instalado en el equipo o ubicado en la ubicación aprobada de la empresa, necesita una aplicación con privilegios elevados con la capacidad de mover un controlador al almacén de equipos.
• Autorun.exe llamar a Setup.exe: la primera vez que colocas en un CD de juego, la operación necesaria de autorun.exe es configurar la aplicación. La segunda vez que insertas el CD, la operación predeterminada es jugar al juego.

Una ventaja para usar el modelo de agente de administración es que probablemente es el mecanismo más fácil de implementar para el desarrollador.

En la lista siguiente se detallan algunos inconvenientes para usar el modelo de agente de Administración:

• Las transiciones de la aplicación a la aplicación pueden resultar confusas para el usuario. Puede ser difícil mantener al usuario informado de por qué una nueva aplicación está "apareciendo" en el monitor.
• Además, el estado es más difícil de pasar entre estas dos aplicaciones. Por ejemplo, no lo usaría para pasar el estado entre un panel de control de usuario estándar (CPL) y su homólogo de administrador simplemente para permitir que la misma CPL tenga funcionalidad administrativa y no administrativa. El CPL de usuario estándar tendría que almacenar su estado en algún lugar.
• A menudo, hay un montón de código replicado al dividir la funcionalidad entre dos programas.

Para implementar el modelo de agente de administración, cree dos programas (un usuario estándar y otro administrativo), guárdelos con el manifiesto adecuado requestedExecutionLevel e inicie el programa administrativo desde el programa de usuario estándar mediante ShellExecute().

Modelo de servicio de Back-End

En el modelo de servicio back-end, la aplicación se divide de nuevo en dos ejecutables independientes: un ejecutable de usuario estándar que proporciona la interfaz de usuario al usuario y un servicio back-end que se ejecuta en el sistema. La llamada a procedimiento remoto de Microsoft (RPC) se usa para comunicarse entre los dos. La aplicación front-end se marca con un valor requestedExecutionLevel de asInvoker y el servicio back-end se ejecuta como SYSTEM. La comunicación entre la aplicación y el servicio back-end se realiza con RPC.

Un uso para el modelo de servicio back-end es controlar programas que podrían afectar al sistema, como programas antivirus o anti-spyware). La aplicación front-end proporciona los medios por los que el usuario que ha iniciado sesión y controla los aspectos del servicio.

Una ventaja importante del uso del modelo de servicio back-end es que no se requiere ninguna solicitud de elevación.

En la lista siguiente se detallan algunos inconvenientes para usar el modelo de servicio back-end:

• El servicio debe limitar los tipos de actividades que la aplicación de front-end puede indicarle que lo haga. Por ejemplo, un servicio antivirus puede permitir que un usuario estándar inicie un examen del sistema, pero no deshabilitar la comprobación de virus en tiempo real.
• Agregar un servicio innecesario al sistema puede afectar a todo el sistema. Asegúrese de que el servicio sea realmente necesario para la implementación de Windows Vista y que el servicio esté correctamente diseñado.

Para implementar el modelo de servicio back-end, cree una aplicación front-end de usuario estándar y un servicio back-end. Instale el servicio en el sistema durante el tiempo de instalación del producto.

Modelo de objetos COM de Administración

Este modelo se incluye aquí, pero se explicó en detalle anteriormente en este documento. El modelo de objetos COM de administrador permite que la elevación administrativa dinámica realice operaciones específicas desde dentro de una aplicación o panel de control.

Una ventaja importante para usar el modelo de objetos COM de administrador es que presenta la mejor experiencia de usuario para el usuario.

En la lista siguiente se detallan algunos inconvenientes para usar el modelo de objetos COM de administración:

• Requiere el mayor trabajo para el desarrollador, ya que cada característica de aplicación debe evaluarse y probarse para la funcionalidad de administrador y esa función debe proporcionarse mediante un objeto COM de back-end.
• El usuario debe proporcionar aprobación de elevación.
• La "unidad" resultante de la aplicación de usuario estándar y Administración objeto COM de back-end ahora es "drivable" y no está protegida por UIPI y otros mecanismos de aislamiento.

Para implementar el modelo de objetos COM de administrador, cree una aplicación front-end de usuario estándar e inicie objetos COM de back-end elevados para realizar tareas administrativas.

5. Rediseñar el instalador de la aplicación

Los siguientes procedimientos recomendados son para instalaciones de aplicaciones bien comportadas en un entorno de Windows Vista o UAC. Esta lista no es una lista completa. Para obtener una explicación más detallada de los requisitos de logotipo para Windows Vista, incluidos los requisitos de UAC, consulta la documentación del logotipo de Windows Vista y la versión detallada del borrador más reciente del documento de directrices del logotipo de Windows Vista.

Use estos requisitos al rediseñar la aplicación.

Usa Windows Installer 4.0 para el paquete de instalación.

Muchos de los siguientes requisitos ya están integrados en el motor de Windows Installer. El uso de Windows Installer para el paquete de instalación le ayudará a seguir los requisitos de instalación de Windows Vista.

Use archivos con versiones y no cambie los archivos durante la instalación.

El control de versiones de archivos garantiza que el estado de instalación final sea correcto cuando se complete la instalación. Sin versiones de archivo, se necesitará algún manual especial para asegurarse de que la instalación funciona correctamente para muchos escenarios de instalación diferentes. Además, al instalar archivos con versiones, no cambie a versiones anteriores, especialmente los archivos compartidos. Las versiones de degradación pueden ser buenas para la aplicación, pero con frecuencia provocan problemas con otras aplicaciones. Al declarar las versiones correctas de los archivos en el paquete de Windows Installer, Windows Installer admite de forma nativa esta característica.

Instale aplicaciones y almacene datos por usuario en diferentes ubicaciones.

Las aplicaciones deben instalarse en una carpeta en el directorio Archivos de programas. Para configurarlo, puedes usar la propiedad ProgramFilesFolder en la tabla Direcotry del paquete de Windows Installer, los datos de configuración por usuario deben almacenarse en archivos en el directorio \Users\username\AppData o en claves del Registro bajo la raíz HKCU. Todos los datos de usuario, plantillas y archivos creados por la aplicación tienen ubicaciones adecuadas en el subdirectorio \Users\username. Aunque esto no se ha aplicado en el pasado, ya que muchos usuarios ejecutarían programas con un token de acceso de administrador completo, es probable que las aplicaciones que no coloquen información en la ubicación correcta produzcan errores. Esto es especialmente cierto cuando la virtualización está desactivada.

Use una ubicación de carpeta coherente al instalar componentes compartidos.

Los componentes compartidos deben instalarse en el directorio Common Files mediante la propiedad CommonFilesFolder de la tabla Directorio del paquete de Windows Installer. La administración de componentes compartidos puede ser problemática y debe evitarse, si es posible. Un desarrollador que no instala componentes compartidos de forma coherente puede terminar con información de registro del Modelo de objetos componentes (COM) que apunte a componentes anteriores. Los módulos de combinación de Windows Installer (MSM) están diseñados específicamente para permitir que los componentes compartidos se instalen de forma coherente en el contexto de todos los paquetes que instalan el componente compartido. Otros problemas surgen cuando las modificaciones de los componentes compartidos hacen que se produzca un error en las aplicaciones existentes. Una manera de solucionar este problema es que las aplicaciones se compilan mediante Microsoft .NET o Win32, ensamblados con versiones.

Realice la reversión de la instalación si se produce un error en la instalación.

El software parcialmente instalado puede producir errores en formas extrañas e inesperadas que proporcionan una experiencia de usuario deficiente. Windows Installer admite esta característica de reversión.

No instale métodos abreviados de aplicación en todo el perfil del usuario.

Aunque puede resultar tentador agregar el icono de la aplicación a todos los puntos de exposición conocidos de Windows, a menudo resulta en que los usuarios sienten que han perdido el control de su equipo. A continuación, los usuarios se ven obligados a quitar manualmente estos accesos directos para devolver el equipo a una apariencia deseada. Si el desarrollador quiere agregar iconos al escritorio, pida al usuario permiso durante la instalación. Windows Vista aborda la detectabilidad de las aplicaciones después de la instalación y la lista de aplicaciones usadas más recientemente para evitar un recorrido grande del menú Inicio.

Evite iniciar automáticamente aplicaciones en segundo plano en el inicio de sesión del usuario.

Aunque es posible agregar programas al grupo de inicio o Ejecutar clave durante la instalación, agrega sobrecarga al sistema. Con el tiempo, el rendimiento del sistema del usuario puede degradarse significativamente. Si la aplicación puede beneficiarse de una tarea en segundo plano, permita que sea configurable por el usuario. Además, agregar una tarea de inicio a través de la clave de ejecución HLKM puede impedir que una cuenta de usuario estándar modifique el comportamiento en el futuro. Si el usuario quiere que una aplicación se inicie en el momento de inicio de sesión, almacene la información en la clave de ejecución de HKCU.

Siga la lógica de eliminación limpia.

Un usuario puede quitar una aplicación no solo para liberar espacio en disco, sino también para devolver el equipo a su estado antes de instalar la aplicación. El proceso de desinstalación de la aplicación debe quitarse correctamente y completamente la aplicación. Windows Installer tiene como valor predeterminado las siguientes reglas:

• Todos los archivos y carpetas de aplicación no compartidos.
• Archivos de aplicación compartidos cuyo recuento de referencias (refcount) alcanza cero.
• Entradas del Registro, excepto las claves que pueden compartir otros programas.
• Todos los accesos directos del menú Inicio que creó la aplicación en el momento de la instalación.
• Las preferencias del usuario se pueden considerar datos de usuario y dejar atrás, pero se debe incluir una opción para realizar una eliminación completamente limpia.
• El propio desinstalador (si no usa Windows Installer).

6. Crear e insertar un manifiesto de aplicación con la aplicación

En Windows Vista, la manera correcta de marcar las aplicaciones es insertar un manifiesto de aplicación en el programa que indique al sistema operativo lo que necesita la aplicación. En la versión de Windows Vista, hay disposiciones para permitir que el código no manifiesto o sin firmar se ejecute con un token de acceso administrativo completo.

Nota En futuras versiones, la única manera de ejecutar una aplicación con privilegios elevados será tener un manifiesto firmado que identifique el nivel de privilegio que necesita la aplicación.

Esquema del manifiesto de aplicación

Los manifiestos de aplicación no son nuevos en la versión de Windows Vista. Los manifiestos se usaron en Windows XP para ayudar a los desarrolladores de aplicaciones a identificar aspectos como las versiones de dll con las que se probó la aplicación. Proporcionar el nivel de ejecución es una extensión para ese esquema de manifiesto existente.

El manifiesto de aplicación de Windows Vista se ha mejorado con atributos que permiten a los desarrolladores marcar sus aplicaciones con un nivel de ejecución solicitado. A continuación se muestra el formato para esto.

<requestedExecutionLevel
level="asInvoker|highestAvailable|requireAdministrator"
uiAccess="true|false"/>

Posibles valores de nivel de ejecución solicitados

Valores	Descripción	Comentario
asInvoker	La aplicación se ejecuta con el mismo token de acceso que el proceso primario.	Se recomienda para aplicaciones de usuario estándar. Realice la refracción con puntos de elevación internos según las instrucciones proporcionadas en este documento.
highestAvailable	La aplicación se ejecuta con los privilegios más altos que puede obtener el usuario actual.	Se recomienda para aplicaciones en modo mixto. Planee la refracción de la aplicación en futuras versiones.
requireAdministrator	La aplicación solo se ejecuta para administradores y requiere que la aplicación se inicie con el token de acceso completo de un administrador.	Se recomienda solo para aplicaciones de administrador. No se necesitan puntos de elevación internos. La aplicación ya se está ejecutando con privilegios elevados.

Nota Las aplicaciones de hospedaje pueden convertirse en aplicaciones estándar de solo usuario o administrador si admiten ese tipo determinado de aplicación hospedada. Por ejemplo, MMC.exe ahora solo hospeda complementos administrativos y Explorer.exe solo hospeda código de usuario estándar.

Comportamiento del sistema

Application Markin	¿Virtualizar?
Unmarked	Sí
asInvoker	No
requireAdministrator	No
highestAvailable	No

Comportamiento de inicio de manifiesto de aplicación y marcado de manifiesto de aplicación

En esta sección se detalla el comportamiento de la solicitud de elevación en función del token de acceso del proceso primario, la configuración del control de cuentas de usuario: comportamiento del mensaje de elevación para los administradores en Administración directiva de modo de aprobación y control de cuentas de usuario: comportamiento de la solicitud de elevación para la directiva de usuarios estándar y el marcado de nivel de ejecución solicitado para la aplicación.

Si una aplicación puede ejecutarse y qué derechos de usuario y privilegios administrativos de Windows puede obtener dependen de la combinación del nivel de ejecución solicitado de la aplicación en la base de datos de compatibilidad de aplicaciones y los privilegios administrativos disponibles para la cuenta de usuario que inició la aplicación. En las tablas siguientes se identifica el posible comportamiento en tiempo de ejecución en función de estas combinaciones posibles.

Comportamiento de inicio de la aplicación para un miembro del grupo administradores local

Token de acceso de proceso primario	Directiva de consentimiento para los miembros del grupo administradores locales	Ninguno o asInvoker	highestAvailable	requireAdministrator
Usuario estándar	No preguntar	La aplicación se inicia como un usuario estándar	La aplicación se inicia con un token de acceso administrativo completo; sin aviso	La aplicación se inicia con un token de acceso administrativo completo; sin aviso
Usuario estándar	Pedir consentimiento	La aplicación se inicia como un usuario estándar	La aplicación se inicia con un token de acceso administrativo completo; solicitar consentimiento	La aplicación se inicia con un token de acceso administrativo completo; solicitar consentimiento
Usuario estándar	Se piden credenciales	La aplicación se inicia como un usuario estándar	La aplicación se inicia con un token de acceso administrativo completo; solicitud de credenciales	La aplicación se inicia con un token de acceso administrativo completo; solicitud de credenciales
Administrador (UAC está deshabilitado)	N/D	La aplicación se inicia con un token de acceso administrativo completo; sin aviso	La aplicación se inicia con un token de acceso administrativo completo; sin aviso	La aplicación se inicia con un token de acceso administrativo completo; sin aviso

Comportamiento de inicio de la aplicación para una cuenta de usuario estándar

Token de acceso de proceso primario	Directiva de consentimiento para usuarios estándar	asInvoker	highestAvailable	requireAdministrator
Usuario estándar	No preguntar	La aplicación se inicia como un usuario estándar	La aplicación se inicia como un usuario estándar	La aplicación no se inicia
Usuario estándar	Se piden credenciales	La aplicación se inicia como un usuario estándar	La aplicación se inicia como un usuario estándar	Solicitar credenciales de administrador antes de ejecutar la aplicación
Usuario estándar (UAC está deshabilitado)	No aplicable	La aplicación se inicia como un usuario estándar	La aplicación se inicia como un usuario estándar	La aplicación podría iniciarse, pero se producirá un error más adelante.

Comportamiento de inicio de la aplicación para un usuario estándar con privilegios adicionales (por ejemplo, operador de copia de seguridad)

Token de acceso de proceso primario	Directiva de consentimiento para usuarios estándar	asInvoker	highestAvailable	requireAdministrator
Usuario estándar	Sin petición	La aplicación se inicia como un usuario estándar	La aplicación se inicia como un usuario estándar con privilegios adicionales	La aplicación no se inicia
Usuario estándar	Se piden credenciales	La aplicación se inicia como un usuario estándar	Solicitar credenciales antes de ejecutar la aplicación	Solicitar credenciales de administrador antes de ejecutar la aplicación
Usuario estándar (UAC está deshabilitado)	No aplicable	La aplicación se inicia como un usuario estándar	La aplicación se inicia como un usuario estándar con privilegios adicionales	La aplicación podría iniciarse, pero se producirá un error más adelante.

Valores de uiAccess

Posibles valores uiAccess

Value	Descripción
False	La aplicación no necesita dirigir la entrada a la interfaz de usuario de otra ventana en el escritorio. Las aplicaciones que no proporcionan accesibilidad deben establecer esta marca en false. Las aplicaciones necesarias para impulsar la entrada en otras ventanas del escritorio (por ejemplo, el teclado en pantalla) deben establecer este valor en true.
True	La aplicación puede omitir los niveles de control de la interfaz de usuario para controlar la entrada en ventanas con privilegios superiores en el escritorio. Esta configuración solo se debe usar para las aplicaciones de tecnología de asistencia de interfaz de usuario.

Importante Las aplicaciones con la marca uiAccess establecida en true deben estar firmadas con Authenticode para iniciarse correctamente. Además, la aplicación debe residir en una ubicación protegida en el sistema de archivos. \Archivos de programa\ y \windows\system32\ son actualmente las dos ubicaciones protegidas permitidas.

Cómo crear un manifiesto incrustado con Microsoft Visual Studio

Visual Studio proporciona la capacidad de insertar automáticamente un archivo de manifiesto XML en la sección de recursos de la imagen Portable Executable (PE). En esta sección se explica cómo usar Visual Studio para crear una imagen pe firmada que contenga un manifiesto. Por lo tanto, este manifiesto puede incluir los atributos requestedExecutionLevel necesarios, lo que permite que la aplicación se ejecute con el nivel de privilegio deseado en Windows Vista. Cuando se inicia el programa, la información del manifiesto se extraerá de la sección de recursos del PE y la usará el sistema operativo. No es necesario usar la interfaz gráfica de usuario (GUI) de Visual Studio para incluir un manifiesto. Una vez que los cambios necesarios estén en el código fuente, la compilación y la vinculación mediante herramientas de línea de comandos también incluirán el manifiesto en la imagen pe resultante.

Archivo de manifiesto

Para marcar la aplicación, cree primero un archivo de manifiesto que se usará con la aplicación de destino. Esto se puede hacer con cualquier editor de texto. El archivo de manifiesto debe tener el mismo nombre que el target.exe con una extensión .manifest , como se muestra en el ejemplo siguiente.

Executable: IsUserAdmin.exe 
Manifest:IsUserAdmin.exe.manifest
Sample application manifest file:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> 
  <assemblyIdentity version="1.0.0.0"
     processorArchitecture="X86"
     name="IsUserAdmin"
     type="win32"/> 
  <description>Description of your application</description> 
  <!-- Identify the application security requirements. -->
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel
          level="requireAdministrator"
          uiAccess="false"/>
        </requestedPrivileges>
       </security>
  </trustInfo>
</assembly>

Las partes del manifiesto que se deben ajustar para la aplicación se marcan en negrita. Entre esos tipos se incluyen los siguientes:

• La identidad del ensamblado
• El nombre
• El tipo
• Descripción
• Atributos de requestedExecutionLevel

Compilar manifiestos de aplicación en código de C/C++ con Visual Studio 2005 para aplicaciones solo de Windows Vista

Importante Si la aplicación está pensada para ejecutarse en Windows Vista y Windows XP, debe seguir los procedimientos detallados en la sección siguiente: Compilar e insertar un manifiesto con Microsoft Visual Studio 2005 para Windows XP y Aplicaciones de Windows Vista.

A continuación, debe adjuntar el manifiesto al archivo ejecutable agregando una línea en el archivo de recursos de la aplicación (el archivo .rc) para que Microsoft Visual Studio inserte el manifiesto dentro de la sección de recursos del archivo PE. Para ello, coloque el manifiesto en el mismo directorio que el código fuente del proyecto que está compilando y edite el archivo .rc para incluir las líneas siguientes.

#define MANIFEST_RESOURCE_ID 1
MANIFEST_RESOURCE_ID RT_MANIFEST "IsUserAdmin.exe.manifest"

Después de volver a generar la aplicación, el manifiesto debe insertarse en la sección de recursos del ejecutable.

Compilar e insertar un manifiesto con Microsoft Visual Studio 2005 para aplicaciones de Windows XP y Windows Vista

En Visual Studio 2005, la interfaz del entorno de desarrollo integrado (IDE) de C/C++ que permite la inclusión de archivos de manifiesto adicionales en un archivo ejecutable de destino realiza algún procesamiento en el XML, que inserta una etiqueta xmlns duplicada. Debido a esto, no se puede usar el método documentado anteriormente sobre cómo incluir un manifiesto en un proyecto de C++ de Visual Studio 2005 si la aplicación debe ejecutarse en Windows Vista y Windows XP. Los procedimientos siguientes se modifican para incluir etiquetas de versión explícitas en la sección trustInfo.

Se planea una corrección para la herramienta de mt.exe para solucionar el problema en el que genera la declaración de espacio de nombres duplicado en el XML. Hasta que haya disponible una nueva versión de mt.exe, puede evitar el problema de combinar manifiestos agregando explícitamente etiquetas de versión a la sección trustinfo del manifiesto. A continuación se muestra un manifiesto de ejemplo:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <ms_asmv2:trustInfo xmlns:ms_asmv2="urn:schemas-microsoft-com:asm.v2">
      <ms_asmv2:security>
         <ms_asmv2:requestedPrivileges>
            <ms_asmv2:requestedExecutionLevel level="asInvoker">
            </ms_asmv2:requestedExecutionLevel>
         </ms_asmv2:requestedPrivileges>
      </ms_asmv2:security>
   </ms_asmv2:trustInfo>
</assembly>

Proyecto de C o C++

En el procedimiento siguiente se detalla cómo crear un manifiesto para un tipo de proyecto de C o C++ en Visual Studio 2005.

Para crear un manifiesto para un proyecto de C o C++ en Microsoft Visual Studio 2005

1. Abrir el proyecto en Microsoft Visual Studio 2005
2. En Proyecto, seleccione Propiedades.
3. En Propiedades, seleccione Herramienta de manifiesto y, a continuación, seleccione Entrada y salida.
4. Agregue el nombre del archivo de manifiesto de aplicación en Archivos de manifiesto adicionales.
5. Vuelva a compilar la aplicación.

Nota Los manifiestos actualizados que incluyen etiquetas de versión explícitas permitirán que la aplicación se ejecute correctamente en Windows Vista y Windows XP.

Código administrado (C#, J# y Visual Basic)

Visual Studio no inserta actualmente un manifiesto predeterminado en código administrado. En el caso del código administrado, el desarrollador simplemente insertaría un manifiesto predeterminado en el ejecutable de destino mediante mt.exe. Los pasos serían los siguientes:

Para insertar un archivo de manifiesto predeterminado en el ejecutable de destino con mt.exe

1. Use un editor de texto, como el Bloc de notas de Windows, para crear un archivo de manifiesto predeterminado, temp.manifest.
2. Use mt.exe para insertar el manifiesto. El comando sería: mt.exe –manifest temp.manifest –outputresource:YourApp.exe;#1

Agregar el manifiesto de aplicación como paso en Visual Studio posterior a la compilación

Agregar el manifiesto de aplicación también se puede automatizar como un paso posterior a la compilación. Esta opción está disponible para C/C++ y los dos lenguajes de código administrado de C# y J#.

Nota El IDE no incluye actualmente una opción posterior a la compilación para una aplicación de Visual Basic.

Coloque la línea siguiente como una tarea posterior a la compilación en Propiedades del proyecto:

mt.exe -manifest "$(ProjectDir)$(TargetName).exe.manifest" 
-updateresource:"$(TargetDir)$(TargetName).exe;#1"

7. Probar la aplicación

Pruebe la aplicación rediseñada o nueva para la compatibilidad de aplicaciones con el Analizador de usuarios estándar. Un procedimiento que detalla este proceso se describió anteriormente en este documento en la sección Probar la aplicación para compatibilidad con UAC.

Use el siguiente flujo de trabajo para probar la aplicación.

Para probar la aplicación con fines de compatibilidad con UAC

1. Pruebe la aplicación con la herramienta Analizador de usuarios estándar.
2. Inicie sesión en un equipo de Windows Vista como administrador en Administración modo de aprobación y ejecute el programa. Asegúrese de probar toda la funcionalidad y tenga en cuenta la experiencia del usuario. Abra los errores de elevación o interfaz de usuario en consecuencia.
3. Inicie sesión en un equipo windows Vista como usuario estándar y ejecute el programa. Asegúrese de probar todas las funcionalidades y tenga en cuenta las diferencias o errores en la experiencia de usuario estándar en comparación con el administrador en Administración experiencia de usuario en modo de aprobación. Abra los errores de elevación y experiencia del usuario en consecuencia.

8. Authenticode Firmar la aplicación

La aplicación ahora contiene un manifiesto, que se detectará y la información analizada en el inicio de la aplicación. Sin embargo, el ejecutable se puede manipular. Para evitar esto, debe firmar la aplicación con una firma Authenticode. Tenga en cuenta que Windows Vista tendrá la capacidad de impedir que cualquier aplicación sin firmar se inicie con un token de acceso de administrador completo. Si desea que la aplicación funcione correctamente en entornos bloqueados, al tiempo que muestra una interfaz de usuario más fácil de usar, debe firmarse con una firma Authenticode.

Para firmar la aplicación, puede generar un certificado a partir de makecert.exe o obtener una clave de firma de código de una de las entidades de certificación comerciales (CA), como VeriSign, Thawte o una CA de Microsoft.

Nota Necesitará un certificado comercial si con la aplicación será de confianza en el equipo de destino de un cliente que instale la aplicación.

Si usa el archivo makecert.exe para generar el par de claves de firma, tenga en cuenta que solo genera una clave de 1024 bits. Las firmas authenticode deben ser al menos una clave de 2048 bits. El archivo makecert.exe solo debe usarse con fines de prueba.

En el procedimiento siguiente se detallan los requisitos de alto nivel para usar makecert.exe para generar el par de claves de firma. Un ejemplo y makecert.exe parámetros siguen este procedimiento.

Para usar makecert.exe para generar el par de claves de firma

1. Genere el certificado.
2. Firme el código.
3. Instale el certificado de prueba.

Procedimiento de firma de ejemplo

Los procedimientos siguientes se proporcionan como ejemplos y no están diseñados para seguirse estrictamente. Por ejemplo, reemplace el nombre del certificado de prueba por el nombre del certificado y asegúrese de adaptar los procedimientos a su ca y entorno de desarrollo específicos.

Paso 1: Generar el certificado

makecert -r -pe -ss PrivateCertStore -n "CN=Contoso.com(Test)" 
ContosoTest.cer

parámetros demakecert.exe

Parámetro	Descripción
/r	Crear certificado autofirmado
/Pe	Hace que la clave privada del certificado se pueda exportar a la máquina de firma.
/ss StoreName	Nombre del almacén de certificados que almacenará el certificado de prueba. Ejemplo: PrivateCertStore
/n X500Name	Nombre X500 del firmante del certificado. Ejemplo: Contoso.com(Test)
CertificateName.cer	Nombre del certificado. Ejemplo: ContosoTest.cer

Paso 2: Firmar el código

Signtool sign /v /s PrivateCertStore /n Contoso.com(Test) /t 
http://timestamp.verisign.com/scripts/timestamp.dll file.exe

Paso 3: Instalar el certificado de prueba

Para instalar el certificado de prueba

1. Inicie una ventana de comandos con privilegios elevados haciendo clic con el botón derecho en símbolo del sistema y seleccionando Ejecutar como administrador.
2. En símbolo del sistema, escriba mmc.exe y presione Entrar.
3. En mmc, seleccione Archivo y, a continuación, seleccione Agregar o quitar complemento...
4. En Agregar o quitar complementos, seleccione Certificados, haga clic en Agregar y, a continuación, haga clic en Aceptar.
5. En el cuadro de diálogo Complemento Certificados, seleccione Cuenta de equipo y haga clic en Siguiente.
6. En Seleccionar equipo, seleccione Equipo local y, a continuación, haga clic en Aceptar.
7. En Agregar o quitar complementos, haga clic en Aceptar.
8. En el complemento Certificados y vaya a Entidades de certificación raíz de confianza, haga clic con el botón derecho en Certificados, seleccione Todas las tareas y, a continuación, seleccione Importar...
9. En el Asistente para importación de certificados, importe el certificado de prueba ContosoTest.cer.

9. Participar en el Programa de logotipos de Windows Vista

Microsoft ofrece el programa logotipo de Windows Vista para ayudar a los clientes a identificar sistemas y periféricos que cumplen una definición de línea base completa de las características de la plataforma y los objetivos de calidad para garantizar una excelente experiencia informática para los usuarios finales.

Implementación y aplicación de revisiones para usuarios estándar

Por lo general, las empresas tendrán que tener en cuenta cómo instalarán aplicaciones en las estaciones de trabajo de sus usuarios de forma automatizada, lo que reduce los costos administrativos. Hay fundamentalmente dos partes de este problema: en primer lugar, cómo se deben empaquetar estas aplicaciones para la implementación y, en segundo lugar, qué tecnología se debe usar para implementarlas. En el caso de entornos empresariales más pequeños, es posible que no sea necesario un mecanismo de implementación automatizado sólido.

Suponiendo que la empresa ya ha realizado un inventario del software que se ejecuta en su entorno, el siguiente paso consiste en volver a empaquetar estas aplicaciones para su implementación. Microsoft recomienda el formato de Windows Installer porque tiene la capacidad única de separar la administración de la configuración por usuario de la configuración por máquina. Por lo general, este tipo de administración no es posible con otros formatos de empaquetado, especialmente los ejecutables de implementación que simplemente se ejecutan mediante una cuenta con más privilegios, como SYSTEM. Msdn Library contiene muchos artículos en Windows Installer; una sugerencia es la documentación de Hoja de ruta para Windows Installer.

El formato de Windows Installer incluye la capacidad de controlar por el usuario la instalación de estas aplicaciones a través de directiva de grupo (Microsoft IntelliMirror) y también a través de SMS. Para habilitar Install on Demand con extensiones de archivo o accesos directos, las tablas siguientes del paquete basado en Windows Installer deben rellenarse con datos publicitarios: acceso directo, extensión, icono y verbo. Se recomienda rellenar también la clase, MIME, ProgID y TypeLib. Lea Aplicación de revisiones Per-User Aplicaciones administradas para obtener más información sobre IntelliMirror e Instalar a petición.

Hay otras tecnologías de instalador que permiten a las aplicaciones instalar por usuario y admitir la actualización automática, como ClickOnce. Esto significa que el instalador no requerirá privilegios de administrador o superior para instalar y que el usuario siempre ejecutará la versión más reciente siempre que el equipo esté conectado a la red. También pone algunos límites en la capacidad de un profesional de TI para controlar la instalación de estas aplicaciones.

La implementación de ClickOnce es una tecnología de instalación de Microsoft .NET que instala y configura automáticamente una aplicación del lado cliente cuando un usuario hace clic en un vínculo de manifiesto, como un manifiesto en un sitio web, en un CD o en una ruta de acceso de convención de nomenclatura universal (UNC). De forma predeterminada, la aplicación se copiará en la carpeta Archivos temporales de Internet y se ejecutará dentro de un entorno restringido.

Nota Incluso si la aplicación se ha firmado con el nombre seguro de TI que le da plena confianza, todavía no puede hacer nada que requiera permisos de administrador, como el acceso a determinadas partes del sistema de archivos y el registro. Sin embargo, las aplicaciones ClickOnce se destinan a las aplicaciones por usuario, por lo que esto no debe ser un problema.

Importante ClickOnce no debe usarse para implementar aplicaciones que realicen operaciones administrativas.

Implementación en un único equipo

Para implementar una aplicación para un único equipo, el administrador debe "publicar" la aplicación en ese equipo.

Implementación en todos los usuarios de un dominio

Para anunciar a todos los usuarios de un dominio, el administrador debe "publicar" la aplicación a través de directiva de grupo implementación. Actualmente, solo el componente de implementación de software basado en directiva de grupo de los sistemas operativos Windows Server® 2003 y el sistema operativo Windows 2000 Server aprovecha esta funcionalidad.

Aplicación de revisiones como usuario estándar con Windows Installer 4.0

La aplicación de revisiones de cuentas de usuario estándar permite a los autores de paquetes de Windows Installer identificar las revisiones firmadas que un usuario estándar futuro puede aplicar. Se deben cumplir las siguientes condiciones para habilitar la aplicación de revisiones de usuarios estándar con Windows Installer 4.0:

• La aplicación se instaló en mediante Windows Installer 4.0.
• La aplicación se instaló originalmente máquina a máquina.
• La tabla MsiPatchCertificate está presente y rellenada en el paquete del instalador de ventana original (.msi archivo).
• Las revisiones las firma digitalmente un certificado que aparece en la tabla MsiPatchCertificate.
• Las revisiones se pueden validar con la firma digital.
• La aplicación de revisiones de cuentas de usuario estándar no se ha deshabilitado estableciendo la propiedad MSIDISABLELUAPATCHING o la directiva DisableLUAPatching.

Comportamiento de desinstalación de usuario estándar de Windows Installer 4.0

El comportamiento esperado para una revisión de Windows Installer 4.0 aplicada por un usuario estándar es que el usuario estándar también puede quitarlo.

Solucionar los problemas comunes

En las secciones siguientes se detallan los problemas comunes detectados con las aplicaciones en Windows Vista.

Algunos problemas comunes son:

• Problemas de instalación de ActiveX
• Los documentos ActiveX no se instalan
• Aplicación, marco o complemento necesarios
• Se requiere permiso administrativo para la instalación o aplicación de revisiones.
• Ubicaciones de configuración de aplicaciones por usuario
• El valor predeterminado de la aplicación es guardar en un directorio protegido

Problemas de instalación de ActiveX

Un administrador debe instalar los controles ActiveX. Normalmente, los controles ActiveX se usan en aplicaciones de línea de negocio para ampliar las funcionalidades del explorador web para crear interfaces de usuario más flexibles o para elevar el acceso a los recursos del equipo que normalmente se deniegan a las aplicaciones que se ejecutan en el explorador web. Normalmente, los controles ActiveX se instalan insertando una referencia al control ActiveX en una página web. Esto hará que Microsoft Internet Explorer descargue e instale el control si no existe en el equipo local. Normalmente, los controles ActiveX descargados de esta manera residen en el directorio %HOMEPATH%\Configuración local\Archivos temporales de Internet, que los usuarios estándar pueden escribir. Sin embargo, para funcionar en Internet Explorer, los controles deben tener varias entradas del Registro, que no son posibles para los no administradores.

Solución

La eliminación del control ActiveX de la aplicación casi siempre produce una pérdida de funcionalidad. Por lo tanto, esto no se recomienda para la corrección a menos que el control ActiveX proporcione alguna mejora visual o funcional que no forme parte de la funcionalidad principal del sitio. Por ejemplo, un ticker de existencias en un portal no relacionado con existencias.

En la mayoría de los casos, empaquetar el control ActiveX para la instalación por SMS o directiva de grupo es la solución correcta. Sin embargo, la mayoría de los controles no se incluirán en la imagen base, por lo que los sitios web deben modificar sus páginas para que no se produzcan errores correctamente. Esto debe incluir la detección del control ActiveX que falta y la redirección a la página de solicitud de software de Escritorio administrado.

Los documentos ActiveX no se instalan

Los documentos ActiveX son una tecnología en desuso de Microsoft Visual Basic 4 y Microsoft Visual Basic 5. Se pueden descargar de forma similar a los controles ActiveX.

Solución

Dado que Visual Basic 4 y Visual Basic 5 están en desuso, Microsoft recomienda reemplazar la aplicación. Debe ser posible instalar el documento ActiveX como parte de una instalación de cliente; sin embargo, las actualizaciones del documento se restringirán sin volver a implementarse a través de SMS o directiva de grupo.

Aplicación, marco o complemento requerido

Muchas aplicaciones tienen dependencias en otro software, que es posible que no se instalen de forma predeterminada, ya sea porque ya están disponibles en el equipo o porque la otra aplicación no proporciona archivos binarios distribuibles para su uso por parte de terceros. En circunstancias normales, el usuario se dirigiría a adquirir e instalar el software adicional. En un escritorio administrado, la instalación no es posible. Entre los ejemplos se incluyen Adobe Acrobat, Microsoft Office, componentes web de Office, WinZip y la directiva de seguridad de Microsoft .NET de TI.

Solución

Una vez identificadas las dependencias, se pueden empaquetar con la imagen base o estar disponibles a través de la instalación de SMS a petición. Es posible que la aplicación tenga que cambiar cómo notifica al usuario final del software que falta, dirigir al usuario al sitio de instalación de SMS en lugar del fabricante.

Se requiere permiso administrativo para la instalación o aplicación de revisiones

Puesto que la instalación de un programa requiere agregar archivos a archivos de programa, siempre requerirá permisos administrativos y, por lo tanto, se debe ejecutar como un usuario con permisos elevados.

Nota También puede "insertar" la revisión con SMS o directiva de grupo junto con el panel de control Agregar o quitar programas (ARP). el usuario selecciona software para instalar y el instalador del sistema hace el resto; el usuario no tiene que ser administrador. En el caso de las instalaciones iniciales, esto se puede tratar empaquetando el software para que un agente de instalación se inserte. Sin embargo, algunas aplicaciones dependen de actualizaciones automáticas frecuentes que pueden no alinearse bien con un modelo de aplicación administrado centralmente.

Las aplicaciones que detectan actualizaciones e intentan aplicar revisiones por sí mismas no podrán hacerlo, ya que no tendrán permiso para modificar archivos en los directorios del sistema.

Solución

• Empaquete la aplicación o revisión para la implementación por SMS. Las aplicaciones todavía pueden detectar que hay disponible una actualización (siempre que lo hagan sin necesidad de permisos administrativos) y pueden redirigir al sitio de aprovisionamiento.
• Pregunta si la aplicación necesita permisos elevados de equipo, como el sistema de archivos, el acceso al registro o la interoperabilidad COM. Si no es así, es posible volver a escribir la aplicación como un paquete de implementación ClickOnce, que se ejecutará en el espacio aislado de Microsoft .NET.
• Convierta en una aplicación web sin dependencias del lado cliente.

ubicaciones de configuración de la aplicación Per-User

Para Windows Vista, la configuración de la aplicación que debe cambiarse en tiempo de ejecución debe almacenarse en una de las siguientes ubicaciones:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Los documentos guardados por el usuario deben almacenarse en CSIDL_MYDOCUMENTS.

Nota La carpeta Documentos de un usuario ya no se almacena en Documentos y configuración. En Windows Vista, un nuevo directorio raíz en el sistema de archivos denominado Usuarios ahora contiene los perfiles de los usuarios del equipo.

Dado que estos directorios han cambiado, se recomienda a los desarrolladores que usen CSIDL para localizar la ruta de acceso a directorios conocidos específicos de forma independiente del sistema. Para obtener más información, consulte CSIDLs.

Una aplicación necesita acceso de escritura al sistema de archivos. Cuando se ejecuta en un escritorio administrado, una aplicación solo tiene permiso de escritura en las siguientes carpetas y sus elementos secundarios.

• CSIDL_PROFILE
• CSIDL_COMMON_APPDATA

Nota Los usuarios estándar no pueden escribir en Users\Common.

• C:\Users\Common>cd "Application Data"
  • C:\Users\Common\Application Data>echo File > File.txt
  • C:\Users\Common\Application Data>

Las aplicaciones no deben intentar escribir en otras ubicaciones, como las siguientes:

• C:\windows.
• C:\Windows\System32.
• Archivos de programa\{application}.
• C:\{application}.

Nota Esto funcionará si el usuario creó la carpeta , que los miembros del grupo Usuarios pueden hacer de forma predeterminada.

No se permite crear específicamente una aplicación C:\Users\Profiles\{user}, ya que el usuario solo puede crear carpetas en C:\Users\{user}. La ubicación elegida parece confundirse en función de dónde Microsoft ha almacenado la carpeta Documentos en versiones anteriores del sistema operativo.

La configuración de la aplicación que se debe cambiar en tiempo de ejecución debe almacenarse en una de las siguientes ubicaciones:

• CSIDL_APPDATA
• CSIDL_LOCAL_APPDATA
• CSIDL_COMMON_APPDATA

Los documentos guardados por el usuario deben almacenarse en la carpeta CSIDL_MYDOCUMENTS.

Todas las rutas de acceso no deben codificarse de forma rígida, pero deben usar la función Environment.GetFolderPath().

El valor predeterminado de la aplicación es guardar en un directorio protegido

Algunas aplicaciones permiten a los usuarios guardar o exportar datos a su equipo local. A menudo, el cuadro de diálogo tiene como valor predeterminado lugares como C:\, a los que los usuarios estándar no tienen permisos de escritura. Además, algunas aplicaciones no responden bien cuando se produce un error en el código para escribir el archivo porque como resultado de un acceso denegado desde el sistema operativo.

Solución

Supongamos que los usuarios solo pueden escribir en sus propios perfiles. Para los documentos guardados intencionadamente por los usuarios, inicialice los cuadros de diálogo para que se inicien en Documentos (Environment.GetFolderPath(Environment.SpecialFolder.Personal). Recuerde que el cuadro de diálogo Guardar permitirá que un usuario vaya a otras ubicaciones que no sean el perfil del usuario, por lo que la aplicación debe incluir lógica para asegurarse de que se produce un error correctamente si un usuario elige un directorio diferente al que se encuentra en su perfil.

Referencias

En esta sección se incluye una referencia de virtualización y una referencia de configuración de seguridad.

Referencia de virtualización

Virtualización de archivos

• Virtualizar (%SYSTEMROOT%, %PROGRAMDATA%, %PROGRAMFILES%\(Subdirectorios)
• Redireccionamiento a: %LOCALAPPDATA%\VirtualStore
• Ejecutables binarios excluidos: .exe, .dll, .sys

Virtualización del Registro:

• Virtualizar (HKLM\SOFTWARE)
• Redireccionamiento a: HKCU\Software\Classes\VirtualStore\MACHINE\SOFTWARE\<Application Registry Keys>
• Claves excluidas de la virtualización
• HKLM\Software\Classes
• Hklmsoftwaremicrosoftwindows
• HKLM\Software\Microsoft\Windows NT

Aplicabilidad

• Las tiendas virtuales no se mueven por itinerancia
• Los objetos globales correspondientes no se moverían
• Habilitado solo para usuarios estándar interactivos
• Deshabilitado para procesos no interactivos
• Deshabilitado para ejecutables de 64 bits
• Deshabilitado para los ejecutables que solicitan un nivel de ejecución (requestedExecutionLevel) en su manifiesto de aplicación, el modelo para la separación
• Deshabilitado para el modo kernel y llamadores suplantados
• Solo se virtualizan las claves y los archivos del Registro que se pueden escribir por el administrador.

Referencia de configuración de seguridad de UAC

Esta referencia detalla la configuración de seguridad disponible para administrar UAC con directiva de grupo o la directiva de seguridad local del equipo.

Nota Los procedimientos presentados en esta sección están destinados a administrar equipos no administrados. Para usar directiva de grupo para administrar la configuración de forma centralizada en un entorno administrado, use usuarios y equipos de Active Directory (dsa.msc) en lugar del complemento administrador de directivas de seguridad local (secpol.msc).

Configuración de opciones de seguridad de UAC

En el procedimiento siguiente se detalla cómo configurar las opciones de seguridad de UAC con el Administrador de directivas de seguridad. El procedimiento detalla la experiencia de usuario predeterminada para un administrador en Administración modo de aprobación.

Para ver o establecer la configuración de seguridad de UAC con el Administrador de directivas de seguridad

1. Haga clic en el botón Inicio , escriba secpol.msc en el cuadro de búsqueda y presione Entrar.
2. En la solicitud de consentimiento del Control de cuentas de usuario, haga clic en Continuar.
3. En Configuración de seguridad local, expanda Directivas localesy, a continuación, haga clic en Opciones de seguridad.
4. Haga clic con el botón derecho en la configuración de seguridad que desea cambiar y seleccione Propiedades.

En el procedimiento siguiente se detalla cómo configurar las opciones de seguridad de UAC con el directiva de grupo. El procedimiento detalla la experiencia de usuario predeterminada para un administrador en Administración modo de aprobación.

Para ver o establecer la configuración de seguridad de UAC con el Editor de objetos de directiva de grupo

1. Haga clic en el botón Inicio , escriba gpedit.msc en el cuadro de búsqueda y presione Entrar.
2. En la solicitud de consentimiento del Control de cuentas de usuario, haga clic en Continuar.
3. En directiva de grupo, expanda Configuración de usuarioy, a continuación, expanda Opciones de seguridad.
4. Haga clic con el botón derecho en la configuración de seguridad que desea cambiar y seleccione Propiedades.

Configuración de seguridad de UAC

En la tabla siguiente se enumeran las opciones de seguridad de UAC configurables. Estas opciones se pueden configurar con el Administrador de directivas de seguridad (secpol.msc) o administrarse de forma centralizada con directiva de grupo (gpedit.msc).

Configuración de seguridad de UAC

Configuración	Descripción	Valor predeterminado
Control de cuentas de usuario: Administración modo de aprobación para la cuenta de administrador integrada.	Hay dos opciones posibles: Habilitado: el administrador integrado se ejecutará como administrador en Administración modo de aprobación. Deshabilitado: el administrador se ejecuta con un token de acceso de administrador completo.	Deshabilitado para las nuevas instalaciones y para las actualizaciones en las que el administrador integrado no es el único administrador activo local en el equipo. La cuenta de administrador integrada está deshabilitada de forma predeterminada para instalaciones y actualizaciones en equipos unidos a un dominio. Se habilita para las actualizaciones cuando Windows Vista determina que la cuenta de administrador integrada es el único administrador local activo en el equipo. Si Windows Vista determina esto, la cuenta de administrador integrada también se mantiene habilitada después de la actualización. La cuenta de administrador integrada está deshabilitada de forma predeterminada para instalaciones y actualizaciones en equipos unidos a un dominio.
Control de cuentas de usuario: comportamiento de la petición de elevación para los administradores en Modo de aprobación de administrador	Hay tres valores posibles para esta configuración: Elevación sin preguntar: eleva en modo silencioso. Solicitar credenciales: pida a los usuarios que escriban su contraseña de inicio de sesión antes de continuar. Solicitar consentimiento: pida al usuario que apruebe antes de elevarlo. Esta es la configuración predeterminada.  Esta configuración determina cómo se solicita al usuario antes de ejecutar un programa con permisos más altos. Esta directiva solo está en vigor cuando UAC está habilitado.	Pedir consentimiento
Control de cuentas de usuario: comportamiento de la petición de elevación para los usuarios estándar	Determina cómo se solicita al usuario antes de ejecutar un programa con permisos superiores. Esta directiva solo está en vigor cuando UAC está habilitado. A continuación se muestran las opciones de configuración disponibles para esta configuración: Denegar automáticamente las solicitudes de elevación: no se pedirá a los usuarios cuando una aplicación quiera realizar una tarea administrativa. La aplicación no se iniciará y presentará un error de acceso denegado, o equivalente, al usuario. Solicitar credenciales: pida a los usuarios que escriban su contraseña de inicio de sesión antes de continuar.	Se piden credenciales
Control de cuentas de usuario: detectar instalaciones de aplicaciones y pedir confirmación de elevación	Hay dos valores posibles: Habilitado: se solicita al usuario el consentimiento o las credenciales cuando Windows Vista detecta un instalador. Deshabilitado: las instalaciones de la aplicación producirán errores o errores de forma no determinista.	habilitado
Control de cuentas de usuario: elevar sólo los archivos ejecutables firmados y validados	Hay dos valores posibles: Habilitado: solo se ejecutarán los archivos ejecutables firmados. Esta configuración impide que las aplicaciones sin firmar se ejecuten. Deshabilitado: se ejecutará el código firmado y sin firmar.	Disabled
Control de cuentas de usuario: elevar sólo aplicaciones UIAccess instaladas en ubicaciones seguras	Hay dos valores posibles: Habilitado: el sistema solo proporcionará privilegios de UIAccess y derechos de usuario a los ejecutables que se inician desde %ProgramFiles% o %windir%. Las ACL de estos directorios garantizan que el archivo ejecutable no sea modificable por el usuario (lo que, de lo contrario, permitiría la elevación de privilegios). Los ejecutables uiAccess iniciados desde otras ubicaciones se iniciarán sin privilegios adicionales (es decir, ejecutarán "asInvoker"). Deshabilitado: las comprobaciones de ubicación no se realizan, por lo que todas las aplicaciones UIAccess se iniciarán con el token de acceso completo del usuario tras la aprobación del usuario.	habilitado
Control de cuentas de usuario: ejecutar todos los administradores en Modo de aprobación de administrador	Hay dos valores posibles: Habilitado: se pedirá a los administradores y a los usuarios estándar que intenten realizar operaciones administrativas. El estilo de solicitud depende de la directiva. Deshabilitado: UAC es básicamente "desactivado" y el servicio AIS se deshabilita para iniciarse automáticamente.	habilitado
Control de cuentas de usuario: cambiar al escritorio seguro cuando se pida confirmación de elevación	Hay dos valores posibles: Habilitado: muestra el símbolo del sistema de elevación de UAC en el escritorio seguro. El escritorio seguro solo puede recibir mensajes de procesos de Windows, lo que elimina los mensajes del software malintencionado. Como resultado, las solicitudes de consentimiento y credenciales no se pueden suplantar en el escritorio seguro. Deshabilitado: el símbolo del sistema de elevación de UAC se muestra en el escritorio del usuario.	habilitado
Control de cuentas de usuario: virtualizar los errores de escritura de archivo y de Registro en diferentes ubicaciones por usuario	Hay dos valores posibles: Habilitado: las aplicaciones que carecen de una entrada de base de datos de compatibilidad de aplicaciones o un marcado de nivel de ejecución solicitado en el manifiesto de aplicación no son compatibles con UAC. Los entornos que usan software que no es compatible deben mantener esta configuración habilitada. Deshabilitado: las aplicaciones compatibles con UAC no deben escribir en áreas protegidas y provocar errores de escritura. Como resultado, los entornos que solo usan aplicaciones compatibles con UAC deben deshabilitar esta configuración. Las aplicaciones no compatibles que intentan escribir en archivos de programa y %systemroot% producirán un error silencioso si esta configuración está deshabilitada.	habilitado

Nota En la mayoría de las situaciones, no se recomienda la opción Elevar sin preguntar . La elevación sin preguntar permitiría a las aplicaciones que se ejecutan como un usuario estándar iniciar aplicaciones administrativas sin consentimiento del usuario y omitir eficazmente UAC.

Ejemplo de código del programador de tareas

En el ejemplo de código de C++ siguiente se muestra cómo usar el Programador de tareas para realizar la elevación del usuario. Como resultado, la aplicación puede elevarse automáticamente durante el inicio de sesión mediante las credenciales de un administrador y Windows Vista no bloqueará la aplicación. Debe crear un usuario administrador para la aplicación durante la instalación para que esta solución funcione correctamente.

//---------------------------------------------------------------------
//  This file is part of the Microsoft .NET Framework SDK Code Samples.
// 
//  Copyright (C) Microsoft Corporation.  All rights reserved.
// 
//This source code is intended only as a supplement to Microsoft
//Development Tools and/or on-line documentation.  See these other
//materials for detailed information regarding Microsoft code samples.
// 
//THIS CODE AND INFORMATION ARE PROVIDED AS IS WITHOUT WARRANTY OF ANY
//KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
//IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
//PARTICULAR PURPOSE.
//---------------------------------------------------------------------

/****************************************************************************
* Main.cpp - Sample application for Task Scheduler V2 COMAPI                * Component: Task Scheduler                          
* Copyright (c) 2002 - 2003, Microsoft Corporation 
* This sample creates a task to at the time registered to start the desired task.                                                             *
****************************************************************************/
#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
#include <comdef.h>
#include <comutil.h>
//Include Task header files - Included in Windows Vista Beta-2 SDK from MSDN
#include <taskschd.h>
#include <conio.h>
#include <iostream>
#include <time.h>

using namespace std;

#define CLEANUP \
pRootFolder->Release();\
        pTask->Release();\
        CoUninitialize();

HRESULT CreateMyTask(LPCWSTR, wstring);

void __cdecl wmain(int argc, wchar_t** argv)
{
wstring wstrExecutablePath;
WCHAR taskName[20];
HRESULT result;

if( argc < 2 )
{
printf("\nUsage: LaunchApp yourapp.exe" );
return;
}

// Pick random number for task name
srand((unsigned int) time(NULL));
wsprintf((LPWSTR)taskName, L"Launch %d", rand());

wstrExecutablePath = argv[1];

result = CreateMyTask(taskName, wstrExecutablePath);
printf("\nReturn status:%d\n", result);

}
HRESULT CreateMyTask(LPCWSTR wszTaskName, wstring wstrExecutablePath)
{
    //  ------------------------------------------------------
    //  Initialize COM.
TASK_STATE taskState;
int i;
    HRESULT hr = CoInitializeEx(NULL, COINIT_MULTITHREADED);
    if( FAILED(hr) )
    {
        printf("\nCoInitializeEx failed: %x", hr );
        return 1;
    }

    //  Set general COM security levels.
    hr = CoInitializeSecurity(
        NULL,
        -1,
        NULL,
        NULL,
        RPC_C_AUTHN_LEVEL_PKT_PRIVACY,
        RPC_C_IMP_LEVEL_IMPERSONATE,
        NULL,
        0,
        NULL);

    if( FAILED(hr) )
    {
        printf("\nCoInitializeSecurity failed: %x", hr );
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Create an instance of the Task Service. 
    ITaskService *pService = NULL;
    hr = CreateElevatedComObject( CLSID_TaskScheduler,
                           NULL,
                           CLSCTX_INPROC_SERVER,
                           IID_ITaskService,
                           (void**)&pService );  
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        CoUninitialize();
        return 1;
    }
        
    //  Connect to the task service.
    hr = pService->Connect(_variant_t(), _variant_t(), _variant_t(), _variant_t());
    if( FAILED(hr) )
    {
        printf("ITaskService::Connect failed: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }

    //  ------------------------------------------------------
    //  Get the pointer to the root task folder.  This folder will hold the
    //  new task that is registered.
    ITaskFolder *pRootFolder = NULL;
    hr = pService->GetFolder( _bstr_t( L"\\") , &pRootFolder );
    if( FAILED(hr) )
    {
        printf("Cannot get Root Folder pointer: %x", hr );
        pService->Release();
        CoUninitialize();
        return 1;
    }
    
    //  Check if the same task already exists. If the same task exists, remove it.
    hr = pRootFolder->DeleteTask( _bstr_t( wszTaskName), 0  );
    
    //  Create the task builder object to create the task.
    ITaskDefinition *pTask = NULL;
    hr = pService->NewTask( 0, &pTask );

    pService->Release();  // COM clean up.  Pointer is no longer used.
    if (FAILED(hr))
    {
        printf("Failed to CoCreate an instance of the TaskService class: %x", hr);
        pRootFolder->Release();
        CoUninitialize();
        return 1;
    }
        

    //  ------------------------------------------------------
    //  Get the trigger collection to insert the registration trigger.
    ITriggerCollection *pTriggerCollection = NULL;
    hr = pTask->get_Triggers( &pTriggerCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get trigger collection: %x", hr );
CLEANUP
        return 1;
    }
  
    //  Add the registration trigger to the task.
    ITrigger *pTrigger = NULL;
    
    hr = pTriggerCollection->Create( TASK_TRIGGER_REGISTRATION, &pTrigger );     
    pTriggerCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\nCannot add registration trigger to the Task %x", hr );
        CLEANUP
        return 1;
    }
    pTrigger->Release();

    //  ------------------------------------------------------
    //  Add an Action to the task.     
    IExecAction *pExecAction = NULL;
    IActionCollection *pActionCollection = NULL;

    //  Get the task action collection pointer.
    hr = pTask->get_Actions( &pActionCollection );
    if( FAILED(hr) )
    {
        printf("\nCannot get Task collection pointer: %x", hr );
        CLEANUP
        return 1;
    }
    
    //  Create the action, specifying that it is an executable action.
    IAction *pAction = NULL;
    hr = pActionCollection->Create( TASK_ACTION_EXEC, &pAction );
    pActionCollection->Release();  // COM clean up.  Pointer is no longer used.
    if( FAILED(hr) )
    {
        printf("\npActionCollection->Create failed: %x", hr );
        CLEANUP
        return 1;
    }

    hr = pAction->QueryInterface( IID_IExecAction, (void**) &pExecAction );
    pAction->Release();
    if( FAILED(hr) )
    {
        printf("\npAction->QueryInterface failed: %x", hr );
        CLEANUP
        return 1;
    }

    //  Set the path of the executable to the user supplied executable.
hr = pExecAction->put_Path( _bstr_t( wstrExecutablePath.c_str() ) );  

//hr = pExecAction->put_Path( (BSTR)wstrExecutablePath );  
    if( FAILED(hr) )
    {
        printf("\nCannot set path of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    hr = pExecAction->put_Arguments( _bstr_t( L"" ) );  
//    hr = pExecAction->put_Arguments( _bstr_t( L"ArgumentsToYourExecutable--HelpFileToOpen" ) );  
   if( FAILED(hr) )
    {
        printf("\nCannot set arguments of executable: %x", hr );
        pExecAction->Release();
        CLEANUP
        return 1;
    }
    
    //  ------------------------------------------------------
    //  Save the task in the root folder.
    IRegisteredTask *pRegisteredTask = NULL;
    hr = pRootFolder->RegisterTaskDefinition(
            _bstr_t( wszTaskName ),
            pTask,
        TASK_CREATE, 
_variant_t(_bstr_t( L"S-1-5-32-545")),//Well Known SID for \\Builtin\Users group
_variant_t(), 
TASK_LOGON_GROUP,
            _variant_t(L""),
            &pRegisteredTask);
    if( FAILED(hr) )
    {
        printf("\nError saving the Task : %x", hr );
        CLEANUP
        return 1;
    }
    printf("\n Success! Task successfully registered. " );
for (i=0; i<100; i++)//give 10 seconds for the task to start
{
pRegisteredTask->get_State(&taskState);
if (taskState == TASK_STATE_RUNNING)
{
printf("\nTask is running\n");
break;
}
Sleep(100);
}
if (i>= 100) printf("Task didn't start\n");

//Delete the task when done
    hr = pRootFolder->DeleteTask(
            _bstr_t( wszTaskName ),
            NULL);
    if( FAILED(hr) )
    {
        printf("\nError deleting the Task : %x", hr );
        CLEANUP
        return 1;
    }

    printf("\n Success! Task successfully deleted. " );

//  Clean up.
    CLEANUP
    CoUninitialize();
    return 0;
}