Endpoints

The domain has two workstations: ObiPC, a physical Windows 11 Pro 25H2 end-user PC on Secure Client VLAN 60, and HQ-WS001, a virtual machine on the identity VLAN that exists to prove policy reaches a client. My admin workstation sits on Secure VLAN 50. This page covers how software reaches those machines, how the end-user PC is locked down, and what a physical-access test against it showed. The directory and its policies are on Active Directory, and the Apple devices are on Microsoft cloud.

Action1

Action1 is the cloud endpoint management plane I use for Windows: software deployment, patching and remote access, through an agent that polls the cloud. I deployed it on 2026-09-12 so that software reaches ObiPC through a console I control rather than through the person using the machine. An assessment the same day had put Intune first, but I needed to install software for a restricted user that day, without scoping an enrollment policy and re-checking licences first.

Item	Value
Agent	6.0.664.1, service A1Agent, LocalSystem, automatic, installed in C:\Windows\Action1\
Connected	HQ-MGT01, HQ-WS001 and ObiPC, read 2026-09-12
Deployer	A1Connector 6.0.664.1 on HQ-MGT01, running as a dedicated domain service account
Deployer scope	Every computer in ad.alphasecunited.com, class exclusions off
Domain controllers	Not enrolled. Installation fails with access denied

The agent installs under %WINDIR%, which the AppLocker baseline allows, and runs as LocalSystem, which AppLocker does not evaluate. Software Action1 deploys is therefore trusted by the allowlist. That is the design and its honest limit: the console is a way into the machine that AppLocker does not police, so its credentials deserve the same care as a domain administrator’s.

Warning: The agent download URL carries the organisation identifier, and Action1 says no login is needed to use it. Anyone holding it can enrol a machine into the organisation, so I treat it as a credential and keep it out of the repository.

Deployments and automations

The Automations page showed no entries on 2026-09-12, and no later record adds a patching or reboot automation. Deployments happen per request. The first, Chrome to ObiPC from Action1’s Software Repository, proved the path from console to cloud to agent. Since 2026-09-19 App Portal turns each install request into a deploy_package automation scoped to one endpoint. The first, 7-Zip on HQ-WS001, succeeded in thirty seconds.

Preparing the AD Deployer

The Deployer enrolls domain computers automatically from HQ-MGT01. I first prepared a Group Policy route, which Action1 recommends ahead of the Deployer, then deleted the unlinked policy once I chose the Deployer.

• Installer. Downloaded directly on HQ-MGT01 and checked before running: version 6.0.664.1 with a valid Action1 Corporation Authenticode signature. It needed an interactive console session to complete.
• Account. A dedicated service account in Admin/Tier 2/Service Accounts, marked not delegatable. Its group, APP-Action1-LocalAdmins, is nested into ADM-T2-WorkstationAdmins, so the existing workstation policy makes it a local administrator. It is also local administrator on HQ-MGT01, with no Domain Admin or Tier 1 membership.
• Workstation firewall. C-WKS-Action1-Deployer-Network adds three inbound rules on the Domain profile, for SMB, the RPC endpoint mapper and service RPC, each admitting only HQ-MGT01.
• Gateway. A UniFi policy, Allow Action1 Deployer to Secure Client, admits HQ-MGT01 to the Secure Client network with logging on.
• Scope. Widened from workstations to the whole domain. The controllers fail with access denied because the account is not an administrator there, and I changed no privileges, so their enrollment is open.

Two read-only scripts came out of this: Test-DeployerInstaller.ps1 stops unless the installer’s signature is valid and names Action1, and Test-DeployerNetwork.ps1 probes the controllers, workstations and Action1 service from HQ-MGT01 only.

The health check that crosses the gateway

An hourly alert reported UniFi intrusion prevention blocking ET RPC DCERPC SVCCTL - Remote Service Control Manager Access from HQ-MGT01 to ObiPC. The Deployer health-checks every managed computer each cycle. HQ-WS001 and HQ-MGT01 share VLAN 65, so their checks never reach the gateway. ObiPC’s check crosses to VLAN 60 and is blocked every cycle, while its agent stays connected through the cloud.

I did not open that path. Remote service control from a management server to a workstation is a standard lateral-movement technique, and this is where the inspection is worth keeping. I excluded ObiPC from the Deployer’s scope in the console instead, not in the local configuration file, which the console overwrites. The exclusion went on at 11:43 PM on 2026-09-12. I lifted it at 6:58 PM on 2026-09-18 after the rebuild, and the Deployer reinstalled the agent in five seconds. Whether it goes back on is open.

ObiPC, the end-user PC

ObiPC is the first physical machine on the domain: a Ryzen 7 7700X with 32 GB of DDR5, an RTX 3070, 1 TB and 500 GB NVMe drives and a 2.5 GbE port. It has a firmware TPM 2.0, Secure Boot on since 2026-09-11, and firmware that is password-locked with external boot disabled. BitLocker is off, and TPM plus PIN is the proposed baseline.

