Powershell sendo iniciado no modo restrito após a aplicação, removendo os GPOs do AppLocker / SRP

0

Aqui é o post technet relacionado a isso. Vou transferir o que eu pedi e tentei este post, mas estou incluindo para referência.

O ambiente é: Controlador de Domínio 2012, Win 10 Endpoints, versão PowerShell 5.algo *

Anteriormente, eu tinha o SRP e o AppLocker habilitados por meio do GPO para testes. Ele funcionou como esperado, então eu coloquei meu computador de volta no grupo de AD 'normal' e desabilitei o serviço de identidade de aplicativo. Isso foi provavelmente 3-4 dias atrás, então não é só GP demorando para implantar.

Eu também tentei aplicar uma política 'negativa' com uma política de AppLocker e SRP permitida para todos, caso a política antiga "tatuasse" até que fosse escrita, mas não consegui fazer nada qualquer um.

Eu encontrei as seguintes soluções alternativas:

1) Launching Powershell as an administrator.

2) Launching Powershell using the -v 2 switch in order to launch Powershell 2.0 instead of 5.0.

3) I am almost certain that signing our scripts would allow them to run in Full Language, but I haven't tested.

Ambos colocam PS no modo Full Language.

No entanto, não quero encontrar uma solução alternativa que tenhamos em mente ao implantar scripts automatizados - quero restaurar o sistema para sua configuração antes de aplicar esses GPOs, onde o Powershell é lançado em Idioma Completo por padrão. Não acredito na implantação de GPOs em toda a organização que não sejam reversíveis. Eu não quero ter que explicar como, mesmo se revertermos esse GPO, ficaremos presos executando scripts no PS v2 ou como administradores para sempre.

Eu testei a correção listada aqui , mas

A) the environmental variable and the registry entry it corresponds to did not exist.

B) Creating that environmental variable as a system EV did not work. I did not try doing so as a user level EV because I don't think that's a viable solution.

*: Não é a versão PS com o bug relacionado ao modo de linguagem restrita. Eu esqueço qual versão é e as especificidades do bug, mas eu confirmei que não estou executando essa versão específica de 5.

    
por Adonalsium 27.07.2018 / 15:29

1 resposta

0

Portanto, a 'correção' que acabei encontrando para isso foi adicionar "Permitir / Assinado por *" na política "reversa" do AppLocker. Seja qual for a razão, isso não a quebrou para scripts assinados. Eu assino meus scripts de qualquer maneira para provas futuras, e planejo ter qualquer script agendado para ser assinado, então isso é "fixo" no que diz respeito ao meu ambiente ... Uma correção mais real que realmente redefinir os controles seria ótima, embora .

    
por 31.07.2018 / 21:57