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

12

Tenemos muchos clientes ligeros que ejecutan Windows Embedded Standard 7 y un servidor SCCM 2012 R2 para administrarlos. Los thin clients tienen sus filtros de escritura habilitados (FBWF) para que los cambios de la máquina no sean persistentes. En la rara ocasión en que tenemos que actualizar algo en ellos, simplemente lo implementamos a través de SCCM y automáticamente se encarga de apagar y volver a encender los filtros de escritura para confirmar los cambios.

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

El problema que tengo es que usamos 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 que sucede en realidad : el
cliente SCCM avisa normalmente con 15 minutos de anticipación antes de reiniciar con el filtro de escritura desactivado. Cuando se reinicia, se muestra la pantalla de inicio de sesión normal . Los usuarios pueden iniciar sesión en el sistema y usarlo mientras SCCM está instalando 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.

En este escenario, no solo agrega 30 minutos adicionales al tiempo de implementación, sino que también brinda a los usuarios comunes un tiempo sólido de 30-60 minutos sin protección en los clientes livianos, con los cambios que realicen que se convierten permanentemente en la imagen cuando el filtro de escritura se vuelve a encender.

El problema surge del hecho de que Windows Embedded 7 utiliza un proveedor de credenciales diferente (también conocido como GINA) que Windows 7 normal, pero el producto SSO debe reemplazar al proveedor de credenciales de Windows para funcionar. Me he puesto en contacto con el proveedor al respecto, pero solo dicen que es un problema conocido y que no hay una solución o solución para ello.

Así que aquí está mi pregunta:
¿cómo puedo simular el comportamiento deseado de otra manera? Sé que hay una configuración de directiva de grupo donde puede negar 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. Domino los scripts, PowerShell, VBScript, etc. Me pregunto si alguien tiene alguna idea brillante sobre cómo resolver esto.


Actualización:
no mencioné que estos dispositivos se están utilizando en un entorno hospitalario para que el personal pueda registrar a 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 notificando por adelantado a los supervisores de turno, pero cualquier cosa que tarde más de una hora se convierte en un problema de cumplimiento legal y requiere que se apliquen los procedimientos oficiales de tiempo de inactividad.

Wes Sayeed
fuente
Gran pregunta Desearía tener una mejor respuesta.
buena pregunta, espero que su historia de infortunio desaliente a otros a comprar clientes delgados. Odio todo el equipaje que traen estos dispositivos de "bajo mantenimiento"
Jim B

Respuestas:

4

Antes de comenzar, quiero hacer un comentario pedante, más para beneficio de los lectores en general que para ti.

simplemente lo empujamos a través de SCCM

SCCM es una tecnología basada en extracción. Sé lo que querías decir, pero creo que con mis muchachos de nivel 1, cada oportunidad que tengo para enfatizar que SCCM no es una tecnología basada en el empuje les ayuda a entenderlo más rápido.


Me he puesto en contacto con el proveedor al respecto, pero solo dicen que es un problema conocido y que no hay solución o solución para ello.

Eso es una lástima, ya que parece que la causa de este problema es el programa de autenticación de tarjeta integrada. Siga con el vendedor, tal vez realmente arreglarán su software.



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 elimine a los clientes de su filtro de escritura, su carga útil real y el reinicio resultante, todo fuera de horario cuando los empleados no están presentes en las terminales. Esta parece ser la opción menos dolorosa. No es necesario hacer SCCM más complicado de lo que ya es.
  • Cree una plantilla de directiva de grupo local que agregue un grupo de seguridad al derecho de usuario de denegación de inicio de sesión y luego asígnelo / desasigne como parte de la implementación de su aplicación.
  • Use PowerShell para establecer el derecho de usuario de Denegar inicio de sesión. Creo que PowerShell Community Extensions (PSCX) tiene los Set/Get-Privilegescmdlets que le permitirán manipular las Asignaciones de derechos de usuario
  • Puede usar la API si lo desea. Aquí hay un ejemplo .

fuente
Gracias por la respuesta. Actualicé mi pregunta para reflejar el medio ambiente. Es una operación 24x7, por lo que la opción 1 no es viable. La opción 2 era lo que estaba pensando, pero no sé cómo asignar / desasignar un GPO a pedido. Eso deja las opciones 3 y 4 que analizaré. Pensé que probablemente tendría que salir de esta secuencia de comandos. Ah, y corregí la terminología :-)
Wes Sayeed
@WesSayeed En teoría, debería poder crear plantillas de directivas de grupo local con SecPol.msc, guardarlas como plantillas y aplicar / no aplicar secedit.exemediante un script. No estoy hablando de usar la directiva de grupo de Active Directory, ya que el tiempo de sondeo aleatorio no funcionará para su ventana de mantenimiento apretada.
+1, me gusta esta respuesta y no estaba al tanto de PSCX.
MDMoore313
4

