Samba Ad Dc

Search Marketplace for Samba Active Directory Domain Controller, select the SecureAnyCloud publisher and click Create.

Two settings on the create blade matter more than any others:

Assign a static private IP. Under Networking, set the private IP allocation to Static. The domain controller registers its own address in Active Directory DNS at first boot.

Do not give the VM a public IP unless you need one for administration. If you do, restrict SSH to your management address only. A domain controller belongs on a private network.

The VM name becomes the domain controller's hostname. NetBIOS computer names are limited to 15 characters, so a longer VM name is truncated in the NetBIOS name. For example, a VM named samba-ad-dc-build registers the NetBIOS name SAMBA-AD-DC-BUI. Both names are registered in DNS, so the domain still resolves. Keep the VM name to 15 characters or fewer to avoid the surprise.

Note the --private-ip-address argument. It pins the static private IP that the domain controller registers in its own DNS.

RG="ad-prod"; LOCATION="eastus"; VM_NAME="samba-ad-dc"; DC_IP="10.0.0.4" IMAGE_URN="sac1647283583153:samba-ad-dc-ubuntu-24-04:default:latest" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION"
# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:samba-ad-dc-ubuntu-24-04:default:latest
az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$IMAGE_URN" \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values "$SSH_KEY" \
  --vnet-name ad-vnet --subnet ad-subnet \
  --private-ip-address "$DC_IP" \
  --public-ip-address ""

Active Directory needs a wide set of ports. Open them from your VNet address space only, never from the internet.

Note the ephemeral RPC range 49152 to 65535. Active Directory's RPC services (replication and many management operations) negotiate a dynamic high port, so domain joins and administration fail in confusing ways without it. The range holds 16,384 ports, so open it as a single range rule rather than as individual port entries.

RG="ad-prod"; NSG="ad-nsg"; VNET_CIDR="10.0.0.0/16"
# Core AD: DNS 53, Kerberos 88, RPC endpoint mapper 135, NetBIOS 139,
# LDAP 389, SMB 445, kpasswd 464, LDAPS 636, Global Catalog 3268/3269 az network nsg rule create --resource-group "$RG" --nsg-name "$NSG" \
  --name allow-ad-core --priority 1001 \
  --source-address-prefixes "$VNET_CIDR" --destination-port-ranges 53 88 135 139 389 445 464 636 3268 3269 \
  --protocol '*' --access Allow --direction Inbound
# Ephemeral RPC high ports — required for domain joins and replication az network nsg rule create --resource-group "$RG" --nsg-name "$NSG" \
  --name allow-ad-rpc-ephemeral --priority 1002 \
  --source-address-prefixes "$VNET_CIDR" --destination-port-ranges 49152-65535 \
  --protocol Tcp --access Allow --direction Inbound
# SSH for administration — restrict to your management network az network nsg rule create --resource-group "$RG" --nsg-name "$NSG" \
  --name allow-ssh-mgmt --priority 1003 \
  --source-address-prefixes "$VNET_CIDR" --destination-port-ranges 22 \
  --protocol Tcp --access Allow --direction Inbound

On first boot, the image reads the VM's private IP and hostname and provisions a brand new Active Directory domain with a 144-bit random Administrator password. It proves that Kerberos issues a ticket and that the domain's DNS SRV records resolve. It then takes over DNS on port 53 for the realm and writes the credentials file. This completes in well under a minute.

The built-in Administrator password is pinned to never expire. Active Directory's default maximum password age is 42 days, which would otherwise silently break a working domain six weeks after deployment, for no security benefit.

SSH in as azureuser and read the details:

sudo cat /root/samba-ad-dc-credentials.txt

samba-tool domain info reports the realm, the NetBIOS domain and this controller's own name. The unified samba-ad-dc service provides every AD role. The standalone smbd, nmbd and winbind units are deliberately disabled, because they would compete with the unified service for the same sockets.

sudo samba-tool domain info 127.0.0.1 systemctl is-active samba-ad-dc ss -tln | awk '/:53 |:88 |:389 |:445 |:636 |:3268 /{print $1, $4}' | sort -u

