Temos um domínio do Active Directory com o Windows Server 2016 no controlador de domínio e o Windows 10 atualizado em todos os clientes. Não muito tempo atrás, comecei a implantar os benchmarks de segurança Nível 1 do Center for Internet Security (CIS) no domínio por meio da Política de Grupo: Windows 10 na política de domínio padrão, com substituições baseadas no documento do Windows Server 2012 R2 (não há t para 2016 ainda) na política do controlador padrão. Eu fui mordido pelo endurecimento descuidado do Windows antes, então desta vez eu passei por todas as configurações uma a uma, com os documentos relevantes abertos e verificando o impacto de qualquer opção desconhecida. Funcionou bem - até hoje, quando consegui finalmente estragar alguma coisa. Os sintomas são os seguintes
- Clicar com o botão esquerdo do mouse em qualquer GPO no Gerenciamento de Diretiva de Grupo mostra uma caixa de erro "acesso negado". Ainda posso examinar e manipular as propriedades do objeto, inclusive alterando o status do GPO;
- Abrir um dos GPOs para edição mostra "acesso negado" novamente, embora em uma caixa diferente, e quando o editor inicia a árvore visível, as entradas são marcadas com um X vermelho;
- De volta ao Gerenciamento de Diretiva de Grupo, se eu for para a guia Detalhes de um GPO, só posso ver sua versão do AD. O em sysvol é descrito como não disponível;
- Finalmente, quando executo gpupdate / force em qualquer computador de domínio - incluindo o próprio DC - recebo um erro como este:
O processamento da Diretiva de Grupo falhou. O Windows tentou ler o arquivo \ contoso.com \ sysvol \ contoso.com \ Policies {foo} \ gpt.ini de um controlador de domínio e não obteve êxito. As configurações da Diretiva de Grupo não podem ser aplicadas até que esse evento seja resolvido. Esse problema pode ser transitório e pode ser causado por um ou mais dos seguintes procedimentos:
a) Resolução de nomes / conectividade de rede para o controlador de domínio atual.
b) Latência do Serviço de Replicação de Arquivos (um arquivo criado em outro controlador de domínio não foi replicado para o controlador de domínio atual).
c) O cliente do Sistema de Arquivos Distribuídos (DFS) foi desativado.
Infelizmente, acabei de perceber que esqueci de verificar o código de erro correspondente no Log de Eventos, no entanto, se eu apontar o Explorer para \ contoso.com \ sysvol \ (ou, se for o caso, algum compartilhar nesse servidor, usando o host e o nome de domínio no caminho) Solicito credenciais e ainda não encontrei as que funcionam, minha aposta está em "acesso negado" novamente. Acessar o sysvol através do caminho local no DC funciona bem, a propósito.
Em suma, pelo menos os dois últimos sintomas sugerem strongmente que consegui me proteger do compartilhamento SYSVOL; Não sei se os dois primeiros são causados por isso também ou não. Em uma nota lateral, depois de reiniciar o controlador de domínio para DSRM e depois voltar ao modo normal, tudo funcionou por cerca de 10 minutos.
Agora, eu tenho backups atualizados para que eu possa restaurar o último estado de trabalho e acabar com isso. No entanto, o que eu realmente gostaria de saber é a) entender quais configurações exatamente causaram esse problema (caso contrário, eu provavelmente vou encontrar o mesmo problema novamente em breve) eb) descobrir como fazer meu domínio funcionar com todo o endurecimento no lugar (benchmarks nível CIS-1 são baseline , eles não devem ter muito efeito sobre a funcionalidade ...). Ah, ec) se eu ainda posso fazer alguma coisa com a configuração atual.
Qualquer pessoa com experiência em proteger o Windows em geral ou aplicar benchmarks do CIS especificamente, quem poderia me dar uma cotovelada na direção certa? Se sim, muito obrigado antecipadamente!
Atualização: parece que consegui desativar as políticas de transgressão, mas ela não desfez o bloqueio do SYSVOL. Redefinir a política de segurança local para os padrões com secedit também não ajudou, possivelmente devido a todos os avisos de "acesso negado" que o procedimento produziu.
A propósito, uma coisa interessante que notei é que, se eu executar o "net share SYSVOL" no DC do Prompt do PowerShell iniciado com permissões elevadas, ele retorna informações esperadas (diferente de executar a partir de um prompt normal que fornece "você" adivinhou! - "acesso é negado").