SFTP Server with Active Directory: 2026 Setup Guide

If you have a Windows domain, your SFTP server should authenticate against it. The alternative is maintaining a parallel user database for file transfers, which is a maintenance treadmill and a security risk because offboarding gets forgotten.

This article covers how to actually do it. Three structural options, the three capability tiers of "AD integration," a step-by-step setup with CompleteFTP, and the common gotchas worth knowing about before you commit to a path.

Disclosure: we make CompleteFTP, a Windows-native SFTP server in the commercial category. We will be honest about the trade-offs of every path here, including the ones where OpenSSH or a Linux deployment is the right answer.

Why use AD authentication for SFTP at all?

Three reasons, in roughly the order they matter for most teams.

The maintenance argument (no separate user database)

Without AD, every SFTP user is a separate entry in a separate database. Onboarding means creating the account twice (once in AD for everything else, once in the SFTP server). Password changes mean updating two places. Account expiry means setting it in two places. Multiply that by your headcount and your churn rate and the operational cost adds up.

With AD authentication, the SFTP server treats AD as the source of truth. New domain users can sign in to SFTP immediately. There is no second account to provision.

The security argument (offboarding actually works)

The single biggest security risk of a separate user database is that nobody remembers to remove the account when an employee leaves. The domain account gets disabled in AD on the person's last day. The SFTP account, in a separate database, often does not.

AD-backed SFTP authentication closes that gap. Disable the domain account and SFTP access is gone with the next login attempt. No manual cleanup, no missed accounts, no ex-employees with active credentials sitting around in a forgotten user list.

The compliance argument (single audit trail)

Most compliance frameworks want a single, authoritative answer to "who has access to what." Two parallel user databases give you two answers, neither complete on its own. Auditors do not like that.

AD-backed authentication produces a single identity per person across the domain, including SFTP. Audit logs reference the AD account, not a server-local one. When the auditor asks for the access list, you query AD and the SFTP server, and they agree.

AD vs LDAP for SFTP. They're not the same thing.

These two terms get used interchangeably and they shouldn't be.

Active Directory authentication uses AD's native protocols: Kerberos for ticket-based authentication, NTLM as the fallback. Users sign in with their normal domain credentials, and you get group-membership lookup and tight Windows integration. The SFTP server has to be domain-joined or have a domain trust path.

LDAP authentication queries a directory using the LDAP protocol. Active Directory exposes an LDAP interface, so you can use LDAP authentication against AD. But LDAP authentication also works against non-AD directories (OpenLDAP, ApacheDS, FreeIPA). Its advantage is portability across directory types; the trade-off is that it doesn't give you the tight Windows integration that native AD authentication does.

The practical advice: if you have AD and your SFTP server runs on Windows, use AD-native authentication. If you have a non-AD directory or you need cross-platform portability, use LDAP. Most commercial Windows-native SFTP servers support both, and you can mix them within the same deployment. CompleteFTP is one of them: AD-native authentication is available from the Professional edition, and LDAP authentication — against OpenLDAP and other directory services — in Enterprise MFT.

Your three structural options (with the trade-off for each)

Three real paths exist for Windows shops that want AD-authenticated SFTP. Each has a structural fit and a cost.

OpenSSH on Windows + manual AD integration

OpenSSH is built into Windows 10 (build 1809+) and Windows Server 2019+ as an optional feature. It is free and functional for SFTP, but its AD support is bare-bones.

You can configure OpenSSH to validate domain passwords by mapping each AD user to a local Windows account. There is no GUI for this. There is no concept of AD group membership in OpenSSH's configuration. You cannot map AD groups to folder permissions without scripting it yourself. When someone leaves a group in AD, their OpenSSH access does not change until you manually remove their local account.

Right answer for: single-server dev environments, CI/CD artifact drops, a one- or two-user transfer endpoint where AD is nice-to-have rather than load-bearing.

Wrong answer for: anything past 10 users, anything compliance-driven, anything where group-to-permission mapping matters. OpenSSH does not grow into those capabilities. Outgrowing it means migrating to a different product, so plan for that early if your needs are likely to evolve.

