BEFORE YOU BEGIN
Check before you begin
This guide describes inspected source behavior and open acceptance requirements; it does not establish production-enforced MFA, validated directory TLS or security acceptance for every sign-in path. Enablement and organizational cutover require controlled tests on a release with the gaps resolved.
Visual/action limit: no real LDAP or OTP screen was captured in this inspection; another workflow’s screenshot was not substituted. Content is based on local LDAP/signin/verify_otp/send_2fa_email source review. No bind, user import, password entry, OTP generation/email delivery or authentication-setting change was performed.
- Installed release and local/external sign-in path
- Tenant/parent and approved test account
- CA/TLS, credentials and protected logging
- Success, failure, exception and access-loss acceptance
011. Separate integration purpose and identity source
LDAP/Active Directory sign-in, AD backup/object recovery and Keystone federation are separate flows. Record domain, directory server, company/tenant, parent admin and test-user scope. This guide does not deploy a domain controller or back up AD data.
Expected resultIdentity flow and relevant acceptance results are recorded.
022. Validate DNS, networking and trusted TLS
With the directory administrator check server DNS, port, time and CA trust. The inspected bind helper uses SSL on 636 and has an optional StartTLS branch; selecting a port does not establish verified TLS. The source copy defaults insecure_skip_verify=True, so production certificate-validation acceptance is not established; complete trusted CA/hostname validation with the technical team before production cutover.
Expected resultIdentity flow and relevant acceptance results are recorded.
033. Prepare the bind identity and search scope
Define an approved bind identity with sufficient directory-read access and the required OU/base DN scope; do not default to a domain-admin account. The inspected discovery can use base_dn or configured ou_paths/base_dn and applies result limits. Do not assume a full-directory import or automatic nested-group resolution. The user should enter the password through the protected operator flow.
Expected resultIdentity flow and relevant acceptance results are recorded.
044. Review LDAP settings under the correct tenant
In the installed user/LDAP management screen compare domain_name, server_address, port and bind identity. Check association with company/tenant and parent admin. Record current sign-in and emergency-access plans before changing enabled state. Saving settings does not itself establish successful bind, discovery or user authorization.
Expected resultIdentity flow and relevant acceptance results are recorded.
055. Validate the selected directory user and local mapping
The inspected add_ldap_user associates a selected username and role with the configured LDAP record; it does not create an AD user. Sign-in uses the enabled LDAP user record, bind result and tenant/parent mapping. With an existing LDAP user and failed bind, it does not fall back locally; a missing/disabled record may fall back through the inspected normal signin path. Do not assume this matches the organization’s policy.
Expected resultIdentity flow and relevant acceptance results are recorded.
066. Accept sign-in and authorization boundaries with a test account
Using an approved test account check tenant, role/group, storage and resource visibility. Assess wrong-password, disabled-record, unreachable-directory and CA-error scenarios in a controlled lab plan without locking real accounts. The inspected successful LDAP path can return directly after login, so test 2FA enforcement separately. Menu visibility is not endpoint authorization.
Expected resultIdentity flow and relevant acceptance results are recorded.
077. Plan disablement and access reviews
Track AD accounts, LDAP settings/user records and resulting local-account lifecycles separately. Automatic termination of existing sessions after AD disablement/deletion was not verified in this inspection. Test synchronization, logout/revocation and emergency access against the installed release. No LDAP record, password, user or domain setting was changed here.
Expected resultIdentity flow and relevant acceptance results are recorded.
COMMON QUESTIONS
Does LDAP integration enforce MFA?
Not by itself. Directory bind, local/external sign-in, OTP enforcement and session access need separate acceptance; test every sign-in path.