Samba DCSync (Vampire)
Theory
A Samba AD DC provides a fully functional Active Directory Domain Controller on Linux, implementing core protocols such as DRSUAPI, the replication protocol used between Windows DCs to synchronise the directory database. Unlike a Windows DC, Samba does not use ntds.dit or VSS, so standard DCSync tools such as Impacket's secretsdump do not work against it out of the box.
However, because Samba implements DRSUAPI, replication-based credential extraction is still possible through alternative paths that speak the same underlying protocol. The goal is identical to a classic DCSync: extract NT hashes for all domain users remotely, using only Domain Admin privileges, without requiring local code execution on the DC.
The Samba LDB files page covers credential extraction when you already have root on the DC. This page focuses on the remote, credential-only scenario.
Three main approaches exist, depending on the Samba backend configuration:
net rpc vampire keytab
Domain Admin creds or NT hash
Samba AD DC
samba-tool drs clone-dc-database
Domain Admin creds
Samba AD DC
samba-tool domain backup online
Domain Admin creds
Samba AD DC
OpenLDAP attribute read
rootDN creds or misconfigured ACL
Samba + OpenLDAP (ldapsam)
The first three methods all rely on DRSUAPI replication and do not work when Samba uses an OpenLDAP backend (passdb backend = ldapsam). In that case, refer to the OpenLDAP section below.
How net rpc vampire keytab Works
net rpc vampire keytab WorksThe net utility ships with most Linux distributions and exposes a vampire keytab subcommand originally designed for DC migrations. Under the hood it triggers a standard DRSUAPI replication transaction, the same DsBind → DsCrackNames → DsGetNCChanges RPC calls used by Windows DCSync, and stores the replicated secrets in a Kerberos keytab file.
Keytab entries include a key typed arcfour-hmac-md5 (RC4). In both Windows and Samba, the RC4 long-term key is mathematically equal to the user's NT hash, making this a direct DCSync equivalent.
Samba + OpenLDAP Backend
When Samba is configured with an OpenLDAP backend (passdb backend = ldapsam), the DRSUAPI-based methods above do not apply. Instead, passwords are stored in OpenLDAP-specific attributes:
sambaNTPassword— the NT hash, used for NTLM authentication.sambaLMPassword— the LM hash (disabled by default in modern Samba).userPassword— the bind password for LDAP authentication (SSHA, MD5, or clear text depending on config).
By default, OpenLDAP ships with a minimal ACL set. The standard recommended default in the OpenLDAP documentation is:
The second wildcard rule (access to * ... by users read) grants any authenticated LDAP user read access to all attributes not explicitly covered by a preceding ACL. Since sambaNTPassword and sambaLMPassword are not part of the default OpenLDAP schema and are not listed in any default ACL, they fall under this wildcard — meaning any user who can bind to LDAP can read all NT hashes, with no admin privileges required, unless the administrator explicitly added an ACL to protect these attributes.
This is a default-open misconfiguration, not an exotic one. Most setup guides do recommend adding a protecting ACL, but it is frequently forgotten. Some distributions default to by * read (even anonymous access), making things worse.
Even when ACLs are properly set, the rootDN password (default: cn=admin,dc=<domain>,dc=<tld>) is sometimes left in plaintext in config files on domain-joined hosts, accessible to an attacker who has compromised a domain machine.
Practice
rpc vampire
The --force flag is required because net warns that vampire was not designed for use against an AD DC.
Then parse the NT hashes (RC4 keys) out of the keytab with klist (from the krb5-user package):
If we only have a domain admin’s NT hash we can use the modified version of net included in the pth-toolkit repo, which adds support for the --pw-nt-hash parameter found in smbclient
Then parse the NT hashes (RC4 keys) out of the keytab with klist (from the krb5-user package):
Clone the DC Database
These methods replicate the entire directory, including the password database. They are slower and generate significantly more traffic in large environments, but serve as a fallback when vampire keytab fails.
Clone the full Samba AD database locally, including secrets:
Point pdbedit at the cloned config to extract NT hashes:
Output format: username:RID:LM_HASH:NT_HASH:::
Create an online backup archive, same result, but requires a restore step before reading secrets, since it is supposed to be used in emergencies where you need to replace a DC.
Restore the backup locally (this only affects your local copy, the target DC is completely unaffected):
Then read hashes from the restored config:
The restore process adds your fake DC as a directory member, but only inside the local backup copy. The live environment is untouched.
OpenLDAP Backend
If no explicit ACL protects sambaNTPassword and sambaLMPassword, the OpenLDAP default wildcard rule (by users read) allows any authenticated LDAP user to read them:
Also check sambaPasswordHistory. Unlike sambaNTPassword, it is frequently absent from hardening guides and ACL examples. When password history is enabled, this attribute holds previous passwords (16-byte salt + NT hash), directly crackable offline.
If you have recovered the rootDN password (see config file hunting below), dump all Samba password attributes:
Hunting the rootDN Password
When Samba uses an OpenLDAP backend, services such as NSS, PAM, SSSD, and Kerberos must authenticate to LDAP. Administrators often use the rootDN account for this convenience, leaving its password in plaintext across domain-joined hosts.
Common locations to check:
If the password is hashed (e.g. SSHA), attempt an offline bruteforce, OpenLDAP imposes no complexity requirement on the rootDN password by default.
Resources
Last updated