Sean Deuby | Tecnólogo principal

Os Serviços de Domínio do Active Directory (AD DS) tornaram-se um componente central maravilhosamente fiável, altamente escalável e tolerante a falhas da infra-estrutura de TI da sua empresa. Geralmente, funciona bastante bem sem exigir muita atenção. Mas o administrador do AD DS tem de fazer um esforço adicional para levar o serviço de um nível "a funcionar bem no dia-a-dia" para um nível "fiável à prova de bala quando surge algum tipo de situação invulgar". Quando esta situação invulgar acontece (e repare que eu disse "quando" e não "se"), há uma série de más configurações e más práticas que colocarão o seu domínio ou floresta do AD DS em risco de perda de dados, falha do controlador de domínio (DC) ou mesmo falha do domínio ou da floresta. Alguns destes itens podem parecer elementares, mas ficaria surpreendido se soubesse como são realmente comuns.

Leitura relacionada

Ainda tem DCs do Windows Server 2003. O Windows Server 2003 foi um excelente sistema operativo no seu tempo... mas o seu tempo já passou. Mais importante ainda, é um sistema operativo vulnerável e não corrigível. Porquê colocar a sua empresa em risco? Avance!

Todos os seus DCs e backups estão num único local físico. Muitas coisas ruins podem acontecer em um único local. É bom que tenha mais do que um DC, mas se estiverem todos no mesmo centro de dados, a sua floresta continua vulnerável a tudo o que possa destruir esse centro de dados. E isso obviamente vale também para os backups da sua floresta. Não há desculpa para não estar preparado para um desastre natural de evolução lenta como o furacão Sandy na costa leste dos EUA. Mas também sei que incêndios externos de rápida propagação causam danos significativos a um centro de dados e, pelo menos, tornam-no indisponível, se não estiver muito danificado. Moral: procure todos os pontos únicos de vulnerabilidade no seu ambiente AD DS.

A Lixeira não está ativada. Todos nós, administradores, respirámos de alívio quando a Reciclagem do Active Directory ficou disponível pela primeira vez no Windows Server 2008 R2. No entanto, demorou algum tempo até que este utilitário de restauro de objectos tão necessário fosse amplamente utilizado, porque requer um nível funcional mínimo de floresta do Windows Server 2008 R2. E para o conseguir, é necessário actualizar todos os seus DCs na floresta a partir de versões mais antigas, nomeadamente o Windows Server 2003. Como um número embaraçosamente grande de organizações só recentemente colocou os seus DCs do Windows Server 2003 num merecido descanso, muitas destas empresas também não activaram a Reciclagem. Você sabe quem é; mãos à obra!

Não está a seguir as práticas recomendadas de virtualização. Se você tiver DCs mais antigos que o Windows Server 2012, eles não compreendem ambientes virtualizados. Em particular, eles se recuperam mal de restaurações baseadas em imagens em que o banco de dados do AD foi restaurado para um momento anterior sem acionador. Certifique-se de que você (e especialmente seus administradores de virtualização) segue as práticas recomendadas da Microsoft para virtualizar o AD DS.

Não está a monitorizar regularmente o estado do DC/DNS. Uma das formas mais comuns de o Active Directory ter problemas é porque ninguém presta atenção a ele. Se for uma pequena organização, compreendo que pode não ter fundos para uma solução de monitorização extensiva (embora existam excelentes soluções gratuitas para pequenas e médias empresas, como a SpiceWorks). Tudo o que é necessário para fazer alguma monitorização básica é um script agendado que executa DCDIAG /s: /E e o escreve num ficheiro. Examine-o todas as manhãs. Se encontrar erros de replicação, por exemplo, existe a ferramenta gratuita ADREPLSTATUS disponível para o ajudar.

Está a executar várias funções num DC. A execução de várias funções num DC compromete a segurança e a capacidade de recuperação. Numa era de VMs facilmente criadas, não há razão para não ter servidores dedicados a esta tarefa.

Nunca se alteram as palavras-passe das contas de serviço. Este é um pequeno segredo sujo que a maioria dos departamentos de TI não quer admitir: as contas de serviço de muitos dos seus principais serviços de infra-estrutura não são actualizadas há anos. Antes do Windows Server 2008 R2, alterar a palavra-passe de uma conta de serviço significava incorrer em tempo de inactividade no serviço (por exemplo, uma base de dados do SQL Server numa aplicação de linha de negócio de vários níveis). Por isso, nunca era alterada. Numa grande organização que eu conhecia, a palavra-passe da conta de serviço SMS era conhecida por pelo menos três gerações de administradores de sistemas! Esta vulnerabilidade foi rectificada, primeiro pelas contas de serviço geridas (MSA) no Windows Server 2008 R2 e depois pelas MSA de grupo no Windows Server 2012. Já fez alguma coisa a esse respeito?

Demasiados administradores. Isto deve deixá-lo acordado à noite. Muitas, muitas organizações têm demasiadas contas administrativas porque quem construiu o seu AD DS nunca dedicou tempo extra a criar um modelo de administração delegada. Como resultado, conceder direitos alargados é a forma mais rápida de fechar um pedido de serviço. Essa é a maneira mais rápida que conheço de colocar sua empresa em uma manchete no feed de notícias de segurança da SC Magazine ou pior.

Não se iluda. Se tiver alguma destas condições no seu ambiente AD DS, é da sua responsabilidade mostrar à administração porque é que a sua correcção deve ser uma prioridade para a segurança da sua empresa.