De onde vem a política de segurança local de um controlador de domínio?

Question

Na Política de Grupo, temos a configuração Deny logon through Remote Desktop ativada para o grupo Domain Computers . Eu promovi um computador que era um membro deste grupo para ser um controlador de domínio. Após a promoção e o computador não era mais um membro do grupo Domain Computers , mas:

1. A configuração de Deny logon through Remote Desktop ainda estava em vigor
2. A configuração não foi listada nos resultados da Política de Grupo

Eu finalmente descobri que você pode editar a configuração no Local Security Policy MMC, mas agora estou preocupado porque:

1. Você não pode determinar facilmente se o valor foi alterado do padrão porque as configurações na Política de segurança local não têm a Define these policy settings box
2. A auditoria remota é difícil porque as configurações não aparecem nos Resultados da Política de Grupo

Alguém conhece alguma solução alternativa para esse comportamento? Se nenhum estiver disponível, existe uma maneira fácil de auditar essas configurações?

    

Answer 1

Os controladores de domínio têm suas próprias políticas de segurança locais, assim como os membros regulares do domínio. As Políticas de Grupo também terão precedência / substituição de políticas de segurança locais, assim como fazem nos membros regulares do domínio.

Como você testemunhou, há muitas configurações de Diretiva de Grupo que podem "tatuar" ou deixar sua marca na diretiva de segurança local do sistema, mesmo depois que o GPO não se aplica mais ao computador. Diretivas de grupo que não tatuam um sistema depois que o GPO não se aplica mais geralmente modificam as configurações em uma subchave "Policies" especial no registro do Windows. A maioria das Políticas de Grupo é bem comportada e segue esse padrão, mas nem todas elas.

A primeira solução óbvia para gerenciar as configurações em um ambiente de domínio é, se você se preocupa com uma configuração, configurá-la na Diretiva de Grupo para que ela substitua qualquer configuração de diretiva local.

Outra possível solução seria criar e aplicar modelos de segurança com a ferramenta Configuração e análise de segurança (snap-in mmc). Não vejo a vantagem de fazer isso simplesmente definindo suas configurações de linha de base por meio da Diretiva de Grupo, mas essa é a ferramenta a ser usada se você quiser aplicar modelos consistentes às políticas de segurança local de muitas máquinas.

A maioria dos administradores apenas promove computadores com uma boa configuração de segurança conhecida como controladores de domínio. Portanto, o seu problema não é muito comum.

Para a auditoria, a execução de gpresult /h policy.html gerará um relatório HTML que lista todas as configurações de política efetivas, incluindo uma mesclagem das Políticas de Grupo e das Políticas Locais. Portanto, se um computador tiver uma configuração de política local modificada, e nenhuma política de grupo a substituir, será exibido:

Em TechNet :

All settings applied through local policy or a Group Policy Object are stored in a local database on your computer. Whenever a security setting is modified, the computer saves the security setting value to the local database, which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database, then the setting does not revert to anything and remains defined as is. This behavior is sometimes called "tattooing."