Ingressando Servidores Ubuntu em um Active Directory

Um guia prático...

O Active Directory é poderosa plataforma da Microsoft usada para gerenciar identidades dentro de uma rede. Ele centraliza o controle de acesso, permitindo administrar usuários, grupos, computadores e outros recursos de forma organizada e segura.

Na prática, isso significa que os administradores podem usar suas próprias credenciais para acessar diferentes computadores e servidores da empresa, sem precisar criar contas locais em cada um deles. Por isso, faz todo sentido aproveitar essa funcionalidade também em servidores Linux.

Neste artigo, vamos aprender como integrar um servidor Ubuntu ao Active Directory, permitindo o acesso e gerencamento centralizado de forma simples e eficiente, desde a instalação de pacotes até a atribuição de permissões de root (sudo) utilizando um grupo pré-defindo do AD.

Este artigo apresenta duas soluções:

Procedimento Manual
Procedimento Automatizado - via script.

Pré-requisitos

Linux / Acesso root: Todos os comandos exigem privilégios sudo ou root.
Rede / Conectividade: O servidor linux precisa de acesso ao servidor Controlador de Dominio do Active Directory (AD DCs), além de ser capaz de efetuar resolução de nomes DNS. Também é necessário que tenha conectividade com a internet (para instalação e atualização de pacotes).
Windows / AD Domain DNS Name: O nome do Active Directory no formato DNS; exemplo = meudominio.corp.
Windows / AD User: Uma conta de usuário com perfil de administrador do domínio; vamos utilizar no formato UPN, exemplo = john@meudominio.corp.
Windows / AD Group: Um grupo de segurança do domínio; ele será o grupo que iremos conceder permissão de root/sudo no servidor linux; utilizar nome de grupos sem espaço; exemplo = Grupo_Admins_Ubuntu.
Tempo / Relógio do Sistema: O tempo entre o relógio do sistema (clock system) do Ubuntu e dos servidores do Active Directory, não deve ser superior a 5 minutos (300 segundos); do contrário a autenticação via Kerberos irá falhar.

Topologia

Para esse exemplo iremos usar o seguinte ambiente de laboratório:


- Rede IP ..............................: 192.168.168.0/24
- Gateway IP ...........................: 192.168.168.11
- Active Directory Domain DNS ..........: acme.labs
- Active Directory Domain Controller ...: alpha.acme.labs (192.168.168.201)
- Active Directory Admin User ..........: tux@acme.labs
- Active Directory Group ...............: Domain_Linux_Admins
- Linux Ubuntu Server ..................: zeta (192.168.168.59)
- Linux Ubuntu Server Root User ........: linux-admin

Além disso esse laboratório foi testado com:
- Microsoft Windows Server 2022 Standart.
- Linux Ubuntu Server 24.04 LTS

Visão Geral

Basicamente o processo envolve as seguintes etapas:

Update/Upgrade.
Instalação.
Rede.
Verificação do Tempo.
Ingressando no Active Directory.
Otimizando o SSSD.
Preparando o 'homedir'.
Concedendo Permissão de root para Usuários do AD.
Checklist de Testes.

1. Update/Upgrade

A primeira coisa que iremos fazer é procurar por atualizações, e instalar essas atualizações:


sudo apt update && sudo apt upgrade -y -q

Se possível, reinicie o servidor.

2. Instalação

Sistema atualizado, vamos começar para valer, realizando a instalação dos seguintes pacotes:


# bash output:

sudo apt install -y -q \
  realmd sssd sssd-tools libnss-sss libpam-sss adcli \
  samba-common-bin oddjob oddjob-mkhomedir packagekit chrony

Concluído, vamos passar adiante para a fase de Redes e Conectividade.

3. Rede

3.1 - Hostname

