Microsoft cloud

The forest lives on premises, and the Microsoft 365 tenant for alphasecunited.com lives in the cloud. Identity flows upward from the directory through Entra Cloud Sync. The member server HQ-MGT01 carries the on-premises half of every link, and Intune manages the Apple devices in the same tenant. This page covers those links. The directory itself is on Active Directory, and the Windows endpoints and Action1 are on Endpoints.

How the pieces fit

Component	Runs on	What it does	Last state
Windows Admin Center 2.7.21.5	HQ-MGT01	Browser console for the five domain machines	Services running, 2026-09-25
Entra provisioning agent 1.1.2334.0	HQ-MGT01	The on-premises half of Entra Cloud Sync	Registered 2026-09-10
Azure Connected Machine agent 1.67.03504.3207	HQ-MGT01	Represents the server in Azure	Connected, heartbeat 2026-09-25
Action1 Deployer	HQ-MGT01	Agent rollout across the domain	See Endpoints
Microsoft Intune	Tenant	Apple device management	Two enrolled devices

HQ-MGT01

HQ-MGT01 is VM 303 on grey-server, a Windows Server 2025 Standard member server on the identity VLAN beside the two controllers. It sits in OU=Management,OU=Servers, gets ADM-T1-ServerAdmins as local administrators by policy, and is managed by Windows LAPS. It exists so management tooling has a domain-joined Windows host that is not a domain controller.

Windows Admin Center

I installed the gateway on 2026-09-11 and verified it on 2026-09-12. It runs as the WindowsAdminCenter service with automatic start, and I sign in with my domain account in the ALPHASEC\ form. The UPN form failed authorization.

Item	Value
Gateway version	2.7.21.5
Shared server connections	HQ-DC01, HQ-DC02, HQ-MGT01
Shared workstation connections	ObiPC, HQ-WS001
Extensions	Active Directory 0.86.0, DNS 2.76.0
Browser certificate	Self-signed for the gateway name, expires 2026-11-10
Browser access	All of Secure VLAN 50 and Secure Client VLAN 60, plus my MacBook Air M3 and Pixel on Trusted VLAN 10 through a device-specific rule
Target transport	WinRM over HTTPS, admitted on each target from HQ-MGT01 only

The gateway’s own firewall admits the three VLANs, and the UniFi policy narrows VLAN 10 down to the two devices. TrustedHosts on HQ-MGT01 lists the five connection names exactly, with no wildcard.

Why the transport is HTTPS

Four targets worked over plain WinRM from the start. ObiPC timed out intermittently. It is the only target on a different VLAN, so its traffic crosses the gateway, and UniFi intrusion prevention recorded flow matches for its “Malicious User Agents” signature group on WinRM traffic from HQ-MGT01 to ObiPC. I did not disable intrusion prevention or loosen a policy. I moved the transport to HTTPS instead.

Each of the five targets got a self-signed WinRM certificate for its full and short names, with a nonexportable private key, an HTTPS listener and a firewall rule that admits only HQ-MGT01. I imported the five public certificates into HQ-MGT01’s trusted root store and enabled HTTPS for WinRM in the gateway. The five certificates expire on 2027-09-12 and are separate from the browser certificate.

Delegation and verification

The gateway connects to targets on behalf of the signed-in user, which needs delegation. I configured resource-based constrained delegation on all five targets with HQ-MGT01 as the only allowed principal.

On 2026-09-12 I repeated the sign-in after the HTTPS switch and queried Win32_OperatingSystem on every target through the gateway’s own API, using only the browser session and no separate target credentials. All five returned HTTP 200, and fresh Kerberos sessions over HTTPS to all five reported elevated administrator tokens.

Entra Cloud Sync

Tenant and licensing

When I started, alphasecunited.com was already verified and set as the tenant’s default domain, and an unlicensed cloud-only break-glass account already existed. My own account holds Microsoft 365 Business Premium, which includes Entra ID P1 and Intune Plan 1. The three staff accounts hold Business Basic.

That split settled two decisions. Conditional Access and password writeback both need Entra ID P1 per user, so the tenant keeps security defaults on and password writeback is not configured. Passwords flow upward only. Both administrative accounts registered MFA on 2026-09-10, since Microsoft enforces it on the admin centers regardless of tenant settings.

Preparing the forest

Device sync needs a service connection point in the forest so joined computers can find their tenant. Microsoft’s script expects an Enterprise Admin. I ran it as SYSTEM on HQ-DC01 through the QEMU guest agent instead, which is the controller’s own machine identity and could write to the configuration partition, so no administrator password was involved. It points at the tenant’s initial onmicrosoft.com domain, as Microsoft specifies for a non-federated tenant.

The provisioning agent