A commercial Windows-native SFTP server with native AD support

This is where most production Windows shops land. Commercial Windows-native servers, including CompleteFTP, support AD authentication as a first-class feature: connect once during setup, then individual users and groups in AD become available to the SFTP server without per-account configuration.

Native AD support in this category typically includes group-to-permission mapping (assign permissions to "Domain Users" or "Finance" and they apply to every member), automatic membership updates (no manual sync needed), and proper integration with the audit log (the AD user shows up as the principal, not a local mapping).

Right answer for: domain-joined deployments with more than a handful of users, any deployment that wants the maintenance and security benefits of single identity, any shop where compliance pressure means audit logs need to reference the real user.

The trade-off is licensing cost. Commercial servers are paid software. The category has both subscription and perpetual-license options.

A domain-joined Linux SFTP server with SSSD/PBIS

It is possible to run a Linux SFTP server that authenticates against AD via SSSD (System Security Services Daemon) or the legacy PBIS (PowerBroker Identity Services, formerly Likewise). The setup involves joining the Linux host to the domain, configuring SSSD to enumerate users and groups, and pointing OpenSSH (or whatever Linux SFTP server you use) at the resulting PAM stack.

This works. Some Linux-heavy organizations prefer it because their SFTP servers can live in the same management plane as their other Linux infrastructure.

The trade-offs are operational. SSSD configuration is its own skill. AD-on-Linux can drift from AD-on-Windows in subtle ways (UID mapping, group membership refresh intervals, cached credentials behavior). Troubleshooting requires people who know both Linux and Windows identity, which is a narrower hiring pool.

Right answer for: Linux-first shops where the SFTP host belongs in the Linux fleet and there is operational maturity around SSSD already.

Wrong answer for: Windows-first shops where the SFTP server is the only Linux box on the network. The complexity isn't worth the consistency gain.

What "AD integration" actually means at each capability tier

AD integration is not one thing. Servers in this category vary widely in how deeply they integrate with AD. Three tiers are worth understanding.

Authentication only

The minimum bar. Users sign in with their domain credentials, but every permission has to be assigned to each user individually inside the SFTP server. AD provides identity, nothing else.

Useful as a starting point but does not scale: each AD user still requires SFTP-side configuration for what folders they can see and what they can do in them.

Group-to-permission mapping

The next tier up. The SFTP server can map AD groups to folder permissions. Membership in "Finance" grants access to /finance/uploads/. Membership in "Contractors" grants access to /contractors/dropbox/ only. The user list inside the SFTP server is effectively the AD group memberships.

This is where the operational benefit really lands. Onboarding a new finance hire becomes "add them to the Finance AD group." No SFTP-side work.

Auto-revoke on AD group change

The top tier. The SFTP server picks up AD group membership changes automatically, ideally on the next login attempt. When somebody is removed from a group in AD, their permissions on the SFTP server adjust without admin intervention.

This is what makes the security argument work. Without auto-revoke, "we use AD integration" can still mean "but our SFTP permissions are stale because we never wrote the sync job."

CompleteFTP supports all three tiers; the higher tiers are configuration choices, not separate products. Most commercial servers in this category sit somewhere on this ladder. It is worth asking specifically which tier a server offers before you commit, because vendors sometimes call all three "AD integration" without distinguishing.

Setting it up with CompleteFTP (step-by-step)

The walkthrough below assumes you already have CompleteFTP installed and running on a member server that is joined to your AD domain. If you do not, the 30-day trial download takes about 10 minutes to install and configure on a fresh Windows Server.

Prerequisites

  • CompleteFTP installed on a domain-joined Windows host (Professional edition or higher).
  • An admin account on the Windows host with permission to start CompleteFTP Manager.
  • An AD user or service account you can test with after configuration.
  • Knowledge of your AD domain name (the FQDN, not just the short name).

Two ways to let AD users in

