O Active Directory é uma ferramenta essencial em ambientes de uma rede corporativa, mas em muitos casos este ambiente é instalado e feito com poucas configurações iniciais. Neste post vamos sugerir algumas práticas para se implementar no Active Directory, ajudando no controle e administração desse ambiente.

Não entraremos aqui no assunto nuvem (EntraID), vamos focar em práticas e soluções iniciais em seu ambiente.

Antes de mais nada, use o Active Directory

Sem querer falar o óbvio, mas em muitas empresas encontramos ambientes com contas separadas. Algumas com razão, por segurança, outras apenas por falta de conhecimento e/ou de organização do ambiente. O Active Directory foi criado para centralizar os objetos de rede (impressoras, compartilhamentos, computadores, grupos, usuários) e isso inclui a autenticação. Muitos sistemas possuem a funcionalidade de autenticar utilizando o LDAP do Active Directory, nossa sugestão é que você utilize e centralize as credenciais de acesso no Active Directory.

AGDLP

AGDLP é um acrônimo para Account – Global Group – Domain Local Group – Permission. É uma recomendação para atribuir as permissões (seja para impressão, pasta compartilhada) sempre à um grupo e definir o usuário como membro desse grupo. Atuando desta forma você tem recebe alguns benefícios iniciais:

  • Rastreabilidade: Você não precisará rever os acessos em todas os recursos (pastas, impressoras e serviços) de tempos em tempos, você monitora apenas no AD;
  • Rastreabilidade inversa: Quando quiser saber onde um usuário tem acesso, você não precisa entrar em vários servidores e serviços. Basta entrar no AD e ver os seus grupos.
  • Administradores não precisam entrar em cada recurso para conceder novos acessos, basta adicionar o usuário ao grupo correspondente e esse fluxo é muito mais simples, dependendo pode ser delegado e executado por uma equipe de Service Desk.

Pensando desta forma, é importante que o nome do serviço deixe claro qual a permissão. Em vez de criar grupos Disco_F ou Contabilidade, crie (por exemplo):

  • AD – Adicionar Computadores ao Dominio
  • AD – Alterar senhas dos usuários
  • Compartilhamento – NomedoServidor – Pasta Contabilidade RW
  • Compartilhamento NomedoServidor – Pasta Contabilidade R
  • Impressora – NomedoServidorImpressora_Contabilidade

Veja que desta forma, ao abrir o usuário e listar os grupos ao qual ele faz parte, é fácil de entender quais acessos ele possuí. Lembre-se de que não estamos falando apenas de AD e/ou serviços Microsoft. As permissões devem, sempre que possível, serem atribuídas à grupos e os grupos devem ter claramente sua função. Por exemplo:

  • Servidores – Fazer Logon com um trabalho em lotes
  • Servidores – Permitir Logon como um Serviço
  • VPN – Prestador de Serviço
  • Internet – Acesso YouTube
  • Admin do Servidor NomedoServidor
  • Acesso Remoto em NomedoServidor

Segmentação de permissões

No domínio padrão do Active Directory, o Grupo Domain Admins é o grupo com permissão de administrator tanto no AD, quanto nos computadores. Por causa disso, muitos ambientes definem várias contas de usuários e de serviços como membro deste grupo. Porém automaticamente está delegando a cada conta destas, acesso à vários recursos desnecessariamente. Uma sugestão é separar pelo menos em 3 (para a administração do AD, dos Desktops e dos Servidores), Para isso sugerimos (vamos falar sobre desktop, mas o fluxo é o mesmo para os servidores):

  • Crie os grupos Admin – Todos os Desktops ;
  • Crie uma estrutura de OU’s no seu AD onde todos os desktops fiquem dentro de uma estrutura (mesmo que em várias OU’s diferentes dentro dela), não poderão ficar servidores nesta estrutura;
  • Crie uma GPO com nome Define Administradores dos Desktops ;
  • Defina nesta GPO que o grupo Admin – Todos os Desktops será administrador local (sugerimos fazer isto em Configuração de Computador/Preferências/Configurações do Painel de Controle/Usuários e Grupos Locais);
  • Vincule a GPO de servidores na OU inicial onde ficam todos os servidores;

Repita o procedimento para todos os outros tipos de computadores para restringir o acesso. Ao final, retire o Grupo Domain Admins das GPO’s que definem que este grupo faz parte do grupo de administradores.

A criação de um grupo “No Logon”

