Existe uma pergunta que todo ambiente deveria conseguir responder e poucos conseguem: quando alguém sai da empresa, o acesso dessa pessoa ao hipervisor é revogado automaticamente?
Se a resposta depende de alguém lembrar de apagar uma conta local no Proxmox, a resposta prática é não. Contas órfãs são a norma em ambientes que crescem — e o hipervisor é o lugar onde uma conta órfã tem o maior alcance possível, porque ali está tudo.
Integrar o Proxmox ao diretório corporativo resolve isso estruturalmente, e a configuração é mais simples do que a maioria imagina.
Os realms disponíveis
O Proxmox chama de realm a origem da autenticação. Ele vem com dois e aceita outros:
| Realm | O que é | Uso adequado |
|---|---|---|
pam | Usuários Linux do nó | Root e casos que exigem shell no host |
pve | Usuários internos do Proxmox | Contas de serviço e automação |
| LDAP | Diretório LDAP genérico | Ambientes com OpenLDAP, FreeIPA |
| Active Directory | Diretório Microsoft | A maioria das empresas |
| OpenID Connect | Provedor de identidade moderno | Quem já tem login único centralizado |
O desenho que recomendamos:
- Pessoas vêm do diretório corporativo (AD, LDAP ou OIDC).
- Automações usam contas no realm
pve, com tokens de API de escopo mínimo. - `root@pam` existe, tem senha forte guardada em cofre, e é de uso excepcional.
Essa separação importa: se as pessoas vêm do diretório, o desligamento revoga o acesso. Se as automações também viessem de lá, uma indisponibilidade do diretório derrubaria as integrações — por isso elas ficam no realm interno.
Configurando o Active Directory
A configuração acontece em uma tela e pede poucas informações: o domínio, os servidores, e uma conta de leitura do diretório.
Os pontos que decidem se vai funcionar bem:
- Use LDAPS ou StartTLS, sempre, com o certificado da autoridade do domínio cadastrado no Proxmox. Autenticação em texto claro na rede é inaceitável no hipervisor.
- Mais de um servidor configurado. Se o diretório fica inalcançável, ninguém entra — e isso transforma uma falha do AD em uma indisponibilidade da gestão do cluster.
- Conta de leitura com privilégio mínimo, dedicada a essa integração, com senha longa e rotacionada.
- Filtro de usuário restringindo quem sequer aparece. Não é necessário — nem desejável — expor todo o diretório ao Proxmox.
- Base de busca apontando para a unidade organizacional correta, e não para a raiz do domínio.
Para LDAP genérico, a lógica é a mesma, com os atributos de nome de usuário e de associação a grupo ajustados ao seu esquema.
Sincronização de grupos: a parte que dá o ganho
Autenticar pelo diretório já resolve o desligamento. Mas o ganho maior vem da sincronização de grupos.
Com ela configurada, os grupos do diretório viram grupos no Proxmox. Você atribui as permissões aos grupos — PVEVMAdmin no pool de um time, PVEAuditor para o grupo de auditoria, PVEVMUser para o suporte de primeiro nível — e a gestão de quem pertence a quê volta para onde deveria estar: o diretório corporativo.
Consequência prática: conceder acesso ao hipervisor passa a ser adicionar a pessoa a um grupo no AD. Nenhum administrador de Proxmox precisa ser acionado, nenhuma permissão é atribuída individualmente, e a revogação é automática.
Alguns detalhes de operação:
- Agende a sincronização para rodar periodicamente. Sincronização apenas manual desatualiza e o benefício se perde.
- Escolha conscientemente o modo de sincronização. Existe a opção de remover do Proxmox o que não existe mais no diretório — que é o comportamento desejado para manter a higiene, e que precisa ser testado antes de ligar, porque remove de verdade.
- Teste em um grupo pequeno antes de aplicar ao diretório inteiro.
- Cuidado com grupos aninhados. Dependendo da configuração, a associação indireta pode não ser reconhecida. Verifique com um usuário real antes de confiar.
Autenticação de dois fatores
O Proxmox suporta 2FA, e não há motivo razoável para não usar em conta com privilégio administrativo. Os métodos:
- TOTP, com aplicativo autenticador. É o mais prático e o mais adotado.
- WebAuthn, com chave física ou biometria do dispositivo. Mais seguro, resistente a phishing.
- Códigos de recuperação, de uso único, para quando o dispositivo se perde.
Pontos de implantação:
- Torne obrigatório para os papéis administrativos. O Proxmox permite exigir por realm.
- Cada usuário registra o próprio fator. O administrador não configura pelos outros.
- Códigos de recuperação impressos ou em cofre, não no mesmo celular do autenticador.
- Procedimento de redefinição documentado: quem pode redefinir o 2FA de alguém, mediante qual verificação. Sem isso, o primeiro celular perdido vira um impasse.
Vale notar que 2FA cobre o acesso pela interface e pela API com senha. Tokens de API não usam 2FA — o que é correto, já que automação não digita código — e é justamente por isso que o escopo mínimo do token é tão importante.
O acesso de emergência
Este é o item que separa uma implantação pensada de uma que vai causar problema.
Se toda autenticação depende do diretório e o diretório fica inalcançável — ele caiu, a rede entre os sites caiu, ou o AD roda em uma VM dentro do próprio cluster —, ninguém entra no hipervisor. Exatamente quando você mais precisa entrar.
O que precisa existir:
- `root@pam` funcionando, com senha forte, guardada em cofre com acesso controlado e registrado.
- Um usuário administrativo no realm `pve`, independente do diretório, com 2FA, para uso em contingência.
- Console fora de banda (IPMI, iDRAC, iLO) acessível e testado.
- O procedimento documentado de quando e como usar o acesso de emergência, e o registro de cada uso.
E uma reflexão de arquitetura: se o seu Active Directory roda como VM dentro do cluster Proxmox que ele autentica, você tem uma dependência circular. Vale ter ao menos um controlador de domínio fora do cluster, ou aceitar conscientemente o acesso de contingência como o caminho nesse cenário.
Auditoria
Com usuários nominais vindos do diretório, o log de tarefas do Proxmox passa a ter valor real: cada ação tem um nome de pessoa. Isso só funciona se ninguém mais usar root compartilhado.
Complete com:
- Exportação dos registros para o log centralizado, fora dos nós.
- Alerta em eventos sensíveis: uso do root, falhas repetidas de autenticação, mudança de permissão, criação de token.
- Revisão periódica de quem tem o quê. Trimestral é suficiente e sempre revela algo.
O roteiro de implantação
- Configurar o realm do diretório com LDAPS e mais de um servidor.
- Testar autenticação com um usuário real, sem atribuir permissão ainda.
- Configurar a sincronização de grupos e testar com um grupo pequeno.
- Criar os grupos e as permissões no Proxmox, por pool.
- Migrar as pessoas para as contas nominais do diretório.
- Exigir 2FA nos papéis administrativos.
- Criar e testar o acesso de emergência.
- Guardar a senha do root em cofre e parar de usá-la no dia a dia.
- Exportar os registros de auditoria.
- Agendar a sincronização e a revisão trimestral de acesso.
Erros comuns
- Continuar com root compartilhado depois de integrar o diretório.
- LDAP sem TLS, com credencial trafegando em claro.
- Um único servidor de diretório configurado.
- Conta de leitura com privilégio excessivo.
- Base de busca na raiz do domínio, expondo o diretório inteiro.
- Ligar a remoção automática sem testar em grupo pequeno.
- Grupos aninhados não reconhecidos, com pessoas sem acesso esperado.
- Sincronização só manual, que desatualiza.
- Nenhum acesso de emergência independente do diretório.
- Controlador de domínio apenas dentro do cluster que ele autentica.
- 2FA sem códigos de recuperação nem procedimento de redefinição.
- Registros de auditoria só no nó, perdidos com ele.
- Nunca revisar quem tem acesso.
Onde a Solvefy/Cloud entra
Como parceiros oficiais Proxmox, implantamos a integração completa: realm do diretório com TLS e redundância, filtro e base de busca corretos, sincronização de grupos agendada e testada, permissões por grupo e por pool, 2FA obrigatório nos papéis administrativos, tokens de API com escopo mínimo para automação, acesso de emergência documentado e testado, e exportação dos registros de auditoria. Também revisamos a dependência circular entre diretório e cluster, que é um achado frequente e raramente percebido antes do incidente.
Uma pessoa que saiu da empresa ainda entra no seu hipervisor? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.