Vamos começar por alterar o hostname. Iremos usar o comando a seguir:


  # bash output:
  
  hostnamectl
        Static hostname: zeta
              Icon name: computer-vm
                Chassis: vm
             Machine ID: 96820f1745e84be499e3e2d7eb697a55
                Boot ID: 3a58bcaaeb5d48d6865122d83c450276
         Virtualization: microsoft
       Operating System: Ubuntu 24.04.3 LTS             
                 Kernel: Linux 6.8.0-87-generic
           Architecture: x86-64
        Hardware Vendor: Microsoft Corporation
         Hardware Model: Virtual Machine
       Firmware Version: Hyper-V UEFI Release v4.1
          Firmware Date: Thu 2024-11-21
           Firmware Age: 11month 1w 3d

Iremos forçar a exibição do 'Nome-do-Computador'+'Dominio-AD-DNS'.

De acordo as premissas identificas na topologia do nosso laboratório:

sudo hostnamectl set-hostname zeta.acme.labs


  # bash output:
  hostnamectl
  
        Static hostname: zeta.acme.labs
              Icon name: computer-vm
                Chassis: vm
             Machine ID: 96820f1745e84be499e3e2d7eb697a55
                Boot ID: 3a58bcaaeb5d48d6865122d83c450276
         Virtualization: microsoft
       Operating System: Ubuntu 24.04.3 LTS

Pronto! Basta reiniciar com sudo reboot.

3.2 Netplan

Muito provavelmente seus servidores irão utilizar endereços IP estáticos. Neste caso é bom verificar as configurações do **Netplan**. Ela é a ferramenta responsável pelo endereçamento IPv4/IPv6 das interfaces de rede no Ubuntu. Caso você esteja usando outra distribuição, verifique a documentação oficial.

Primeiro vamos localizar o arquivo de configuração:

sudo ls -l /etc/netplan/


  # bash output:
  
  total 4
  -rw------- 1 root root 256 Oct 30 01:37 50-cloud-init.yaml

Em seguida vamos editar o arquivo: sudo nano /etc/netplan/50-cloud-init


  # bash output:
  
  network:
    version: 2
    ethernets:
      eth0:
        addresses:
        - "192.168.168.59/24"
        nameservers:
          addresses:
          - 192.168.168.201        # IP do DC do Active Directory (DNS Server);
          search:
          - acme.labs              # Nome DNS do Active Directory;
        routes:
        - to: "default"
          via: "192.168.168.11"    # IP do Default Gateway.

Caso venha realizar alterações no arquivo, lembre-se de aplicar as configurações com a execução do comando: sudo netplan apply. Isso fará com que a interface de rede aplique as configurações imediatamente.

4. Verificação do Tempo

"Timming is the key" - O tempo é chave... e isso é absoluta verdade no que se trata de autenticação via **Kerberos**. O Active Directory irá abortar qualquer tentativa de autenticação, se o horário do sistema entre o seu cliente e o servidor, for maior que 5 minutos (300s). Por isso vamos adicionar como fonte de tempo alternativa para o Ubuntu, pelo menos um endereço dos Controladores de Domínio do AD. Isso manterá o servidor sempre "sincronizado" com o serviço de Kerberos do AD; e mesmo que o ambiente fique offline, o chrony utilizará outras fontes NTP, deixando o sistema autônomo.

4.1 - TimeZone

Vamos começar ajustando o fuso horário:


  # bash output:
  
  # Se você quiser uma lista de Fusos, execute a linha
  # timedatectl list-timezone
  #
  sudo timedatectl set-timezone America/Maceio

4.2 - Chrony

Agora precisamos saber os endereços dos controladores de dominio existente no Active Directory, para adicionar no arquivo de configuração do chrony. Uma forma de garantir essa informação é digitando o seguinte commando:

dig SRV _ldap._tcp.dc._msdcs.acme.labs +noall +answer


  # bash output:
  
  _ldap._tcp.dc._msdcs.acme.labs. 23 IN SRV 0 100 389 alpha.acme.labs.
  _ldap._tcp.dc._msdcs.acme.labs. 23 IN SRV 0 100 389 (xxx).acme.labs.