The domain controller runs a Kerberos KDC. Requesting a ticket-granting ticket for the Administrator account proves that the KDC is authenticating, not merely listening.

This command reads the generated password straight from the root-only credentials file, so nothing is typed or echoed:

sudo bash -c 'PW=$(grep "^samba.admin.password=" /root/samba-ad-dc-credentials.txt | cut -d= -f2-); printf "%s" "$PW" | kinit Administrator@AD.SAC.INTERNAL && klist'

klist shows a real krbtgt/AD.SAC.INTERNAL@AD.SAC.INTERNAL ticket. A deliberately wrong password is rejected with a preauthentication failure, which confirms that the check is real.

samba-tool manages users and groups. The freshly minted domain contains only the built-in accounts (Administrator, Guest and the krbtgt service account) and the standard Active Directory groups.

sudo samba-tool user list
sudo samba-tool group list | head -14

Creating a user and reading it back proves the directory is writable:

sudo samba-tool user create demo.user 'Dem0-Passw0rd!2026' --given-name=Demo --surname=User sudo samba-tool user show demo.user | grep -E '^(dn|sAMAccountName|userPrincipalName):'
sudo samba-tool user delete demo.user

The directory is an LDAP server. You can read the naming context anonymously, but any authenticated bind must be encrypted. Samba enforces ldap server require strong auth, so it refuses a simple bind over plain ldap:// before the password can cross the wire. Use StartTLS (-ZZ) or ldaps:// on port 636.

First read the naming context anonymously:

sudo bash -c 'IP=$(grep "^samba.dc.ip=" /root/samba-ad-dc-credentials.txt | cut -d= -f2-); ldapsearch -x -LLL -H "ldap://$IP" -s base -b "" namingContexts'

The image uses a self-signed certificate generated at provisioning time, so this local check sets LDAPTLS_REQCERT=never. For production clients, distribute your own CA and drop that override.

sudo bash -c 'set -e CREDS=/root/samba-ad-dc-credentials.txt PW=$(grep "^samba.admin.password=" $CREDS | cut -d= -f2-) REALM=$(grep "^samba.realm=" $CREDS | cut -d= -f2-) FQDN=$(grep "^samba.dc.fqdn=" $CREDS | cut -d= -f2-) BASE=$(grep "^samba.realm=" $CREDS | cut -d= -f2- | tr "A-Z" "a-z" | sed "s/^/DC=/; s/\./,DC=/g") LDAPTLS_REQCERT=never ldapsearch -x -ZZ -LLL -o ldif-wrap=no -H "ldap://$FQDN" \
  -D "Administrator@$REALM" -w "$PW" -b "$BASE" "(sAMAccountName=Administrator)" dn | grep "^dn:"'

Active Directory clients find the domain through its DNS SRV records, which only this controller serves. Set your VNet's DNS server to the controller's static private IP, then restart the client VMs so that they pick up the change.

In the Portal, go to Virtual network > DNS servers > Custom and enter the controller's private IP.

Alternatively, run this from the Azure CLI on your own workstation:

RG="ad-prod"; VNET="ad-vnet"; DC_IP="10.0.0.4" az network vnet update --resource-group "$RG" --name "$VNET" --dns-servers "$DC_IP"

From a client VM in the same VNet, verify that the domain's SRV record resolves:

host -t SRV _ldap._tcp.ad.sac.internal

The realm AD.SAC.INTERNAL is a documented default namespace, not a secret. It is the DNS equivalent of a default base DN, and many deployments keep it. If you want your own realm, re-provision now, before you join any machine or create any user. The realm cannot be changed afterwards without rebuilding the domain.

On a freshly deployed VM, this is free and takes about 30 seconds. Choose a realm you control. Never use a .local suffix, because it is reserved for mDNS and causes resolution problems. A subdomain of a domain you own, or a .internal name, is the right choice.

The following block is destructive. It permanently deletes the domain that the VM minted on first boot, including its Administrator password and every account in it. Run it only on a VM you have just deployed, and never paste it into a working domain controller.

