Directory-Based Access
Managed on-prem deployments can connect Lumetry to an existing LDAP or Active Directory service. Directory users continue to authenticate through the configured identity service, while Lumetry access follows membership in existing directory groups.
How It Works
An administrator configures a read-only directory connection from User Management >
Directory connection and tests the connection. To grant access, the administrator opens
User Management > Directory groups, enters the group's full distinguished name (DN),
and binds it to one of Lumetry's fixed roles, such as Admin, Operator, or Viewer.
An optional display name makes the mapping easier to recognize. Lumetry shows only groups
that have been mapped to roles instead of loading the full enterprise group catalog into
the screen. Existing bindings can be edited to change their DN, display name, or role.
The Directory section is shown only when directory management is enabled by the on-prem deployment operator. It is not available in Lumetry SaaS.
For example, mapping an existing LumetryAdmins group to Admin gives members the Admin
role after their next sign-in. No per-user role assignment is required in Lumetry.
For Active Directory, bind roles to the direct groups that should grant access. Nested group
inheritance is not assumed for access decisions.
When the directory provides a profile photo, Lumetry displays it in the signed-in user's header badge. If no photo is available or it cannot be loaded, the standard badge remains.
Field Mapping
Use the directory team's values for the search bases and bind account. For standard Active Directory deployments, Lumetry expects these defaults unless the directory team provides a different schema:
| Directory concept | Typical Active Directory value |
|---|---|
| Login attribute | sAMAccountName |
| User object classes | person, organizationalPerson, user |
| User filter | (!(objectClass=computer)) |
| Group membership attribute | memberOf |
Role Sources
The Users list shows manual Lumetry assignments and deployment membership records. It does not expand LDAP/AD group members, because that can force slow directory-backed reads through the identity service. Directory-derived access is granted during sign-in/token issuance from the mapped directory group. Add or remove the user from the source directory group to change that access.
Security Behavior
- Directory federation is read-only; Lumetry does not write users or groups back.
- Lumetry sends configuration and management requests to the deployment's identity service; the identity service performs LDAP connection tests and authentication.
- Lumetry does not browse, synchronize, or import the directory group tree from the role-mapping screen.
- The bind password is write-only and is never returned by the Lumetry API.
- Group distinguished names are matched case-insensitively against the user's direct group memberships.
- Group mappings remain aligned when a Lumetry role's permission set changes.
- Administrators can map only permissions they are themselves allowed to grant.
- Removing the directory connection does not delete saved group mappings; remove obsolete mappings separately.
This capability is intended for a single-organization managed deployment. Shared SaaS directory mapping is not supported by this model.