Open CompleteFTP Manager and go to the Users panel. CompleteFTP gives you two ways to let AD users in:

  • Add individual Windows users: click Add in the user list and select Windows user. Enter your domain name and select the domain users to add. Use this when you want a specific, named set of AD users, each with their own settings.
  • Enable the Windows/AD Group authenticator: any permitted AD user can then log in with their domain credentials, without being added to the user list individually. This is the path most production deployments take, and the one the rest of this walkthrough follows.

Enabling the Windows/AD Group authenticator

The authenticator is in the Authenticators panel at the bottom of the Users panel. Turn it on by checking its box in the Enabled column.

Logins can be restricted to one or more AD groups (covered in the next section), and each user's home folder is a path you specify rather than a Windows profile directory. By default, users connecting this way inherit the settings of the built-in defaultWindows user, including which protocols they may use.

The CompleteFTP guide page on configuring Windows/AD group users covers the dialog screens in detail if you want the click-by-click reference.

Mapping AD groups to folder permissions

The more useful pattern is to grant permissions by AD group rather than by individual user.

In the Windows/AD Group authenticator, click Configure. There you list each AD (or local Windows) group you want to permit and map it to one or more CompleteFTP groups (and, optionally, a per-group log-in-as user and home-folder override). Those CompleteFTP groups are how you grant folder access in the virtual file-system, provided the user's (or log-in-as user's) Access control setting is non-Windows. If Access control is set to Windows, folder access is governed by Windows/NTFS permissions instead, and the CompleteFTP group permissions don't apply.

When an AD user signs in, CompleteFTP looks up their AD group membership and makes them a member of the mapped CompleteFTP groups. With non-Windows access control, those groups' folder permissions then apply: add somebody to "Finance" in AD (mapped to a CompleteFTP group with access to /finance/uploads/) and they can read and write that folder via SFTP the next time they connect. Remove them from "Finance" and the access disappears on the next session.

The tutorial on allowing all users from a Windows group to log in covers the group-permission setup with screenshots.

Testing with a domain user

Before you let real users near the new setup, test with a deliberately-created AD account.

Create a test user in AD, add them to one of the groups you mapped in the previous step, and try to connect via SFTP using an SFTP client (FileZilla, WinSCP, or your CLI of choice). Authenticate with the AD username and password.

You should see only the folders the group has access to. Try a write to one of those folders. Then try to list a folder the group does not have access to and confirm you get a permission-denied response, not silent failure.

If anything is unexpected, the most common causes are:

  • The CompleteFTP service account does not have permission to query AD. Make sure it can read user and group attributes.
  • The user's group membership is stale. CompleteFTP reads AD group membership from the user's Windows security token at login, so a very recent AD change may not be reflected until they get a fresh token, have them reconnect, and confirm the change has replicated to the domain controller CompleteFTP is querying.
  • The group name entered in CompleteFTP does not exactly match the AD group name. Make sure it matches, including the domain prefix where required (e.g. MyDomain\MyGroup).

Verifying offboarding works

This is the test that confirms you have actually gained the security benefit of AD integration.

Disable the test user account in AD. Wait a minute. Try to connect via SFTP using the disabled account's credentials. You should get an authentication failure.

If you can still connect, something in the chain is honoring cached credentials. Track that down before you start onboarding real users, because the entire offboarding story depends on this working.

Common gotchas

A few specific issues come up enough to be worth flagging before you hit them.

User home folder mapping for AD users

AD users do not have a Windows profile directory on the SFTP host by default. You need to tell CompleteFTP where their SFTP home folder lives. The Windows/AD Group authenticator's configuration lets you specify a home-folder path that can include the username as a macro (e.g. C:\FTP\%UserName%), so each user lands in a different folder under a shared parent.

Pick the template carefully on the first user, because changing it later for a deployed user requires moving their existing files.

Mixed-mode (local + AD users) deployments

You can run a CompleteFTP site with both local (server-internal) users and AD users at the same time. This is a perfectly supported pattern; it is occasionally useful for service accounts that shouldn't live in AD or for legacy users you want to migrate gradually.

