Technical Training Module
Managing Non-Domain Windows Endpoints with Delinea
A deep-dive into extending Delinea's privileged access management to workstations and servers outside Active Directory — covering workgroup support, local account vaulting, agentless session brokering, and enterprise-scale security architecture.
01 Overview & Scope
Understanding the non-domain challenge in enterprise PAM
Most enterprise PAM deployments begin with Active Directory as their foundation — users and computers are domain-joined, Group Policy enforces baselines, and AD accounts drive authentication. But the real world is messier. Workgroup machines, DMZ servers, legacy systems, lab environments, IoT management hosts, and cloud-provisioned VMs frequently sit outside AD's reach.
This module covers how Delinea (Secret Server and Privilege Manager) handles these "unmanaged" endpoints at enterprise scale — without compromising on security posture.
Workgroup Machines
Windows endpoints not joined to any domain, managed via local accounts with no central identity directory.
Local Account Vaulting
Discovery, check-in/out, rotation, and auditing of local Windows accounts within Delinea's vault.
Remote Session Brokering
Launching privileged RDP/SSH sessions to non-AD machines through the Delinea session proxy.
Zero-Trust Architecture
Securing unmanaged endpoints without AD trust chains, using local agent attestation and certificate-based auth.
Why Non-Domain Management Is Harder
Domain-joined machines benefit from implicit trust: the Kerberos ticket, the computer account in AD, and Group Policy all reinforce each other. For non-domain machines, every one of these trust anchors is absent. Delinea must compensate by:
Key Insight This module covers both Secret Server (vault + session brokering) and Privilege Manager (endpoint least privilege). Understanding which product handles which function is critical for non-domain deployments.
02 Workgroup Machine Support
Adding non-domain computers to Delinea's managed inventory
Delinea Secret Server can manage Windows machines regardless of domain membership. The key concept is that the machine is represented as a managed computer object in Secret Server's database, not in Active Directory. This unlocks discovery scanning, heartbeat checks, and automated password rotation for workgroup endpoints.
Machine Registration Methods
🔎 Method A — Network Scanner Discovery
Secret Server's built-in Discovery Scanner can target IP ranges or host lists without requiring domain credentials. Configure an IP Range Scanner in Admin → Discovery → Edit Discovery Sources.
# Discovery Source: IP Range (non-domain)
Scanner Type : Windows
IP Range Start : 10.20.5.1
IP Range End : 10.20.5.254
Credential Secret : Workgroup-Admin-Shared # local admin cred
Port Scan : 445, 3389
OS Filter : Windows*
Domain Filter : NONE # leave blank = workgroup only
Machines discovered this way are added to a non-domain computer group and can be targeted by password rotation rules and session policies.
📋 Method B — Manual Import via CSV
For air-gapped or segmented environments where network scanning is not permitted, use the bulk computer import. Navigate to Admin → Discovery → Import and provide a CSV with these columns:
ComputerName, IPAddress, OperatingSystem, ComputerType, Domain
LAB-WRK-01, 10.20.5.11, Windows 10, Workstation, WORKGROUP
DMZ-SRV-02, 10.30.1.5, Windows Server 2022, Server, WORKGROUP
Setting the Domain column to WORKGROUP (or any non-AD value) tells Secret Server to treat these as non-domain endpoints and skip AD-based authentication flows.
🤖 Method C — Agent-Based Self-Registration
Install the Delinea Agent (used by both Secret Server and Privilege Manager) on the target machine. On first run, the agent self-registers with the Secret Server instance by calling the registration endpoint over HTTPS.
# Agent silent install + registration (run as SYSTEM or local admin)
msiexec /i DelineaAgent.msi /qn `
SS_URL="https://secretserver.corp.local" `
REG_KEY="wrkgrp-onboard-token-abc123" `
MACHINE_GROUP="Workgroup-Endpoints"
The registration token is a one-time-use code generated in Secret Server under Admin → Agents → Registration Tokens. This ensures only authorized machines can self-register without requiring an AD computer account.
Heartbeat & Connectivity Verification
Once registered, each non-domain computer gets a heartbeat schedule. For workgroup machines, the heartbeat uses local credential authentication (stored in the linked Secret) rather than domain trust.
| Heartbeat Status | Meaning | Action |
|---|---|---|
| ● Success | Credential valid, machine reachable, RPC responding | None required |
| ● Unable to connect | Machine offline or firewall blocking WMI/RPC (ports 135, 445) | Check network path; verify Windows Firewall exceptions |
| ● Failed | Credential rejected — password likely drifted out of sync | Run manual password change; check local account lockout |
| ● Pending | Heartbeat not yet run since registration or password rotation | Trigger heartbeat manually or wait for next scheduled run |
WMI/RPC Firewall Requirement Non-domain machines do not automatically receive the domain GPO that opens the remote management firewall ports. You must manually enable the Windows Management Instrumentation (WMI-In) and File and Printer Sharing firewall rules via local policy, startup script, or your existing endpoint management tool (SCCM, Intune, Ansible, etc.).
03 Local Account Vaulting
Discovering, storing, rotating, and auditing local Windows credentials
On a non-domain machine, every privileged access is via a local account — typically Administrator or a named local admin. Left unmanaged, these accounts share passwords across machines and never rotate. Delinea's vault closes this gap.
Secret Template: Windows Local Account
Delinea ships with a built-in "Windows Account (Local)" Secret Template. This template stores the fields required to authenticate to and rotate a local Windows account:
Machine : LAB-WRK-01 # hostname or IP
Username : Administrator
Password : •••••••••••••••• # encrypted at rest (AES-256)
Domain : [blank] # leave empty for local accounts
Port : 3389 # for session launcher
Heartbeat : Enabled
Auto-Change : Enabled — Every 30 days
Change Template : Windows Local Account
Password Rotation — How It Works
For non-domain machines, Secret Server uses Windows Remote Procedure Call (RPC) via the NetUserSetInfo API to change passwords. This does not require the machine to be domain-joined — it only needs the current local credential to be valid and network connectivity on port 445.
Rotation Trigger
Triggered by schedule (e.g., every 30 days), post-checkout (one-time-use mode), or manually. Secret Server queues a Remote Password Change (RPC) job.
Privileged Account Selection
The rotation uses a Privileged Account Secret — a separate local admin credential on that machine with permission to change other accounts' passwords. Alternatively, the same account can rotate itself.
RPC Password Change
Secret Server connects to the machine over SMB (port 445) using the privileged account and issues NetUserSetInfo with a newly generated password conforming to the Secret Policy password complexity rules.
Vault Update + Heartbeat
On success, the new password is encrypted and stored in the vault. A heartbeat immediately confirms the new credential works before the change is considered complete.
Bulk Discovery: Finding All Local Accounts
Delinea's Discovery engine can enumerate all local accounts on a workgroup machine using the same local admin credential. This surfaces hidden or forgotten local accounts (e.g., LocalService, legacy support accounts) that should be vaulted or disabled.
Discovery Scanner Type For non-domain machines, select "Local Windows Accounts" as the Account Scanner Type under the Discovery Source. This uses NetLocalGroupGetMembers and NetUserEnum APIs rather than LDAP queries.
Secret Policy Configuration for Non-Domain Machines
| Policy Setting | Recommended Value (Non-Domain) | Rationale |
|---|---|---|
| Auto-Change | Enabled · 30 days | Local accounts have no Kerberos expiry; rotation must be enforced by the vault |
| Check-Out Required | Enabled | Prevents concurrent use of the same local admin across multiple sessions |
| Check-Out Interval | 1–4 hours max | Limits exposure window for high-privilege local accounts |
| Change on Check-In | Enabled | Rotates password after every checkout — no standing privilege |
| Heartbeat Interval | Every 4 hours | Detects local password drift early; workgroup machines lack domain health signaling |
| Hide Password | Enabled | Forces use of session launcher; prevents clipboard copy of local admin password |
04 Remote Session Initiation
Brokering RDP and other sessions to non-domain endpoints
Delinea's Session Connector (formerly Connection Manager / Distributed Engine proxy) acts as a session broker: it injects credentials into the session on behalf of the user, so the end user never sees the actual local admin password. This works equally well for domain and non-domain targets.
Session Flow: Non-Domain RDP
↑ Full audit trail · session recording · no credential exposure to end user
User sees
What actually happens
Prerequisites for Non-Domain RDP Sessions
Network Connectivity
Session Proxy (Distributed Engine) must have TCP 3389 access to the target. The end user's workstation only needs access to the Proxy — never directly to the target machine.
Valid Local Credential
A vaulted "Windows Local Account" Secret must exist for the target machine and pass heartbeat checks before a session can be launched.
NLA Configuration
If Network Level Authentication is enforced on the target, the proxy performs NLA using the vaulted local credential. NLA over NTLM (not Kerberos) is used for workgroup machines.
Session Recording Policy
A Secret Policy must be applied to the local account Secret that enables session recording. Recording is stored in Delinea's vault or an external storage path — not on the target machine.
Configuring the Session Launcher
The Launcher is configured on the Secret Template level. For "Windows Account (Local)" secrets, map the launcher fields as follows:
# Secret Server → Admin → Secret Templates → Windows Account (Local)
# → Edit → Launcher tab
Launcher Type : Remote Desktop
Machine : $MACHINE # maps to Machine field
Username : $USERNAME # maps to Username field
Password : $PASSWORD
Domain : [blank] # Critical: empty = local account login
Connect as Credentials: Yes
Use Proxy : Yes
Record Session : Yes
Critical: Leave Domain Blank When logging into a local account via RDP, the domain field must be empty or set to the machine's hostname. If a domain name is passed, Windows will attempt domain authentication and fail for workgroup machines. A common misconfiguration is copying a domain account template and leaving the domain field populated.
SSH Sessions to Non-Domain Windows
Windows Server 2019+ and Windows 10+ include OpenSSH Server as an optional feature. Delinea can broker SSH sessions to these machines using a "Unix Account (SSH)" secret pointing to a local Windows account, with the same session proxy architecture. This is preferred for headless servers or scripted access patterns.
05 Security Architecture
How Delinea secures non-domain endpoints without AD trust chains
For domain-joined machines, Active Directory provides an implicit trust fabric — computer accounts, Kerberos, and GPO all contribute to a layered security model. Delinea must recreate this security posture through its own mechanisms when managing workgroup endpoints.
Trust Establishment: No AD — Now What?
Non-Domain Trust Architecture
DELINEA LAYER
+ API TOKEN
CREDENTIAL
TARGET LAYER
Key Security Controls
🔒 Credential Isolation — No Pass-the-Hash Exposure
Because the session proxy injects credentials at the protocol level, the local admin password hash never traverses the network in a form that can be intercepted for PTH attacks. The Distributed Engine holds credentials in memory transiently during session setup only.
Credentials are encrypted in-transit via TLS 1.2+ between Secret Server and the Distributed Engine. The Distributed Engine itself has a unique TLS client certificate issued by Secret Server — this certificate is used for mutual authentication, meaning even a compromised Distributed Engine cannot authenticate to a different Secret Server instance.
📹 Session Recording & Audit for Workgroup Endpoints
Session recordings are captured at the proxy layer — no recording agent is needed on the target machine. This is critical for workgroup machines where deploying endpoint agents may not be feasible. The recording captures full screen video, keystroke metadata, and command activity (for SSH sessions).
Recordings are stored in Secret Server's blob storage (SQL database or external file store) and are associated with:
🏛️ Privilege Manager on Non-Domain Machines
Delinea Privilege Manager (application control + local admin rights management) can run on workgroup machines via the Delinea Agent. Without AD, application policies are delivered via the agent's direct connection to the Privilege Manager server over HTTPS rather than through Group Policy.
Key capabilities on non-domain machines include:
Machine groups in Privilege Manager can be defined by IP range, hostname pattern, OS version, or agent registration tag — fully replacing OU-based targeting.
🔑 Local Administrator Password Solution (LAPS) for Non-Domain
Microsoft LAPS only works for domain-joined machines (it stores passwords in AD computer object attributes). For non-domain endpoints, Delinea's Secret Server serves as a LAPS replacement — each machine gets a unique local admin password rotated on schedule, stored in the vault, and accessible only via checkout with full audit trail.
This directly addresses the lateral movement risk of shared local admin passwords (which enabled the famous NTLM relay / PTH attack chains on workgroup networks).
Threat Model: What's Mitigated?
| Threat | Without Delinea | With Delinea (Non-Domain) |
|---|---|---|
| Shared local admin passwords | Unmitigated | Per-machine unique, auto-rotated |
| Pass-the-Hash lateral movement | High Risk | Mitigated — unique passwords per host |
| Standing local admin access | Always present | JIT via checkout + change on check-in |
| Unaudited privileged sessions | No audit trail | Full session recording at proxy |
| Forgotten/rogue local accounts | Unknown | Discovery scan surfaces all accounts |
06 Deployment at Scale
Managing hundreds or thousands of non-domain endpoints efficiently
The architectural patterns for managing 10 workgroup machines are the same as managing 10,000. What changes is the organizational structure, automation tooling, and Distributed Engine topology needed to keep the solution performant and maintainable.
Organizational Structure: No OUs — Use Folders & Groups
In an AD deployment, machines are organized via Organizational Units, and Secret Server maps to those OUs. For non-domain machines, the equivalent constructs are Secret Folders and Computer Groups:
Secret Folder Structure
├── 📁 DMZ Servers
│ ├── 🔑 DMZ-SRV-01 · Admin
│ └── 🔑 DMZ-SRV-02 · Admin
├── 📁 Lab Workstations
│ ├── 🔑 LAB-WRK-01 · Admin
│ └── 🔑 LAB-WRK-02 · Admin
└── 📁 Cloud Ephemeral VMs
Policy Application
Automation: Bulk Secret Creation via API
For large fleets, use Secret Server's REST API to create secrets programmatically during machine provisioning. Integrate into your existing automation (Ansible, Terraform, CI/CD pipelines):
# Example: Create local account secret via SS REST API
$body = @{
name = "$machineName - Local Administrator"
secretTemplateId = 6036 # Windows Account (Local) template ID
folderId = 218 # Target folder ID
items = @(
@{ fieldName = "Machine"; itemValue = $machineName }
@{ fieldName = "Username"; itemValue = "Administrator" }
@{ fieldName = "Password"; itemValue = $generatedPassword }
)
secretPolicyId = 42 # Non-domain strict policy
} | ConvertTo-Json
Invoke-RestMethod -Uri "$ssUrl/api/v1/secrets" `
-Method POST `
-Headers @{Authorization = "Bearer $token"} `
-Body $body
Distributed Engine Topology for Non-Domain Networks
Deploy Distributed Engines in the same network segment as the non-domain machines they manage. Engines communicate outbound to Secret Server over HTTPS/443 only — no inbound firewall rules needed. This makes them ideal for DMZ, isolated lab, and cloud VPC deployments.
| Network Zone | Engine Placement | Manages |
|---|---|---|
| Corporate LAN | Primary SS Server (direct) | Domain-joined + workgroup LAN machines |
| DMZ | 1× Distributed Engine in DMZ | DMZ workgroup servers (no cross-firewall cred injection) |
| Isolated Lab | 1× Distributed Engine per lab segment | Lab workstations; engine relays over bastion |
| Cloud VPC | 1× Engine per VPC / region | Cloud VMs, spot instances, non-AD servers |
Engine Sizing Rule of Thumb A single Distributed Engine can handle approximately 1,000 heartbeat cycles per hour and 50 concurrent session proxies. For large non-domain fleets with high heartbeat frequency, add engines per zone and configure engine pools for load distribution.
07 Knowledge Check
Validate your understanding of non-domain endpoint management
Complete all five questions to finish the module. Your selections are saved as you go.
1 / 5 — When Secret Server performs a password rotation on a workgroup machine, which protocol and API does it use?
2 / 5 — When configuring an RDP Launcher for a local (non-domain) Windows account, what is the correct value for the Domain field?
3 / 5 — What is the primary advantage of the Session Proxy (Distributed Engine) for non-domain endpoint access?
4 / 5 — Delinea's approach to non-domain machines effectively replaces which Microsoft technology that only works with domain-joined computers?
5 / 5 — Where should a Distributed Engine be placed when managing workgroup machines in a DMZ?