Como bloquear usuários normais (não administradores) durante instalações de software?

Question

Temos muitos thin clients executando o Windows Embedded Standard 7 e um servidor SCCM 2012 R2 para gerenciá-los. Os thin clients têm seus filtros de gravação habilitados (FBWF) para que as alterações da máquina não sejam persistentes. Nas raras ocasiões em que precisamos atualizar algo neles, apenas implantamos via SCCM e ele automaticamente se encarrega de desligar e ligar novamente os filtros de gravação para confirmar as alterações.

Aqui está o quedeveacontecer:
O cliente SCCM avisa o usuário e faz uma contagem regressiva de 30 minutos para salvar seu trabalho e sair do sistema. O thin client então reinicia e desativa o filtro de gravação. A tela de login exibe um cadeado e avisa que a unidade está sendo reparada e não permitirá que usuários normais (não administradores) façam login enquanto o SCCM estiver fazendo isso. Quando o SCCM é concluído, ele reativa o filtro de gravação, reinicia e os usuários podem fazer login novamente.

O problema que estou tendo é que usamos leitores de cartão de proximidade para fazer login no sistema. Os funcionários não digitam senhas. Eles apenas tocam em seu crachá. Este sistema é bom, mas o software que o executa quebra a automação do filtro de gravação com o Windows Embedded.

Aqui está o quena verdadeacontece:
O cliente SCCM avisa normalmente com 15 minutos de antecedência antes de reiniciar com o filtro de gravação desativado. Quando ele reinicia, onormala tela de login é exibida. Os usuários podem fazer login no sistema e usá-lo enquanto o SCCM instala o software. E como uma sessão de usuário está ativa, ela emite outro aviso de 30 minutos antes de reiniciar com o filtro de gravação ativado novamente.

Nesse cenário, isso não apenas adiciona 30 minutos extras ao tempo de implantação, mas também oferece aos usuários comuns 30 a 60 minutos de tempo desprotegido nos thin clients, com quaisquer alterações que eles façam, tornando-se permanentemente incorporadas à imagem quando o o filtro de gravação é ativado novamente.

O problema decorre do fato de que o Windows Embedded 7 usa um provedor de credenciais diferente (também conhecido como GINA) do Windows 7 normal, mas o produto SSO deve substituir o provedor de credenciais do Windows para funcionar. Entrei em contato com o fornecedor sobre isso, mas eles apenas disseram que é um problema conhecido e que não há solução ou solução alternativa para ele.

Então aqui está minha pergunta:
Como posso simular o comportamento desejado de outra maneira? Eu sei que existe uma configuração de política de grupo onde você pode negar o logon local a grupos de usuários específicos. Eu estava pensando em alterar a configuração de registro correspondente antes e depois da instalação, mas estou aberto a outras ideias.

Não estou acima de instalações de scripts, se for necessário. Sou fluente em scripts, PowerShell, VBScript, etc. Só me pergunto se alguém tem alguma ideia brilhante sobre como resolver isso.

---

Atualizar:
Esqueci de mencionar que esses dispositivos estão sendo usados ​​em ambiente hospitalar para que a equipe faça registros de seus pacientes. Eles devem estar disponíveis 24 horas por dia, portanto não podemos restringir horários de logon ou configurar janelas de manutenção. Gerenciamos o tempo de inatividade avisando com antecedência os supervisores de turno, mas qualquer coisa que leve mais de uma hora se torna uma questão de conformidade legal e exige a implementação de procedimentos oficiais de tempo de inatividade.

Answer 1

Antes de prosseguirmos, quero fazer uma observação pedante, mais para o benefício do leitor em geral do que para você mesmo.

nós apenas enviamos via SCCM

SCCM é uma tecnologia baseada em pull. Eu sei o que você quis dizer, mas acho que com meu pessoal de nível 1, cada oportunidade que tenho de enfatizar que o SCCM não é uma tecnologia baseada em push os ajuda a entendê-la mais rapidamente.

