¿Cómo bloquear a los usuarios normales (no administradores) durante las instalaciones de software?

Question

Tenemos muchos clientes ligeros que ejecutan Windows Embedded Standard 7 y un servidor SCCM 2012 R2 para administrarlos. Los clientes ligeros tienen habilitados sus filtros de escritura (FBWF), por lo que los cambios de la máquina no son persistentes. En las raras ocasiones en que tenemos que actualizar algo, simplemente lo implementamos a través de SCCM y automáticamente se encarga de desactivar y volver a activar los filtros de escritura para confirmar los cambios.

Esto es lo quedeberíasuceder:
El cliente SCCM avisa al usuario y le muestra una cuenta regresiva de 30 minutos para guardar su trabajo y salir del sistema. Luego, el cliente ligero se reinicia y desactiva el filtro de escritura. La pantalla de inicio de sesión muestra un candado y advierte que la unidad está siendo reparada y no permitirá que los usuarios normales (no administradores) inicien sesión mientras SCCM está haciendo su trabajo. Cuando SCCM finaliza, vuelve a habilitar el filtro de escritura, se reinicia y luego los usuarios pueden iniciar sesión nuevamente.

El problema que tengo es que utilizamos lectores de tarjetas de proximidad para iniciar sesión en el sistema. Los empleados no escriben contraseñas. Simplemente tocan su placa. Este sistema es bueno, pero el software que lo ejecuta rompe la automatización del filtro de escritura con Windows Embedded.

Esto es lo quede hechosucede:
El cliente SCCM avisa con 15 minutos de antelación antes de reiniciar con el filtro de escritura desactivado. Cuando se reinicia, elnormalSe muestra la pantalla de inicio de sesión. Los usuarios pueden iniciar sesión en el sistema y usarlo mientras SCCM instala el software. Y debido a que una sesión de usuario está activa, nuevamente da otro aviso de 30 minutos antes de reiniciar con el filtro de escritura nuevamente activado.

En este escenario, no solo agrega 30 minutos adicionales al tiempo de implementación, sino que también brinda a los usuarios comunes entre 30 y 60 minutos de tiempo desprotegido en los clientes ligeros y cualquier cambio que realicen quedará permanentemente integrado en la imagen cuando se complete el proceso. El filtro de escritura se vuelve a activar.

El problema surge del hecho de que Windows Embedded 7 utiliza un proveedor de credenciales diferente (también conocido como GINA) que el Windows 7 normal, pero el producto SSO debe reemplazar al proveedor de credenciales de Windows para poder funcionar. Me comuniqué con el proveedor al respecto, pero simplemente me dijeron que es un problema conocido y que no existe ninguna solución alternativa para ello.

Así que aquí está mi pregunta:
¿Cómo puedo simular el comportamiento deseado de otra manera? Sé que existe una configuración de política de grupo en la que se puede denegar el inicio de sesión local a grupos de usuarios específicos. Estaba pensando que podría cambiar la configuración de registro correspondiente antes y después de la instalación, pero estoy abierto a otras ideas.

No estoy por encima de las instalaciones de secuencias de comandos si es necesario. Hablo con fluidez secuencias de comandos, PowerShell, VBScript, etc. Me pregunto si alguien tiene alguna idea brillante sobre cómo resolver esto.

---

Actualizar:
Olvidé mencionar que estos dispositivos se utilizan en un entorno hospitalario para que el personal realice registros de sus pacientes. Deben estar disponibles las 24 horas del día, por lo que no podemos restringir las horas de inicio de sesión ni configurar ventanas de mantenimiento. Gestionamos el tiempo de inactividad avisando con antelación a los supervisores de turno, pero cualquier cosa que demore más de una hora se convierte en un problema de cumplimiento legal y requiere que se pongan en práctica procedimientos oficiales de tiempo de inactividad.

Answer 1

Antes de continuar, quiero hacer una observación pedante, más para beneficio de los lectores en general que para usted.

simplemente lo enviamos a través de SCCM

SCCM es una tecnología basada en pull. Sé lo que quisiste decir, pero encuentro que con mis muchachos de nivel 1, cada oportunidad que tengo para enfatizar que SCCM no es una tecnología basada en push les ayuda a entenderlo más rápido.

