Control de acceso de seguridad de Windows

Se aplica a: Microsoft Windows Vista

Resumen: este artículo ofrece directrices para los departamentos de TI sobre la creación e implementación de correcciones de compatibilidad de aplicaciones para sus aplicaciones existentes con errores provocados por la función de protección de cuentas de usuario (UAP) en Microsoft Windows Vista.

En esta página

Introducción e información general
Marcado de nivel de ejecución
Directiva de consentimiento para elevación
Preparación para crear correcciones de base de datos de compatibilidad de aplicaciones
Ejecución de CompatAdmin.exe
Eliminación de una corrección de la base de datos AppCompat
Implementación mediante la directiva de grupo en la empresa
VBScript de instalador personalizado de muestra
Creación del paquete .msi.
Firma de MSI con Authenticode
Comprobación del paquete
Implementación del MSI mediante la directiva de grupo
Adición de la directiva de grupo a Microsoft Active Directory
Comprobación de la implementación

Introducción e información general

La protección de cuentas de usuario (UAP) aprovecha la arquitectura de seguridad de Windows tal y como se diseñó originalmente en Microsoft Windows NT 3.1. Cuando UAP se habilita en Windows Vista, todos los usuarios (administradores incluidos) se ejecutan en una cuenta de usuario limitada. Los administradores tienen permiso para ejecutar de forma selectiva aplicaciones administrativas que pueden utilizar los privilegios completos de la cuenta sólo cuando sea necesario. Este es el principio que hay tras el concepto de una cuenta de administrador protegido (PA). Cuando los usuarios con privilegios inician sesión en sus cuentas, en realidad lo hacen en el entorno de una cuenta de usuario limitada, pero tienen la capacidad de ejecutar aplicaciones con privilegios completos si ofrecen aprobación. Sólo tras la aprobación podrá ejecutarse una aplicación con los privilegios de usuario completos.

En cuanto a nuevas aplicaciones compatibles con Windows Vista, la aplicación necesita ejecutarse en una cuenta de usuario limitada o, en el caso de una aplicación administrativa, debe marcarse con una entrada de manifiesto. En tal caso, Windows podrá informar a los usuarios de que están intentando iniciar una aplicación administrativa y necesitan ofrecer aprobación. Para obtener más información sobre el programa Logo de Microsoft, visite la página de inicio de Microsoft Windows Logo (en inglés).

Los departamentos de TI pueden descubrir que durante la instalación de Windows Vista, sus aplicaciones existentes de línea de negocio ya no funcionan correctamente. Esto suele deberse a una incompatibilidad de las aplicaciones con las mejoras que Windows Vista incorpora. Microsoft ofrece el conjunto de herramientas Application Compatibility Toolkit, que ayudará al departamento de TI a identificar los problemas de compatibilidad y crear correcciones al respecto. Es posible que el departamento de TI descubra que, para que un programa funcione correctamente en Windows Vista, necesita poder realizar operaciones administrativas. Para ello, el programa necesita etiquetarse para que, antes de ejecutar privilegios administrativos completos, se solicite la aprobación del usuario. El conjunto de herramientas ofrece los medios para crear e instalar las entradas de la base de datos AppCompat, que hace que este mecanismo de etiquetado esté disponible.

Encontrará información sobre la aplicación aquí (en inglés).

Encontrará Application Compatibility Toolkit aquí (en inglés).

Marcado de nivel de ejecución

El nivel de ejecución seleccionado para la aplicación depende del tipo de operaciones de nivel de sistema que esté realizando la aplicación.

• RunAsLUA: la aplicación debe ejecutarse con los mismos privilegios que el proceso primario, lo que equivale a no tener ninguna base de datos AppCompat para la aplicación. La aplicación se inicia con los mismos privilegios que los del proceso que la inicia.