Vamos editar o arquivo de configuração e incluir os dados, na ultima linha do arquivo:


  # Get TAI-UTC offset and leap seconds from the system tz database.
  # This directive must be commented out when using time sources serving
  # leap-smeared time.
  leapsectz right/UTC
  
  # --------------------------------------------------------------------
  # para cada controlador,
  # você irá adicionar uma linha semelhante a seguir.
  server alpha.acme.labs prefer iburst

4.3 - Verificação do NTP

Reinicie o serviço do chrony usando:

sudo systemctl restart chrony

Uma forma de verificar se tudo está ok, é digitando chronyc tracking. Você verá a lista das fontes NTP, juntamente com os controladores aqui:


  # bash output: 
  
  chronyc tracking 
  
  MS Name/IP address     Stratum Poll Reach LastRx Last sample               
  ===============================================================================
  ^- prod-ntp-3.ntp1.ps5.cano>      2    6   377    35 +5861us[+5882us] +/-  105ms
  ^- alphyn.canonical.com          2    6   377    37 +4053us[+4074us] +/-   96ms
  ^* 194.58.38.95                  2    6   377    32   -80us[  -59us] +/-   18ms
  ^+ lrtest1.ntp.ifsc.usp.br       1    6   377    35  +220us[ +241us] +/-   24ms
  ^? alpha.acme.labs               0    7     0     -    +0ns[  +0ns] +/-    0ns

5. Ingressando no Active Directory

Chegou a parte mais fácil do processo... porém, para deixarmos a ingressão do seu servidor Linux Ubuntu, mais profissional, vamos ciar um arquivo de identificação do sistema operacional; assim o computador não irá ser identificado como um Linux Genérico.

5.1 - Preparando o realmd.conf

Crie esse arquivo /etc/realmd.cfg utilizando o nano:

sudo nano /etc/realmd.conf


  # E copie e cole neste arquivo.
  # Vcoê pode adaptar  o contéudo de acorso com as caracteristicas de seu servidor linux.
  #
  [active-directory]
  default-client = sssd
  os-name = Ubuntu
  os-version = 24.04.3 LTS (Noble Numbat)

Agora quando o Ubuntu fizer parte do Active Directory, suas caracteristicas do sistema operacional e versão poderam ser consultadas pelo AD.

5.2 - Discover realm

Vamos preparar o Ubuntu para receber os parametros do Active Directory, que irão defnir configurações dos serviços REALM, SSSD e ADCLI.

Execute o comando: sudo realm discover acme.labs


  # bash output:
  
  acme.labs
    type: kerberos
    realm-name: ACME.LABS
    domain-name: acme.labs
    configured: not configured         # <== Ainda não é membro do AD.
    server-software: active-directory
    client-software: sssd
    required-package: sssd-tools
    required-package: sssd
    required-package: libnss-sss
    required-package: libpam-sss
    required-package: adcli
    required-package: samba-common-bin
    login-formats: %U
    login-policy: allow-permitted-logins
    permitted-logins: 
    permitted-groups: Domain_Linux_Admins

5.3 - Ingressando no AD com realm join

Execute o comando:


  # bash output:
  
  sudo realm join -v --user=tux acme.labs    
  # em algumas situações se falhar, use o nome em maiusculas [ACME.LABS]

Para testar, basta usar realm list e ele deverá trazer maiores informações sobre o domínio.

5.4 - Limitando o acesso dos usuários do AD.

O objetivo desse tutorial é fazer com que apenas os administradores do Active Directory e/ou usuários, grupos, selecionados, possam também ter o nível de permissões root no Ubuntu.


  # bash output:
  
  sudo realm deny --all
  sudo realm permit -g Domain_Linux_Admins

