Possibilidades e melhores práticas relacionadas à implantação do GPO para o direito do usuário “Fazer logon como um serviço”

Question

Plano de fundo

Tenho um caso em que um computador de desenvolvedor está em um ambiente no qual o departamento de TI configurou uma política de grupo forçada para a diretiva de atribuição de direitos do usuário "Fazer logon como um serviço". A política está definida para ser forçada e não editável e, portanto, substitui totalmente as configurações locais.

Como este é um computador de desenvolvimento com o SQL Server Developer Edition instalado e um IIS em execução, esse direito de usuário é usado tanto pelas contas padrão do SQL Server quanto pelas contas virtuais dos pools de aplicativos (que foram adicionados / removidos dinamicamente / deste direito de usuário quando um pool de aplicativos é adicionado ou removido). Sem a conta de serviço do SQL Server adicionada a esse direito de usuário, o SQL Server nem sequer será iniciado.

Pessoalmente, acho estranho ter um GPO forçado que proíbe o comportamento padrão de um direito de usuário local. O departamento de TI adicionou vários grupos de serviços de administração, bem como vários grupos de usuários especiais que parecem ter sido adicionados como uma solução alternativa para outros departamentos de desenvolvedores da organização. Puramente em termos de segurança, também questiono por que outros departamentos de desenvolvimento devem obter o acesso "Fazer logon como um serviço" no meu computador quando eles realmente querem apenas o acesso a seus computadores locais.

Perguntas

1. É possível implantar um GPO de modo que ele apenas adicione as configurações do servidor às configurações locais em vez de substituí-las?

2. É possível implantar um GPO e ainda permitir que ele seja editável pelo usuário local?

3. É possível implantar o GPO de alguma outra maneira para que ele não afete as configurações locais?

4. Funcionaria com uma solução alternativa em que um grupo de usuários é adicionado ao GPO do servidor e onde o administrador local na máquina do desenvolvedor tem acesso para administrar e adicionar contas de serviço local a esse grupo?

5. O método no 4 trabalha com as contas virtuais do Pool de Aplicativos ou precisa ter acesso direto ao direito do usuário em vez de implicitamente através de um grupo de usuários?

6. Quais são as práticas recomendadas referentes a GPOs para o usuário "Log on como um serviço"? Espontaneamente, parece estranho lidar com o usuário da maneira como é feito por esse departamento de TI.

Ambiente

Máquina do desenvolvedor: Windows 8 Enterprise Eng

Servidor AD: domainControllerFunctionality: 5 = (WIN2012); domainFunctionality: 4 = (WIN2008R2); forestFunctionality: 4 = (WIN2008R2);

Não sei se isso indica um servidor Win2008R2 ou Win2012.

Agradecemos muito as informações detalhadas sobre o que é possível quando se trata de implantação de GPO, bem como práticas recomendadas e soluções criativas do problema específico!

    

Answer 1

Todo GPO é "forçado".

A resposta para 1 a 3 é um sonoro NÃO.

Nesse caso, peço que criem usuários para os serviços do SQL Server. Esses usuários devem ser adicionados ao grupo que pode ser executado como um serviço e, em seguida, configurar a máquina SQL local para execução usando essas credenciais.

A Microsoft tem um guia de ameaças e contramedidas. Procure. Eu vou colá-lo aqui. Estou no celular, então me perdoe por não formatá-lo corretamente.

Log on as a service

This policy setting determines which service accounts can register a process as a service. In Windows Server 2008 R2 and Windows 7, only the Network Service account has this right by default. Any service that runs under a separate user account must be assigned this user right.

Possible values: User-defined list of accounts / Not Defined Vulnerability

Vulnerability: Log on as a service allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with administrative privileges can install and configure services. An attacker who has already attained that level of access could configure the service to run with the Local System account.

Countermeasure: By definition, the Network Service account has the Log on as a service user right. This right is not granted through the Group Policy setting. You should minimize the number of other accounts that are granted this user right.

Potential impact: On most computers, restricting the Log on as a service user right to the Local System, Local Service, and Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to assign the Log on as a service user right to additional accounts that are required by those components. IIS requires that this user right be explicitly granted to the ASPNET user account.