Active Directory and LDAP
Authenticate XPLG console users against Active Directory or another LDAP directory: the provider URL, manager and search settings, verifying that groups are retrieved, and mapping directory groups to XPLG groups and policies.
What you will do: point the console at your directory, prove that it authenticates a user and retrieves the user's groups, then give those groups policies and permissions.
Active Directory / LDAP is the direct-authentication baseline: the directory validates the password, XPLG retrieves the user's group membership at sign-in and maps it to its own groups and policies automatically, and every match is written to the audit log. XPLG stores no directory credentials; MFA is enforced at the identity provider for the federated methods (SAML, OAuth).
Steps
- Open PortX > Settings > System Settings > Security, add Active Directory / LDAP to the Selected Types (the top entry is the primary type when several are selected) and open its configuration link.
- Fill in the settings:
| Setting | Value |
|---|---|
| Provider URL | ldap://<server>:389/ or, secured, ldaps://<server>:636/; several servers separated by a space |
| Manager Path / Manager password (optional) | The distinguished name and password of an account allowed to search the directory, for example CN=<user>,OU=Users,DC=example,DC=local |
| Root path | Where the user search starts; [ALL DOMAINS] to search users across several domains |
| Search filter | sAMAccountName={0} — {0} is replaced with the username |
| User path | <USER_DOMAIN>\{0}; several domains as a semicolon-separated list <DOMAIN_1>\{0};<DOMAIN_2>\{0} (for a generic LDAP directory, the user DN pattern such as uid={0},ou=people,cn=xplg) |
| Unique id attribute | sAMAccountName |
| Display name attribute | displayName |
| Groups attribute | memberOf |
| Group id pattern, Initial context factory | Further settings; leave the defaults unless your directory needs them |
- Save, sign out and sign in with a directory account. A successful sign-in proves authentication.
- Prove group retrieval: open the audit log and look for "get the following groups" after that sign-in; the list that follows is what XPLG received from the directory.
- Create the groups: under Security > Groups add a group with exactly the name of each directory group you want to authorise, assign it a policy (otherwise the default policy applies) and leave it without members — see Groups.
- Grant permissions to those groups on the folders, logs and applications they should see, and remove the All group from the top-level folders — see Folder, log, app and AppTag permissions.
The console reaches the directory on 389 or 636 outbound; see Networking and ports.
Related methods
- Kerberos. The security specification lists LDAP and Kerberos protocol support at the product layer; the wiki has no configuration page for Kerberos — the steps are pending from XPLG engineering.
- Azure AD / Entra ID. The wiki's Azure Active Directory page describes collecting Office 365 and Azure AD audit logs through an Enterprise Application, not signing in; for sign-in with Entra ID use SAML 2.0 — see SAML, OAuth and SSO gateways.
- A proxy that authenticates against AD and forwards the username in a header is the header-based SSO method on the same page.
Next: SAML, OAuth and SSO gateways
Source: XPLG wiki, pages 1594133404, 1594133402, 1594133513, 3161718811, 3161489438, 1702690910, 1595408328 (https://xpolog.atlassian.net/wiki/spaces/XPOL/pages/1594133404). Pending from XPLG engineering: the Kerberos configuration steps.
