Come bloccare gli utenti normali (non amministratori) durante le installazioni di software?

Abbiamo molti thin client che eseguono Windows Embedded Standard 7 e un server SCCM 2012 R2 per gestirli. I thin client hanno i loro filtri di scrittura abilitati (FBWF) in modo che le modifiche alla macchina non siano persistenti. In rare occasioni dobbiamo aggiornare qualcosa su di loro, lo implementiamo semplicemente tramite SCCM e si occupa automaticamente di disattivare e riaccendere i filtri di scrittura per eseguire il commit delle modifiche.

Ecco cosa dovrebbe accadere: il
client SCCM avvisa l'utente e un conto alla rovescia di 30 minuti per salvare il lavoro e scendere dal sistema. Il thin client si riavvia quindi e disabilita il filtro di scrittura. La schermata di accesso mostra un lucchetto e nota che l'unità è sottoposta a manutenzione e non consentirà agli utenti normali (non amministratori) di accedere mentre SCCM sta facendo la sua cosa. Al termine, SCCM riattiva il filtro di scrittura, si riavvia e quindi gli utenti possono accedere nuovamente.

Il problema che sto riscontrando è che usiamo i lettori di carte di prossimità per accedere al sistema. I dipendenti non digitano le password. Toccano semplicemente il loro badge. Questo sistema è carino, ma il software che lo esegue interrompe l'automazione del filtro di scrittura con Windows Embedded.

Ecco cosa succede effettivamente : il
client SCCM dà il solito preavviso di 15 minuti prima di riavviare con il filtro di scrittura disattivato. Al riavvio, viene visualizzata la normale schermata di accesso. Gli utenti possono accedere al sistema e utilizzarlo mentre SCCM sta installando il software. E poiché una sessione utente è attiva, dà nuovamente un altro preavviso di 30 minuti prima di riavviare con il filtro di scrittura attivo.

In questo scenario, non solo aggiunge altri 30 minuti al tempo di distribuzione, ma fornisce anche agli utenti ordinari 30-60 minuti solidi di tempo non protetto sui thin client con qualsiasi modifica essi apportino diventando permanentemente inseriti nell'immagine quando il il filtro di scrittura viene riattivato.

Il problema deriva dal fatto che Windows Embedded 7 utilizza un provider di credenziali diverso (noto anche come GINA) rispetto al normale Windows 7, ma il prodotto SSO deve sostituire il provider di credenziali di Windows per funzionare. Ho contattato il fornitore a riguardo, ma dicono solo che è un problema noto e non c'è soluzione o soluzione alternativa per questo.

Quindi, ecco la mia domanda:
come posso simulare il comportamento desiderato in un altro modo? So che esiste un'impostazione dei criteri di gruppo in cui è possibile negare l'accesso locale a gruppi di utenti specifici. Stavo pensando di poter girare le impostazioni del registro corrispondenti prima e dopo l'installazione, ma sono aperto ad altre idee.

Non sono al di sopra delle installazioni di script, se devo. Sono fluente con gli script, PowerShell, VBScript, ecc. Mi chiedo solo se qualcuno ha qualche idea brillante su come risolverlo.

Aggiornamento:
ho trascurato di menzionare che questi dispositivi vengono utilizzati in un ambiente ospedaliero affinché il personale possa tracciare grafici sui propri pazienti. Devono essere disponibili 24 ore al giorno, quindi non possiamo limitare le ore di accesso o configurare le finestre di manutenzione. Gestiamo i tempi di fermo dando preavviso ai turni di supervisione, ma tutto ciò che richiede più di un'ora diventa un problema di conformità legale e richiede l'entrata in vigore delle procedure ufficiali di fermo.

Prima di andare avanti voglio fare un punto pedante, più a beneficio dei lettori in generale che a te stesso.

lo spingiamo semplicemente via SCCM

SCCM è una tecnologia basata su pull. So cosa intendevi, ma trovo che con i miei ragazzi di livello 1, ogni occasione che ho per sottolineare che SCCM non è una tecnologia basata su push li aiuta a capirlo più rapidamente.

Ho contattato il fornitore a riguardo, ma dicono solo che è un problema noto e non c'è soluzione o soluzione alternativa per questo