• RunAsHighest: la aplicación debería ejecutarse con los mayores privilegios que pueda obtener el usuario actual, pero no es necesario que el usuario sea un administrador. Este marcado se utiliza para dos tipos de aplicaciones.

  1. Tanto los usuarios con privilegios como los usuarios limitados pueden ejecutar la aplicación, que adapta su comportamiento según los privilegios del usuario.

  2. La aplicación necesita privilegios superiores a los de un usuario limitado, si bien no es preciso que el usuario sea miembro del grupo de administradores, por ejemplo, un usuario miembro del grupo de operadores de copia de seguridad. Este tipo de usuario no puede ejecutar aplicaciones que necesiten privilegios completos de administrador, pero puede ejecutar aplicaciones de copia de seguridad. En este caso, la aplicación de copia de seguridad heredada debería marcarse como RunAsHighest.

• RunAsAdmin: la aplicación sólo debería ejecutarse para administradores y requiere que se inicie con privilegios de administrador. Este marcado es para aquellas aplicaciones heredadas que necesiten que el usuario sea miembro del grupo de administradores.

Directiva de consentimiento para elevación

La directiva de consentimiento determina el tipo de aprobación que debe ofrecer un usuario para iniciar una aplicación que necesita privilegios. Se controla mediante una configuración en la directiva de seguridad local.

Para ver/configurar la directiva para el sistema

1. Haga clic en Inicio, Ejecutar y, a continuación, escriba secpol.msc.

2. Desplácese a Configuración de seguridad local, haga clic en Directivas locales y, a continuación, en Opciones de seguridad.

3. Seleccione LUA: Behavior of the elevation prompt.

   LUA: Behavior of the elevation prompt

   Determina cómo se notifica a un usuario antes de ejecutar un programa con permisos superiores. No Prompt: eleva los privilegios en modo silencioso Prompt for Consent: pregunta al usuario si desea continuar o no Prompt for Credentials: exige la contraseña de inicio de sesión del usuario antes de continuar (configuración predeterminada) Esta directiva sólo tiene efecto cuando LUA está habilitada. Nota En la mayoría de las situaciones, la selección de No PromptNO es recomendable, ya que permitiría a las aplicaciones de LUA iniciar aplicaciones de administrador sin su conocimiento ni consentimiento.

Tenga en cuenta que la configuración anterior se puede controlar mediante directivas de grupo y se puede administrar de forma central.

Comportamiento operativo basado en el indicador de proceso primario

Los privilegios que puede obtener una aplicación, incluso si la aplicación se puede ejecutar, dependen de la combinación del nivel de ejecución de la aplicación en la base de datos AppCompat y los privilegios de cuenta bajo los que se está ejecutando la aplicación. Las siguientes tablas reflejan el comportamiento basado en las distintas combinaciones.

La cuenta de administrador local integrada

La cuenta de administrador local integrada no está protegida por UAP, de modo que todas las aplicaciones se inician con los privilegios completos de la cuenta sin solicitar aprobación del usuario.

• Símbolo (token) de proceso primario: privilegios completos de administrador

• Directiva de consentimiento: (no importa)

Una cuenta de usuario que es miembro del grupo de administradores

• Símbolo (token) de proceso primario: usuario estándar

• Directiva de consentimiento: silencio

• Símbolo (token) de proceso primario: usuario estándar

• Directiva de consentimiento: consentimiento

• Símbolo (token) de proceso primario: usuario estándar

• Directiva de consentimiento: credencial

• Símbolo (token) de proceso primario: privilegios completos de administrador

• Directiva de consentimiento: (no importa)

Una cuenta de usuario limitada

• Símbolo (token) de proceso primario: usuario limitado

• Directiva de consentimiento: silencio

• Símbolo (token) de proceso primario: usuario limitado

• Directiva de consentimiento: consentimiento

• Símbolo (token) de proceso primario: usuario limitado

• Directiva de consentimiento: credencial

Un usuario con privilegios adicionales que no es administrador (operador de copias de seguridad)

• Símbolo (token) de proceso primario: usuario limitado

• Directiva de consentimiento: silencio

• Símbolo (token) de proceso primario: usuario limitado

