LDAP Write Operations

LDAP Write Operations#

GLAuth exposes the standard LDAP write operations — Add, Modify, and Delete — via its Handler interface , but all built-in backends deliberately reject every write request by returning ldap.LDAPResultInsufficientAccessRights. There is no pathway through which a client can mutate the directory tree via the LDAP protocol itself.

Affected Backends#

Every first-party backend stubs out writes in exactly the same way:

Backend	File	Add	Modify	Delete
config (static file)	`config.go`	✗	✗	✗
ldap (proxy)	`ldap.go`	✗	✗	✗
SQL (SQLite/MySQL/Postgres)	`basesqlhandler.go`	✗	✗	✗

Each method immediately returns ldap.LDAPResultInsufficientAccessRights, nil with no body logic — the comments in the source read "not yet supported" or "not supported for a static config file."

Write Routing in the Server#

server.go registers only BindFunc, SearchFunc, and CloseFunc on the underlying ldap.Server. Add, Modify, and Delete function registrations are absent — meaning the server framework itself never dispatches those operations to a handler. Even if a backend were to implement them, the server would need to be updated to register those routes.

SQL Backends: Live Reads Without Writes via LDAP#

Although LDAP writes are blocked, SQL-backed deployments (SQLite, MySQL, Postgres) do reflect database changes in real time. The databaseHandler queries the database on every Search request — there is no in-memory cache that needs invalidation and no restart is required. Operators can mutate users or groups directly in the SQL database; the next LDAP query will return updated data immediately.

This is the intended workflow for managing entries in SQL-backed GLAuth: use the database directly (or a management tool on top of it), not LDAP write operations.

Implications for Plugin Authors#

If a custom backend plugin needs to support write operations, it must:

Implement Add, Modify, and Delete on its handler.Handler with real logic instead of the stub return.
Register the corresponding AddFunc, ModifyFunc, and DeleteFunc routes in server.go — none are currently wired.

Until both steps are done, any LDAP write directed at a plugin backend will still be rejected at the server routing layer.