Essa configuração permite que apenas usuários deste grupo possam ser autenticados e ter acesso ao servidor linux.

6. Otimizando o SSSD e Melhorando o Login

Agora que o servidor já está integrado ao Active Directory, vamos realizar alguns ajustes no serviço **SSSD** — responsável por autenticar usuários do domínio no Linux.

Essas otimizações trarão benefícios como:

**Login simplificado** (sem necessidade de user@domínio);
**Cache de credenciais** para logins offline;
**Criação automática do diretório home** ao efetuar login;
**Desativação da enumeração de usuários do AD**, o que melhora a performance e evita sobrecarga no sssd.

6.1 - Fazendo backup do arquivo sssd.conf

Antes de aplicar qualquer alteração, é recomendável fazer um backup da configuração atual:

sudo cp /etc/sssd/sssd.conf /etc/sssd/sssd.conf.bak_$(date +%Y%m%d_%H%M)

Esse backup pode ser restaurado posteriormente, se necessário.

6.2 - Parando o serviço SSSD

Vamos parar o serviço antes de editar o arquivo de configuração:

sudo systemctl stop sssd

6.3 - Editando o arquivo de configuração

Abra o arquivo de configuração principal do SSSD:

sudo nano /etc/sssd/sssd.conf

Agora verifique e ajuste os seguintes parâmetros:


  use_fully_qualified_names = False
  enumerate = False

Explicação:

use_fully_qualified_names = False: Permite fazer login usando apenas o nome do usuário, sem precisar do sufixo de domínio (ex: tux ao invés de tux@acme.labs).
enumerate = False: Evita que o SSSD liste todos os usuários e grupos do AD localmente, o que melhora performance e reduz latência.

Salve e feche o arquivo

6.4 - Ajustando permissões

Esse arquivo contém informações sensíveis, por isso, defina permissões restritas:

sudo chmod 600 /etc/sssd/sssd.conf

6.5 - Reiniciando e validando o SSSD

Execute os comandos a seguir para validar a sintaxe e reiniciar o serviço:


  #bash output
  
  sudo systemctl daemon-reexec
  sudo systemctl restart sssd

7. Criando Diretórios Home Automaticamente (PAM)

Nesta etapa vamos garantir que, ao efetuar login com uma conta do Active Directory, o diretório /home/usuario seja criado automaticamente.

Esse comportamento é essencial em ambientes multiusuário integrados ao AD, pois evita que o administrador precise criar manualmente os diretórios /home de cada usuário autenticado.

Para isso, utilizaremos o módulo **PAM**: pam_mkhomedir.so. Este módulo faz parte da pilha de autenticação do PAM (Pluggable Authentication Modules), usada por sessões interativas como login local e via SSH.

7.1 - Ajustando o PAM

O arquivo que precisamos alterar é o /etc/pam.d/common-session.

Primeiro, remova quaisquer entradas anteriores da diretiva pam_mkhomedir.so, para evitar duplicações ou conflitos:

sudo sed -i '/pam_mkhomedir.so/d' /etc/pam.d/common-session

7.2 - Adicionando a regra correta

Vamos editar o arquivo:

sudo nano /etc/pam.d/common-session

Agora insira a seguinte linha logo após a diretiva pam_unix.so:


  session required pam_unix.so
  session required pam_mkhomedir.so skel=/etc/skel umask=0022

O resultado do arquivo deve ficar semelhante a este resultado:


  # and here are more per-package modules (the "Additional" block)
  session	required	pam_unix.so 
  session required      pam_mkhomedir.so skel=/etc/skel umask=0022
  session	optional	pam_sss.so  
  session	optional	pam_systemd.so  
  # end of pam-auth-update config
  linux-admin@zeta:~$

Explicação dos parâmetros:

skel=/etc/skel: indica que os arquivos padrão de /etc/skel serão copiados para o novo home.
umask=0022: define permissões padrão para os arquivos criados.

7.3 - Salvando e testando

