What TWAD is

A replacement for Active Directory, Group Policy and Intune that you run yourself.

TWAD does the four jobs those three products do between them:

It holds your users and groups: One account per person, one password, used everywhere.
It manages your Windows PCs: Settings, software, scripts, compliance — pushed out and kept applied.
It signs people in to those PCs: A TWAD tile on the Windows logon screen, using their directory password.
It signs people in to web applications: Standard OIDC, so anything that speaks "log in with…" can use it.

The one big difference from Active Directory

There is no domain, and no VPN. An AD-joined laptop has to reach a domain controller on the network. A TWAD-enrolled laptop reaches your appliance over the internet, through your reverse proxy, and works identically in the office, at home, or in a hotel.

The trade is that TWAD does not do Kerberos. Where AD would hand out a ticket, TWAD keeps a local Windows account on each PC whose password it keeps in step with the directory. That is why file shares and RDP work — Windows sees a normal local account — and why there is no single sign-on to an old on-premises app that demands Kerberos.

The shape of it

The appliance: A Linux machine (or two, or three) running TWAD. This console is served from it.
The agent: A small service installed on every managed Windows PC. It checks in, applies policy, and carries the tunnel that remote control and the live tools ride on.
Your reverse proxy: You provide it. It terminates HTTPS and forwards to the appliance. TWAD deliberately does not ship one — you almost certainly already have one you trust.

Your first day

The shortest path from a fresh appliance to a managed PC.

In order

1 · Finish setup: Static address, hostname, first administrator, console (break-glass) password. The hostname matters: it is what devices and applications resolve for ever after.
2 · Point your reverse proxy at it: HTTPS in front, plain HTTP to the appliance. Until this is done nothing can enrol.
3 · Make an org unit or two: Start simple. Workstations and Servers is a fine first tree.
4 · Create a user: Yourself, ideally not the setup administrator — so you find out early whether an ordinary account works.
5 · Download the agent and enrol one PC: Devices → Enrol. You get a one-time PIN. Run the installer, type the PIN.
6 · Make one policy and assign it: Something harmless and visible, like a logon banner, so you can watch it land.
7 · Sign in on that PC with your directory account: The TWAD tile appears at the logon screen. This is the moment it is really working.

Do this before you need it: set up backups (System → Backup) and write down where the cluster root key is. A directory you cannot restore is a directory you are renting from luck.

Users

One account per person. Their password is the one they use everywhere.

What a user is

A person, with a username, a password, an org unit, and optionally an email. Their username is what they type at a Windows logon screen and at any application that signs in through TWAD.

Every user lives in exactly one org unit. That is what decides which policies reach them.

Try it — these are the buttons on a real user

Reset password

Sets a new password and pushes it to every PC the person has an account on, so their Windows login keeps working. It also signs them out everywhere — every browser session and every application token — because a reset usually means something went wrong.

You can tick "must change at next sign-in" so they pick their own.

Unlock

Clears a lockout caused by too many wrong passwords. It does not change the password. Use it when someone fat-fingered their way out of their own account.

Disable

The account stops working immediately — no console, no applications, no Windows sign-in — and their local accounts on managed PCs are disabled too. Nothing is deleted, and one click puts it all back.

This is what to use when somebody leaves. Delete only once you are sure nothing of theirs is needed.

Delete

Removes the account. Their local Windows accounts go with it at the next check-in, taking that profile's data on those machines with them.

You have to disable an account before you can delete it — a deliberate speed bump, because this is the one that is hard to undo.

Passwords, and where they can be changed

A managed user changes their password in one place: their TWAD portal page. Not Ctrl+Alt+Del on their PC — that is blocked on purpose.

The reason is worth knowing. TWAD keeps a hidden local Windows account in step with the directory. If Windows let someone change the local one directly, that PC would quietly disagree with the directory, and the first symptom would be RDP or a file share refusing a password they know is right.

Groups

How you target things at more than one person without listing them.

Two kinds

Static: You put people in and take them out. Ordinary, predictable, and what you want most of the time.
Dynamic: A saved query — "every user whose org unit starts with /Sales", "every device whose hostname starts with LAB-". Membership is recalculated for you, so joiners land in the right groups without anybody remembering.

What groups are used for

Targeting a policy, deploying software, granting an admin role, and controlling who may use an application. A group can hold users, devices, or other groups.

Built-in groups cannot be deleted. Domain Admins, Helpdesk and the rest are how TWAD grants its own admin roles — deleting one would quietly strip whoever held that role. Empty them instead if you do not use them.

Delegation

Giving somebody exactly as much administrator as their job needs.