During setup I chose “Domain join instead”, which creates a plain local account. Signing in with a Microsoft 365 account there would have cloud-joined the machine and got in the way of the hybrid join. A bootstrap script then ran once, elevated. It reads back the TPM, Secure Boot and Windows build, sets the network profile to Private, installs OpenSSH Server with a winget fallback, installs one administrator public key, turns password authentication off, and prints the host key fingerprint, which I compared before trusting the machine. Each physical machine gets its own copy of the template, so the folder records exactly what ran where.

The offline join package travelled over SSH, so no domain administrator password was typed anywhere. ObiPC rotated its LAPS password within twenty seconds and was hybrid joined after one provisioning on demand.

The Secure Client VLAN

VLAN 60 is reserved for every end-user PC. It sits in the Internal zone, hands out the two controllers as DNS servers, and is admitted to them by Allow Workstations to AD and to the Windows Admin Center page by a separate policy. Traffic from the identity plane into this VLAN crosses the gateway and gets inspected, which is why the WinRM timeouts and the Action1 health-check blocks hit only ObiPC.

The restriction design

The goal was an allowlisted standard account: approved applications, a Settings app that stays out of the way, and no software arriving without my approval. Every restricting rule names ROL-ObiPC-Restricted, a single allow-all rule names ROL-ObiPC-Unrestricted, and the baseline every identity needs is written for Everyone. Any account that signs in should belong to one of the two groups, because an account in neither matches no allow rule, and AppLocker blocks what no rule allows.

Pro historically could configure AppLocker but not enforce it. Since KB 5024351 no particular edition is required, which is what this approach rests on. The policy is versioned as ObiPC-AppLocker.xml.

• Executables, enforced. Everyone may run from the Windows folder, minus 23 user-writable subfolders found by an ACL sweep, and both Program Files trees. Administrators and the unrestricted group run anything. The restricted group has no allow rule of its own for any path. It is denied the reset, recovery and boot tools, script and launch-proxy hosts, download-staging tools, .NET Framework build tooling and the registry editors, including their copies under WinSxS and servicing\LCU. Thirteen publisher denies follow the key binaries if they are copied elsewhere. Seven publisher allows, for Spotify, Discord, Roblox, Riot Games, Ubisoft, NVIDIA and BattlEye, let signed software that installs into the profile run.
• Installers, enforced. Everyone may run only the system installer cache, and the restricted group has an explicit deny on everything.
• Packaged apps, enforced. Signed packages are allowed, which keeps Start and Settings working. The restricted group is denied App Installer, the Microsoft Store, the Store purchase app and the Xbox app.
• Scripts, audit only. The same baseline plus eight per-user developer paths, so npm and pip shims keep working once it is enforced.

I deliberately left rundll32, msiexec, curl, cmd, PowerShell, Node, Python and VS Code runnable.

Date	Executable rules	Installer rules	Packaged-app rules	Script rules
2026-09-12	13	3	3	11, audit
2026-09-18, after the wipe	56, 44 of them denies	4	4	12, audit
2026-09-18, developer paths closed	48	4	4	12, audit
2026-09-19, Store denied	48	4	7	12, audit
2026-09-20, publisher allows	55	4	7	12, audit

The first rollout gave the Windows and Program Files trees only to the two role groups. The restricted account had signed in before its group existed, so it matched no allow rule and logged 70 blocks in two minutes until the Everyone baseline went in.

The user side, U-WKS-ObiPC-Restricted, applies through loopback. Settings uses a showonly: allowlist of display, sound, notifications, personalisation, taskbar, input, printers, region and accessibility pages, which fails closed when Microsoft adds a page. Control Panel allows nine items. The power menu, MMC snap-ins, registry tools and the Store are gone, and Chrome and Edge block extensions and executable downloads.

The directory adds logon hours of 7 AM to 11 PM and a workstation restriction to OBIPC, neither of which Entra ID honours. A session-limit script enforced a daily budget from 2026-09-12 to 2026-09-18. I rewrote it on 2026-09-28 as a one-time 90-minute pass that adds local deny-logon rights before signing the session out, ran it for about an hour, and retired it again.

The recovery-menu wipe and the lockdown

On 2026-09-18 the restricted user reset ObiPC from the Windows recovery menu. On Windows 11, “Remove everything” there needs no credentials by default, and my design had treated recovery as out of scope. The reset took the domain membership, the allowlist, SSH, the agent and the applications. The directory side was untouched, and I rebuilt and rejoined the machine to the same computer object that evening, keeping its hybrid device identity. The full write-up is with the security incidents. The response was in force by 11:35 PM:

