Falhas graves de administração do Active Directory

O Active Directory é o alicerce da infraestrutura de uma rede Microsoft. Hoje eu vou enumerar algumas falhas graves de administração do Active Directory

Não ter um plano de recuperação de floresta Active Directory

Manter a disponibilidade é um dos pilares de segurança da informação – Restaurar rapidamente todo o seu domínio ou floresta a um momento anterior de quando houve o corrompimento (Recovery Point Objective (RPO)) Ter um plano de recuperação contra desastre no qual inclui toda e floresta sempre pensando no tempo máximo que pode ficar de inatividade Maximum Tolerable Downtime (MTD) e com que rapidez Recovery Time Objective (RTO)

• Recuperação de floresta do AD – Pré-requisitos
• Recuperação de floresta do AD-planejar um plano de recuperação de floresta personalizado
• Recuperação de floresta do AD – Etapas para recuperação
• Recuperação de floresta do AD – identificar o problema
• Recuperação de floresta do AD-determine como recuperar
• Recuperação de floresta do AD-executar recuperação inicial
• Recuperação de floresta do AD – Procedimentos
• Recuperação de floresta do AD-perguntas frequentes
• Recuperação de floresta do AD-recuperando um único domínio em uma floresta de multidomínio
• Recuperação de floresta do AD – Virtualização
• Recuperação de floresta do AD-recuperação de floresta com controladores de domínio do Windows Server 2003

Não atualizar o Windows Server

As atualizações para mitigar vulnerabilidades críticas são muito importantes. Além disso, você também terá que manter atualizado com os service packs e hotfixes mais recentes para garantir que seus sistemas permaneçam estáveis.

É recomendado que você aplique os patches em um ambiente de teste primeiro e depois aplique na produção. Se você aplicar patches sem testar, corre o risco de afetar os serviços fornecidos pelo sistema. Embora a chance seja baixa, você nunca saberá o impacto negativo que pode encontrar ao aplicar patches.

Não controlar grupos de usuários

Grupos de usuários se multiplicam em uma velocidade incrível. E os atores maliciosos irão enumerar usuários e grupos para identificar um caminho para o Admin de Domínio ou recursos confidenciais. Grupos de usuários vazios e únicos podem ter direitos elevados ou acesso a dados críticos. A Microsoft recomenda que os grupos Domain Admins, Enterprise Admins e Administrators não contenham usuários diários, com a possível exceção da conta interna Administrator. Os usuários só devem ser adicionados quando necessário para situações específicas, como situações de construção e recuperação de desastres.

Não gerenciar corretamente contas de serviços

Como a conta de serviço frequentemente tem permissões elevadas, é importante saber quem tem os direitos para alterar a senha da conta de serviço, pois essas contas podem alterar a senha e fazer logon no Active Directory como a conta de serviço.

Altere as senhas da conta de serviço regularmente ou mude para a Conta de Serviço Gerenciado (sMSA) no Windows Server 2008 R2 e superior ou Contas de Serviço Gerenciado de Grupo (gMSA).
Remova ou desative as contas de serviço que não estão mais em uso.

• Criar uma conta de serviço gerenciado de grupo (gMSA) no Azure Active Directory Domain Services
• Contas de serviços passo a passo

Uma conta de serviço gerenciado autônoma (sMSA) é uma conta de domínio gerenciado que fornece gerenciamento automático de senhas, gerenciamento de SPN (nome da entidade de serviço) simplificado e a capacidade de delegar o gerenciamento a outros administradores. Esse tipo de MSA (conta de serviço gerenciado) foi introduzido no Windows Server 2008 R2 e no Windows 7.

Não controlar usuários

Usuários desatualizados podem aumentar a superfície de ataque. Isso é especialmente verdadeiro se as senhas forem configuradas para nunca expirar, as senhas forem antigas e a conta estiver habilitada.
SIDHistory é comum para cenários de migração. No entanto, após a conclusão da migração, o SIDHistory deve ser removido. Existem ferramentas disponíveis hoje que permitirão a um adversário injetar um SID no atributo SIDHistory.

• A conta com permissão para alterar senhas pode se tornar qualquer outro usuário a qualquer momento.
• Contas configuradas com Delegação irrestrita podem ser comprometidas para personificar outras contas, como administrador e outras contas de administrador.