Após salvar o arquivo (Ctrl+O, Enter, Ctrl+X), a configuração já estará ativa.

Para testar:

Tente logar com um usuário do AD que ainda não possua diretório home.
Verifique se o diretório é criado automaticamente:


  ls -l /home/
  # ou
  pwd

O resultado esperado é:


  #bash output
  
  tux@zeta:~$ ls -l /home/
  total 8
  drwxr-x--- 5 linux-admin linux-admin    4096 Nov  8 14:38 linux-admin
  drwxr-xr-x 3 tux          domain guests 4096 Nov  8 15:01 tux@acme.labs
  tux@zeta:~$

Essa configuração complementa as alterações feitas no módulo 6 (sssd.conf) e garante uma experiência de login suave e funcional para usuários do AD no Linux.

8. Concedendo Permissões de root (sudo) para um Grupo do AD

Para que os usuários do Active Directory possam executar tarefas administrativas no servidor Linux Ubuntu (como atualizar pacotes, configurar serviços, instalar programas etc.), é necessário conceder permissões de sudo ao grupo adequado do AD.

Essa etapa é essencial para que os administradores do domínio Windows possam ter privilégios elevados no ambiente Linux, de forma controlada e segura.

8.1 - Escolhendo o grupo do AD

Durante a configuração, você deve ter definido um **grupo de segurança no Active Directory** que receberá as permissões de sudo. Exemplo de nome recomendado: Domain_Linux_Admins Esse grupo deve conter os usuários e/ou grupos do Active Directory que você deseja autorizar como administradores no Ubuntu.

8.2 - Criando o arquivo de regra no sudoers.d

Vamos criar um arquivo no diretório /etc/sudoers.d/, porém usando o comando **visudo** que é a forma recomendada para adicionar regras de sudo sem alterar o arquivo principal.

Crie o arquivo de configuração:

sudo visudo /etc/sudoers.d/Domains_Linux_Admins

Use o nome do grupo como parte do nome do arquivo; isso torna fácil a identificação e manutenção futura.

Cole o seguinte conteúdo, substituindo pelo nome exato do seu grupo AD (sem espaços):


        # Permite que membros do grupo AD tenham acesso sudo completo.
        # Este arquivo é gerenciado manualmente ou via script de integração AD.
        # Regra:
        %Domain_Linux_Admins ALL=(ALL) ALL

Salve e saia do editor.

8.3 - Testando a permissão

Você poderá testar, fazendo login com um usuário do grupo e execute:


        #bash output
        tux@zeta:~$ sudo whoami
        [sudo] password for tux: 
        root
        tux@zeta:~$

A partir de agora, todos os **membros do grupo definido no AD** terão acesso administrativo completo no servidor Ubuntu, desde que a autenticação via SSSD/Realm esteja funcionando corretamente.

9. Automatizando o Processo com Script Interativo

Se você preferir não realizar todas as etapas manualmente, este tutorial também disponibiliza um **script interativo** chamado integra_ad.sh que automatiza toda a integração do Ubuntu ao Active Directory — incluindo instalação de pacotes, configuração de rede, SSSD, PAM e permissões de sudo para usuários do AD.

📦 Download do Script

Você pode baixar o script diretamente do repositório no GitHub:

wget https://raw.githubusercontent.com/wevertonjlima/scripts/main/integra_ad.sh

⚙️ Tornando o script executável

Depois de baixado, torne o script executável com:

chmod +x integra_ad.sh

▶️ Executando o script

Para iniciar a execução, use:

sudo ./integra_ad.sh

O script foi projetado com uma interface interativa e validações em cada etapa. Ele permite que você acompanhe todo o processo com segurança, além de oferecer opções de **cancelamento** antes de executar comandos sensíveis.

💡 **Importante:** Mesmo utilizando o script, recomendamos que você leia este tutorial para entender o que está sendo configurado em seu sistema.