• Directiva de consentimiento: consentimiento

• Símbolo (token) de proceso primario: usuario limitado

• Directiva de consentimiento: credencial

• Símbolo (token) de proceso primario: privilegios completos

• Directiva de consentimiento: silencio

• Símbolo (token) de proceso primario: privilegios completos

• Directiva de consentimiento: consentimiento

• Símbolo (token) de proceso primario: privilegios completos

• Directiva de consentimiento: credencial

Preparación para crear correcciones de base de datos de compatibilidad de aplicaciones

Una vez que el departamento de TI ha identificado las aplicaciones de administrador empresariales, el resto de secciones de este documento pueden servir como guía para crear e implementar las correcciones de compatibilidad de aplicaciones adecuadas para esas aplicaciones.

Ejecución de CompatAdmin.exe

CompatAdmin.exe es una herramienta de interfaz gráfica de usuario (GUI) que ayuda a los administradores empresariales a crear correcciones de compatibilidad de programas para aplicaciones heredadas que se ejecutan en nuevas versiones de Windows. En lo que respecta a Windows Vista, este conjunto de herramientas se ha mejorado con la capacidad para crear las entradas de la base de datos de correcciones, que se utilizan para marcar aplicaciones con un nivel de ejecución. Una vez que el departamento de TI crea una base de datos, podrá instalarla en el sistema mediante una herramienta denominada sdbinst.exe, que también se incluye en el Application Toolkit.

Cada base de datos creada puede contener una o varias correcciones de nivel de ejecución para aplicaciones de destino. El departamento de TI utiliza los siguientes pasos para determinar el marcado de aplicaciones administrativas.

1. Instalar Application Compatibility Toolkit en un equipo adecuado que ejecute Windows Vista.

2. Identificar cualquier aplicación administrativa heredada que no se ejecute correctamente en Windows Vista. El departamento de TI puede utilizar otras funciones de Application Compatibility Toolkit para facilitar el proceso de identificación.

3. Determinar el nivel de ejecución para cada aplicación.
   Para obtener información sobre el marcado adecuado para las aplicaciones, consulte la sección Marcado de nivel de ejecución.

4. Ejecutar CompatAdmin.exe para crear las bases de datos de correcciones AppCompat.

5. Probar la corrección instalándola en un equipo de prueba mediante sdbinst.exe.

Ejemplo:

1. Inicie compatadmin.exe (figura 1).

   

   Figura 1 |
   
   

2. Haga clic en el icono de reparación.

3. Escriba el nombre del programa y el del proveedor, así como la ubicación del programa (figura 2). Haga clic en Next.

   

   Figura 2 |
   
   

   La primera pantalla del asistente sirve para aplicar revisiones de compatibilidad general para versiones anteriores de Windows. Más avanzado el asistente podrá seleccionar una corrección de compatibilidad de aplicaciones de nivel de ejecución.

4. Para modos de sistema operativo, seleccione None y, a continuación, haga clic en Next (figura 3).

   

   Figura 3 |
   
   

5. Desplácese a las revisiones de compatibilidad y seleccione el nivel de ejecución que desee. Para determinar el nivel de ejecución adecuado para la aplicación, consulte la sección Marcado de nivel de ejecución. Haga clic en Next (figura 4).

   

   Figura 4 |
   
   

6. Seleccione la información de coincidencia. Esa información se utiliza para identificar el archivo al que pertenece la corrección. En el ejemplo siguiente, el tamaño y la suma de comprobación PE se utilizan además del nombre del programa para determinar si la corrección debería aplicarse a este programa. Si bien se puede seleccionar más información de coincidencia, seleccionar el tamaño y la suma de comprobación suele ser suficiente para asegurar que la corrección no se aplica de forma inadvertida a otras aplicaciones que puedan tener el mismo nombre. Haga clic en Finish (figura 5).

   

   Figura 5 |
   
   

7. Haga clic en File y, a continuación, en Save (figura 6).

   

   Figura 6 |
   
   

