Local de Execução de Script de Logon do Windows 10

0

Estou procurando informações sobre quaisquer alterações que possam ter sido feitas na forma como os scripts de logon do GPO são executados no Windows 10 versus Windows 7.

Eu tenho uma configuração de script de logon (powershell) via GPO para o Windows 7. Ao testar uma imagem do Windows 10, esse script parece primeiro ser copiado para minha pasta temp de perfil local (c: \ users \ myaccount \ appdata \ local \ temp) com uma string aleatória para um nome (dyyxi3ra.i2u.ps1) antes de ser executado. Isso é um problema porque o software de gerenciamento que usamos está bloqueando-o por meio da regra configurada. A regra está em vigor e só descobri isso na minha imagem de teste do Windows 10 (7 ainda está zumbindo).

Alguém sabe, esse comportamento é esperado e é uma mudança do Windows 7? O Google não ajudou, e o TechNet estava procurando por uma agulha num palheiro que eu não tenho certeza se o palheiro ainda existe.

Obrigado antecipadamente.

ETA: Isso parece ser um comportamento normal. No logon uma segunda vez, recebi uma mensagem semelhante que um script foi bloqueado e uma cadeia aleatória diferente .ps1. Ele estava novamente tentando executar a partir da pasta temp do perfil local.

Vou testar assinando meu script, mas preciso atualizar primeiro o certificado de assinatura de código. Espero que o problema esteja na política de execução e que isso resolva o problema.

ETA2: Nos meus testes, parece que toda vez que um script armazenado remotamente é executado, ele copia algo (o script em si?) para um arquivo temporário na pasta temp do perfil local. Scripts de logon incluídos. Se alguém pudesse me apontar alguma documentação sobre isso, eu agradeceria.

ETA3: atualize as descobertas até o momento ...

Parece haver alguma mudança entre o PowerShell V4 e o anterior e o V5. Eu instalei o WMF5 no meu dispositivo Windows 7 e depois de fazer isso, posso duplicar o mesmo comportamento que estou vendo no dispositivo Windows 10.

Eu encontrei um artigo que explica algo parecido com o que estou vendo, mas eles estão usando o AppLocker.

link

Eu pensei que talvez o Bit9 estivesse detectando o Language Mode do powershell e ativando isso, mas mudar o modo de FullLanguage para ConstrainedLanguage não parece fazer nenhuma diferença no meu ambiente.

link

Não sei se isso aciona algo na mente de qualquer pessoa, mas o prompt de comando do Powershell aciona uma notificação do Bit9, enquanto o Powershell ISE não o faz. Eu corri o módulo get em ambos para ver quais módulos estão sendo carregados e comparados entre os dispositivos. Pelo menos um dos dispositivos não está carregando nenhum módulo na inicialização, então estou decidindo que um módulo é o culpado. O que é diferente entre o powershell.exe e o ISE que podem fazer com que um aplicativo whitelisting de aplicativo seja acionado?

    
por lightwing 06.10.2016 / 20:59

1 resposta

0

O mais importante é que, para compatibilidade com o AppLocker, a Microsoft incorporou no powershell v5 uma gravação de um arquivo .ps1 (e potencialmente um .psm1) em% temp% ao iniciar para determinar o modo Language a ser iniciado.

É uma boa prática de segurança monitorar os scripts que são iniciados a partir de% temp%. Infelizmente, se você usar um aplicativo whitelisting de aplicativo para fazer isso (como Bit9 ou AppLocker) e criar uma regra para monitorar scripts do powershell usando esse diretório com base na extensão do arquivo, há uma boa chance que toda vez que o powershell for lançado, ele acionará essa regra.

Pelo menos no meu caso, isso significa que sempre que um arquivo .ps1 for executado no contexto do usuário (como um script de logon do powershell), ele acionará a notificação do aplicativo de lista de permissões e possivelmente bloqueará o script. Assinatura de script e configuração de política de execução eram irrelevantes nos meus testes.

Alguns links relevantes para mais informações:

link

link

link

    
por 27.10.2016 / 21:53