Por que grandes empresas exigem AD/LDAP/SSO no Bitrix24
Empresas com centenas de usuários precisam de integração centralizada de identidade no Bitrix24 self-hosted: o provisionamento automático elimina cadastros manuais, o desprovisionamento instantâneo revoga acessos ao desligamento e o SSO garante login único, enquanto políticas de senha corporativas são aplicadas automaticamente via AD/LDAP.
Em ambientes corporativos com centenas de usuários, gerenciar credenciais individuais no Bitrix24 é inviável e arriscado. Quando o funcionário é desligado, a conta no portal precisa ser desativada imediatamente — de preferência de forma automática, pelo mesmo processo que bloqueia o acesso ao e-mail e à rede.
A versão self-hosted do Bitrix24 foi projetada para essa realidade. Diferente da versão cloud, ela permite integração direta com o diretório corporativo, seja via protocolo LDAP clássico, via Active Directory (AD) da Microsoft ou via federação de identidade com SAML 2.0. O resultado prático:
- Provisionamento automático — novos colaboradores cadastrados no AD aparecem no Bitrix24 sem intervenção manual.
- Desprovisionamento instantâneo — ao bloquear a conta no diretório, o acesso ao portal é revogado simultaneamente.
- Login único (SSO) — o usuário autentica-se uma vez no domínio corporativo e navega pelo Bitrix24 sem digitar senha novamente.
- Conformidade — políticas de senha, complexidade e expiração definidas centralmente no diretório valem para o Bitrix24.
Para aprofundar os motivos de escolha do modelo on-premise, consulte Self-Hosted CRM: por que escolher o Bitrix24 On-Premise para soberania de dados.
Os três protocolos e quando usar cada um
O Bitrix24 self-hosted suporta três mecanismos de autenticação centralizada: LDAP nativo (baixo esforço, ideal para AD ou OpenLDAP local), Active Directory com Kerberos (médio esforço, domínio Windows) e SAML 2.0 federado (médio-alto esforço, indicado para Azure AD, Okta ou acesso externo à rede).
| Mecanismo | Caso de uso típico | Protocolo | Nível de esforço |
|---|---|---|---|
| LDAP nativo | AD ou OpenLDAP na rede local | LDAP / LDAPS | Baixo |
| Active Directory (Kerberos) | Domínio Windows com Kerberos | LDAP + NTLM/Kerberos | Médio |
| SAML 2.0 / SSO federado | Azure AD, Okta, ADFS, Keycloak | SAML 2.0 | Médio–Alto |
Regra prática: se todos os usuários estão em um único domínio Windows na rede local, LDAP + Kerberos é o caminho mais direto. Se parte da equipe acessa o Bitrix24 de fora da rede ou via provedor de identidade em nuvem (Azure AD, Okta), prefira SAML 2.0.
Integração LDAP: configuração passo a passo
A configuração LDAP no Bitrix24 self-hosted exige 5 campos essenciais — servidor, Base DN, Bind DN com conta de serviço de leitura mínima, filtro de usuários por grupo AD e mapeamento de atributos — e deve obrigatoriamente usar LDAPS (porta 636) ou StartTLS para evitar transmissão de credenciais em texto claro.
O módulo de autenticação LDAP fica em Configurações → Configurações do produto → Configurações de módulos → Active Directory/LDAP. Os campos essenciais são:
- Servidor LDAP — hostname ou IP do controlador de domínio (ex.:
ldap://dc01.empresa.localouldaps://dc01.empresa.local:636para conexão criptografada). - Base DN — o ponto de partida da busca no diretório (ex.:
DC=empresa,DC=local). - Bind DN e senha — conta de serviço com permissão de leitura no diretório; use uma conta dedicada com privilégios mínimos.
- Filtro de usuários — expressão LDAP para restringir quais objetos são sincronizados (ex.:
(&(objectClass=user)(memberOf=CN=Bitrix24Users,OU=Groups,DC=empresa,DC=local))). - Mapeamento de atributos — associa campos LDAP (
cn,mail,telephoneNumber,department) aos campos de perfil do Bitrix24.
Recomendações de segurança para a conexão LDAP:
- Sempre prefira LDAPS (porta 636) ou StartTLS para evitar transmissão de credenciais em texto claro.
- A conta de serviço (Bind DN) deve ter apenas permissão de leitura (
Read); nunca use a conta de Administrador do Domínio. - Defina um grupo específico no AD (ex.:
Bitrix24Users) e sincronize apenas seus membros — reduz a superfície de ataque e facilita o offboarding.
Veja também o guia de hardening do Bitrix24 self-hosted para configurações de firewall e restrições de acesso ao servidor LDAP.
Integração com Azure AD via OAuth 2.0 / Microsoft 365
Empresas Microsoft 365 integram o Azure Active Directory ao Bitrix24 self-hosted via OAuth 2.0 em 6 passos: registrar app no Azure AD, definir URI de redirecionamento, adicionar permissões no Microsoft Graph, gerar segredo do cliente (exibido apenas uma vez), copiar Client ID e configurar o módulo de Serviços Sociais — com MFA herdado automaticamente das políticas do Azure AD.
Empresas que já utilizam o Microsoft 365 (antigo Office 365) podem federar autenticação entre o Azure Active Directory e o Bitrix24 self-hosted usando OAuth 2.0. O fluxo exige registro de um aplicativo no Azure AD:
- No portal Azure, acesse Azure Active Directory → Registros de aplicativo → Novo registro.
- Defina o nome do aplicativo e selecione o tipo de conta como Diretório organizacional múltiplo (multitenancy).
- No campo URI de redirecionamento, insira o endereço exibido nas configurações do módulo Serviços Sociais do Bitrix24 (
Configurações → Configurações do sistema → Configurações de módulo → Integração com serviços sociais). - Em Permissões de API, adicione as permissões necessárias no Microsoft Graph:
profile,offline_access. Para integração com documentos (Bitrix24.Drive/Docs), acrescenteFiles.ReadWrite.Alle permissões de leitura/escrita no SharePoint. - Em Certificados e segredos, clique em + Novo segredo do cliente, defina descrição e prazo de validade e clique em Adicionar. O valor do segredo é exibido apenas uma vez — copie-o imediatamente para o campo Chave no módulo de Serviços Sociais do Bitrix24.
- O Client ID (ID do aplicativo) está disponível na aba Visão geral do registro.
⚠️ O campo Locatário (Tenant) é opcional, mas restringe o acesso de edição de documentos apenas a usuários da sua organização. Geralmente corresponde ao domínio
empresa.onmicrosoft.com.
Autenticação multifator (MFA): o Azure AD suporta MFA com acesso condicional para proteger administradores globais e usuários comuns. Quando habilitado, o Bitrix24 herda automaticamente a política de MFA definida no Azure AD — nenhuma configuração adicional é necessária no portal.
SSO com SAML 2.0: federação com ADFS, Okta e Keycloak
O SAML 2.0 é o protocolo indicado para IdPs externos como ADFS, Okta e Keycloak: o usuário é redirecionado ao IdP, recebe um token SAML assinado e retorna ao Bitrix24 já autenticado em 5 etapas, sem que o portal armazene senhas, com suporte opcional a MFA no fluxo.
O SAML 2.0 é o protocolo indicado quando o provedor de identidade (IdP) é externo ao domínio Windows — como ADFS, Okta, Keycloak ou PingFederate. O diagrama abaixo mostra o fluxo de autenticação federada:
O usuário acessa o Bitrix24, é redirecionado ao IdP corporativo para autenticação, recebe um token SAML assinado e retorna ao portal já autenticado — sem que o Bitrix24 armazene a senha.
flowchart LR
A[Usuário no navegador] -->|1 - Acessa o portal| B[Bitrix24 Self-Hosted]
B -->|2 - Redireciona para IdP| C[IdP: ADFS / Okta / Keycloak]
C -->|3 - Autentica com credenciais corporativas| C
C -->|4 - Emite token SAML assinado| B
B -->|5 - Valida assinatura e cria sessão| A
C -.->|Opcional: MFA| A
Itens de configuração no Bitrix24 (SP — Service Provider):
- Entity ID do SP — URL única que identifica o Bitrix24 perante o IdP.
- URL de ACS (Assertion Consumer Service) — endpoint que recebe o token SAML; gerado automaticamente pelo módulo.
- Certificado do IdP — certificado X.509 usado para validar a assinatura dos tokens.
- Mapeamento de atributos — associa atributos SAML (
NameID,email,displayName,groups) aos campos de usuário do Bitrix24.
No lado do IdP (ADFS, Okta, Keycloak):
- Registre o Bitrix24 como Relying Party Trust (ADFS) ou Application (Okta/Keycloak).
- Configure a URL de ACS e o Entity ID informados pelo Bitrix24.
- Defina as regras de claim para enviar os atributos de usuário necessários.
Sincronização de grupos e controle de acesso
A integração AD/LDAP no Bitrix24 sincroniza grupos do AD com departamentos e grupos de trabalho do portal, herdando permissões de CRM, tarefas e drives automaticamente — com intervalo recomendado de 60 minutos para até 200 usuários, 30 minutos para até 500 e 15 minutos (ou webhook de evento) acima de 500.
A integração não se limita a autenticar usuários — ela pode sincronizar grupos do AD com departamentos e grupos de trabalho no Bitrix24. Isso significa:
- Membros do grupo
AD\Vendassão automaticamente adicionados ao departamento Vendas no Bitrix24. - Permissões de CRM, tarefas e drives são herdadas da estrutura organizacional importada do AD.
- Alterações no AD (promoção, transferência de departamento) refletem no Bitrix24 na próxima sincronização.
Frequência de sincronização recomendada:
| Tamanho da empresa | Intervalo sugerido |
|---|---|
| Até 200 usuários | A cada 60 minutos |
| 200 – 500 usuários | A cada 30 minutos |
| Acima de 500 usuários | A cada 15 minutos ou via webhook de evento |
Para empresas com alta rotatividade ou requisitos de segurança rigorosos, considere acionar a sincronização via script a partir de eventos do AD (criação/desativação de conta), em vez de depender apenas do intervalo programado.
Requisitos de infraestrutura e pré-requisitos
A integração AD/LDAP/SSO no Bitrix24 self-hosted exige: edição Business ou Enterprise, conectividade nas portas 389/636 (LDAP) ou 443 (ADFS), certificado SSL obrigatório para SAML e OAuth 2.0, conta de serviço AD com leitura mínima e senha sem expiração, e servidor NTP sincronizado para evitar rejeição de tokens SAML.
Antes de iniciar a configuração, valide os seguintes pontos com a equipe de infraestrutura:
- Versão do Bitrix24: módulo AD/LDAP disponível nas edições Business e Enterprise do pacote self-hosted.
- Conectividade de rede: o servidor Bitrix24 precisa alcançar o controlador de domínio na porta 389 (LDAP) ou 636 (LDAPS); para ADFS, porta 443.
- Certificado SSL no servidor Bitrix24: obrigatório para fluxos SAML e OAuth 2.0 — o IdP não aceita URIs de redirecionamento sem HTTPS.
- Conta de serviço no AD: privilégios mínimos de leitura; recomenda-se senha sem expiração e bloqueio de login interativo.
- Servidor NTP sincronizado: tokens SAML têm validade de poucos minutos — divergência de relógio entre SP e IdP causa falha de autenticação.
Para dimensionar corretamente o servidor que hospedará o Bitrix24, consulte o guia de hardware para 50 a 1.000 usuários.
Checklist de implantação em 8 etapas
A implantação de AD/LDAP/SSO no Bitrix24 self-hosted segue 8 etapas obrigatórias: definir protocolo, criar conta de serviço com leitura mínima, abrir portas de firewall, configurar o módulo, mapear atributos e grupos, testar com usuário piloto, configurar sincronização periódica com alertas e documentar o fluxo de offboarding para a equipe de TI.
- Definir protocolo — LDAP nativo, Azure AD (OAuth) ou SAML 2.0 com IdP externo.
- Criar conta de serviço no AD com permissão de leitura e MFA desabilitado para essa conta de serviço.
- Abrir portas de firewall entre o servidor Bitrix24 e o controlador de domínio / IdP.
- Configurar o módulo no Bitrix24 (LDAP ou Serviços Sociais para Azure AD; SAML no módulo de autenticação).
- Mapear atributos de usuário e grupos do AD para campos e departamentos do Bitrix24.
- Testar com usuário piloto antes de habilitar para todos — valide login, dados de perfil e grupos.
- Configurar sincronização periódica e alertas para falhas de autenticação.
- Documentar e treinar a equipe de TI sobre o fluxo de offboarding (desativar conta no AD → acesso revogado no Bitrix24).
Para uma visão completa dos custos e prazos de um projeto de implantação self-hosted, veja Bitrix24: custo e prazo de implantação com dados reais.
Riscos comuns e como evitá-los
Os 5 principais riscos na integração AD/LDAP/SSO do Bitrix24 são: usuários bloqueados por cache de credenciais, tokens SAML rejeitados por dessincronia NTP, sincronização falhando silenciosamente por expiração de senha de serviço, acesso não revogado no desligamento por intervalo longo e certificado do IdP vencido — todos mitigáveis com configurações preventivas específicas.
| Risco | Causa | Mitigação |
|---|---|---|
| Usuários bloqueados após mudança de senha | Cache de credenciais no Bitrix24 | Habilitar LDAP bind dinâmico; nunca armazenar senha localmente |
| Token SAML rejeitado | Dessincronia de relógio (NTP) | Configurar NTP nos servidores SP e IdP |
| Sincronização falha silenciosamente | Expiração da senha da conta de serviço | Conta de serviço sem expiração de senha + monitoramento de log |
| Acesso não revogado no desligamento | Sincronização com intervalo longo | Webhook de evento no AD + sincronização imediata |
| Certificado do IdP vencido | Falta de renovação automática | Alertas de expiração 60 dias antes; renovação planejada |
Para um checklist completo de segurança da instalação self-hosted, acesse Self-Hosted Bitrix24 Security Hardening: 25-Point Checklist.