8. Escriba un nombre para la base de datos. Cuando haya instalado la corrección con sdbinst.exe, este será el nombre que aparecerá en Agregar o quitar programas del Panel de control. Seleccione un nombre descriptivo para facilitar la identificación de la corrección en Agregar o quitar programas. Haga clic en OK (figura 7).

   

   Figura 7 |
   
   

9. Seleccione un nombre para el archivo de la base de datos y haga clic en Save (figura 8).

   

   Figura 8 |
   
   

10. Ejecute sdbinst.exe pasando el nombre del archivo de la base de datos que acaba de crear como parámetro (figura 9). El calificador -q ejecuta sdbinst.exe sin mostrar un cuadro de diálogo de salida lo que permite usarlo para realizar la implementación en modo desatendido.

    

    Figura 9 |
    
    

Eliminación de una corrección de la base de datos AppCompat

Un administrador puede eliminar entradas de la base de datos AppCompat previamente instaladas a través del subprograma Programas instalados del Panel de control (figura 10). Esto es de utilidad si la aplicación para la que se ha creado una corrección de compatibilidad de aplicaciones ya no sirve en el entorno o si la corrección en sí debe modificarse. Para eliminar la corrección de compatibilidad de aplicaciones, haga clic con el botón secundario en la lista y seleccione Cambiar o quitar. El administrador podrá eliminar otras entradas de la base de datos AppCompat repitiendo este mismo proceso.

Implementación mediante la directiva de grupo en la empresa

Esta sección describe cómo implementar las correcciones de la base de datos de compatibilidad de aplicaciones creadas en la sección Ejecución de compatAdmin.exe mediante la directiva de grupo. Estos son los principales pasos.

• El departamento de TI crea una secuencia de comandos de Microsoft Visual Basic (VBScript) de instalador personalizado. Aquí podrá ver una secuencia de comandos de ejemplo.

• El departamento de TI crea un paquete .msi para cada base de datos .sdb creada.

• El paquete .msi se firma con el Authenticode del departamento de TI.

• Tras ello, el departamento de TI lo implementará a través de la directiva de grupo.

VBScript de instalador personalizado de muestra

Antes de crear el .msi, el departamento de TI necesita crear un VBScript que realice la instalación personalizada. Esto sólo hace falta hacerlo una vez, ya que pueden utilizar el mismo archivo de secuencia de comandos para todos los paquetes .msi. A continuación se incluye una secuencia de comandos de ejemplo.

'--------------------------------------------------------------------------------------
'  Filename         : setsdb.vbs
'  Description      : Installs SDB entry in appcompat database
'  Version          : 1.0
'--------------------------------------------------------------------------------------
' History:
'   07-19-2005:  Created version 1.0

	dim Ws
	myCmdArgs = Session.Property("CustomActionData")
	setDir = "%ComSpec% /C sdbinst.exe -q " & chr(34) & myCmdArgs & chr(34)
	set Ws = CreateObject("WScript.Shell")
	retval = Ws.Run( setDir, 2, true )

Creación del paquete .msi.

El siguiente ejemplo muestra cómo crear un paquete instalador de .msi para implementar la corrección de la base de datos AppCompat mediante Microsoft Visual Studio 7.

1. Inicie Visual Studio.

2. En la barra de menús, haga clic en Archivo y, a continuación, en Nuevo proyecto.

3. Para Tipos de proyecto, seleccione Proyecto de instalación e implementación en el panel de la izquierda. Seleccione Proyecto de instalación en el panel de la derecha, escriba un nombre para la corrección de la implementación y, a continuación, haga clic en Aceptar (figura 11).

   

   Figura 11 |
   
   

4. En el Explorador de soluciones del panel de la derecha, haga clic con el botón secundario en el nombre del proyecto de implementación (en este ejemplo: DeployIsUserAdminShim), haga clic en Agregar y, a continuación, en Archivo.

5. Ubique el archivo de base de datos .sdb creado y, a continuación, haga clic en Abrir (figura 12).

   

   Figura 12 |
   
   

