---
title: "How to manage LDAP/AD servers"
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.

# How to manage LDAP/AD servers

Registering an Active Directory (AD) server in Segura™ Platform is an essential procedure for integrating and efficiently managing an organization’s IT infrastructure. Active Directory is a widely used solution for identity and access management in corporate networks, enabling centralized authentication and authorization of users and devices.

This document provides information on how to manage Active Directory–type servers in Segura™ Platform, including new mechanisms for authentication locking and local fallback control.

## Requirements

- Hold **PAM administrator** role

## Register/Edit a new AD server

1. On Segura™ Platform, hover over the Products menu in the navigation bar and select **Settings**.
2. In the side menu, go to **Provisioning > Active Directory > Servers**.
3. In the **Servers** form, you will see a list with all servers registered in your Segura™ Platform instance. To register a new server, click **Add** and follow the on-screen steps.

### Domain, Device, and Credential tab

          Warning

          

Both the domain and the credential must be registered before the AD server.

1. In the **Domain** dropdown, select your AD server’s domain.
2. In the **Authentication credential** dropdown, select the credential to be used for authentication on the AD server.
3. Click **Continue**.

### LDAP tab

          Warning

          

The account form must be created beforehand.

          Info

          

The order in which servers are configured defines the authentication sequence in Segura™ Platform. When multiple servers are set up, the system will attempt to authenticate the user following the established order, trying each server until authentication succeeds. For example, if servers A, B, and C are configured in this order and a user exists only in server C, Segura™ Platform will attempt authentication on A, then B, and finally authenticate on C.

1. In the **Host** field, fill in the AD server’s host name.
2. In the **Port** field, fill in the port number where the AD server is listening.
3. In the Base **DN** field, fill in the AD server’s *Distinguished Name Base*. This is the starting point from which the system will search for objects and set the scope for LDAP searches within the AD hierarchy. For example, for the domain `example.com` , the **Base DN** would be `DC=example,DC=com`.
4. In the **Account form** dropdown, select the account form you want to use for this server. This form allows administrators to configure and standardize user accounts and permissions suitable for the AD environment. Typically, when using AD, the Principal option is most common.
5. In the **Order** selector, choose the server order for authentication attempts.
6. In the **Active** option, enable the switch so that the server is registered in Segura™ Platform as active. By default, this option is enabled.
7. In the **Is member a DN?** option, enable the toggle if the user is identified by their DN.
8. In the **Bind requires DN?** option, enable the toggle if the binding process needs to use the DN. This setting is necessary when a user is located in a different place from the base DN.
9. In the **Use SSL?** option, enable the toggle to use the SSL protocol. By default, this option is disabled.
10. In the **Network connector** dropdown menu, select which connector will be used with the LDAP server. This additional step is required if your infrastructure uses a network connector. In this case, select the connector from the dropdown menu.
11. In the Account filter format option, specify the search criteria to restrict the object results. For example: `(&(objectClass=user)(sAMAccountName=johndoe)).`
  1. In this case, the fields are:
    1. `objectClass=user`: indicates that the user type must be *user*.
    2. `sAMAccountName=johndoe`: the SAM (*Security Account Manager*) identifier for the user account must be `johndoe`.
12. In the **Use credential domain** option, enable the toggle to use a domain credential. By default, this option is disabled.
13. Use the **Username attribute** option only when the username attribute is different from the default. By default, this attribute is `sAMAccountName`.
14. In the **Bind DN (leave blank to use the Base DN)** field, enter the DN to be used as a unique identifier. For example: `CN=John Doe,OU=Users,DC=Segura,DC=com`.
15. In the **Group** option, enter the account's group.
16. In the **Group DN** option, enter the group's DN.
17. In the **Group attribute (GroupAttr)** option, fill in the group attributes.
18. In the **Group scope** option, specify the group scope.
19. In the **Group filter** option, enter a filter expression for the group. For example: `(objectClass=group)`, which will return all objects of type group in the LDAP/AD server.
20. In the **Member attribute (MemberAttr)** option, enter the attributes of the group members.
21. Click **Continue**.

At the end of the process, review your AD server information and, if everything is correct, click **Save**.

## Authentication control and local fallback

Segura™ Platform implements advanced authentication control mechanisms that ensure consistency between the Active Directory and the local system, preventing password divergence and unintended behaviors.

### "Disable Local Authentication Fallback" parameter configuration

Segura™ Platform provides the **Disable Local Authentication Fallback** parameter, which, when enabled, prevents Segura™ Platform from using local authentication if AD authentication encounters specific blocking conditions.

### Authentication Validation Flow

During the login process, the system performs the following sequential checks:

1. **Connectivity check:** ensures the connection with the AD server is active and functional.
2. **User parameter analysis:** checks if the user has special settings in AD, including:
  - "Change password at next login" parameter.
  - Account lock status.
3. **Fallback configuration validation:** confirms the status of the "Disable Local Authentication Fallback" parameter.

### Authentication Blocking Scenarios

#### Mandatory password change at next login

When a user has the "change password at next login" parameter enabled in Active Directory, the system operates as follows:

**Activation conditions**

- Active AD connection.
- "Disable Local Authentication Fallback" parameter enabled.
- User configured for mandatory password change.

**System behavior**

- Access to Segura™ Platform is proactively blocked.
- The local fallback mechanism is not activated.
- No divergent local password is created.
- An informational message is displayed to the user.

#### User blocked in the authentication provider

For users with a blocked status in Active Directory, the system performs specific validation and displays an appropriate message.

## System messages and error handling

Segura™ Platform implements specific error messages for different authentication scenarios.

### Messages

| Scenario | Message |
| --- | --- |
| **Mandatory password change** | Your access has been temporarily blocked by the authentication provider. This happens because your user account is configured to change the password on the next login. Please contact your system administrator to perform this change. |
| **User blocked in AD** | The specified user is currently blocked by the authentication provider. Please contact your system administrator for immediate assistance |

## Audit

Segura™ Platform maintains detailed audit logs for all blocked authentication attempts, including:

- Timestamp of the login attempt.
- User identification.
- Specific reason for the block.
- AD connection status.
- Fallback parameter configuration.

These logs allow for further analysis and troubleshooting of authentication issues.

## How to test authentication for an LDAP/AD server

1. In the **LDAP/AD Servers** report, identify the server you want to test and, in the **Actions** column, select the **Test authentication** option in the **Actions** dropdown menu.
2. In the **LDAP Authentication Test** form, fill in the following fields:
  1. In the **Base DN** option, fill in the **Base DN** value. For example: `CN=Users,DC=Segura,DC=com,DC=br`.
    1. By default, this field comes pre-filled with the base DN of the server previously selected.
    2. If you have modified the **Base DN** field, to ensure authentication works, you must copy this new value and update it in the server settings. This step is important because, if not changed in editing, the value used for authentication will be the originally registered value.
3. In the **Username** option, enter the username. For example: `johndoe`.
4. In the **Password** option, enter the user's password.
5. Click **Authenticate**.

A message will be displayed below the fields indicating whether authentication was successful.

## Troubleshooting common issues

- **Issue:** The user cannot access the system after the mandatory password change configuration is set.
  - **Solution:** Verify if the parameter has been removed in Active Directory or instruct the user to change their password directly in AD.
- **Issue:** Error messages do not appear in the login interface.
  - **Solution:** Check the system’s language settings and ensure message identifiers are correctly implemented.
- **Issue:** The system continues to use local fallback even with the parameter disabled.
  - **Solution:** Confirm the setting of the "Disable Local Authentication Fallback" parameter and check audit logs to identify the specific cause.