Me comuniqué con el proveedor al respecto, pero solo dicen que es un problema conocido y que no hay solución ni solución alternativa para ello.

Es una lástima, ya que parece que la causa de este problema es el programa de autenticación de tarjeta integrado. Continúe con el proveedor, tal vez realmente arreglen su software.

Pasemos a una respuesta real: veo algunas soluciones posibles para usted, ninguna de ellas particularmente buena.

• Configure una ventana de mantenimiento para estos clientes de modo que su reinicio inicial para eliminar a los clientes de su filtro de escritura, su carga útil real y el reinicio resultante se realicen fuera del horario laboral cuando los empleados no están presentes en las terminales. Ésta parece la opción menos dolorosa. No es necesario hacer que SCCM sea más complicado de lo que ya es.
• Crear unPolítica de grupo localplantilla que agrega un grupo de seguridad al derecho de usuario Denegar inicio de sesión y luego asignarlo o cancelar su asignación como parte de la implementación de su aplicación.
• Utilice PowerShell para configurar el derecho de usuario Denegar inicio de sesión. Yo creo queExtensiones de la comunidad de PowerShell (PSCX)tiene los Set/Get-Privilegescmdlets que le permitirán manipular las asignaciones de derechos de usuario
• Puede utilizar la API si lo desea. Aquí hay unejemplo.

Answer 2

Parece que nadie mencionó la posibilidad de usar una secuencia de tareas para manejar esto, así que permítanme enumerar los beneficios (asumiendo que no están muy familiarizados con ellos en general, pero léanlos incluso si lo están):

Si todo lo que instala y configura se maneja con SCCM, debería poder usar una secuencia de tareas para lograrlo. Principalmente para OSD, usar un TS no essolopara OSD y puede proporcionar los siguientes beneficios:

No iniciar sesión en la estación de trabajo

Un TS se ejecuta antes de que se ejecute winlogon.exe, por lo que no hay posibilidad de que un usuario inicie sesión sin darse cuenta, ya que no hay una ventana de inicio de sesión. Lo que me lleva a mi segundo punto:

Pantalla de fondo personalizada

Puede proporcionar una pantalla de presentación que diga que se está realizando el mantenimiento, o lo que realmente quiera que diga.

Un TS es en realidad solo un script glorificado, pero tiene mucha funcionalidad y está diseñado de manera que reduce el tiempo de desarrollo, y he encontrado casos de uso más allá de OSD.

Parece que ya tiene un script para hacer lo que necesita, por lo que debería poder ponerlo en un TS con una depuración mínima y comenzar.

Answer 3

No ha especificado si el software SSO utiliza credenciales de Active Directory, por lo que una solución sería utilizar la función "Horas de inicio de sesión" de Active Directory. Está a nivel de usuario, pero se puede programar fácilmente en Powershell (estesiendo un ejemplo). Básicamente, configure las horas de inicio de sesión para "denegar" el inicio de sesión en la ventana de actualización de SCCM y los usuarios no podrán iniciar sesión en los clientes mientras SCCM hace su trabajo. Necesitará realizar ese primer reinicio forzado que los cerrará (la función de horas de inicio de sesión no funciona en usuarios que han iniciado sesión), pero de lo contrario sería sencillo de implementar.

Answer 4

Es posible que desee probar esto y ver si funciona:

Un guión al comienzo de la actividad SCCM para hacer lo siguiente:

• Eliminar la identidad de NT AUTHORITY\Usuarios autenticados del grupo de usuarios local
• Eliminar NT AUTHORITY\Identidad interactiva del grupo de usuarios local
• Eliminar el grupo de usuarios de dominio del grupo de usuarios local

Al final:

Agregue las entidades principales de seguridad que eliminó nuevamente al grupo de Usuarios local

Los grupos reales que agregue o elimine pueden depender de cómo estén configuradas actualmente sus computadoras.

Algo un poco más complicado, el comienzo de la actividad SCCM podría copiar un acceso directo a logoff.exe a la carpeta Menú Inicio Todos los usuarios\Inicio (normalmente C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp). Esto tendría el efecto de cerrar una sesión tan pronto como inicien sesión. Para estar seguro, es posible que desee tener un script de inicio/apagado para eliminar ese acceso directo. (Creo que los atajos de inicio se pueden omitir manteniendo presionada la tecla Mayús durante el inicio de sesión).