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 de máquina não sejam persistentes. Nas raras ocasiões em que temos que atualizar algo sobre eles, nós apenas o implementamos via SCCM e ele automaticamente se encarrega de desligar e voltar os filtros de gravação para confirmar as alterações.

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

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

Veja o que realmente acontece:
O cliente SCCM dá o aviso usual de 15 minutos antes de reiniciar com o filtro de gravação desativado. Quando é reinicializado, a tela de login normal é exibida. Os usuários podem efetuar login no sistema e usá-lo enquanto o SCCM está instalando o software. E como uma sessão de usuário está ativa, ela novamente fornece outro aviso de 30 minutos antes de reinicializar com o filtro de gravação novamente.

Nesse cenário, ele não só adiciona 30 minutos extras ao tempo de implantação, mas também proporciona aos usuários comuns 30 a 60 minutos de tempo desprotegido nos thin clients, com as alterações que fizerem, tornando-se permanentemente integrados no imagem quando o filtro de gravação é ativado novamente.

O problema decorre do fato de que o Windows Embedded 7 usa um provedor de credenciais diferente (a.k.a GINA) do que o Windows 7 comum, mas o produto SSO deve substituir o provedor de credenciais do Windows para funcionar. Eu entrei em contato com o fornecedor sobre isso, mas eles dizem que é um problema conhecido e não há solução ou solução alternativa para isso.

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

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

Atualização:
Eu deixei de mencionar que esses dispositivos estão sendo usados em um ambiente hospitalar para que os funcionários façam um gráfico de seus pacientes. Eles devem estar disponíveis 24 horas por dia, por isso não podemos restringir as horas de logon nem configurar as janelas de manutenção. Nós gerenciamos o tempo de inatividade informando com antecedência os supervisores, mas qualquer coisa que leve mais de uma hora se torna um problema de conformidade legal e exige que os procedimentos oficiais de inatividade sejam efetivados.

    

Answer 1

Antes de continuarmos, quero fazer um ponto pedante, mais para o benefício dos leitores em geral do que você mesmo.

we just push it via SCCM

O SCCM é uma tecnologia baseada em pull. Eu sei o que você quis dizer, mas acho que com meus colegas de nível 1, todas as oportunidades que tenho de enfatizar que o SCCM não é uma tecnologia baseada em push ajuda-os a entender isso mais rapidamente.

I've contacted the vendor about it, but they just say it's a known issue and there is no fix or workaround for it

Isso é muito ruim, já que a causa desse problema é o programa de autenticação de cartão embutido. Continue com o fornecedor, talvez eles realmente consertem o software deles.

Para 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 a reinicialização inicial remova os clientes do filtro de gravação, a carga real e a reinicialização resultante ocorram fora do expediente quando os funcionários não estiverem presentes nos terminais. Esta parece ser a opção menos dolorosa. Não há necessidade de tornar o SCCM mais complicado do que já é.
• Crie um modelo Política de grupo local que adicione um grupo de segurança ao direito de usuário Negar logon e, em seguida, atribuir / desatribuí-lo como parte da implantação do seu aplicativo.
• Use o PowerShell para definir o direito de usuário Negar logon. Acredito que as extensões da comunidade do PowerShell (PSCX) têm os cmdlets Set/Get-Privileges , que permitem manipular atribuições de direitos de usuário
• Você pode usar a API, se quiser. Aqui está um exemplo .

Answer 2

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

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

No logging onto the workstation

Um TS é executado antes de o winlogon.exe ser executado, portanto, não há possibilidade de um usuário inadvertidamente efetuar logon, pois não há uma janela de logon. O que me leva ao segundo ponto:

Custom background screen

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

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

Parece que você já tem um script para fazer o que precisa ser feito, então você deve ser capaz de colocar isso em um TS com depuração mínima e seguir em frente.

    

Answer 3

Você não especificou se o software SSO usa as credenciais do Active Directory, portanto, uma solução seria usar a função "Horário de logon" do Active Directory. É em nível por usuário, mas pode ser facilmente roteirizado no Powershell ( this sendo um exemplo). Basicamente, defina as horas de logon para "negar" o logon em sua janela de atualização do SCCM e os usuários não poderão efetuar login nos clientes enquanto o SCCM faz a sua coisa. Você precisará ter a primeira reinicialização forçada que será efetuada (a função de horário de logon não funciona em usuários logados), mas de outra forma seria indolor implementar.

    

Answer 4

Pode querer testar isto e ver se funciona:

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

• Remova a identidade NT AUTHORITY \ Authenticated Users do grupo de usuários local
• Remover NT AUTHORITY \ Identidade interativa do grupo de usuários local
• Remover o grupo Usuários do domínio do grupo Usuários locais

No final:

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

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

Algo um pouco mais estacionado em trailers, 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 \ Menu Iniciar \ Programas \ Comece). Isso teria o efeito de efetuar logoff de uma sessão assim que eles fizerem logon. Por segurança, talvez você queira ter um script de inicialização / desligamento para excluir esse atalho. (Acredito que os atalhos do Startup podem ser contornados mantendo a tecla Shift pressionada durante o logon).