ZimaOS does not currently document native LDAP or Active Directory authentication for its owner/member accounts or Samba shares. The supported multi-user model remains local ZimaOS member accounts with per-share permissions.
The source thread was a feature request from homelab and small-business users who wanted domain identities. No IceWhale reply announced LDAP support, so do not configure a Docker LDAP server and assume ZimaOS Samba will automatically consume it.
What ZimaOS Supports Today
The current ZimaOS Samba multi-user guide documents local member accounts, passwords, guest access, and folder permissions.
Why Running OpenLDAP in Docker Is Not Enough
An LDAP container can provide a directory service for applications that support LDAP, but the ZimaOS account/Samba layer still needs explicit LDAP/SSSD/winbind integration. Current ZimaOS documentation does not expose that integration.
Use App-Level LDAP Where Supported
You can still run an identity provider and connect individual applications—such as Nextcloud or other software with LDAP/OIDC support—to it. That can centralize app logins even if ZimaOS itself keeps local NAS accounts.
Keep NAS Administration Separate
For a home or small-office system, keeping the owner/admin identity local reduces the chance that a directory outage locks you out of storage management.
Map SMB Access with Local Members
Create a ZimaOS member per user who needs SMB access, assign only the shares they require, and keep guest access disabled on sensitive folders.
Do Not Modify Samba into a Domain Member Blindly
Joining Samba to AD normally involves Kerberos, winbind/SSSD, NSS/PAM, machine credentials, DNS, and persistent configuration. ZimaOS is an appliance-style OS, so unmanaged package/config changes can be lost or conflict with the built-in sharing service.
A Hybrid Identity Architecture
LDAP / OIDC Provider
├─ Nextcloud
├─ Other Docker apps
└─ Internal services
ZimaOS local accounts
├─ Owner/admin
└─ SMB member accounts
This is not single sign-on everywhere, but it is maintainable with the current product boundaries.
The access control guide gives useful security context.
Use One Source of Identity Per Layer
If applications use LDAP but ZimaOS SMB uses local members, document that split clearly for users. Avoid creating identical usernames with different passwords unless you have a password-management policy, because that can look like broken single sign-on.
Back Up the Directory Service Separately
If you run OpenLDAP, Authentik, Keycloak, or another identity service in Docker, its database and signing/configuration data need their own backup. Losing the identity provider can lock users out of every app attached to it.
Do Not Make NAS Recovery Depend on LDAP
Keep at least one local ZimaOS owner account that can administer storage even when the directory container, DNS, or network is unavailable. That preserves a recovery path during identity-service outages.
FAQ
Can ZimaOS join Active Directory today?
No first-party AD/LDAP join workflow is documented in current ZimaOS docs.
Can I run OpenLDAP on ZimaOS?
Yes as a Docker app, but that does not automatically make ZimaOS Samba authenticate against it.
Can Docker apps use LDAP?
Yes when each application supports LDAP or another identity protocol.
What should I use for SMB users?
Use current ZimaOS local member accounts and per-share permissions.
