Skip to main content

Configuring LDAP authentication

A supported MDM enrollment-authentication workflow can use fixed enrollment accounts or an LDAP directory, such as Active Directory, eDirectory, or Open Directory. This is optional unless your organization requires it; do not change an established policy just for an evaluation. Central’s LDAP connection and directory extraction are distinct from authentication and authorization at enrollment URLs. A successful Test Connection does not validate every LDAP setting or confirm that device enrollment has completed.
This reference concerns /usr/local/filewave/apache/conf/mdm_auth.conf on a self-managed FileWave Server. Have the Server owner confirm the supported release, enrollment route, and whether FileWave generates or manages the active file before considering a manual edit. Hosted FileWave customers must work with FileWave Technical Support; they do not have direct server file access and must not follow self-managed shell examples.

  1. Preserve the known-good configuration and agree on recovery access.
  2. Review a separate, narrowly scoped candidate against the installed build’s templates and active configuration.
  3. Use the owner-approved validation and activation procedure, then verify service health, enrollment cases that should be permitted or denied, and unaffected routes.

Getting the files ready

Initial review does not require a privileged shell. On new Debian Appliances, authorized administration uses fwadmin and sudo, not direct root login. For self-managed macOS, obtain the supported macOS procedure separately; Debian package evidence is not a macOS runtime test.

Keep credentials out of screenshots, chat, shell transcripts, and version control. Arrange any directory lookup account through the approved secret-handling process.

The historical examples below identify the configuration directory. They are for review only, not commands to run on a live Server.

cd /usr/local/filewave/apache/conf/

Before an approved change, preserve a uniquely named, protected copy of the active mdm_auth.conf, its ownership and permissions, and relevant included configuration. The historical fixed-name example below can overwrite an earlier backup; it is not a recovery plan.

cp mdm_auth.conf mdm_auth.conf.bac

Historical whole-file overwrite—review only; do not run. The next command replaces the active configuration with an example and can remove unrelated routes or generated settings. Instead, compare a separate candidate with the active file and preserve all unrelated controls. Confirm configuration ownership before editing.

cp mdm_auth.conf.example_ldap_auth mdm_auth.conf

Review the applicable template and route with the directory and Server owners. In the inspected FileWave 16.4.1 Debian amd64 Server package, static examples under /usr/local/filewave/apache/conf/ and parameterized LDAP templates under /usr/local/filewave/django/inventory/ldap/templates/ differ in route coverage and provider configuration. Neither is proof of the active Server policy.

Check the search base DN, login attribute, bind identity, secure directory transport and certificate trust, and intended authorization. Require valid-user permits authenticated users; it is not a group allowlist. Do not disable certificate verification. Apache’s provider is ldap; the older guide’s literal lda4 is a source mismatch. Do not silently correct it or describe the correction as tested. Preserve the applicable template’s authorization-header handling and unrelated enrollment routes.

Save the candidate separately, whether edited on or off the Server. Do not copy it over the active file until the owner has reviewed the diff, permissions, generated-file behavior, full-context syntax check, activation, and recovery plan.

Active Directory normally requires a bind account to read the directory. Use an owner-approved, least-privilege read account, not a directory administrator. Review HTTPS/TLS and certificate trust separately for the client-facing enrollment connection and for the directory connection.

Historical activation command—review only; do not run as a generic reload. In the inspected FileWave 16.4.1 Debian amd64 Server package, /usr/local/filewave/apache/bin/apachectl maps both restart and graceful to fw-server restartApache, which invokes a supervisor restart. The wrapper contains no configtest, -t, or generic argument pass-through. Apache’s generic script documentation does not establish a FileWave syntax check or a nondisruptive graceful reload.

Have the owner identify the supported executable and full configuration context for validation, the approved activation and service-health checks, and the exact procedure for restoring and reactivating the configuration on the installed release and OS. Stop if any of these is unknown. No command, authentication test, or enrollment was executed for this source review; no replacement command is implied.

/usr/local/filewave/apache/bin/apachectl graceful

Saving a file, activating configuration, passing authentication/authorization checks, and completing device enrollment are separate results. As part of an owner-approved lab plan, verify that one authorized device can complete enrollment, that an out-of-scope valid identity is denied, that the planned invalid-credential case fails, and that unaffected routes retain their policy. Follow the account-lockout policy; do not repeat failed logins or weaken controls. If checks fail, use the agreed recovery procedure. A Model Update is not an Apache reload.

Related Content

No comments to display

Back to top