Wiki: give importing people its own page
It was a section two-thirds of the way down LDAP-and-Active-Directory,
which is a page about signing in. Anybody sent that link had to read
about bind accounts and group gating before reaching their answer, and
the question people actually ask - "how do I import my AD users?" - was
not the title of anything.
Three pages, three jobs:
LDAP-and-Active-Directory signing in
Importing-People-from-a-Directory the how-to <- the one to send people
Directory-Sync the design record
The sign-in page keeps a short pointer explaining why importing exists
at all (the people who hold equipment are largely the people who never
log in), so the link is worth following rather than a bare cross-ref.
Expanded on the way: prerequisites, step-by-step with the tree and the
mapping test, the full table of what happens when somebody leaves or a
branch is renamed, the CLI for scheduling until that is built, and a
troubleshooting table keyed on what you actually see on screen.
All links verified to resolve; sidebar updated.
Directory sync: record what shipped, and the design note that was half right
Directory-Sync.md was a design record for something now built. §3.8, §3.9
and §3.11 say how each idea actually turned out, the slice table marks
what is done, and scheduling is named as the only outstanding piece.
§3.9 had warned that storing DNs breaks when an OU is renamed. It was
right, and incomplete: it only considered a renamed INCLUDE. A renamed
EXCLUDE is worse - the people you carved out silently start being
imported, and the sanity brake cannot see it because the brake only
guards against a sudden DROP. Both are now detected; the page says so,
says GUID self-healing was not built, and says why detection came first.
LDAP-and-Active-Directory.md had NO mention of importing at all, so
pointing at it as "the manual" would have been false and anyone reading
it would never learn the feature exists. Added the how-to: what comes
across, choosing branches, checking the mapping, previewing, and the
table of what happens when somebody leaves or a branch is renamed.
Every file path and wiki link in both pages verified to resolve.
Absorb the README's deep-dive content ahead of the README slim-down
The project README is being reduced to a landing page; every fact it
held that the wiki lacked is merged here first (615 lines across 33
pages): the full email-threading & reply-flow design onto Tickets,
directory layout + module-page pattern + file-locations reference onto
Architecture, per-endpoint tables onto API Reference, MFA login flow +
LDAP subsection + injection/audit notes onto Security, the icon library
and editor internals onto Network Mapper, Branding + landing-page and
help/search internals + debug-tool depth onto System, planned objects
onto CMDB, custody/locations/warranty onto Assets, and more.
Also corrects stale claims found during the audit: the Knowledge
audience table still said customer-visible articles had no reader
(the portal Knowledge section shipped), a pre-#903 Portal-Privacy
ambiguity row, the Workflows trigger-wiring section (catalogue spans
every module now), the superseded System module-access bullet, the
Multi-Tenancy users page marked "Planned" for a shipped feature,
and the locale count (21 languages incl. Ukrainian, not 20).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
LDAP wiki: login-decision flowchart, and every fix from a code audit
Adds the diagram that was missing: a mermaid flowchart of how the login decides
between local, directory and single sign-on — the two moments the decision
happens (leaving the first box, then pressing Sign in), all four outcomes
including the OIDC-pinned rejection, the group gate, and which directories get
tried for an unknown user.
Audited both pages against the code. Corrected:
FALSE
- "db_verify only ever ADDS columns, never MODIFYs" — true of the $schema
array, not of db_verify; there are seven probe-then-MODIFY precedents, two of
them added last week. The page then contradicted itself by documenting those
two. Replaced with the directional rule: relaxing is safe, tightening isn't.
- A dead line reference (db_verify.php:2614 — the file is 2557 lines) and the
wrong path for $schema (it lives in includes/db_verify_schema.php).
- "covered by an explicit unit-style assertion" — no such test existed. Rather
than soften the sentence, the test now exists (tests/ldap/), and the note
says to go and look before writing that phrase again.
- "an account with no email -> JIT must refuse cleanly" — it provisions them;
that is the whole point of #872/#902.
- "set default_modules so auto-created people aren't handed the keys" — they
were handed the keys. Now fixed in code (#904) and documented, including
that existing accounts are not retroactively restricted.
INCOMPLETE
- The two logins were described as identical. They differ in five ways; there
is now a table. Includes the wrinkle that the analyst lookup is by username
only, so an LDAP analyst typing their email takes the JIT branch.
- The immutable-ID promise omitted the DN fallback, which has exactly the
orphaning consequence the sentence says can't happen.
- The empty-login guard, the retained-secret-on-protocol-switch behaviour, the
LDAPS and phpldapadmin ports, NOCOMPLEXITY, and the OpenLDAP half of the
seeding (missing it produces trap 3's misleading error).
- w.noemail's NW-Sales membership, which is what makes the portal journey
testable at all.
LDAP wiki: portal directory sign-in, and staff with no mailbox
LDAP-and-Active-Directory said a directory account with no email "cannot be
auto-created" — false since #872 for analysts, and false for the portal since
#902. Replaced with a section covering what actually happens for mailbox-less
staff: username sign-in, company from the provider, name-not-address in the
inbox, notes instead of replies, and the multi-company username limit.
Developer guide gains a Portal directory sign-in section: why the candidate
provider list is SCOPED (spraying a password across every client's DC, and
AD lockout counters, are invisible at N=1), the three deliberate divergences
in ldapResolveUser (NULL not '', claim-don't-refuse, company from provider),
why both groups may use the portal, the schema table, and the two things that
broke elsewhere — the privacy policy failing open on a blank address, and
reply having no address validation at all.
Known-gaps list updated: the portal item is done; the multi-company bare
username limit takes its place.
Add "Setting up OpenLDAP & Samba AD in Docker" walkthrough
A copy-paste guide from nothing to a working LDAP login, mirroring the
Keycloak (Docker) page for SSO: run both directories, seed Samba AD with a
realistic company (nested OUs, a no-email account, a disabled leaver, nested
groups), grant the OpenLDAP ACL that everyone trips over, configure the
provider, and test the group gate with four correct passwords that produce
four different outcomes.
Linked from the sidebar and cross-linked from both LDAP pages.
Add LDAP & Active Directory pages (feature + developer guide)
Covers the LDAP sign-in shipped for issue #47: the admin-facing guide
(setup, group-based access, troubleshooting) and the developer deep-dive
(architecture, schema, the two-step bind, the traps, the Docker test rigs).
Both linked from the sidebar under Single Sign-On.