Entrei em contato com o fornecedor sobre isso, mas eles apenas disseram que é um problema conhecido e que não há solução ou solução alternativa para isso

Isso é uma pena, pois parece que a causa desse problema é o programa de autenticação de cartão incorporado. Continue com o fornecedor, talvez eles realmente consertem o software.

Vamos a uma resposta real: vejo algumas soluções possíveis para você, nenhuma delas particularmente boa.

• Configure uma janela de manutenção para esses clientes para que sua reinicialização inicial remova os clientes de seu filtro de gravação, sua carga útil real e a reinicialização resultante ocorram fora do horário comercial, quando os funcionários não estão presentes nos terminais. Esta parece ser a opção menos dolorosa. Não há necessidade de tornar o SCCM mais complicado do que já é.
• Criar umaPolítica de grupo localmodelo que adiciona um grupo de segurança ao direito de usuário Negar logon e, em seguida, atribua/desatribua-o como parte da implantação do seu aplicativo.
• Use o PowerShell para definir o direito Negar logon do usuário. Eu acredito queExtensões da comunidade PowerShell (PSCX)tem os Set/Get-Privilegescmdlets que permitirão manipular as atribuições de direitos do usuário
• Você pode usar a API se quiser. Aqui está umexemplo.

Answer 2

Parece que ninguém tocou na possibilidade de usar uma sequência de tarefas para lidar com isso, então permita-me listar os benefícios (supondo que você não esteja realmente familiarizado com eles em geral, mas leia mesmo se estiver):

Se tudo o que você instala e configura for tratado com SCCM, você poderá usar uma sequência de tarefas para fazer isso. Principalmente para OSD, usar um TS não éapenaspara OSD e pode fornecer os seguintes benefícios:

Sem login na estação de trabalho

Um TS é executado antes da execução do winlogon.exe, portanto, não há possibilidade de um usuário fazer logon inadvertidamente, pois não há janela de logon. O que me leva ao meu segundo ponto:

Tela de fundo personalizada

Você pode fornecer uma tela inicial informando que a manutenção está sendo realizada ou o que você realmente quiser.

Um TS é realmente apenas um script glorificado, mas tem muitas funcionalidades e é montado de forma a diminuir o tempo de desenvolvimento, e encontrei casos de uso além do OSD.

Parece que você já tem um script para fazer o que precisa, então você deve ser capaz de colocá-lo em um TS com o mínimo de depuração e seguir em frente.

Answer 3

Você não especificou se o software SSO usa credenciais do Active Directory, portanto, uma solução seria usar a função "Horas de logon" do Active Directory. Está no nível por usuário, mas pode ser facilmente programado no Powershell (essesendo um exemplo). Basicamente, defina o horário de logon para "negar" o logon na janela de atualização do SCCM e os usuários não conseguirão fazer login nos clientes enquanto o SCCM faz seu trabalho. Você precisará fazer a primeira reinicialização forçada, que os desconectará (a função de horas de logon não funciona em usuários logados), mas, caso contrário, seria fácil de implementar.

Answer 4

Pode querer testar isso e ver se funciona:

Um script no início da atividade do SCCM para fazer o seguinte:

• Remover a identidade NT AUTHORITY\Authenticated Users do grupo de usuários locais
• Remover a identidade NT AUTHORITY\Interactive do grupo de usuários locais
• Remover grupo de usuários de domínio do grupo de usuários locais

No final:

Adicione as entidades de segurança que você removeu de volta ao grupo de usuários locais

Os grupos reais que você adiciona/remove podem depender de como seus computadores estão configurados atualmente.

Algo um pouco mais trailer-parky, o início da atividade do SCCM poderia copiar um atalho para logoff.exe para a pasta All Users Start Menu\Startup (normalmente C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp). Isso teria o efeito de fazer logoff de uma sessão assim que eles fizessem logon. Por segurança, você pode querer ter um script de inicialização/desligamento para excluir esse atalho. (Acredito que os atalhos de inicialização podem ser ignorados mantendo pressionada a tecla Shift durante o logon).