Purpose
This guide explains how to connect Logsign USO to Active Directory over LDAP so that directory users can log in to Logsign with their domain username and password. You create an LDAP integration, sync the directory users into Logsign and assign a role to the users who should have access. When one of these users logs in, Logsign checks the password by binding to the directory as that user.
The same LDAP integration is also used for identity enrichment and as a Response integration (see Available Response Methods below).
For cloud directories, see Microsoft Entra ID SSO Login Configuration or Google Workspace SSO Login Configuration.
How the Login Works
- The user opens Logsign, types their username (the sAMAccountName, for example
jane.doe) and clicks Next, then enters their domain password. - Logsign binds to the domain controller configured on the LDAP integration as
<username>@<domain>, where the domain is built from theDC=parts of the Base DN. For Base DNOU=Staff,DC=corp,DC=examplethe bind name isjane.doe@corp.example. - If the bind succeeds and the user is found under the Base DN, the login succeeds. If Logsign two-factor authentication is enabled for that user, the 2FA step follows. The dashboard then opens.
A wrong password counts toward the Active Directory lockout policy, and also toward the Logsign lockout policy when user locking is enabled in the Logsign password policy.
Prerequisites
| Item | Requirement |
|---|---|
| Network from Logsign | Every Logsign node must reach the domain controller on TCP 389 (LDAP) or TCP 636 (LDAPS). |
| Service account | A domain account used for the identity sync. It only needs to read user objects under the Base DN; an ordinary domain user account is enough, and a Domain Admin is not required. For the Response methods that change accounts (disable, enable, unlock, reset password, group membership), the account additionally needs those rights delegated on the relevant OU. |
| Base DN | Must contain the DC= components of the users' domain, because the login bind name is built from them. |
Step 1: Create the LDAP Integration
-
Go to Settings > Integrations > Responses, search for LDAP, click Configure and click +Device.
- Fill in the fields below, click Test, and when the test succeeds click Create.
| Field | Required | Description |
|---|---|---|
| Server | Yes | Host name or IP address of the domain controller, without a scheme. Correct: dc01.corp.example. Wrong: ldap://dc01.corp.example. |
| Port | No | 389 for LDAP, 636 for LDAPS. Defaults to 389 when empty. |
| Use Ssl | Yes | Tick to connect with LDAPS. Recommended, because the users' passwords travel to the domain controller at login. |
| BaseDN | Yes | Where to search for users, for example DC=corp,DC=example for the whole domain or OU=Staff,DC=corp,DC=example for one OU. |
| Username | Yes | The service account used for the identity sync. |
| Password | Yes | The service account password. Stored encrypted by Logsign. |
| Sync Interval | No | How often identities are synced automatically: 1, 2, 4, 6 or 12 hours. Left empty or set to 24, the sync runs once a day at 02:00. |
Step 2: Add the Users to Logsign
-
Go to Settings > Enrichment > Identities, click Sync Ldap, select the LDAP integration and click Sync. All users under the Base DN are listed.
- Select the users who should have access and click Apply Role Selected.
-
In the Add Logsign User window choose the role and save.
The users now appear under Settings > Accounts and Views > Users with the ldap tag and can log in with their domain credentials.
Manual sync always works regardless of the Sync Interval, and a failure in one source does not stop the others from syncing.
Behavior to Be Aware Of
- Only users added in Step 2 can log in. Syncing alone does not grant access.
- The password is checked by the domain controller at every login. Logsign does not store it.
- Disabling or locking a user in Active Directory stops their next login. Disabling the user in Logsign also blocks them regardless of Active Directory.
Troubleshooting
| Symptom | Likely cause | What to check |
|---|---|---|
| Test fails when creating the integration | Logsign cannot reach the domain controller, the port or Use Ssl setting does not match, or the service account credentials are wrong. | Firewall on 389 or 636, the Port and Use Ssl pair, and the service account. |
| Sync returns no users or fewer than expected | The Base DN points to the wrong OU, or the directory limits the page size. | The Base DN. For large directories see LDAP Page Size Limit Changes. |
| "Authentication Failed" with the correct password | The Base DN does not contain the DC= components of the user's domain, so the bind name is wrong; or the user is outside the Base DN; or the user was not added in Step 2. |
That the Base DN includes DC= parts matching the user's domain, and that the user is listed under Settings > Accounts and Views > Users. |
| "Authentication Failed" for a user in a child or trusted domain | The bind name is built from this integration's Base DN only. | Create a separate LDAP integration for that domain and add its users from there. |
| User is locked out | Too many wrong passwords under the Logsign or Active Directory lockout policy. | Unlock in Active Directory or in Logsign, depending on where the lock is. |
Available Response Methods
The LDAP device can also be used as a Response integration under Settings > Integrations > Responses > LDAP, from an Action Rule or manually from an incident. The available methods are:
- list-users and search-users: list or search directory users.
- disable and enable: disable or re-enable a user account. This is the method used in account-compromise response scenarios.
- unlock-user: clears a locked-out account without changing its password.
- reset-password: forces a password reset for a user.
- add-user-to-group and remove-user-from-group: manage group membership.
The service account needs the matching rights in Active Directory for each method that changes an account. Test these methods in a non-production OU first.