Algumas contas necessárias para autenticação de serviços (como integrar o Linux com o AD, por exemplo) nunca irão realmente logar em nenhum computador. Por isso vamos sugerir retira-las do grupo padrão Domain Users. Mas para isso é necessário colocar em outro grupo primeiro e definir este novo grupo como primário, aconselhamos então, a criação do grupo chamado No Logon e, sempre que possível, colocar contas de serviços neste grupo (definir este como grupo primário) e retirar do grupo padrão Domain Users.

A conta padrão “Administrator” do AD

A conta de administrador padrão do domínio não deve ser usada. Existem locais, inclusive, que essa senha é quebrada em partes e entregue cada parte à membros distintos. Algumas sugestões para essa conta:

  • Configurar (na conta) que esta conta é sensível e não pode ser delegada;
  • Bloquear, na GPO padrão do domínio, o login desta conta (restringindo-a apenas à administração do AD e mesmo assim não deve ser usada).

    Opcional – Grupo específico para cada PC

    Via GPO, em Configuração de Computador/Preferências/Configurações do Painel de Controle/Usuários e Grupos Locais é possível definir os membros dos grupos locais, mas uma função muito útil é a de usar variáveis para isso. Por exemplo, você pode definir como membro de um grupo o seguinte:

    SeuDominio\Admin PC %computername%

    Como %computername% é uma variável do Windows (neste caso, é o nome do próprio computador), o computador chamado PC-RH-01 irá procurar no AD um grupo chamado Admin PC PC-RH-01, enquanto o computador Contabilidade02 irá procurar no AD um grupo chamado Admin PC Contabilidade02 . Ou seja, deixando a GPO deste jeito, quando você desejar e criar um grupo desses e colocar os membros, automaticamente passará a ser administrador do computador.

    Run as a Batch Job

    Motivo de muitas contas se tornaram administradores, muitas vezes criar um grupo Servidores – Fazer Logon com um trabalho em lotes e atribuir este grupo com a permissão de Fazer Logon com um trabalho em lotes (Run as a Batch Job).

    Login diferente para administradores

    Muitos administradores possuem super privilégios em suas contas, para poderem ter acessos e executar todas as suas tarefas. Porém, uma boa prática é usar uma conta de usuário comum e ter uma conta utilizada para administração, está outra conta deve ser auditada ou até controlada por alguma solução de cofre de senha (onde a pessoa não tem autonomia sobre a senha, mas utiliza um software terceiro para acessar a credencial dessa conta administrativa, quando necessário).

    Local Administrator Password Solution (LAPS)

    Já fizemos um post mais detalhado sobre o LAPS – Solução Microsoft para troca de senha automática da conta Administrador Local. O LAPS é uma solução simples e eficiente para alterar a senha da conta de administrador, ou outra conta que deseje, armazendo a senha no seu Active Directory. Ela é baseada em GPO e, por isso, garante só alterar a senha quando tiver acesso ao AD (onde grava a nova senha em um atributo com visualização restrita). Recomendamos seu uso para todas as contas de administrador dos desktops e servidores.

    Automação

    Por fim, é importante automatizar os processos possíveis, já falamos de alguns por aqui, como fazer um Script para gerenciar horário de logon, ou Criar contas no seu Active Directory automaticamente de uma lista do SQL, usando o PowerShell. Você pode adaptar os scripts para, além de criar objetos, revogar acessos também (por exemplo, em mudanças de cargo). Esse tipo de ação vai minimizar falhas nos processos e, com a maturidade dos processos, um ambiente mais estável e seguro.

    Conclusão

    Neste Post tentamos falar rapidamente sobre a pequena ponta do iceberg, com o objetivo de lhe abrir algumas possibilidades que talvez ainda não tenha em seu ambiente. Não temos a pretensão de tentar criar um guia de segurança. Apenas lhe ajudar, lhe mostrando algumas boas práticas.

    Fontes/Referências

    NVLAN – Criar contas no seu Active Directory automaticamente de uma lista do SQL, usando o PowerShell
    NVLAN – LAPS – Solução Microsoft para troca de senha automática da conta Administrador Local
    NVLAN – Script para gerenciar horário de logon

    https://en.wikipedia.org/wiki/AGDLP
    https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-d–securing-built-in-administrator-accounts-in-active-directory
    https://microsoft.com/en-us/download/details.aspx?id=46899

    Mais Informações

    Esperamos ter ajudado e estamos à disposição para mais informações.

    Se você tem interesse em algum assunto específico, tem alguma dúvida, precisa de ajuda, ou quer sugerir um post, entre em contato conosco pelo e-mail equipe@nvlan.com.br.

    NVLAN - Consultoria