6. Repita los pasos 4 y 5 y agregue el nombre del VBScript de acción personalizada que creó anteriormente, en este ejemplo: setsdb.vbs.

7. En el Explorador de soluciones del panel de la derecha, haga clic con el botón secundario en el nombre del proyecto de implementación, haga clic en Ver y, a continuación, en Acciones personalizadas. Aparecerá la ficha Acciones personalizadas en el panel de la izquierda (figura 13).

   

   Figura 13 |
   
   

8. En la ficha Acciones personalizadas, haga clic con el botón secundario en la carpeta Confirmar y, a continuación, haga clic en Agregar acción personalizada.

9. Haga doble clic en la carpeta Aplicación, seleccione el archivo vbscript y, a continuación, haga clic en Aceptar (figura 14).

   

   Figura 14 |
   
   

10. Haga clic con el botón secundario en la acción Confirmar denominada setsdb.vbs en el panel de la izquierda y, a continuación, haga clic en Ventana Propiedades.

    Agregue la siguiente línea a la propiedad CustomActionData.
    [ProgramFilesFolder][Manufacturer]\[ProductName]\IsUserAdmin.sdb.

    Nota

    • No hay barra diagonal inversa (\) entre [ProgramFilesFolder] y [Manufacturer].

    • Utilice el nombre de archivo .sdb que seleccionó al crear el archivo (figura 15).

    
    

    

    Figura 15 |
    
    

11. En el menú Archivo, haga clic en Generar y, a continuación, haga clic en Generar solución. Cuando se haya generado, el paquete .msi se almacenará en la carpeta de depuración.

12. Salga de Visual Studio.

Firma de MSI con Authenticode

Cuando el departamento de TI crea el paquete .msi, Microsoft recomienda firmarlo con Authenticode antes de implementarlo mediante la directiva de grupo. Microsoft da por hecho que el departamento de TI ya ha creado una clave de firma para su empresa con la que firmar los paquetes .msi de implementación. Las herramientas de firma y comprobación utilizadas en los siguientes ejemplos se incluyen en el SDK de Microsoft Visual Studio.

signcode -v <path>yourkey.pvk -spc <path>yourkey.spc (deployment package).msi

Para incluir una marca de hora en la firma, incluya el siguiente parámetro en la línea de comandos.

-t http://timestamp.verisign.com/scripts/timstamp.dll

El departamento de TI puede comprobar la firma con el siguiente comando.

ckhtrust (deployment package).msi

Si el archivo se valida y el certificado de firma se encadena a un certificado de compañía de software de confianza, chktrust.exe volverá simplemente con un código de retorno correcto.

Podrá encontrar información adicional sobre la tecnología Authenticode de Microsoft aquí.

Comprobación del paquete

Cuando el departamento de TI haya creado el paquete, podrán comprobarlo copiando el archivo .msi a un equipo de destino y haciendo doble clic en él para abrir el Asistente para la instalación de Microsoft Windows (figura 16).

1. Haga clic en Siguiente.
   Aparecerá la ventana Seleccionar carpeta de instalación (figura 17).

   

   Figura 17 |
   
   

2. Haga clic en Siguiente.
   Aparecerá la ventana Confirmar instalación (figura 18).

   

   Figura 18 |
   
   

3. Haga clic en Siguiente.
   Cuando la instalación haya finalizado, aparecerá un mensaje confirmando que la instalación es correcta (figura 19).

   

   Figura 19 |
   
   

4. Haga clic en Cerrar.
   El departamento de TI puede comprobar la instalación del archivo .sdb mediante el icono Programas instalados del Panel de control. El instalador de la corrección y la entrada de la corrección deberían ser visibles (figura 20).

   

   Figura 20 |
   
   

Implementación del MSI mediante la directiva de grupo