I installed the Microsoft Entra provisioning agent on HQ-MGT01 on 2026-09-10. The interactive parts, the download and the configuration wizard, need a Global Administrator sign-in, so I did them at the server’s console. Prerequisites were already met: .NET Framework 4.8, TLS 1.2 for .NET clients, outbound HTTPS to the Microsoft sign-in endpoints, and a KDS root key on HQ-DC01 so the wizard could create a group managed service account.

Check	Result
Service	AADConnectProvisioningAgent, running, automatic
Runs as	A group managed service account created by the wizard
Allowed to retrieve its password	HQ-MGT01 only
Rights on the domain partition	Replicating Directory Changes, Replicating Directory Changes All, Reset Password, plus create, delete and write on users and groups
Agent log	Successfully registered, using the gMSA credential type

The two replication rights are what password hash sync needs. The reset right is what password writeback would use if a user in scope held P1.

Two detours are worth recording. The installer’s only Start menu shortcut opened the unrelated ECMA2Host wizard, which generated four self-signed certificates into the server’s Trusted Root store before I removed them. Then the service account page rejected my Tier 0 account with “The user name or password is incorrect” although the password was correct. That account is in Protected Users, which blocks the NTLM and plain LDAP binds the wizard’s check relies on, and five attempts tripped the PSO-Admins lockout. I unlocked it and completed the wizard once with the built-in domain Administrator, which the wizard does not keep.

Note: Neither controller audits Credential Validation failures, so those five failures produced no 4776 events, and I read the lockout from the account itself. Turning on failure auditing is an open item.

Configuration

Setting	Value
Direction	Active Directory to Microsoft Entra ID
Password hash sync	Enabled
Device sync	Enabled, in preview
Exchange hybrid writeback	Disabled
Scope	Two selected security groups, APP-EntraCloudSync-Users and APP-EntraCloudSync-Devices
Attribute mapping	Default
Prevent accidental deletion	Enabled, threshold 500

The first cycle ran on its own schedule at 2:19 PM on 2026-09-10. It created the three staff accounts and the users scope group, and every row in the provisioning log passed import, scope evaluation and export. That afternoon a staff test account signed in to Microsoft 365 with its directory password, which proved the password hash had reached the tenant.

What syncs and what does not

Object or attribute	In the tenant	Reason
Three staff accounts	Yes	Members of APP-EntraCloudSync-Users, signing in with the alphasecunited.com suffix
My daily account	Yes, since 2026-09-10	Soft-matched onto its existing cloud object
HQ-WS001 and ObiPC	Yes, as hybrid joined devices	Members of APP-EntraCloudSync-Devices
The users scope group	Yes	A group used as a scoping filter is itself in scope
Tier 0 and Tier 2 administrator accounts	No	Outside the scope groups and kept on the internal suffix. They must never exist in the cloud
Password hashes	Yes, upward only	Password hash sync is on and writeback is not configured
Account enabled state	Yes	Cloud Sync exports it, so a disabled directory account is disabled for Microsoft 365 too. I have not timed how long a change takes to land
Logon hours and workstation restrictions	No effect	Entra ID honours neither attribute
Anything back to the directory	No	Exchange hybrid writeback is off, so Cloud Sync writes nothing back

Scoping by group rather than by OU is what keeps the administrative accounts out. The portal itself calls group scoping a pilot arrangement and warns that nested membership beyond the first level is not followed, which suits a handful of direct members. Synced users carry DisablePasswordExpiration in Entra, so tenant expiry never fights the directory.

Device sync and the JoinNotFound trap

Provisioning HQ-WS001 on demand as a device first stopped with Object was skipped and SkipReason = JoinNotFound, which Microsoft does not document. The workstation meanwhile kept failing at the Device Registration Service because its device did not exist in the tenant.

The provisioning log showed the cause: the first step of every attempt was an import of type Delete. The agent applies the group scoping filter itself, before the cloud evaluates anything, and returns an object outside every scope group as a delete. HQ-WS001 was in no scope group. I created APP-EntraCloudSync-Devices rather than putting a computer into a group named for users, added it to the scoping filter, and the device exported cleanly. The workstation’s Automatic-Device-Join task then succeeded on its first run, and dsregcmd /status reported both AzureAdJoined and DomainJoined, with the device key held in the TPM.

The lesson: with group scoping, every computer that should hybrid join has to be in a scope group, or the agent never exports it. Both workstations needed provisioning on demand before they first appeared in the tenant, and whether the scheduler alone would manage it within 30 minutes is left for the next workstation.

Moving my own account onto the directory

My Microsoft 365 account already existed in the cloud and held the tenant’s administrative roles. Entra ID refuses to soft match a directory user onto a cloud account that holds an administrative role, and Microsoft recommends against syncing a directory account onto an administrator at all, because whoever controls the controllers would then hold a tenant administrator’s password.