Parece que nadie tocó la posibilidad de usar una secuencia de tareas para manejar esto, así que permítame enumerar los beneficios (suponiendo que no esté realmente familiarizado con ellos en general, pero lea incluso si lo está):

Si todo lo que instala y configura se maneja con SCCM, debería poder usar una secuencia de tareas para lograr esto. Principalmente para OSD, el uso de un TS no es solo para 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 inadvertidamente, 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 inicio que indique que se está realizando el mantenimiento, o lo que sea que quiera que realmente diga.

Un TS es realmente solo un script glorificado, pero tiene mucha funcionalidad y se combina de una manera que disminuye 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 hacer, por lo que debería poder ponerlo en un TS con una depuración mínima y comenzar.

MDMoore313
fuente
1
+1 Siempre me pregunté si había usos del mundo real para las secuencias de tareas que no son OSD.
alx9r
@BigHomie; Intenté hacer una implementación utilizando una secuencia de tareas en lugar de una aplicación normal y no impidió el inicio de sesión del usuario. El primer paso en la secuencia de tareas es reiniciar la computadora. Una vez que la computadora vuelve a funcionar, presenta una pantalla de inicio de sesión normal. La secuencia de tareas no se reanuda hasta aproximadamente un minuto después (porque el servicio está configurado para inicio retrasado). Puedo configurar el servicio para que comience de inmediato con la Política de grupo para que el usuario vea una barra de progreso, pero eso solo desalentaría los inicios de sesión, no los impedirá. ¿Me estoy perdiendo de algo?
Wes Sayeed
@WesSayeed !! ¿Se anuncia ese TS al usuario o la computadora?
MDMoore313
@BigHomie; AFAIK, las secuencias de tareas solo pueden anunciarse en colecciones de computadoras.
Wes Sayeed
Así es, me olvidé de eso. Desafortunadamente, tomé un nuevo trabajo el año pasado y he estado fuera del juego sccm por bastante tiempo. Sin embargo, continuaré buscando la respuesta, pero pensé que el mismo mecanismo que permitía la instalación del software durante un OSD antes de que apareciera la pantalla de inicio de sesión también se puede usar fuera del OSD. Supongo que su implementación no se puede hacer si la máquina arranca en WinPE, ¿correcto?
MDMoore313
2

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á en un nivel por usuario, pero se puede programar fácilmente en Powershell ( esto es 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 lo suyo. Deberá tener ese primer reinicio forzado que los cerrará sesión (la función de horas de inicio de sesión no funciona en los usuarios conectados), pero de lo contrario sería sencillo implementarla.

Nathan C
fuente
El software SSO usa AD. Todo lo que hace es hacer coincidir una etiqueta RFID con una cuenta AD y pasar las credenciales a Windows para realizar el inicio de sesión. Actualicé mi respuesta para explicar por qué no puedo usar las horas de inicio de sesión (no mencioné el entorno), pero echaré un vistazo al script al que hizo referencia. Podría hacer algo así localmente.
Wes Sayeed
-1

Es posible que desee probar esto y ver si funciona:

Un script al comienzo de la actividad SCCM para hacer lo siguiente:

  • Eliminar la identidad de NT AUTHORITY \ Authenticated Users 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 los principios de seguridad que eliminó nuevamente al grupo de usuarios local

Los grupos reales que agregue / elimine pueden depender de la configuración actual de sus computadoras.

Algo un poco más trailer-parky, el comienzo de la actividad de SCCM podría copiar un acceso directo a logoff.exe a la carpeta Menú de inicio \ Inicio de todos los usuarios (generalmente C: \ ProgramData \ Microsoft \ Windows \ Menú de inicio \ Programas \ 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 accesos directos de inicio pueden pasarse por alto manteniendo presionada la tecla Mayús durante el inicio de sesión).

Greg Askew
fuente
Tengo que -1 esto, funcionaría, pero si el script se elimina en el medio, por algún error aleatorio o la Ley de Murphy, el usuario no puede iniciar sesión y está muerto en el agua hasta que TI pueda responder.
MDMoore313