- New GitHub Actions workflow: builds the real Dockerfile.openldap
image, starts it, seeds the LDAP fixtures the test suite expects
(uid 'test' + 'wmantly', matching the existing "wmantly is always
present in the test LDAP" assumption in several test files), then
runs the full Jest suite against it on Node 18/20/22. This repo
previously had unit tests but no automated workflow running them.
- Found while building this: the bundled default ppolicy entry
(docker-entrypoint.sh + ops/ldap-setup.sh) sets pwdLockout: FALSE,
which is backwards -- it silently makes the admin "deactivate user"
action a no-op for auto-lockout-after-failed-attempts (a related
but distinct ppolicy feature from pwdAccountLockedTime). Fixed to
TRUE in both places; ldap-setup.sh also gets a drift-correction
path so an existing deployment can pick up the fix by re-running it.
- Separately, deactivating a user still doesn't block their LDAP bind
in the bundled image even with this fix -- filed as #68, since it's
a deeper OpenLDAP ppolicy overlay question unrelated to the CI/test
setup here. tests/user_admin.test.js now soft-skips that specific
assertion (with a console warning pointing at #68) instead of
failing, so this known environment gap doesn't block CI.
ops/backup.sh snapshots LDAP (slapcat), Redis (BGSAVE, dynamic RDB path
lookup), and ./config for standalone deployments, with retention. A
background service polls GitHub releases every 24h and surfaces an
admin-only banner in the UI when a newer version is published.
The Integrations page's Service Accounts (bind-only, organizationalRole)
don't cover the other real use case: an account something actually runs
as on a Linux host -- a media manager, a torrent client, Emby -- with a
real uidNumber/gidNumber that owns files, and a group other accounts
join for write access (e.g. a `stuff_manager` group granting write
rights to a media library). That needs a real posixAccount, which the
bind-only model can't be.
- New well-known group `app_sso_service_account`, seeded the same way as
app_sso_admin/app_sso_invite/app_sso_oauth_admin (docker-entrypoint.sh,
ops/ldap-setup.sh). Not a permission gate -- a marker.
- "Add new user" form gets a "This is a service account" checkbox: swaps
the person-shaped fields (first/last name, birthday, ToS agreement)
for a single account-name field, since none of those make sense for a
non-person account. On create, the route adds the user to
app_sso_service_account.
- User.listDetail() annotates each user with isServiceAccount (checked
against the marker group's member list once per call, not the memberof
overlay's reverse attribute -- not reliably returned by every LDAP
server this app might point at, confirmed against a real external
directory during testing). Users page shows a "service" badge.
- Notification broadcasts (filter_type=all/all_active) exclude service
accounts by default -- nobody reads mail as `stuff_manager`.
- Fixed a real, previously-unrelated bug this surfaced: addPosixAccount
unconditionally set `mail: data.mail` in the LDAP entry even when
undefined, and ldapts/slapd reject an attribute given an explicit
undefined value ("no values for attribute type") rather than treating
it as absent. This meant creating ANY user without an email already
failed outright -- not something a service account (which commonly has
no real mailbox) could route around. Made mail conditional, matching
how mobile/sshPublicKey/dob already work.
- docs/ldap.md now explains both kinds of service account side by side
and when to use which.
Verified end-to-end against a real external LDAP server (not a local
sandbox): created a service account with no email, confirmed it's
correctly flagged and excluded from broadcast recipient resolution,
confirmed a normal user is unaffected, confirmed the code degrades
gracefully if the marker group doesn't exist yet (pre-upgrade
deployments).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The SSO app (nodejs/models/user_ldap.js addPosixAccount) tags every new user
with objectClasses [inetOrgPerson, sudoRole, ldapPublicKey, posixAccount, top,
theta42Person] and writes sudoHost/sudoCommand/sudoUser + sshPublicKey. The
all-in-one image's slapd.conf only included core/cosine/inetorgperson/nis +
theta42, so creating a user failed: sudoRole and ldapPublicKey were unknown
objectClasses (LDAP objectClassViolation 65) and sudoHost/sudoCommand/sudoUser
and sshPublicKey were unknown attributes.
Ship the two missing schemas and include them in slapd.conf:
- ops/schema/sudo.schema (sudoRole + sudo* attributes)
- ops/schema/openssh-lpk.schema (sshPublicKey + ldapPublicKey)
sudoRole is AUXILIARY here, not STRUCTURAL as in upstream sudo. The app
attaches sudoRole directly onto the user entry, which is already inetOrgPerson
(STRUCTURAL); two unrelated structural classes violate RFC 4512 and OpenLDAP
rejects with 65. AUXILIARY lets it coexist with inetOrgPerson — the app's
per-user-sudoers model. sudo's LDAP backend still finds entries via
(objectClass=sudoRole) regardless. ldapPublicKey is AUXILIARY as in upstream
openssh-lpk.
Also fix the build error from the previous theta42 schema PR: .dockerignore
excluded all of ops/, so 'COPY ops/schema/theta42.schema' failed at build
time ('not found' — file is git-tracked but stripped from the context). Re-
include ops/schema/*.schema with !exceptions, matching the existing
README.md/tos.md pattern.
Co-Authored-By: Claude <noreply@anthropic.com>
The app (nodejs/models/user_ldap.js) adds objectClass theta42Person whenever a
user has a dateOfBirth, and lists it among every new user's objectClasses. But
the all-in-one image's static slapd.conf only included core/cosine/inetorgperson/
nis — never the project's own theta42 schema — so slapd rejects
objectClass: theta42Person with LDAP 0x15 (objectClass: value #0 invalid per
syntax). Symptom: PUT /api/user/<uid> (and user creation) failing.
ops/ldap-setup.sh loads this schema for bare-metal (as a cn=config LDIF); the
Docker image uses slapd.conf, so ship it as a .schema file and include it.
- ops/schema/theta42.schema: dateOfBirth attribute + theta42Person auxiliary
objectClass (same OIDs/definition as ldap-setup.sh section 5).
- Dockerfile.openldap: COPY it to /etc/openldap/schema/theta42.schema.
- docker-entrypoint.sh: include it in the generated slapd.conf (after nis).
Co-Authored-By: Claude <noreply@anthropic.com>
wmantly