TWAD vs Active Directory
Where it replaces AD outright, where it needs help, and the one thing it deliberately does not do.
| Feature | Active Directory | TWAD |
|---|---|---|
| Users, groups, org units | ✓ yes | ✓ yes |
| Policy by OU with inheritance | Group Policy | yes, plus a why-is-it-like-this view |
| Works off the network without a VPN | ✗ needs a domain controller | yes, built for it |
| Kerberos single sign-on | ✓ yes | ✗ see the note below |
| NTLM file shares and RDP | ✓ yes | ✓ yes |
| Software deployment | needs Intune or SCCM | included |
| Scripts, on demand and scheduled | needs an RMM | included |
| Remote control and terminal | needs an RMM | included |
| Compliance reporting | needs Intune | included |
| OIDC for web apps | needs ADFS or Entra | included |
| LDAP for appliances | ✓ yes | yes, read-only |
| MFA at Windows sign-in | needs an add-on | included |
| Runs on your own hardware | ✓ yes | ✓ yes |
| Per-seat cloud bill | Entra/Intune do | ✗ |
| Domain controllers to patch | ✓ yes | one appliance, or two |
The Kerberos question, answered straight
TWAD does not do Kerberos. In AD, signing in gets you a ticket that other services accept without asking again. TWAD instead keeps a local Windows account on each PC and keeps its password in step with the directory.
What that buys: file shares, RDP and anything using NTLM work normally, because Windows is looking at an ordinary local account. And it all works over the internet with no line of sight to a domain controller.
What it costs: an old on-premises application that insists on Kerberos SSO will prompt for credentials. If you have one of those and cannot change it, AD is still the right tool and we would rather you knew now.
The migration question
TWAD is not an AD upgrade and does not join an existing domain — it is a replacement for shops that want out of one, or that never had one. The usual path is to run it alongside, move a team, then the rest.