# DESTRUCTIVE — this DELETES the existing domain. Fresh VMs only. REALM="AD.EXAMPLE.COM"
# your realm, uppercase NETBIOS="EXAMPLE"
# <= 15 chars, no dots ADMIN_PW='ChangeMe-Str0ng!2026'
# your Administrator password
sudo systemctl stop samba-ad-dc
sudo rm -rf /var/lib/samba/private /var/lib/samba/sysvol /var/lib/samba/bind-dns
sudo rm -f /etc/krb5.conf /etc/samba/smb.conf
sudo install -d -m 0700 /var/lib/samba/private
sudo samba-tool domain provision \
  --use-rfc2307 --realm="$REALM" --domain="$NETBIOS" \
  --server-role=dc --dns-backend=SAMBA_INTERNAL \
  --adminpass="$ADMIN_PW" sudo cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
sudo samba-tool user setexpiry Administrator --noexpiry sudo systemctl start samba-ad-dc
# Point the VM at its own DNS and confirm the new realm:
sudo samba-tool domain info 127.0.0.1 kinit "Administrator@$REALM"

After re-provisioning, update /root/samba-ad-dc-credentials.txt (or your own secret store) so that the recorded realm and password match the new domain.

Point the client's DNS at the domain controller first. Every join failure that is not a firewall problem is a DNS problem.

On a Windows client, join from an elevated PowerShell prompt and enter the Administrator credentials when prompted:

Add-Computer -DomainName ad.sac.internal -Restart

On an Ubuntu client, realmd performs the join:

sudo apt-get install -y realmd sssd sssd-tools adcli krb5-user
sudo realm join --user=Administrator ad.sac.internal

If a join fails, check these in order:

• The client resolves _ldap._tcp.ad.sac.internal.
• The NSG allows the core AD ports and the ephemeral RPC range 49152 to 65535.
• The client's clock is within five minutes of the controller's, because Kerberos rejects tickets outside that skew.

Never expose this VM to the internet. Keep every Active Directory port reachable only from your own VNet, and prefer a VM with no public IP at all.

Keep the static private IP. The controller registers its address in its own DNS, and changing the address breaks the domain for every client.

Rotate the generated Administrator password into your own secret store after deployment, then remove /root/samba-ad-dc-credentials.txt. The file is mode 0600 and root only, but it is still a password on disk.

Replace the self-signed LDAPS certificate with one from your own CA, and distribute the CA to clients. Clients can then verify the controller instead of trusting it blindly.

Leave unattended upgrades enabled. Samba security fixes reach this VM through the noble-security pocket automatically. Confirm with systemctl is-enabled unattended-upgrades.

Back up the directory, not just the disk. samba-tool domain backup offline --targetdir=/var/backups/samba produces a restorable copy of the domain.

A single domain controller is a single point of failure. For production, join a second controller to the domain so that authentication survives the loss of one VM.

The Samba Team develops Samba and distributes it under the GNU General Public License version 3 or later (GPL-3.0-or-later). This SecureAnyCloud image bundles the unmodified Samba packages from the Ubuntu 24.04 archive.

In accordance with GPL-3 section 6, the complete corresponding source is available from the Ubuntu archive with apt-get source samba (the image ships with source repositories already enabled). A three-year written offer for the source code is included on the image at /usr/share/doc/sac/SAMBA-GPL-3-WRITTEN-OFFER.txt, valid for anyone in possession of the object code.

The Active Directory schema files bundled with Samba are distributed under the Microsoft Active Directory Schema License (MS-ADSL). They were accepted into the Debian and Ubuntu main archive under that license.

SecureAnyCloud provides the packaging, the per-VM domain provisioning automation, the fail-closed safety levers, the Azure-specific hardening and 24/7 support with a guaranteed 24 hour response SLA.

SecureAnyCloud is not affiliated with, endorsed by or sponsored by the Samba Team. Samba is a trademark of its respective owner and is used here only to identify the software this image packages.

Deploy on Azure

Find Samba Active Directory Domain Controller on Ubuntu 24.04 LTS on the Azure Marketplace, published by SecureAnyCloud. Deploy from the Portal or the Azure CLI as shown above.

Need Help?

Email sales@secureanycloud.com for deployment help, configuration questions or licensing inquiries.

Deploy on Azure

Launch Samba Active Directory Domain Controller 4.19.5 on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com