The gotcha: namespace collisions. If you have a local user named "smith" and an AD user named "smith" in your default domain, the resolution order matters. Document which takes precedence in your environment and check the audit log periodically to confirm logins are attributed to the user you expected.

AD users who aren't local Windows accounts

This was covered above (the Windows/AD Group authenticator vs adding individual Windows users), but it is worth repeating because the wrong choice here is a common source of "I can't log in" tickets.

Most production AD integrations use the Windows/AD Group authenticator, so there's no need to create a local account or a user-list entry for every person. Adding individual Windows users is mainly for shops that need to give specific domain users their own distinct settings.

What runs on CompleteFTP today

CompleteFTP runs in production at thousands of organizations worldwide, including NASA, Boeing, Audi, 3 Italia, Global Payments, and TeliaSonera. AD integration is part of why those teams adopted it: when you have a domain and you want SFTP that respects it, the path of least resistance is a server that treats AD as a first-class identity source.

"CompleteFTP has worked for years without any issue whatsoever. CompleteFTP is absolutely mission critical for what we do. It just works."

  • Malcom Moody, Sky News Australia

Per-server perpetual licensing. AD integration is available from the Professional edition up. Unlimited users at every tier.

Try it

The 30-day trial includes the full feature set. Install on a domain-joined Windows host, enable the Windows/AD Group authenticator, map a group or two to folder permissions, and connect with a domain account. The whole walkthrough takes about half an hour from a fresh server.

Frequently asked questions

How do I authenticate an SFTP server with Active Directory?

Three approaches work on Windows: (1) OpenSSH with manual per-user AD mapping, which doesn't scale past a handful of accounts; (2) a commercial Windows-native SFTP server with native AD authentication, the standard production path; (3) a domain-joined Linux SFTP server using SSSD or PBIS, which works but adds operational complexity. For most production Windows shops, option 2 is the lowest-effort path that supports AD group-to-permission mapping out of the box.

Does OpenSSH on Windows support Active Directory authentication?

Yes, but only manually. OpenSSH on Windows can validate AD passwords if you map each AD user to a local Windows account or configure sshd_config carefully. There is no GUI for it, no group-to-permission mapping, and no auto-revoke when AD group membership changes. It works at single-digit user counts. It stops being practical somewhere between 10 and 20 users.

Can I map AD groups to SFTP folder permissions?

Yes, if the SFTP server supports it. Commercial Windows-native SFTP servers including CompleteFTP let you attach folder permissions to server-side groups and map those to AD groups rather than to individual users. When someone joins or leaves the group in AD, their server access updates automatically on the next session. OpenSSH does not offer this; you'd have to script it yourself.

What's the difference between AD authentication and LDAP authentication for SFTP?

AD authentication uses Active Directory's native protocols (Kerberos, NTLM). LDAP authentication queries an LDAP directory using the LDAP protocol. Active Directory exposes an LDAP interface, so you can authenticate against AD via either. The practical difference: AD-native authentication gives you group membership lookup and better Windows integration, with users signing in using their normal domain credentials. LDAP authentication is more portable (it works against non-AD directories like OpenLDAP) but doesn't provide that native Windows integration.

Do I need a domain controller on the same server as the SFTP server?

No. The SFTP server only needs to reach a domain controller on the network. Most production deployments put the SFTP server on a member server that joins the domain but is not itself a DC. Co-locating the SFTP service on a DC is technically possible but generally discouraged for security reasons: DCs should run the minimum surface area possible.

How do I handle AD users who don't have Windows accounts on the SFTP server?

Enable the "Windows/AD Group" authenticator in your SFTP server. In CompleteFTP this lets any Active Directory user log in with their domain credentials without adding a local Windows account or an individual entry to the server's user-list, which is what you want for most production AD integrations. You can restrict logins to specific AD groups, and each user's home folder is a path you specify rather than a Windows profile directory.

Other technical articles

Download Free Trial