Mediante la directiva de grupo, el departamento de TI puede asegurar la implementación de cualquier corrección de la base de datos AppCompat en todos los equipos cliente de forma automática. Esta sección contiene los pasos básicos que el departamento de TI podría utilizar para configurar esta implementación. Podrá encontrar información adicional sobre el almacenamiento provisional de directiva de grupo aquí (en inglés).

El primer paso es colocar el paquete de implementación .msi en un recurso compartido de archivos que esté disponible para todos los equipos que deberían recibir la corrección. Puede tratarse de todo el dominio o restringirse a unidades organizativas (OU). Microsoft recomienda que el departamento de TI se asegure de que el paquete .msi tenga la entrada de lista de control de acceso (ACL) adecuada en el recurso compartido de archivos para permitir el acceso sólo a los equipos adecuados.

En el ejemplo, el archivo DeployIsUserAdmin.msi se almacenará en un recurso compartido de archivos en el dominio denominado \\jettdualproc\Applications. La ACL del archivo tendrá un aspecto parecido al de la figura 21.

Adición de la directiva de grupo a Microsoft Active Directory

1. Una vez tenemos el archivo .msi, inicie sesión en el controlador de dominio como administrador de dominio, haga clic en Inicio, señale Programas, Herramientas administrativas y, a continuación, haga clic en Usuarios y equipos de Active Directory.

2. Haga clic con el botón secundario en el nombre del dominio en el panel de la izquierda y, a continuación, haga clic en Propiedades. Cuando aparezca la ventana Propiedades, haga clic en la ficha Directiva de grupo (figura 22).

   

   Figura 22 |
   
   

3. Haga clic en Nuevo y escriba un nombre para el nuevo objeto de directiva de grupo (GPO). En este ejemplo, el GPO se denomina Deploy IsUserAdmin Shim (figura 23).

   

   Figura 23 |
   
   

4. Resalte el GPO recién creado y haga clic en Propiedades.

5. Ya que las correcciones se han aplicado a los equipos del dominio y no a los usuarios, seleccione la casilla de verificación Deshabilitar los parámetros de configuración de usuario (figura 24). Si aparece un cuadro de diálogo de confirmación, haga clic en Sí.

   

   Figura 24 |
   
   

6. Haga clic en la ficha Seguridad y agregue cualquier ACL necesaria para permitir el acceso de sus equipos de dominio. Asegúrese de que Read and Apply Group Policy está seleccionado. Haga clic en Aceptar cuando haya terminado.

7. En la ventana Propiedades (que aún debería estar abierta), haga clic en Editar.
   Aparecerá el Editor de objetos de directiva de grupo.

8. En Configuración del equipo en el panel de la izquierda, expanda Configuración de software.

9. Haga clic con el botón secundario en Instalación de software, haga clic en Nuevo y, a continuación, en Paquete.

10. Seleccione el paquete que va a implementar en el cuadro de diálogo Abrir y, a continuación, haga clic en Abrir (figura 25).

    

    Figura 25 |
    
    

11. Aparecerá el cuadro de diálogo Implementar software. Seleccione Asignada y, a continuación, haga clic en Aceptar.
    Esto hará que el paquete se instale en los equipos de destino sin intervención alguna por parte del usuario (figura 26).

    

    Figura 26 |
    
    

    El paquete .msi seleccionado aparecerá en el Editor de objetos de directiva de grupo (figura 27).

    

    Figura 27 |
    
    

12. Cierre el Editor de objetos de directiva de grupo.

13. Cierre la ventana Propiedades.

14. Salga de la aplicación Usuarios y grupos de Active Directory.

Comprobación de la implementación

Para comprobar la implementación, el departamento de TI deberá reiniciar uno de los equipos miembros del dominio. Tras ello, y antes de que aparezca la pantalla de inicio de sesión, la directiva de grupo debería instalar automáticamente el paquete en el equipo.

Para confirmarlo, inicie sesión en el equipo y abra Programas instalados en el Panel de control. Si la instalación se ha realizado correctamente, el usuario debería ver el .msi instalado, así como la entrada de base de datos de compatibilidad de aplicaciones (figura 28).