How the 365TUNE Hybrid Agent is secured
Who can register an agent, the credentials it holds, least privilege in Active Directory, what leaves the server, the threat model and a checklist.
This article covers the controls that protect your directory: who can register an agent, the credentials the agent holds, what its service account may do, what leaves the server, the threat model and a checklist for your own deployment. For what the agent is, read What is the 365TUNE Hybrid Agent; for the architecture and the path of a change, read How the 365TUNE Hybrid Agent works.
Who can register an agent
An agent can be registered only by a person who is invited to the 365TUNE tenant that owns the server, with a role that allows agent registration, signing in from that tenant's own Microsoft Entra directory. Two independent authorities have to agree before an agent exists: 365TUNE, which checks the invitation and the role, and your Active Directory, which requires administrator rights for the service account and delegation steps.
Tenant binding. The sign-in token names the Microsoft Entra tenant it was issued by. 365TUNE maps that tenant to the 365TUNE tenant connected to it and checks the signed-in user's role there. The installer then proves that the server's forest belongs to the same tenant, using three signals in order: the Entra device-registration record that Entra Connect or hybrid join writes into the forest; a verified domain of the tenant that is also a UPN suffix or domain name of the forest; and Microsoft's public domain lookup. If the forest points at a different tenant, or no signal matches, registration stops before any key is created. After registration the installer also confirms that 365TUNE recorded the agent under the same tenant, and reports a mismatch without installing anything. The evidence is sent to 365TUNE with the registration and kept for audit. The decision to allow registration rests on your invitation and role, not on the evidence.
What this means in practice
| Situation | Result |
|---|---|
| Administrator of your own tenant, registering your own server | Allowed |
| A technician from your managed service provider, invited to your tenant with a role that allows agent registration | Allowed |
| The provider's own account, signing in from the provider's directory | Refused: the token belongs to the provider's tenant, not yours |
| A guest account signing in from its home directory | Refused for the same reason |
| A work account with no 365TUNE invitation, or with a role that does not allow registration | Refused |
A managed service provider's own account, a guest from another tenant, or a work account with no 365TUNE invitation cannot register an agent. The person who registers must be invited to your 365TUNE tenant with a role that allows agent registration, and must sign in from your own directory.
Multi-factor authentication. Registration is a privileged act. 365TUNE publishes an authentication context for it so that your Conditional Access policy can require multi-factor authentication or a compliant device for the registration sign-in specifically, independent of your policy for everyday portal use. Device-code sign-in is not offered, because it is a known phishing vector. If your policy requires phishing-resistant sign-in, the server needs a security key, or you register from a server where one can be used.
Notification and limits. Every successful registration notifies the tenant's administrators with the server name, forest, registrant and time, and each tenant has a ceiling on active agents.
The trust bootstrap
Registration turns a one-time, person-bound sign-in into a long-lived, machine-bound identity for the agent. Three things are created, and each has a single purpose.
| Credential | Created where | Used for | Protection |
|---|---|---|---|
| 4096-bit RSA private key | On the server, in the Windows machine key store, marked non-exportable | Proves the agent's identity in every TLS connection to 365TUNE and to the message queue | Never leaves the server; readable only by the service account; cannot be copied to another machine |
| Agent certificate | Issued by 365TUNE for the key above; subject bound to your tenant | Mutual TLS: 365TUNE accepts calls on the agent endpoints only from a certificate it issued, and the agent presents it on every call | Valid 12 months, renewed automatically from 30 days before expiry, revocable from the portal |
| Command signing secret | Generated by 365TUNE at registration, delivered once over the registration call | Every command 365TUNE sends is signed with it; the agent verifies the signature before anything else | Stored only inside the DPAPI-protected configuration on the server and in 365TUNE's key vault; never logged |
The sign-in token that started registration is held in memory only, passed to the elevated tool over an access-controlled pipe, and wiped the moment the registration call completes. It is valid for about an hour and for one purpose, registering, so a captured token cannot read reports or change settings.
All connections from the server use TLS 1.2 or 1.3 with online revocation checking, both from the installer and from the running service. The service also declines TLS session resumption, so a renewed certificate is presented on the very next connection rather than a resumed session with the old one.
Least privilege in Active Directory
The agent runs as a group managed service account (gMSA), created in your domain during registration. A gMSA has a long random password that Active Directory rotates automatically every 30 days and that only the servers you authorise can retrieve. No person knows it, it is never typed or stored on the server, and it cannot be phished or reused elsewhere. Only the registered server is permitted to retrieve it.
What the service account can do is chosen per agent in the 365TUNE portal, from a fixed set of capabilities. Nothing is selected by default. During registration the tool delegates exactly the Active Directory right each selected capability needs, and nothing more, scoped to the organisational units you authorised and their child units:
| Capability | Active Directory right delegated |
|---|---|
| Modify attributes | Write the allow-listed attributes on user objects |
| Enable or disable accounts | Write the Account Restrictions property set on user objects |
| Unlock accounts | Write the Account Restrictions property set on user objects |
| Reset passwords | The Reset Password extended right on user objects; the agent never reads a password |
| Group membership | Write the member attribute on group objects |
| Create users | Create user objects in the authorised units |
Agent version: every capability other than attribute changes needs agent 1.0.12 or later. Earlier versions apply attribute changes only.
Whatever the selection, the account can log on as a service on the registered server and read the agent's own configuration folder and certificate private key, so that the service can start and authenticate.
The agent enforces the same selection in software: a command for a capability you have not selected is refused before Active Directory is touched, so the portal selection and the delegation always agree.
That table is the whole of it. The account holds rights only inside the authorised units, only for the selected capabilities and only over the delegated attributes; it is not a member of any administrative group and has no right over its own delegation. The Domain Admin rights used to create the account and apply the delegation belong to the person registering and are used only during those minutes; they are not stored and the service never has them.
If you later change the authorised units, the capabilities or the attribute list in the portal, the agent's runtime checks follow the portal at the next refresh, and a --sync-permissions run on the server re-applies the Active Directory delegation to match. Uninstalling the agent removes the service; the service account and its delegation are removed with the documented clean-up steps, so nothing silent is left behind.
Changing the authorised units, the capabilities or the attribute list in the portal updates the agent's own checks at the next refresh, but the Active Directory delegation stays as it was set at registration until you run the permissions sync on the server. Run it after every such change so the two match.
What leaves the server, and what never does
| Leaves the server | When | Content |
|---|---|---|
| Certificate signing request | Registration | The public key and the server name; no private key |
| Directory evidence | Registration | Forest name, domain names, UPN suffixes and the tenant id the forest points at; no user data |
| Heartbeat | Every 60 seconds | Agent id, version, certificate thumbprint and expiry, service state |
| Command results | After each command | Command id, outcome, error text if any |
| Audit records | After each command | Command id, target user, attributes changed, outcome, time |
| Configuration requests | Every few minutes | A request for your current organisational units, attribute list and allowed actions; nothing about your directory is sent |
| Never leaves the server | Why |
|---|---|
| The agent's private key | Non-exportable, machine key store |
| Your administrator credentials | Used once, in the elevated tool, from memory; the sign-in token is wiped after registration |
| Passwords or password hashes | The agent never reads them. With the reset capability selected it sets the value a command carries, and that value is never logged or sent back |
| Directory contents beyond the attributes it is told to change | The agent does not enumerate or export your directory |
| The command signing secret | Delivered once, stored encrypted, never transmitted again |
Attribute values that the agent writes are those 365TUNE sends it, so the data in a command is data the portal already holds. The agent sends no telemetry other than the heartbeat and audit records above.
Secrets on the server
- Private key. Generated in the Windows machine key store and marked non-exportable. Windows refuses to export it, even to an administrator; it cannot be copied to another host. Only the service account is granted read access to the key file.
- Configuration file. The agent's configuration, including the command signing secret, is encrypted with the Windows Data Protection API in machine scope and carries an integrity check. It can be decrypted only on the machine that wrote it, and a file edited by hand fails the integrity check and is refused.
- In memory. The signing secret is held wrapped in memory and unwrapped only for the moment each signature check takes. The sign-in token used at registration is zeroed as soon as the registration call returns.
- Replay state. The list of commands already seen and the last accepted sequence number are kept in protected files so that a restart cannot be used to replay an old command.
- No secrets in logs. The event log and the setup log carry command ids, outcomes and error text; never the token, the secret or the key.
Anyone with local administrator rights on the server can use the agent's key in place, even though it cannot be exported. Treat the server as a privileged host: limit who can sign in to it, patch and monitor it, and revoke the agent in the portal if you suspect it is compromised.
Threat model
| Threat | What stops it |
|---|---|
| Someone on the network intercepts traffic between the server and 365TUNE | TLS 1.2 or 1.3 with certificate revocation checking on every connection; the agent's own certificate on every call after registration. A proxy that is trusted by the server can inspect traffic, but gains a short-lived registration token at most, never the private key or the signing secret |
| A forged or replayed command reaches the agent | Every command is signed with a secret only 365TUNE and this agent hold, carries a time limit, a unique id and a sequence number; duplicates and stale commands are rejected and logged, including across restarts |
| A command asks for something outside the agreed scope | The agent checks action, organisational unit and attribute against your portal configuration; Active Directory separately enforces the delegation granted to the service account |
| A 365TUNE account is phished and used to register an agent | Registration needs an invitation to your tenant with the right role, a sign-in from your own directory, and a forest that provably belongs to your tenant; multi-factor can be required through Conditional Access; administrators are notified of every registration; agents per tenant are capped |
| A managed service provider's account, or a guest, tries to register against your forest | Refused: the sign-in token belongs to another directory |
| The agent server itself is compromised | The attacker can do only what the service account may do, within the capabilities you selected, inside your authorised units and attributes; the key cannot be exported; revocation from the portal cuts the agent off; the event log and portal audit show what it did |
| Someone copies the agent's files to another machine | The key is non-exportable and the configuration is bound to the original machine by DPAPI; the copy is useless |
| A modified installer is used | The installer is signed; evidence it sends that contradicts the tenant raises an alert; the API, not the installer, decides who may register |
| An insider at 365TUNE tries to act on your directory | Commands reach the agent only through the signed channel; every action is logged on your server; the agent's scope is set by your administrators, not by 365TUNE staff |
| A leaked registration token | Valid for about an hour and for one scope only; the API additionally refuses tokens outside its issue window |
| Denial of service against the agent | The agent needs no inbound port, so nothing can be sent to it directly; a flood on the queue is rejected at signature check, and 365TUNE rate-limits the registration endpoints |
Security checklist for customers
Before deployment
- Choose a member server rather than a domain controller, patched and monitored like any privileged host.
- Decide which capabilities, organisational units and attributes 365TUNE may use, and configure them in the portal before registering; an agent with no authorised units does nothing.
- Invite the person who will register with the agent registration role only, from your own directory, and require multi-factor authentication for the registration sign-in through a Conditional Access policy using the published authentication context.
- Allow outbound HTTPS to login.microsoftonline.com, app.365tune.com and your Service Bus namespace; confirm that any TLS inspection proxy is trusted by the server and does not rewrite error responses.
- Confirm the Key Distribution Service root key exists and the Active Directory PowerShell module is installed on the server.
After deployment
- Review the registration notification and the agent list in the portal; revoke anything unexpected.
- Forward the server's Application event log entries for 365TuneHybridADAgent to your SIEM, and alert on rejected commands and certificate renewal failures.
- Re-run the permissions sync on the server after changing capabilities, authorised units or attributes in the portal, so the Active Directory delegation matches.
- Revoke the agent in the portal before retiring, rebuilding or re-imaging the server, and before handing the server to another team.
- Include the agent server and the service account in your periodic access review.
Frequently asked questions
Can my managed service provider register the agent for me? Not with the provider's own account. The person who registers must be invited to your 365TUNE tenant and sign in from your directory. A provider's technician can be invited to your tenant with the agent registration role for that purpose.
Can the agent reset passwords, change group membership or create users? Only if you select those capabilities for the agent in the portal. Each selected capability delegates one specific Active Directory right to the service account, scoped to your authorised units, and the agent refuses commands for any capability that is not selected. Deleting users is not a capability; a leaver is disabled, never deleted.
What if I lose the server? Revoke the agent in the portal; its certificate, signing secret and queue access are invalidated in one step. Register a replacement server; it receives a new identity.
Read next
Updated about 19 hours ago