How it works

A role is a set of permissions. You grant a role to a user or a group, and you can scope that grant to one org unit — which makes them a full administrator of that branch and nothing else.

This is the Active Directory idea of delegating an OU, done with fewer sharp edges.

The built-in roles

Administrators: Everything. Scope it to an org unit and it becomes a full administrator of that part of the directory only.
Helpdesk: Reset a password, unlock an account, look at a machine, run a saved script on it. Cannot change policy and cannot make anybody an administrator.
Device Enrollers: Issues enrolment PINs and nothing else. For whoever unboxes the laptops.
Audit Readers: Reads the audit log and holds no power to change anything — which is the point.

One rule worth knowing: cluster administration — joining nodes, sites, licence, the settings catalog — is deliberately not reachable from a scoped grant, however broad. An OU-scoped "full administrator" is a full administrator of that OU, not of the appliance.

Org units

The tree. It decides what reaches whom.

What they are for

Every user and every device sits in exactly one org unit. Policies, software and admin delegation are attached to org units, and by default they flow down the tree.

If you have used Active Directory this is the same idea and the same instincts apply: shape the tree around how you manage things, not around your org chart.

Rules

An org unit must be empty to delete: No child org units, devices, users, policy assignments or app deployments. The console tells you which of those is stopping you.
The last top-level org unit cannot be deleted: A newly enrolled machine has to land somewhere. Any other top-level one can go.
Renaming is safe: Policy targeting follows the rename, including for everything underneath.

Devices

The managed PCs, and everything you can do to one.

Getting a PC in

Devices → Enrol produces a one-time PIN. Install the agent on the PC and type the PIN. The PC generates its own key, TWAD issues it a certificate, and from then on it proves who it is with that key rather than any shared secret.

Try it — a device, with the buttons you actually get

Hostname	Status	Last seen
WS-MARK-01	Active	just now
SRV-FILES-01	Active	2 min ago

Remote control

You see the PC's screen and take the mouse and keyboard, in a window of its own. The person sitting there sees what you are doing — this is not a hidden session.

It works wherever the PC is, because it rides the agent's own outbound tunnel rather than needing anything open to the internet. It also handles Ctrl+Alt+Del, which most remote tools cannot, so you can reach the logon screen.

Needs: the "Remote control, terminal, live registry and files" permission. Every session is written to the audit log.

Terminal

A command prompt on that PC, running as SYSTEM, in its own window. Faster than remote control when you know the command you want and nobody needs to watch.

Services & processes

What that machine is running right now. Services with their state and start type — start, stop, restart — and processes with their memory, biggest first, which you can end.

Not remembered. Starting a service here does not make TWAD keep it started; the next policy cycle will overwrite whatever you did by hand. Anything that should last belongs in a policy.

Registry

Browse and edit that one machine's registry, live. For finding out what a value actually is while somebody is on the phone about it.

Same warning as above: an edit here does not survive a policy that manages the same value, and does not apply to any other machine. Use it to diagnose; use a policy to fix.

Files

Browse the PC's disk, pull a log off it, drop a fix onto it. Over the same tunnel, with the same audit trail — rather than talking somebody through finding a folder.

Sync now

Tells the PC to check in immediately instead of waiting for its next cycle. Use it after changing a policy when you want to see whether it worked.

Disable

The machine stops getting policy and its TWAD accounts are switched off, so nobody can sign in with a directory account. The sign-in tile disappears.

It stays enrolled, and you keep remote control — which is the point. This is for a laptop that has gone missing for a week, not one that is gone for good. One click undoes it.

Revoke

Effectively an un-enrol. The certificate stops being accepted, the local accounts TWAD made are deleted, and the sign-in tile goes. The agent stays installed but can do nothing until the machine is enrolled again with a fresh PIN.

Use this when a machine is lost or leaving. Coming back means re-enrolling.

Primary user

Assigning a machine's primary user makes TWAD create that person's local account before they ever sign in interactively. That is what lets somebody RDP into a PC they have never sat in front of. Everybody else gets an account the first time they log on at the keyboard.

Software

Getting applications onto machines, and off them.

How a deployment works

You describe a package once — an install command, optionally an installer file to upload, and a way to tell whether it is already there. Then you assign it to an org unit, a group or a device, as Install or Uninstall.

Agents pick it up at their next check-in, decide whether the machine already matches, and act only if it does not. A machine that already has the software is left alone.

Uploading an installer

If you upload the MSI or EXE, TWAD serves it to the machines itself and checks its hash before running it — so a download that got mangled or swapped fails loudly instead of running. If you would rather the command fetch its own installer (winget, a vendor URL), that works too.

