Source files and build instructions for an OCI image (compatible with e.g. Docker or Podman) to mimic Active Directory Lightweight Directory Services (AD LDS) using Samba more or less. AD LDS is an independent mode of Active Directory, minus infrastructure features (such as Kerberos KDC, Group Policies or DNS SRV records), that provides directory services for applications.
This “Samba (Active Directory) Lightweight Directory Services” container image is primarily intended for developers and CI/CD use cases. As such, the Samba AD DC configuration has been reduced to a bare minimum of run-time components to enable applications to access an LDAP service that feels and behaves like the one of a Samba AD DC, but without the overhead of a full Active Directory Domain Controller.
The OCI image automatically provisions and starts a lightweight Samba AD DC, if a valid configuration has been provided. It may be started with Docker using:
docker run --name smblds \
--publish 389:389 \
--publish 636:636 \
--detach smblds/smblds:latest
And it may be started with Podman using:
podman run --name smblds \
--publish 389:389 \
--publish 636:636 \
--detach quay.io/smblds/smblds:latest
TZ
- Time zone according to IANA's time zone database, e.g.Europe/Amsterdam
, defaults toUTC
.REALM
- Kerberos realm, the uppercase version of the AD DNS domain, defaults toSAMDOM.EXAMPLE.COM
.DOMAIN
- NetBIOS domain name (workgroup), single word up to 15 characters without a dot, defaults toSAMDOM
.ADMINPASS
- Domain administrator password, needs to match complexity requirements, defaults toPassw0rd
.INSECURE_LDAP
- Set totrue
to allow simple LDAP binds over unencrypted connections, defaults tofalse
.INSECURE_PASSWORDSETTINGS
- Set totrue
to disableADMINPASS
complexity requirements, defaults tofalse
.SSH_AUTHORIZED_KEYS
- SSH public key(s) to enable SSH access to the container, e.g. for complex scenarios.SERVER_SERVICES
- Override option for the services that the Samba daemon will run, defaults toldap cldap
.
22
- TCP port for optional SSH access to the container, requiresSSH_AUTHORIZED_KEYS
to be set.389
- TCP port for LDAP access (STARTTLS or plaintext ifINSECURE_LDAP
is enabled).389/udp
- UDP port for optional CLDAP (Connection-less LDAP) access, usually not needed.636
- TCP port for LDAPS access (mandatory SSL/TLS encryption).3268
- TCP port for optional LDAP access to Global Catalog (STARTTLS or plaintext ifINSECURE_LDAP
is enabled).3269
- TCP port for optional LDAPS access to Global Catalog (mandatory SSL/TLS encryption).
Docker Hub and Quay can both automatically build OCI images from a linked GitHub account and automatically push the built image to the respective container repository. However, as of writing, this leads to OCI images for only the amd64
CPU architecture. To support as many CPU architectures as possible (currently 386
, amd64
, arm/v6
, arm/v7
, arm64/v8
, ppc64le
and s390x
), GitHub Actions are used. There, the current standard workflow "Build and push OCI image" roughly uses first a GitHub Action to install QEMU static binaries, then a GitHub Action to set up Docker Buildx and finally a GitHub Action to build and push Docker images with Buildx.
Thus the OCI images are effectively built within the GitHub infrastructure (using free minutes for public repositories) and then only pushed to both container repositories, Docker Hub and Quay (which are also free for public repositories). This not only saves repeated CPU resources but also ensures identical bugs independent from which container repository the OCI image gets finally pulled (and somehow tries to keep it distant from program changes such as Docker Hub Rate Limiting in 2020). The authentication for the pushes to the container repositories happen using access tokens, which at Docker Hub need to be bound to a (community) user and at Quay using a robot account as part of the organization. These access tokens are saved as "repository secrets" as part of the settings of the GitHub project.
To avoid maintaining one Dockerfile
per CPU architecture, the single one is automatically multi-arched using sed -e 's/^\(FROM\) \(alpine:.*\)/ARG ARCH=\n\1 ${ARCH}\2/' -i Dockerfile
as part of the workflow itself. While this might feel hackish, it practically works very well.
Commits to Git trigger the workflow and lead to updated OCI images being pushed (except for GitHub pull requests) to public container image registries. Additionally, a cron-like option in the workflow leads to a daily updated OCI image.
This project is licensed under the GNU General Public License, version 3 or later - see the LICENSE file for details.
As with all OCI images, these also contain other software under other licenses (such as BusyBox, OpenLDAP, Python, Samba etc. from the base distribution, along with any direct or indirect dependencies).
As for any pre-built image usage, it is the image user's responsibility to ensure that any use of this image complies with any relevant licenses for all software contained within.