# LDAP
Flopsar can authenticate operators against an external LDAP directory (for example Microsoft Active Directory) in addition to local accounts. When LDAP is enabled, sign-in uses a **bind → search → bind** flow: the server binds with a service account, searches for the user entry, then re-binds as that user with the supplied password to verify the credentials. A user who logs in for the first time is provisioned automatically with the built-in **Guest** role.
Local accounts always take precedence: if a username matches a local account, that account is used and LDAP is not consulted.
## Connection modes
The transport is controlled by two switches — **Use SSL/TLS** and **Skip Certificate Verification** — which combine into three meaningful modes. The **Server URL** field holds only the host (and optional port), e.g. `192.168.1.198` or `dc01.win.local:636`; the `ldap://` or `ldaps://` scheme is derived automatically from the SSL switch (default ports 389 for LDAP, 636 for LDAPS).
### 1. No SSL — plaintext LDAP
*Use SSL/TLS off.*
The server connects over `ldap://`. The bind DN, bind password, user search, and the user's own password all travel **in clear text** over the network. The Skip Verify switch and the CA Certificate field have no effect in this mode.
Use this only on an isolated, fully trusted segment (for example a localhost or back-to-back link). It is not appropriate for production directory traffic.
### 2. SSL with verification skipped
*Use SSL/TLS on, Skip Certificate Verification on.*
The server connects over `ldaps://`, so the channel is **encrypted**, but the directory's certificate is **not validated** — any certificate, including a self-signed or mismatched one, is accepted. This protects against passive eavesdropping but **not against an active man-in-the-middle** attacker who can present a forged certificate.
Use it only as a temporary measure while bootstrapping, or in lab environments. The interface flags it as "Not recommended for production."
### 3. SSL with verification (recommended)
*Use SSL/TLS on, Skip Certificate Verification off.*
The server connects over `ldaps://` and **validates the directory's certificate** against a trust store. The trust store is built from the operating system's native CA certificates, plus any certificate you paste into the **CA Certificate (PEM)** field.
* If your directory's certificate chains up to a publicly trusted or OS-installed CA, you can leave the CA Certificate field empty.
* If your directory uses an **internal/enterprise CA** that is not in the host trust store, paste that CA certificate (PEM) into the field so the chain can be verified. See *Obtaining the CA certificate* below.
This is the recommended mode for production: it provides both confidentiality and authentication of the directory server.
## Required settings
The following fields make up a working configuration (values shown match a typical Active Directory setup):
**Connection**
* **Server URL** — directory host, optionally with port, without a scheme. Example: `192.168.1.198`.
* **Bind DN** — distinguished name of the service account used for the initial bind and user search. Example: `CN=Jan Kowalski,OU=AppUsers,DC=win,DC=local`. Active Directory also accepts a `userPrincipalName` (e.g. `svc-flopsar@win.local`) or `DOMAIN\user` form.
* **Bind Password** — password for the service account.
* **Use SSL/TLS**, **Skip Certificate Verification**, **CA Certificate (PEM)** — the transport settings described under *Connection modes*.
**Users**
* **User Base DN** — subtree searched for user entries. Example: `DC=win,DC=local`.
* **User UID Attribute** — attribute matched against the login name. For Active Directory this is typically `sAMAccountName`; for generic LDAP it is often `uid`.
* **User Filter** — optional additional filter, ANDed with the UID match. Leave empty to match on the UID attribute alone. When set, the effective filter is `(&(=))`. The service account needs only enough directory rights to bind and to read user entries under the base DN.
## Obtaining the CA certificate
The **CA Certificate (PEM)** field expects the **PEM-encoded certificate of the authority that issued your directory's TLS certificate** (your AD Certificate Services root, or its issuing CA) — not the domain controller's own (leaf) certificate. A PEM certificate is a text block delimited by `-----BEGIN CERTIFICATE-----` and `-----END CERTIFICATE-----`.
How to obtain this certificate depends on how your directory and its CA are set up, so there is no single universal command. Ask your directory or PKI administrator for the CA certificate, or follow the export procedure in your directory vendor's documentation (for example, the documentation for your Active Directory / AD Certificate Services deployment). Request it in PEM format; if you receive a DER/`.cer` file, your administrator can convert it to PEM.
Once you have the PEM text, paste it into the **CA Certificate (PEM)** field, keep *Use SSL/TLS* on and *Skip Certificate Verification* off, then confirm with **Test Login**.
## Testing the configuration
Three test actions let you validate settings incrementally, in increasing order of coverage. All of them honor the current SSL / Skip Verify / CA Certificate settings, so they exercise exactly the same transport that live sign-in will use.
* Test Connection — binds with the Server URL, Bind DN, and Bind Password. Confirms that the host is reachable, the TLS settings are correct, and the service-account credentials are valid. It does not search for any user.
* Test Query — performs the bind and then searches the User Base DN with your User UID Attribute and User Filter, returning the number of matching users. Use it to confirm that the base DN, UID attribute, and filter resolve to the expected set of accounts.
* Test Login — runs the full end-to-end flow: service-account bind, search for a specific username, then bind as that user with the supplied password. This is the definitive check that a real user can authenticate. Enter a sample user's credentials in the dialog.
{% hint style="info" %}
The **Query Users** action is available only after the configuration has been saved **with Enable LDAP turned on** (it is hidden while you are editing and when LDAP is disabled). It lists matching directory users (common name, login, DN) so you can add them to Flopsar directly.
{% endhint %}
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.flopsar.com/7/administrator-guide/ldap.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.