--- title: "Como gerenciar servidores LDAP/AD" slug: "how-to-manage-ldapad-servers" updated: 2026-11-03T14:57:58Z published: 2026-11-03T14:57:58Z canonical: "docs.senhasegura.io/how-to-manage-ldapad-servers" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.senhasegura.io/llms.txt > Use this file to discover all available pages before exploring further. # Como gerenciar servidores LDAP/AD O cadastro de um servidor Active Directory (AD) na Segura™ Platform é um procedimento essencial para integrar e gerenciar eficientemente a infraestrutura de TI de uma organização. O Active Directory é uma solução amplamente utilizada para o gerenciamento de identidade e acesso em redes corporativas, permitindo centralizar a autenticação e autorização de usuários e dispositivos. Neste documento, você encontrará as informações para gerenciar servidores do tipo Active Directory no Segura™, incluindo os novos mecanismos de bloqueio de autenticação e controle de *fallback* local. ## Requisitos - Ter o papel **PAM administrator**. ## Cadastrar/Alterar um novo servidor AD 1. Na Segura™ Platform, na barra de navegação, passe o mouse sobre o **Menu de produtos** e selecione **Configurações**. 2. No menu lateral, acesse **Provisionamento > Active Directory > Servidores**. 3. No formulário **Servidores,** você verá uma listagem com todos os servidores cadastrados na sua instância da Segura™ Platform. Para cadastrar um novo servidor, clique em **Adicionar** e siga os passos na tela. ### Aba Domínio, dispositivo e credencial Atenção Tanto o domínio como a credencial devem ser cadastrados antes do servidor AD. 1. No menu suspenso **Domínio**, selecione o domínio do seu servidor AD. 2. No menu suspenso **Credencial para autenticação**, selecione a credencial que será usada para autenticação no servidor AD. 3. Clique em **Continuar**. ### Aba LDAP Atenção O formulário de conta deve ser cadastrado antes. Info A ordem de configuração dos servidores define a sequência de autenticação na Segura™ Platform. Quando múltiplos servidores são configurados, o sistema tenta autenticar o usuário seguindo a ordem estabelecida, percorrendo cada servidor até que a autenticação seja bem-sucedida. Por exemplo, se os servidores A, B e C estiverem configurados nessa ordem, e um usuário existir apenas no servidor C, a Segura™ Platform iniciará a tentativa de autenticação no servidor A, prosseguirá para o B e, por fim, completará a autenticação no servidor C. 1. No campo **Host**, preencha com o nome do *host* do servidor AD. 2. No campo **Porta**, preencha com o número da porta onde o servidor AD está escutando. 3. No campo **DN Base**, preencha com o *Distinguished Name Base* do seu servidor AD. Este campo é o ponto de partida a partir do qual o sistema irá realizar a busca por objetos no diretório e irá definir o escopo para buscas LDAP dentro da hierarquia do AD. Por exemplo, para o domínio `example.com` o **DN Base** será `DC=example,DC=com`. 4. No menu suspenso **Formulário de conta**, selecione o formulário de conta que você deseja utilizar para esse servidor. Esse formulário permite aos administradores configurar e padronizar contas de usuário com as informações e permissões corretas para o ambiente do AD. Geralmente, quando usamos AD, a opção **Principal** é a mais utilizada. 5. No seletor **Ordem**, selecione a ordem de servidores em que a autenticação será realizada. 6. Na opção **Ativo**, ative o interruptor para que o servidor seja cadastrado na Segura™ Platform já ativo. Por padrão, essa opção está ativada. 7. Na opção **Membro é DN?** ative o botão *toggle* se o usuário for identificado por seu DN 8. Na opção **Bind requer DN?** ative o botão toggle se o processo de associação precisar usar o DN. Esta configuração é necessária para o caso em que um usuário esteja em uma localização diferente do DN base. 9. Na opção **Usar SSL?** ative o botão *toggle* se você deseja usar o protocolo SSL. Por padrão, essa opção está desativada. 10. No menu suspenso **Network connector,** selecione qual conector será usado com o servidor LDAP. Este passo adicional é utilizado quando a sua estrutura utiliza o **network connector**. Nesse caso, é necessário selecionar o conector no menu suspenso. 11. Na opção **Formato do filtro de conta,** especifique os critérios de pesquisa para restringir os resultados dos objetos. Por exemplo: `(&(objectClass=user)(sAMAccountName=johndoe)).` 1. Nesse caso, os campos são: 1. `objectClass=user`: indica que o tipo de usuário deve ser *user*. 2. `sAMAccountName=johndoe`: o identificador SAM (*Security Account Manager*) da conta de usuário deve ser `johndoe`. 12. Na opção **Usar domínio de credencial**, ative o botão *toggle* se você deseja usar uma credencial de domínio. Por padrão, essa opção está desativada. 13. Utilize a opção **Atributo de username** apenas quando o atributo do *username* for diferente do padrão. Por padrão, este atributo é `sAMAccountName`. 14. Na opção **DN Bind (deixar em branco para utilizar o DN Base)**, preencha com o DN que será usado como identificador exclusivo. Por exemplo: `CN=John Doe,OU=Users,DC=Segura,DC=com`. 15. Na opção **Grupo** digite o grupo da conta. 16. Na opção **DN do grupo** digite o DN da conta. 17. Na opção **Atributo do grupo (GroupAttr),** preencha com os atributos do grupo. 18. Na opção **Escopo do grupo**, preencha com o escopo do grupo. 19. Na opção **Filtro do grupo**, digite uma expressão de filtro para o grupo. Por exemplo: `(objectClass=group)` que retornará todos os objetos no servidor LDAP/AD do tipo *group*. 20. Na opção **Atributo do membro (MemberAttr)**, insira os atributos dos membros do grupo. 21. Clique em **Continuar**. Ao final do processo, revise as informações do seu servidor AD e, caso tudo esteja correto, clique em **Salvar**. ## Controle de autenticação e *fallback* local A Segura™ Platform implementa mecanismos avançados de controle de autenticação que garantem a consistência entre o Active Directory e o sistema local, prevenindo divergências de senha e comportamentos não intencionais. ### Configuração do parâmetro "Desabilitar fallback de autenticação local" A Segura™ Platform disponibiliza o parâmetro **Desabilitar Fallback de Autenticação Local** que, quando ativado, impede que a Segura™ Platform utilize autenticação local quando a autenticação via AD encontra condições específicas de bloqueio. ### Fluxo de Validação de Autenticação Durante o processo de *login*, o sistema executa as seguintes verificações sequenciais: 1. **Verificação de conectividade**: confirma se a conexão com o servidor AD está ativa e funcional. 2. **Análise de parâmetros do usuário**: verifica se o usuário possui configurações especiais no AD, incluindo: - Parâmetro "alterar senha no próximo login". - *Status* de bloqueio da conta. 3. **Validação de configuração de fallback**: confirma o *status* do parâmetro "Desabilitar Fallback de Autenticação Local". ### Cenários de bloqueio de autenticação #### Alteração de senha obrigatória no próximo login Quando um usuário possui o parâmetro "alterar senha no próximo login" ativado no Active Directory, o sistema implementa o seguinte comportamento: **Condições de ativação** - Conexão com AD ativa. - Parâmetro "Desabilitar Fallback de Autenticação Local" habilitado. - Usuário configurado para alteração obrigatória de senha. **Comportamento do sistema** - O acesso a Segura™ Platform é bloqueado preventivamente. - O mecanismo de *fallback* local não é ativado. - Nenhuma senha local divergente é criada. - Mensagem informativa é exibida ao usuário. #### Usuário bloqueado no provedor de autenticação Para usuários com *status* de bloqueio no Active Directory, o sistema executa validação específica e apresenta mensagem apropriada. ## Mensagens de Sistema e Tratamento de Erros A Segura™ Platform implementa sistema de mensagens de erro específicas para diferentes cenários de autenticação. ### Mensagens | Cenário | Mensagem | | --- | --- | | **Alteração de senha obrigatória** | O seu acesso foi temporariamente bloqueado pelo provedor de autenticação. Isso ocorre porque seu usuário foi configurado para alterar a senha no próximo *login*. Por favor, entre em contato com o administrador do sistema para realizar essa alteração. | | **Usuário bloqueado no AD** | O usuário informado está com acesso bloqueado ao provedor de autenticação. Entre em contato com o administrador do sistema para assistência imediata. | ## Auditoria A Segura™ Platform mantém registros detalhados de auditoria para todas as tentativas de autenticação bloqueadas, incluindo: - *Timestamp* da tentativa de login. - Identificação do usuário. - Motivo específico do bloqueio. - *Status* da conexão com AD. - Configuração do parâmetro de *fallback*. Estes *logs* permitem análise posterior e *troubleshooting* de problemas de autenticação. ## Como testar a autenticação de um servidor LDAP/AD 1. No relatório **Servidores LDAP/AD**, identifique o servidor que deseja testar a autenticação e, na coluna **Ações**, selecione a opção **Testar autenticação** no menu suspenso **Ações**. 2. No formulário **Teste de autenticação LDAP**, preencha os seguintes campos: 1. Na opção **Base DN**, preencha o valor da **Base DN**. Por exemplo: `CN=Users,DC=Segura,DC=com,DC=br`. 1. Por padrão, este campo vem preenchido com o DN base do servidor que foi selecionado anteriormente. 2. Se o usuário tiver alterado o valor do campo **Base DN**, para que a autenticação funcione, é necessário copiar este novo valor e alterá-lo no servidor. Esse passo é importante porque, caso o valor não seja modificado na edição, o valor que será utilizado na autenticação será o valor cadastrado originalmente. 3. Na opção **Usuário**, preencha o nome de usuário. Por exemplo:`johndoe`. 4. Na opção **Senha**, preencha a senha do usuário. 5. Clique em **Autenticar**. Uma mensagem será exibida abaixo dos campos, indicando se a autenticação foi bem-sucedida ou não. ## Solução de problemas comuns - **Problema**: o usuário não consegue acessar o sistema após configuração de alteração de senha obrigatória. - **Solução**: verificar se o parâmetro foi removido no Active Directory ou orientar o usuário a alterar a senha diretamente no AD. - **Problema**: mensagens de erro não aparecem na interface de *login*. - **Solução**: verificar a configuração de idioma do sistema e validar se os identificadores de mensagem estão corretamente implementados. - **Problema**: o sistema continua utilizando *fallback* local mesmo com parâmetro desabilitado. - **Solução**: confirmar a configuração do parâmetro "Desabilitar Fallback de Autenticação Local" e verificar *logs* de auditoria para identificar a causa específica.