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

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

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

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.