This document covers how to report a vulnerability, what the server can do to your directory, the controls that limit it, and a credential exposure in the repository history that you should know about before you use or fork this project. See also the README, CONTRIBUTING and CHANGELOG.

Only the latest release line receives security fixes.

Please do not open a public issue for a security problem.

• Preferred: use GitHub private vulnerability reporting ("Report a vulnerability" on the repository's Security tab). This channel exists only after the repository owner has enabled the feature; if the button is not there, it is not enabled yet.
• Fallback, valid today: email [email protected] with the subject "ActiveDirectoryMCP security".

Include the affected version, a description, reproduction steps and the impact you see. Do not include real credentials or production data.

This is a volunteer-maintained project. There is no guaranteed response time. Reports are acknowledged and triaged on a best-effort basis, and a fix is released with a CHANGELOG entry and credit to the reporter if wanted.

In scope: the server code in src/active_directory_mcp, its HTTP transport and authentication, the policy, validation and redaction layers, the Docker image and the example configurations.

Out of scope: weaknesses of Active Directory itself, of the MCP client or the language model, of your reverse proxy or network, and a service account that was given more rights than this document recommends.

The server binds to each configured domain with exactly one service account (one domain unless a multi-domain configuration is used). Every tool call, whoever or whatever triggered it, runs with the rights of the account of the domain it targets. The server's reach therefore equals the rights of those accounts, and the server's own controls, set per domain, can only narrow it further.

What each risk class can do (the full per-tool table is generated below):

• read: enumerate users, groups, computers and organizational units, group membership (including nested membership), password policy and policy violations, privileged group membership, the rootDSE and the schema summary, and the TLS posture of the directory connection.
• write: create, modify, enable and disable user, group and computer accounts, add and remove group members (a privilege escalation path when pointed at privileged groups), reset user and computer passwords, create, modify and move organizational units.
• destructive: delete users, groups, computers and organizational units, including recursive deletion of an organizational unit with its contents (force).

Write and destructive tools are refused by default.

• LLM client prompt injection and confused deputy: text the model reads (a user description, a group name, a document) can steer it into calling tools the human did not intend. The server cannot distinguish an injected call from an intended one. Keep security.allow_writes off unless the session needs it, use a read-only account for exploration, and review tool calls in the client.
• Data returned to the model: results contain personal data (names, mail addresses, phone numbers, group memberships, last logon times). It is sent to whichever model and client you connect.
• reset_user_password and reset_computer_password return the new password in the tool response. The server registers it for log redaction and does not write it to its logs or audit file, but it is visible in the MCP client transcript. Treat client transcripts and logs as secrets.
• Shared key authentication: the HTTP transport uses a shared API key. There is no per-user identity; the audit record stores a key identifier and client address, not a person.

• No per-user delegation or impersonation: callers share the bind account of each domain.
• No rate limiting or request quotas (a search of the source finds none). Put limits in front of the server if you need them. Result sizes are capped by security.max_list_results.
• No TLS termination for the HTTP transport: it serves plain HTTP. Run it behind a TLS-terminating reverse proxy or on a private network.
• No Kerberos or NTLM: authentication to the directory is a simple bind (use LDAPS or StartTLS).
• It does not make the bind account safe: a Domain Admin account makes every tool a Domain Admin tool.

Each row names the enforcing code and a test that exercises it.

Generated from RISK_CLASSIFICATION in src/active_directory_mcp/policy.py by scripts/gen_security_table.py. Do not edit by hand; run python scripts/gen_security_table.py --write after changing the classification.

None of the commands below were executed against a live Active Directory by this project. No such environment was available. The syntax was checked against Microsoft documentation (dsacls, the User-Force-Change-Password extended right, and the protected accounts appendix) but test every change in a lab domain first.

Principles:

• Use a dedicated service account. Never use a member of Domain Admins, Enterprise Admins, Administrators or Account Operators.
• Use one account per posture: a read-only account for reporting (security.allow_writes false), and a separate write-enabled account for provisioning, used only in sessions that need it.
• Delegate on the specific organizational units the tools should touch, not on the domain root.
• Set active_directory.base_dn and the OU settings to the delegated subtree.

Permissions needed per risk class (on the delegated OU, inherited by its children):

Example with placeholder names, using the Active Directory dsacls syntax <account>:<permissions>[;<object type or property>][;<inherited object type>]. Run in an elevated prompt on a domain-joined host:

:: allow the account to create and delete user objects in one OU
dsacls "OU=Managed,DC=example,DC=com" /I:T /G "EXAMPLE\svc-ad-mcp-write:CCDC;user"

:: allow the account to reset passwords on user objects in that OU
dsacls "OU=Managed,DC=example,DC=com" /I:S /G "EXAMPLE\svc-ad-mcp-write:CA;Reset Password;user"

:: allow it to read and write the lockout and last-set properties of users
dsacls "OU=Managed,DC=example,DC=com" /I:S /G "EXAMPLE\svc-ad-mcp-write:RPWP;lockoutTime;user" "EXAMPLE\svc-ad-mcp-write:RPWP;pwdLastSet;user"

:: allow it to change membership of one specific group
dsacls "CN=Project Team,OU=Groups,DC=example,DC=com" /G "EXAMPLE\svc-ad-mcp-write:WP;member"

The Delegation of Control wizard (Active Directory Users and Computers, right-click the OU, "Delegate Control...") can express the same grants through a custom task; review the resulting entries with dsacls "<OU DN>" afterwards. Verify with a test account that each tool works only with the rights you delegated.

Protected accounts: Active Directory resets the permissions of members of protected groups (for example Domain Admins, Account Operators, Backup Operators) from the AdminSDHolder object (CN=AdminSDHolder,CN=System,<domain DN>), so delegation on an OU does not apply to them. The server's security.protect_privileged_targets setting adds a second barrier for those targets.

• Use ldaps:// (or StartTLS) with a certificate chain your host trusts, keep security.validate_certificate true and security.require_secure_connection true. For an internal CA set security.ca_cert_file. get_tls_posture reports what the connection actually negotiated.
• Keep security.allow_writes false unless the session needs writes; keep security.allow_destructive false unless deletion is intended.
• The Docker image listens on 0.0.0.0 inside the container. Publish the port only to a trusted interface and put a TLS-terminating reverse proxy in front of it; the API key travels in a header.
• Generate a long random API key, store only its SHA-256 digest in security.http_auth.api_key_sha256 (or pass the key through the environment), and rotate it by adding the new digest, switching clients, then removing the old one.
• Keep secrets out of config files: use environment variables or Azure Key Vault. ad-config/ad-config.json is git-ignored; do not commit it.
• Set security.audit_log_path to a directory only the service user can write; the file is created with mode 0600. Ship it to your log system.
• Log hygiene: keep logging.level at INFO or above in production, and still treat log files as sensitive (they contain DNs and account names).
• Docker: the image runs as the non-root user aduser (UID 1000); the virtual environment and code are root-owned, and docker-compose.yml mounts ad-config read-only. The root filesystem of the container is not set read-only by the compose file.

An earlier version of ad-config/ad-config.json that contained a lab bind password was tracked from the first commit of this repository, and the same value also appears in other files of the first commits (compose files, README, LDIF fixtures and test scripts). It is in the public git history.

• As of 1.0.0 the file is untracked and every tracked example is placeholder-only. The history was not rewritten, so the value remains retrievable from the repository and from every existing fork and clone.
• Treat the value as compromised. Rotate it everywhere it was or may have been used, and never reuse it.
• The maintainer's checklist tracks as pending, owner-side actions: a decision on purging the history, enabling GitHub secret scanning with push protection, and enabling private vulnerability reporting.
• Scan results (scan of 2026-10-20, re-run after the pre-release review fixes): the scripted full-history and tree scan (scripts/secret_scan.py with the custom rules in .gitleaks.toml) covers all refs, including merge-commit diffs, and the tracked tree. The gitleaks binary was not available, so the useDefault gitleaks rules were not exercised; only the custom rules ran. The allow-list accepts exact placeholder values only (${VAR}, <name>, changeme, YourSecurePassword, REPLACE_WITH_...), not substrings. Every remaining finding is in the committed baseline scripts/secret_scan_baseline.txt, which stores a per-value fingerprint, the path and the rule, never a value, so a new credential in an already-baselined file is still reported. The baseline holds the lab credential in the first commits and later compose and script edits, plus synthetic test and documentation strings reviewed by hand. The gate fails on any new finding.
• Baseline review (2026-10-20): the 101 fingerprints in .gitleaksignore were re-checked with a throwaway script that resolves each commit:file:rule:line to the blob, re-applies the rule from .gitleaks.toml and prints only a classification and counts, never a matched value. Result: no finding looks like real secret material. Matches are environment references (${VAR}), documented placeholders and word-based example values (README Azure sections), prose or comments (the CHANGELOG URL-shape sentence, the "throwaway value" compose comment), an environment variable name constant (not a key), test fixtures under tests/, and the lab and LDIF fixture values already described above, which are treated as compromised and must not be reused. High-entropy strings outside tests/, ad-config/ and ldap-init/ were not found.
• AI-residue scan (scripts/ai_residue_scan.py): the tracked tree and all commit messages are clean except one merged upstream pull request commit that carries third-party Co-authored-by trailers. It is allow-listed by SHA in scripts/ai_residue_allowlist.txt and was not rewritten.

The credential value is intentionally not written in this document or in the scan evidence.