Scripts

Saved commands you can run on demand, or on a timer.

Two ways to run one

On demand: Pick a script, pick machines, run. You get a job you can watch, with each machine's output. This is the "do the thing now" path.
On a timer, by policy: Add a Scheduled script setting to a policy and it runs on every machine that policy reaches, on the interval you set. This is the RMM-style recurring task.

A policy can carry several scheduled scripts — add as many as you need.

Scripts run as SYSTEM. That is what makes them useful and what makes them dangerous. Anyone who can save and run a script effectively owns every machine they can target, so treat the permission as equivalent to full administrator on those PCs.

Jobs

What happened when you asked machines to do something.

Every on-demand script run becomes a job: which machines it went to, which have picked it up, what each one printed, and what it exited with. A machine that is switched off simply has not run it yet — it will when it comes back.

This is the first place to look when "I ran that script and nothing happened".

Policies

The Group Policy half. How a setting is made to stick on a fleet.

The model

A policy is a named bag of settings. An assignment attaches it to an org unit, a group, a device or a user. A machine gets a setting when a policy reaches it through any assignment.

Each setting is tagged [Computer] or [User] and that tag decides who it applies to. You do not pick a mode — the setting knows what it is.

When two policies disagree

Higher priority wins. If priorities tie, it is settled consistently rather than randomly, so the same setup always produces the same answer.

The device page shows effective policy: every setting that actually applies, which policy won it, and what it overrode. That is the screen that answers "why is this machine like this", and it is computed on the server before anything reaches a PC.

What you can set

Anything from an imported ADMX template — the same Administrative Templates you already know — plus TWAD's own settings for the things ADMX cannot describe: local group membership, local users, scripts, scheduled tasks, certificates, wireless profiles, user rights, audit policy, security options, drive maps, shortcuts, file permissions, service state, registry values, and directory sign-in over RDP.

A policy cannot be assigned to a site. A site is a list of cluster nodes — it says where a machine checks in, not who it is. Target an org unit, a group, a device or a user instead.

Compliance

Checking that machines are how you think they are.

A compliance check says what must be true — disk encryption on, a particular file present, a registry value set, an antivirus running — and machines report against it. A policy can set something and verify it in one place, assigned to the same machines.

Non-compliant machines are visible on the device list, so "which of my PCs are not encrypted" is a question with an answer rather than a project.

Settings catalog

Where the available settings come from.

TWAD ships its own settings, and you can import Microsoft's Administrative Templates (ADMX) on top — as a zip of the whole bundle, which is the only practical way given there are hundreds of files.

Once imported they behave like any other setting: searchable, browsable by category, with the same explanation text Microsoft wrote.

Applications

Letting other software sign people in with their TWAD account.

TWAD is an OIDC provider. Register an application, give it a redirect URI, and it can offer "sign in with TWAD". Users get one password for everything and you get one place to switch somebody off.

You control which users or groups may use each application, so registering one does not hand it your whole directory.

LDAP

There is also a read-only LDAP front end, for the appliances and NAS boxes that only speak LDAP — Unraid, TrueNAS and their relatives. They can read users and groups to decide permissions. It is read-only on purpose: the directory is edited here, not from a NAS.

Signing in to a PC

The part that has to feel like a domain, and how it actually works.

What the user sees

A TWAD tile on the Windows logon screen. They type their directory username and password and they are in — with their own profile, on any enrolled machine.

What happens underneath

The tile asks the agent; the agent asks the appliance; the appliance checks the password and sends back a sealed answer. The agent then signs the user in to a local Windows account that TWAD keeps in step with the directory.

That local account is why file shares and RDP work — Windows sees an ordinary local account, so NTLM works normally. It is also why the password must only ever be changed through TWAD.

Away from the network

A laptop that cannot reach the appliance signs the user in from a cached record for a limited number of days, and says so. After that it stops — which is the offline half of revoking a device.

RDP

Turn on the Allow directory sign-in over RDP policy for the machines that need it. It enables Remote Desktop, opens the firewall rule, and turns off the pre-authentication that would otherwise refuse the connection before the TWAD tile ever loads.

You can also name the directory groups allowed to connect, which adds them to the machine's Remote Desktop Users — the RDP equivalent of putting a group in Administrators.

Scope it deliberately. Directory sign-in over RDP lowers the connection's pre-authentication protection. Turn it on for the jump box, the shared workstation or the file server — not the whole fleet.

Cluster

More than one appliance, and what to do when one dies.

Roles

