Identity Lab

01 · OBJETIVO

Identidade corporativa num laboratório realista

O objetivo é criar uma cadeia de identidade em que Samba AD mantém utilizadores e grupos e Keycloak fornece a camada de IAM para aplicações, SSO, MFA e RBAC.

02 · ARQUITETURA

Separar diretório de autenticação aplicacional

03 · SAMBA AD

Preparar o controlador de domínio

Usa uma VM dedicada, hostname estável, IP fixo e DNS coerente. O exemplo abaixo mostra os pacotes base em Ubuntu.

sudo apt update
sudo apt install samba krb5-user winbind smbclient dnsutils

samba --version
krb5-config --version 2>/dev/null || true

04 · DNS E DOMÍNIO

DNS é parte da identidade

Antes de integrar Keycloak, confirma que o domínio resolve corretamente e que Kerberos não sofre desvios de hora.

hostname -f
resolvectl status
host -t SRV _ldap._tcp.SEUDOMINIO.LOCAL
host -t SRV _kerberos._udp.SEUDOMINIO.LOCAL
timedatectl

05 · UTILIZADORES E GRUPOS

Criar identidade de laboratório

sudo samba-tool user create lab.user
sudo samba-tool group add LAB-APP-USERS
sudo samba-tool group addmembers LAB-APP-USERS lab.user

sudo samba-tool user show lab.user
sudo samba-tool group listmembers LAB-APP-USERS

Evita usar contas administrativas nos testes funcionais. O laboratório deve distinguir utilizador normal, operador e administrador.

06 · KEYCLOAK

Adicionar a camada IAM

Keycloak deve correr num serviço separado do controlador de domínio. Para documentação pública, usa nomes e endereços exemplificativos, não dados internos.

1. Instalar Keycloak de acordo com o método escolhido para o laboratório.
2. Criar um realm dedicado.
3. Criar o cliente da aplicação.
4. Configurar redirect URIs de forma restritiva.
5. Ativar MFA quando o fluxo base estiver validado.

07 · FEDERAÇÃO

Ligar Keycloak ao Samba AD

No realm, configura User Federation com provider LDAP. Define Vendor como Active Directory, Connection URL LDAP/LDAPS, Bind DN dedicado e Base DN adequada.

Depois da ligação, testa a conexão, autenticação e sincronização. Só depois adiciona mappers para grupos ou atributos.

08 · VALIDAÇÃO

Testar por camadas

1. Utilizador existe no AD.
2. DNS e Kerberos funcionam.
3. Keycloak consegue consultar LDAP.
4. Utilizador aparece no realm.
5. Login funciona na aplicação.
6. Utilizador sem role é bloqueado onde deve.
7. MFA funciona sem quebrar o fluxo.

09 · CENÁRIO PRÁTICO

Falha de autenticação até ao SIEM

Cria uma tentativa de login inválida numa conta de laboratório. Confirma o evento no Keycloak, encaminha os logs para o Wazuh e correlaciona utilizador, aplicação, origem e timestamp. O resultado esperado é conseguir reconstruir o evento sem depender apenas da interface da aplicação.

11 · SSO

Transformar identidade em acesso centralizado

Depois da federação LDAP estar estável, cria um cliente OIDC dedicado à aplicação de laboratório. Define Client ID, redirect URIs e web origins de forma restritiva.

Valida login, logout, expiração da sessão e novo acesso a uma segunda aplicação integrada. O utilizador deve autenticar uma vez e reutilizar a sessão quando a política o permitir.

12 · MFA

Adicionar um segundo fator

Ativa MFA apenas depois do login federado estar funcional. No laboratório, TOTP permite demonstrar o fluxo sem depender de integrações externas.

1. Configura a ação necessária para registo de OTP.
2. Associa a política ao grupo ou utilizador de laboratório.
3. Regista o autenticador.
4. Testa login correto.
5. Testa tentativa sem segundo fator.

Regista o que aparece no Event Log do Keycloak em cada cenário.

13 · RBAC

Separar autenticação de autorização

Um utilizador autenticado não deve automaticamente ter acesso a todas as funções. Mapeia grupos do diretório para roles da aplicação.

LAB-APP-USERS  -> role: user
LAB-SOC        -> role: analyst
LAB-ADMINS     -> role: admin

Testa pelo menos três contas. Cada uma deve conseguir apenas as operações previstas para o respetivo papel.

14 · APLICAÇÃO

Integrar um cliente real

A aplicação deve usar OIDC ou SAML em vez de receber diretamente a password do Active Directory. O fluxo recomendado mantém a autenticação no Keycloak e entrega à aplicação apenas os tokens necessários.

Browser
  -> Aplicação
  -> Keycloak
  -> Samba AD / LDAP
  -> Keycloak
  -> Authorization Code
  -> Aplicação
  -> sessão local

15 · EVENTOS

Tornar autenticação observável

Ativa os eventos necessários no realm e confirma que logins, erros e alterações administrativas relevantes ficam registados. Não aumentes a retenção ou detalhe sem avaliar o volume e os dados pessoais envolvidos.

Eventos úteis no laboratório incluem LOGIN, LOGIN_ERROR, LOGOUT e alterações administrativas controladas.

16 · WAZUH

Levar os eventos de identidade ao SIEM

O objetivo é recolher o ficheiro ou stream de logs do Keycloak através do agente instalado no host que executa o serviço, mantendo timestamp e contexto suficientes para correlação.

Keycloak
  -> log de eventos
  -> Wazuh Agent
  -> decoder / regra
  -> Wazuh Manager
  -> Dashboard

17 · INVESTIGAÇÃO

Reconstruir uma falha de autenticação

1. Usa uma conta de laboratório.
2. Executa várias tentativas inválidas controladas.
3. Efetua depois um login válido.
4. Localiza os eventos no Keycloak.
5. Confirma a chegada ao Wazuh.
6. Correlaciona username, client, origem e timestamp.
7. Regista a conclusão e limitações da evidência.

O exercício está concluído quando consegues explicar a sequência a partir dos logs, sem depender da memória de quem executou o teste.

10 · CHECKLIST

Critérios de conclusão

• Samba AD responde por DNS
• Kerberos e hora validados
• Utilizador e grupo de teste criados
• Realm Keycloak criado
• LDAP ligado ao diretório
• Login federado validado
• Role ou grupo testado
• Evento de falha identificável
• SSO validado
• MFA testado
• RBAC validado com perfis distintos
• Aplicação integrada por OIDC
• Eventos Keycloak observáveis
• Eventos recebidos no Wazuh
• Cenário de investigação documentado

Continuação: SSO, MFA, RBAC, integração de aplicações e envio estruturado de eventos para Wazuh.