È un peccato che sembri che la causa di questo problema sia il programma di autenticazione della scheda incorporato. Mantieni il venditore, forse risolveranno il loro software.

Su una vera risposta: vedo alcune possibili soluzioni per te, nessuna delle quali particolarmente buona.

• Configurare una finestra di manutenzione per questi client in modo che il riavvio iniziale per rimuovere i client dal loro filtro di scrittura, il carico utile effettivo e il riavvio risultante avvengano tutti fuori orario quando i dipendenti non sono presenti ai terminali. Questa sembra l'opzione meno dolorosa. Non è necessario rendere SCCM più complicato di quanto non lo sia già.
• Creare un modello di criteri di gruppo locale che aggiunge un gruppo di sicurezza al diritto utente nega accesso e quindi assegnarlo / annullarlo come parte della distribuzione dell'applicazione.
• Utilizzare PowerShell per impostare il diritto utente Nega accesso. Credo che PowerShell Community Extensions (PSCX) abbia i Set/Get-Privilegescmdlet che ti permetteranno di manipolare le assegnazioni dei diritti utente
• Puoi usare l'API se vuoi. Ecco un esempio .

Sembra che nessuno abbia toccato la possibilità di utilizzare una sequenza di attività per gestirla, quindi permettimi di elencare i vantaggi (supponendo che tu non li abbia davvero familiari in generale, ma per favore leggi anche se lo sei):

Se tutto ciò che installi e configuri viene gestito con SCCM, dovresti essere in grado di utilizzare una sequenza di attività per raggiungere questo obiettivo. Principalmente per OSD, l'uso di un TS non è solo per OSD e può offrire i seguenti vantaggi:

Nessun accesso alla workstation

Un TS viene eseguito prima dell'esecuzione di winlogon.exe, quindi non è possibile che un utente acceda inavvertitamente, poiché non esiste una finestra di accesso. Il che mi porta al mio secondo punto:

Schermata di sfondo personalizzata

Puoi fornire una schermata iniziale che indichi che è in corso la manutenzione o qualsiasi cosa tu voglia dire davvero.

Un TS è davvero solo uno script glorificato, ma ha molte funzionalità ed è messo insieme in modo da ridurre i tempi di sviluppo, e ho trovato casi d'uso oltre l'OSD.

Sembra che tu abbia già uno script per fare ciò che devi fare, quindi dovresti essere in grado di inserirlo in un TS con un debug minimo e iniziare.

Non è stato specificato se il software SSO utilizza le credenziali di Active Directory, quindi una soluzione sarebbe quella di utilizzare la funzione "Orario di accesso" di Active Directory. È a livello di utente, ma può essere facilmente copiato in Powershell ( questo è un esempio). Fondamentalmente, impostare le ore di accesso per "negare" l'accesso nella finestra di aggiornamento di SCCM e gli utenti non saranno in grado di accedere ai client mentre SCCM fa le sue cose. Avrai bisogno di quel primo riavvio forzato che li disconnetterà (la funzione delle ore di accesso non funziona sugli utenti che hanno effettuato l'accesso), ma sarebbe altrimenti indolore da implementare.

Potrebbe voler provare questo e vedere se funziona:

Uno script all'inizio dell'attività SCCM per eseguire le seguenti operazioni:

• Rimuovere l'identità NT AUTHORITY \ Authenticated Users dal gruppo Users locale
• Rimuovere NT AUTHORITY \ Interactive identity dal gruppo Users locale
• Rimuovere il gruppo Domain Users dal gruppo Users locale

Alla fine:

Aggiungi le entità di sicurezza rimosse nel gruppo Utenti locale

I gruppi effettivi che aggiungi / rimuovi potrebbero dipendere dalla configurazione dei tuoi computer.

Qualcosa di più un po 'più park-parky, l'inizio dell'attività SCCM potrebbe copiare un collegamento a logoff.exe nella cartella All Start Menu \ Startup (in genere C: \ ProgramData \ Microsoft \ Windows \ Start Menu \ Programmi \ StartUp). Ciò avrebbe l'effetto di disconnettersi da una sessione non appena accedono. Per sicurezza, potresti voler avere uno script di avvio / arresto per eliminare quel collegamento. (Credo che le scorciatoie all'avvio possano essere escluse tenendo premuto il tasto Maiusc durante l'accesso).