So I split the two uses on 2026-09-10. I created a separate, unlicensed cloud-only administrator account with Global Administrator and MFA, removed every role from my daily account, and only then added the daily account to the users scope group. Provisioning on demand reported a match and an update, not a create, and the object ID was the same before and after, so the mailbox, licence and MFA methods stayed with it. The break-glass account kept Global Administrator throughout.

Azure Arc

I connected HQ-MGT01 to Azure Arc through the Windows Server setup wizard on 2026-09-12. Arc represents the server in Azure while it keeps running in Proxmox.

Item	Value
Machine	HQ-MGT01 only
Agent	Azure Connected Machine agent 1.67.03504.3207, himds running
Status	Connected, last heartbeat 2026-09-25 1:32 AM EDT
Region and cloud	eastus, AzureCloud
Controllers	HQ-DC01 and HQ-DC02 had no Arc agent when checked on 2026-09-12

I read the status back with azcmagent show. My intent is the free core inventory and management features. I have not inspected subscription billing, Defender plans or inherited policies, so a Connected status is not proof of zero charges. No Arc Run Command execution has been verified here. Group Policy onboarding is available for enrolling other domain machines in bulk, but I have not deployed it.

Microsoft Intune

Intune is the device management plane for the tenant. Identity comes from the forest, device management comes from here, and the two are separate concerns.

Item	Value
MDM authority	Microsoft Intune, service release 2608
Intune licences	One, assigned to my account
Apple MDM push certificate	Active, raised 2026-07-21, expires 2027-07-21
Apple Business Manager	Connected, one token, one device synced, expires 2027-07-21
Enrollment restrictions	The built-in default only, every platform allowed, personally owned devices allowed
Device limit	Five per user
Compliance policies	None
Conditional Access policies	None

Enrolled devices

Device	OS	Ownership	Enrollment path	Entra join type	Enrolled
iPad	iPadOS 17.7.11	Corporate	Automated Device Enrollment through Apple Business Manager	None shown	2026-09-07
MacBook Air M3	macOS 26.6.2	Personal	Company Portal, user-initiated	Microsoft Entra registered	2026-09-11

The two paths differ on purpose. Automated Device Enrollment runs inside Setup Assistant, so it needs a new or erased device, and it makes the device supervised and organisation-owned. That is right for the iPad and wrong for a laptop I bought myself. Before enrolling the Mac I audited the tenant read-only and found the push certificate, platform restriction, device limit and licence already in place. I installed the Company Portal, signed in with my daily account because it holds the Intune licence, and approved the management profile in System Settings, which macOS does not allow from the command line on an unsupervised Mac. Nothing was erased. Registered is the correct end state for a Mac, since hybrid join is Windows only.

The compliance decision

Both devices report Compliant, and neither has been evaluated against anything. The tenant has zero compliance policies and the setting “Mark devices with no compliance policy assigned as” reads Compliant, so the status is the built-in policy returning a default. I decided on 2026-09-11 to leave it that way: two devices, both mine, that I can inspect by hand faster than I could write a policy to inspect them.

Warning: The consequence is a standing rule. No Conditional Access policy may require a compliant device. It would pass for the wrong reason today and start failing the moment a real compliance policy arrived. Neither administrative account is excluded from anything, so that failure would lock me out of my own tenant. If I ever build Conditional Access for another purpose, the break-glass exclusion comes first and gets tested before the policy is enabled.

The decision gets revisited when the tenant manages a device I cannot personally inspect.

Windows workstations and Intune

HQ-WS001 and ObiPC are hybrid joined but not Intune managed. On 2026-09-12 I confirmed ObiPC had no MDM enrollment and compared Intune, ManageEngine Endpoint Central and Fleet. Intune came first, because the tenant already manages my Apple devices and my Business Premium seat covers it. The proposed path keeps the domain join, LAPS and the local-administrator policies, enrolls through the automatic-enrollment Group Policy with user credentials, and assigns settings so that Group Policy and MDM never configure the same one. That is Group Policy alongside Intune, not Configuration Manager co-management.

Enrollment is still undecided. What I deployed that day was Action1, for a narrower reason: I needed to install software on ObiPC for a restricted user the same day. If Intune enrollment happens later, software deployment is the overlap to settle first.

Open items

• Click through user, DNS and service management in the Windows Admin Center browser UI, and replace its browser certificate before 2026-11-10.
• Renew the five WinRM certificates before 2027-09-12 and update HQ-MGT01’s trust store.
• Turn on Credential Validation failure auditing on both controllers.
• Decide whether Intune enforces FileVault on the Mac with its recovery key escrowed, to match the BitLocker baseline open for the physical Windows workstation.
• Decide on Platform SSO for the Mac, which would change its join type from registered to joined.
• Renew the Apple push certificate and the Apple Business Manager token before 2027-07-21. The push certificate has to be renewed with the same Apple ID that created it, or every Apple device needs re-enrolling.
• Decide whether the two Windows workstations enroll in Intune.