• C-WKS-ObiPC-Lockdown. Recovery tools require an administrator, the sign-in screen has no power button, sideloading and the App Installer protocols are closed, workplace join is blocked, the machine locks after 15 idle minutes, and AutoPlay is off.
• A recovery lockdown task. Enforce-ObiPCRecoveryLockdown.ps1 runs as SYSTEM at every start and daily at 3 AM. It disables the recovery environment, which a feature update turns back on, and sets the recovery-authentication policy through the local MDM bridge.
• The developer carve-out closed. The executable allows for C:\Dev and the toolchain paths were removed, so a downloaded program has nowhere to run.
• The Application Identity service set to Automatic on the machine, since Group Policy cannot set a protected service.

Two machine-wide settings from the first pass were withdrawn because they would have restricted every account. The accepted costs: no recovery environment for me either, so an unbootable ObiPC is a rebuild, and no restart or shutdown from any menu for the restricted user.

The restricted account was disabled on 2026-09-23. I enabled it for about an hour on 2026-09-28, after installing Zoom machine-wide from its MSI so the existing Program Files rule covered it, then disabled it again.

App Portal on ObiPC

Action1’s own self-service portal was still on its roadmap, so I built one, written up at App Portal. The person at the keyboard picks an approved application and it installs as LocalSystem, with no administrator rights.

• 2026-09-19. I installed the client over SSH rather than through Action1, which would have kept the device token in the automation’s script history. It lives in Program Files, which the Everyone rule covers.
• 2026-09-20. Version 0.6.0 brought an MSI and a LocalSystem agent service. Chrome, Firefox, 7-Zip, VLC and VS Code install through Action1, and Steam, Spotify, Discord, Roblox and VALORANT through the portal’s agent. A per-user install runs with the user’s own token, so the publisher allows above are what let those applications run. With App Installer denied, they use vendor installers pinned by URL, SHA-256 and size instead of winget.

I removed Steam on 2026-09-28, because its folder under Program Files is user-writable and sat inside the Everyone allow. Whether it stays in the catalog is open.

HQ-WS001, the test workstation

HQ-WS001 proved that the Tier 2 policy and Windows LAPS reach a client, not only a server, and it was the first machine to hybrid join. On Windows 11 25H2, a scripted DiskPart answer file failed with 0x80070103 and the documented DiskConfiguration element worked first time. Since 2026-09-19 it runs sshd, reachable only from Secure VLAN 50. The VM was found stopped on 2026-09-24.

The admin workstation

Jedi PC is my Windows 11 Pro administration workstation: a 16-core Ryzen 9 9950X3D, 32 GB of DDR5, an RTX 5070 Ti, two 2 TB NVMe drives and a 2.5 GbE adapter, on its own UPS. It is the privileged workstation on Secure, VLAN 50, in the Internal zone, and was the only client there when I checked on 2026-09-19.

That VLAN is what the identity plane trusts for administration: it is admitted to the controllers, the Windows Admin Center page, RDP on all five domain machines and SSH on HQ-WS001, as a whole network rather than one host.

The physical-access exercise

On 2026-09-27 I tested what attempted sign-in at ObiPC’s keyboard looks like after someone gains physical access, as an authorized exercise of my own, then read the machine’s Security log over a fixed 72-hour window.

Finding	Result
Failed interactive sign-ins	22, all logon type 2
Rejected as a disabled account	15
Rejected with no logon servers available	4
Rejected as an unknown account name	3
Successful human sign-ins, unlocks or RDP sessions	0
Successful logon events overall	1,416, all system, service, computer-account or management activity

I separated successful events by logon type before counting any as a person. Logon auditing reported Success and Failure, retained logs reached back before the window, and no log-clear or audit-policy-change events appeared. The evidence is three JSON exports and a SHA-256 manifest.

The disabled-account rejections match the 2026-09-23 disablement. The no-logon-server failures fit the online-only sign-in policy but do not prove it alone. The exercise did not test the recovery menu, external boot, offline disk access, local-account attacks or an open session, and it changed no policy. Its fixes are follow-ups:

• Decide on Other Logon/Logoff Events auditing. It reported No Auditing, so missing unlock and reconnect events prove nothing.
• Confirm that failed sign-ins reach central monitoring and raise a useful alert. This review read local logs only.
• Repeat the offline sign-in checks with a bounded plan: times, identity entered, network state and expected events.

Open items

• Decide whether the Action1 exclusion for ObiPC goes back on, and confirm Action1 patches the software installed outside it.
• Deploy Git, Node.js and Python to ObiPC from Action1.
• Walk the restricted experience with the test account, then move it back to the unrestricted group.
• Enforce the Script collection after a week of audit events.
• Settle BitLocker with TPM and PIN for ObiPC, with the recovery key in the directory.
• After every feature update, confirm the recovery environment was disabled again.