Primary: The node that accepts changes. There is exactly one.
Replica: Holds a full copy and follows the primary. Serves reads.
Voter: Takes part in electing a leader. Two nodes should have one voter — two voters with no tiebreaker is the configuration that takes both nodes down.
Witness: Votes but stores no data. A tiny machine that exists to break ties, so three-node safety does not cost a third full appliance.

Try it — the two buttons people mix up

Hand over primary — the everyday one

A planned handover between two healthy nodes. The new node catches up fully before it takes over, so nothing is lost, and nothing is fenced — the old primary simply becomes a replica of the new one. Writes pause for a few seconds.

Use this before rebooting or upgrading the primary. Afterwards, point your reverse proxy at the new primary.

Promote to primary — the emergency one

For a primary that is dead and not coming back. The survivor takes over and every other node is fenced: revoked from the cluster, refused on every call, and able to return only by being reinstalled and joined fresh.

That sounds harsh and it is the point — it is what stops a revived old primary coming back and serving a stale directory alongside the new one.

Do not use this for maintenance. Reaching for it when the primary was merely going down for a reboot costs you a reinstall of a perfectly good machine.

Upgrades

The Cluster page shows a rolling-upgrade plan: which node to take down next and whether it is safe to do so yet. Replicas first, the primary last — because taking the primary down forces a failover.

Sites

Named lists of nodes. That is all a site is.

What a site is for

A site is a group of cluster nodes — "the London appliances", "the main office pair". You put nodes in a site by hand, exactly like Active Directory's Sites and Services.

Its one job is to answer "which appliance should this PC talk to". A branch office's machines should come back through the branch's own node rather than crossing a WAN link to head office.

How a machine is pointed at one

With the node affinity policy setting, which names sites in order: this office's site first, then the main office as a fallback. Because it is a policy, you target it with the same org units and groups as everything else.

Sites are not a way to target policy. A site contains nodes, not PCs, so "assign this policy to a site" is not a thing — and TWAD refuses it rather than letting you create an assignment that would silently match nothing. Use org units and groups for that; they are what they are for.

Backup & restore

Do this on your first day, not your worst one.

A backup is a full copy of the directory. Take them on a schedule, keep them somewhere that is not the appliance, and restore one at least once so you know the procedure works before you need it in a hurry.

The cluster root key is separate and it matters. Everything sensitive in the backup is encrypted under it. A backup without that key cannot be restored by anybody — including you. Record it somewhere safe and somewhere else.

Audit log

Who did what, to what, and when.

Every administrative action is recorded: sign-ins, password resets, policy changes, enrolments, remote control sessions, live registry reads, service stops. Reads are logged as well as writes — "who looked at that" is a question that gets asked after an incident.

The Audit Readers role exists so the people who need to read it (HR, compliance, an auditor) can, without being able to change anything.

Licence

What it counts, and what happens at the ceiling.

The licence sets how many users, devices and nodes you may have. The console shows what is in use against what you are entitled to.

Going over the ceiling refuses new things rather than breaking existing ones. If a licence lapses or is locked, sign-in pauses fleet-wide until it is put right — reversibly, and nothing is deleted.

Troubleshooting

The failures that actually happen, and where to look.

A policy is not applying

Check, in this order:

Is the device checking in at all — what does Last seen say? Then open the device's effective policy: if the setting is not listed, the assignment is not reaching it, so check the org unit and the assignment. If it is listed but the machine disagrees, look at the warnings on that same screen — that is where "this setting could not be turned into anything the machine can do" is reported.

Somebody cannot sign in to their PC

Is the user disabled or locked out? Is the device disabled or revoked? Is the machine online — if not, has its offline grace run out? If the tile reports that Windows rejected the stored account details, that machine's local account and the directory have drifted apart; get it online so the agent can reconcile them.

RDP is refused

Almost always one of four things, and all four have to be right: Remote Desktop enabled, the firewall rule open, pre-authentication off, and the person allowed to connect. The Allow directory sign-in over RDP policy does all four — check it is assigned to that machine and that the machine has checked in since.

A node is down

If the primary is gone, the surviving node still serves reads and still lets you sign in to the console — it will tell you it cannot make changes rather than simply failing. From there, decide honestly whether the old primary is coming back: if it is, wait or repair it; if it is not, Promote to primary on the survivor and accept that the dead one has to be reinstalled to return.

Getting into the appliance itself

The console administrator is a directory user, not a Linux one. The appliance has a separate break-glass account created at setup, and root is locked on purpose. Log in as that account at the console or over SSH and use sudo -i — never su, which cannot work because root has no password.