AD & Identity Integration

ad-identity-integration — Round 1 Research Report

Session: 20260321-0115 Domain: AD Integration, Entra ID, SSPR & Cached Credentials Date: 2026-03-21 Tools Used: mcp__claude_ai_Tavily__tavily_search (12 queries), mcp__exa_websearch__web_search_exa (2 queries), WebFetch (7 page fetches)

Executive Summary

NetBird integrates with Microsoft Entra ID via an App Registration using Microsoft Graph API permissions (User.Read.All, Group.Read.All). It supports both user and group synchronization with automatic provisioning and deprovisioning capabilities. SSPR with password writeback requires Entra ID P1 (minimum) or Microsoft 365 Business Premium, plus Microsoft Entra Connect (or Cloud Sync) configured on-premises.

The critical cached credential problem is a known limitation documented by Microsoft: hybrid AD-joined devices require line-of-sight to a domain controller after an SSPR password reset to update cached credentials. An always-on VPN like NetBird solves this by maintaining persistent connectivity to DCs. However, NetBird does not currently support true pre-logon VPN (authenticated user tunnel before Windows login) — this is an open feature request. A workaround exists using setup keys (machine-level authentication), which establishes the tunnel at boot time under the SYSTEM account, providing DC connectivity at the login screen. This is a workable but imperfect solution.

Findings

Question 1: NetBird Microsoft Entra ID Integration

Confidence: HIGH (verified from official NetBird documentation)

App Registration Setup:

Register an application in Entra ID (Azure AD)
Required Azure roles: Application Administrator, Cloud Application Administrator, or Global Administrator
Store the Application (client) ID and Directory (tenant) ID
Create a client secret

Microsoft Graph API Permissions Required:

User.Read.All (Application permission) — read user profiles, group memberships, reports
Group.Read.All (Application permission) — read group information
Admin consent must be granted for these permissions

User and Group Sync:

YES, supports both user AND group sync
By default, syncs ALL users and ALL groups from Entra ID
Optional filtering: add user/group filters to sync only specific subsets
Groups from Entra ID map to NetBird groups, usable in access control policies

Sync Frequency:

The documentation states “NetBird will now automatically sync with your Microsoft Entra ID at regular intervals” but does NOT specify the exact interval
Manual sync can be triggered at any time from the dashboard
The Intune integration documentation mentions syncing “every few minutes”
Best estimate: sync occurs every 5-10 minutes (unconfirmed exact number)

Auto-Provisioning/Deprovisioning:

YES — documented for “automating onboarding and offboarding processes”
When a user is added to a synced group in Entra ID, they are provisioned in NetBird at the next sync
When a user is removed from Entra ID (or from synced groups), their access is revoked
NetBird also supports SCIM protocol for identity providers that support it
JWT Group Sync is available as an alternative: groups from JWT claims are automatically created/assigned on authentication

Availability:

IdP-Sync is only available in the cloud version of NetBird on the Team plan and above
Self-hosted deployments use JWT group claims or SCIM instead

Sources:

Question 2: SSPR Password Writeback Technical Flow

Confidence: HIGH (verified from official Microsoft documentation)

Licensing Requirements:

Feature	Free	M365 Business Std	M365 Business Premium	Entra ID P1/P2
Cloud-only password change	Yes	Yes	Yes	Yes
Cloud-only password reset	No	Yes	Yes	Yes
Hybrid password change/reset with writeback	No	No	Yes	Yes

Minimum for writeback: Entra ID P1 or Microsoft 365 Business Premium
P2 is NOT required for writeback; P1 is sufficient
Standalone M365 Basic and Standard do NOT include writeback

Entra Connect Requirements:

Current version of Microsoft Entra Connect (or Microsoft Entra Connect Cloud Sync)
Domain controllers can run any supported version of Windows Server
Both Entra Connect and Cloud Sync can be deployed side-by-side in different domains
Cloud Sync provides higher availability (no single instance dependency)

Supported Hybrid Identity Models:

Password hash synchronization
Pass-through authentication
Active Directory Federation Services (ADFS)

Exact Technical Flow (9 steps):

Check password type: System verifies the user has an on-prem managed password and that the writeback service is running
Authentication gates: User passes MFA/authentication methods configured for SSPR
Password selection: User enters and confirms new password on the Reset Password page
Encryption (2048-bit RSA): Plaintext password is encrypted with a public key created during writeback setup
HTTPS transport: Encrypted password is packaged into a payload sent over HTTPS to a tenant-specific Azure Service Bus relay (protected by a randomly generated password only the on-prem installation knows)
Service Bus pickup: The password-reset endpoint on-prem wakes up and sees the pending reset request
User lookup: The sync engine uses the cloudAnchor attribute to find the user through the connector space -> metaverse -> AD DS object chain (uses Microsoft.InformADUserAccountEnabled.xxx sync rule for multi-forest)
Password set: Direct password reset attempt in the appropriate AD DS forest via the AD DS SetPassword API (enforces on-prem password policy: complexity, age, history, filters)
Result: Success notification to user, or error with guidance

Security Model (4 tiers):

Tenant-specific Service Bus relay with randomly generated strong password
Cryptographically strong symmetric key for password encryption
TLS/SSL for all communication (outbound port 443 only — no inbound firewall rules needed)
Message expiration: messages timeout and are removed after several minutes if the on-prem service is down

Encryption Details:

Password encrypted with 2048-bit RSA key
Entire package encrypted with 256-bit AES-GCM
All communication over TLS/SSL
Automatic key rollover every 6 months

Sources:

Question 3: How Always-On NetBird Solves the Cached Credential Problem

Confidence: HIGH (verified from Microsoft documentation + real-world community reports)

The Problem (Microsoft’s own documentation confirms):

“Microsoft Entra hybrid-joined machines must have network connectivity line of sight to a domain controller to use the new password and update cached credentials.”

“When a device doesn’t have line of sight to a domain controller, it’s unable to validate the new password. The user needs to establish a connection with the domain controller (either via VPN or being in the corporate network) before they’re able to sign in to the device with their new password.”

When a user resets their password via SSPR while off-network:

The new password is written back to on-prem AD (via the writeback flow above)
The user’s Windows laptop still has the OLD password cached locally
The user CANNOT log in with the new password (Windows cannot validate it against a DC)
The user CAN still log in with the OLD password (cached credential)
BUT Entra ID invalidates the old password for cloud services, so SSO and cloud app access breaks

How NetBird Always-On Solves This:

The technical chain when NetBird is running as a persistent tunnel:

NetBird tunnel is UP (running as a Windows service under SYSTEM, started at boot)
DC reachable: NetBird network routes or routing peers provide connectivity to on-prem domain controller IPs
DNS resolution: NetBird’s DNS configuration (match domain for corp.local or equivalent) directs AD DNS queries through the tunnel to internal DNS servers
User resets password via SSPR: New password is written back to on-prem AD via Entra Connect
User locks workstation, then unlocks with NEW password: Windows sends the new password through the NetBird tunnel to the DC
Kerberos authentication (port 88): DC validates the new password, issues a new TGT
Cached credentials updated: Windows updates the local credential cache with the new password hash
User is logged in with new password: All subsequent logins use the updated cached credentials

Alternative flow (login with old password first):

User logs in with OLD cached password (works because cached creds are still valid)
NetBird tunnel comes up (already running as service, or user triggers connection)
User does Lock -> Unlock with NEW password
Windows validates against DC through the tunnel
Cached credentials update
User can now use new password going forward

Required Ports/Protocols Through the NetBird Tunnel:

DNS (53 TCP/UDP) — for DC discovery via SRV records
Kerberos (88 TCP/UDP) — for authentication and TGT issuance
Kerberos password change (464 TCP/UDP) — for password operations
LDAP (389 TCP/UDP) — for directory queries
LDAPS (636 TCP) — for secure directory queries
SMB (445 TCP) — for Group Policy, SYSVOL, NETLOGON
RPC (135 TCP) — for endpoint mapper
RPC high ports (49152-65535 TCP) — for dynamic RPC
NTP (123 UDP) — for time sync (critical for Kerberos; 5-minute skew tolerance)
Global Catalog (3268/3269 TCP) — for forest-wide searches

Sources:

Question 4: Edge Cases Where Cached Credential Update Fails

Confidence: HIGH (verified from Microsoft TechCommunity, Dell KB, ServerFault)

Edge Case 1: Machine account password “expiration” (30+ days offline)

Common misconception: The computer account password expires after 30 days and breaks the trust relationship.
Reality (Microsoft-confirmed): The machine password change process is initiated by the client, not by AD. If the machine cannot reach a DC, it does NOT change its local password. The process “bails out” safely.
When the device reconnects: The password change process wakes up, contacts a DC, and successfully renegotiates the password.
TRUE risk: If an admin script or cleanup process deletes or disables the computer account in AD while the device is offline, THEN the trust relationship breaks. The machine itself does not self-break.

Edge Case 2: Broken secure channel (trust relationship failure)

Symptoms: “The trust relationship between this workstation and the primary domain has failed”
Causes: Computer account manually reset/deleted in AD, or very rare sync issues
Effect: Users who have NEVER logged into that machine cannot log in. Users with cached credentials CAN still log in.
Fix: Reset-ComputerMachinePassword (PowerShell), netdom resetpwd, or re-join domain

Edge Case 3: CachedLogonsCount set to 0

If Group Policy sets Interactive logon: Number of previous logons to cache to 0, NO cached credentials are stored
User MUST have DC connectivity at every login
This would make NetBird connectivity critical at every login, not just after password changes

Edge Case 4: Kerberos time skew

Kerberos requires clock sync within 5 minutes between client and DC
If the client’s clock drifts significantly (rare but possible), authentication will fail even with DC connectivity
NTP (port 123) through the tunnel prevents this

Edge Case 5: Multiple DCs with replication lag

After SSPR writeback, the new password is set on the DC where Entra Connect writes
AD replication propagates to other DCs (typically within seconds for intra-site, up to 15 minutes inter-site)
If the client contacts a different DC before replication completes, the new password may fail briefly
Mitigation: Usually resolves within minutes; not a persistent issue

Edge Case 6: User never logged into this specific machine before

No cached credentials exist for this user on this machine
The machine MUST have DC connectivity for the first login
NetBird with always-on tunnel (setup key) is essential for this scenario

Sources:

Question 5: NetBird Pre-Logon VPN on Windows

Confidence: HIGH (verified from GitHub issues and community discussions)

Current State: NetBird does NOT support true pre-logon user-authenticated VPN.

This is tracked as an open feature request in multiple GitHub issues:

Issue #2809: “VPN before Windows logon” (opened Oct 2024, still open)
Issue #4207: “Windows Agent Pre-Login” (opened Jul 2025, still open)

What NetBird DOES support (machine-level pre-logon):

NetBird runs as a system-wide Windows service under the SYSTEM account. When configured with a setup key (machine authentication, not user authentication):

The service starts at boot, BEFORE any user logs in
The WireGuard tunnel is established at the machine level
Network routes to DCs are available at the Windows login screen
This survives reboots and does not require user interaction

Confirmed by community member (GitHub #1661):

“I was able to finally test this and verify that you can in fact install this at the SYSTEM level with a setup key and it survives reboots and doesn’t register to a user profile, it submits as a ‘Default’ profile. This is a valid ‘Always On VPN’ solution.”

Limitations of setup key approach:

Authenticates the MACHINE, not the USER
Any user on the device gets the tunnel connection
Cannot differentiate ACLs per-user on shared devices
No SSO-style authentication at the login screen (no PLAP/credential provider integration)

What the community wants (not yet implemented):

A baseline device-level tunnel with minimal access (DC/LDAP only)
User prompted to authenticate to NetBird after Windows login
User gets elevated ACLs based on their identity
Alternative: pre-logon GUI for NetBird SSO auth before Windows login

Comparison with other VPN solutions:

Windows Always On VPN: Has a “device tunnel” feature that connects before user login using machine certificates. This is the gold standard for this use case.
Palo Alto GlobalProtect: Has “Connect Before Logon” (Pre-Logon) with machine certificates
Cisco AnyConnect: Has “Start Before Logon” (SBL/PLAP) credential provider
NetBird: Machine-level tunnel via setup key (functional but no per-user auth)

For GSISG’s use case: The setup key approach IS sufficient for the SSPR cached credential problem. The goal is DC connectivity at login time, and machine-level authentication achieves this. Per-user authentication at the login screen would be a nice-to-have but is not strictly necessary for password resets.

Sources:

Question 6: Domain-Joined vs Hybrid AD Joined vs Azure AD Joined

Confidence: HIGH (verified from Microsoft documentation)

Feature	Domain-Joined (Traditional)	Hybrid Azure AD Joined	Azure AD Joined
Primary authority	On-prem AD	On-prem AD + Entra ID	Entra ID (cloud)
Authentication at login	DC required (or cached)	DC required (or cached)	Entra ID (cloud)
SSPR password reset	Writeback needed	Writeback needed	Native (no writeback)
Cached credential update after SSPR	Requires DC connectivity	Requires DC connectivity	Not required
VPN needed for SSPR?	YES	YES	NO
Cloud SSO after password change	N/A	Breaks without DC	Works immediately
Device management	GPO only	GPO + Intune	Intune only
Best for GSISG?	Current state	Recommended transitional	Long-term goal

Key insight from Microsoft FAQ:

“This issue doesn’t occur if you use Microsoft Entra joined devices” — referring to the SSPR cached credential problem.

Which scenario works best with NetBird + SSPR?

Hybrid Azure AD Joined (RECOMMENDED for GSISG today):
- Devices are joined to both on-prem AD and Entra ID
- SSPR writeback works for password changes
- NetBird always-on tunnel provides DC connectivity for cached credential updates
- GPO still works for management
- Gradual migration path to cloud-only
Azure AD Joined (IDEAL long-term):
- Eliminates the cached credential problem entirely
- No VPN needed for password resets
- Managed via Intune instead of GPO
- But requires significant migration effort from traditional AD
Domain-Joined Only (Current state):
- Works with NetBird + SSPR but misses cloud benefits
- No Entra ID registration means no Conditional Access, no device compliance
- Should migrate to Hybrid Azure AD Joined at minimum

Sources:

Question 7: NetBird Device Posture Checks

Confidence: HIGH (verified from official NetBird documentation)

Built-in Posture Check Types:

Check Type	Details	Can Check Domain Membership?
NetBird Client Version	Require minimum client version	No
Country/Region	Allow/block by geographic location	No
Peer Network Range	Allow/block by source IP ranges	No
Operating System	Require minimum OS/kernel version (Windows, macOS, Linux, Android, iOS)	No
Process Check	Require specific processes running on the device	No (but can check for domain-related services)

Domain Membership Check: NOT NATIVELY SUPPORTED

NetBird does NOT have a built-in posture check for Active Directory domain membership.

Workaround via Intune Integration:

NetBird integrates with Microsoft Intune for device compliance posture checks
Intune CAN enforce: device enrollment, compliance state, disk encryption, OS updates, firewall status, endpoint protection
Required API permission: DeviceManagementManagedDevices.Read.All
Intune compliance posture checks work on Windows and macOS only
Non-compliant devices are automatically blocked; access restored when compliant
24-hour sync requirement: device must have synced with Intune within 24 hours
Intune sync with NetBird occurs “every few minutes”

SentinelOne Integration (EDR):

Verify SentinelOne agent is active, updated, and recently checked in
Enforce disk encryption and host firewall via EDR status

Process Check as Workaround:

Could check for svchost.exe with specific service names, or domain-specific processes
Not a robust domain membership check, but provides some assurance

Sources:

Question 8: Group Policy Application Over NetBird Tunnel

Confidence: HIGH (verified from Microsoft documentation)

The Core Problem:

Microsoft explicitly documents this issue:

“This behavior occurs because Windows uses cached information to improve performance when users sign in. Windows also uses cached information to sign in users on domain-joined clients that are not connected to the network. Unexpected consequences occur if the client exclusively uses a VPN to connect to the network, and the client cannot establish the VPN connection until after the user signs in.”

How Group Policy Works Over a VPN Tunnel:

Trigger	Sync/Async	When it Runs	VPN Requirement
Computer startup	Sync or Async	Before user login	Need pre-logon tunnel
User sign-in	Sync or Async	During login	Need pre-logon tunnel
Background refresh (~90 min)	Async	During user session	Tunnel must be UP
`gpupdate /force`	Async	User-initiated	Tunnel must be UP

Key Issues:

Fast Logon Optimization: Windows caches GPO state. If the VPN is not connected at login time, Windows uses cached GPOs. Some policies (Folder Redirection, Scripts) require synchronous foreground processing at login WITH DC connectivity.
Group membership updates: If VPN connects AFTER user login, the user’s security token retains the OLD group memberships. New group memberships only take effect after: VPN connects -> Lock -> Unlock -> Sign out -> Sign in again.
Latency concerns with WireGuard: WireGuard itself adds minimal latency (typically <2ms for tunnel overhead). The bigger concern is the underlying internet connection latency to the corporate site. GPO processing timeouts are generous (several minutes), so typical home internet connections should not cause GPO timeout issues.

Microsoft’s Resolution Statement:

“To resolve the problems that this article describes, use a VPN solution that can establish a VPN connection to a client before the user signs in.”

NetBird + GPO Best Practices:

Use setup key for machine-level tunnel (provides pre-logon connectivity)
Ensure DNS match domains are configured for the AD domain
Ensure SMB (445), LDAP (389), and RPC (135, 49152-65535) are accessible through the tunnel
For critical GPO changes, instruct users to: connect VPN -> lock -> unlock -> sign out -> sign in
Background GPO refreshes (every ~90 minutes) will work fine as long as the tunnel is up during the user session

Sources:

https://learn.microsoft.com/en-us/troubleshoot/windows-client/group-policy/group-membership-changes-not-updating-over-some-vpn-connections

Question 9: Required Ports/Protocols for Full AD Functionality

Confidence: HIGH (verified from Microsoft and multiple third-party sources)

Core AD Ports (MUST allow through NetBird policies):

Port	Protocol	Service	Purpose
53	TCP/UDP	DNS	Domain name resolution, DC discovery via SRV records
88	TCP/UDP	Kerberos	Authentication, TGT issuance
123	UDP	NTP (W32Time)	Time synchronization (critical for Kerberos)
135	TCP	RPC Endpoint Mapper	Service discovery for RPC-based services
389	TCP/UDP	LDAP	Directory queries, DC locator
445	TCP	SMB	Group Policy (SYSVOL), NetLogon, file shares
464	TCP/UDP	Kerberos kpasswd	Password changes and resets
636	TCP	LDAPS	Secure directory queries
3268	TCP	Global Catalog	Forest-wide searches
3269	TCP	Global Catalog SSL	Secure forest-wide searches
9389	TCP	ADWS	Active Directory Web Services (PowerShell AD module)
49152-65535	TCP	RPC Ephemeral	Dynamic RPC endpoints

Legacy Ports (optional, Windows 2012+):

Port	Protocol	Service	Purpose
137	UDP	NetBIOS Name	Legacy name resolution
138	UDP	NetBIOS Datagram	Legacy browsing
139	TCP	NetBIOS Session	Legacy file sharing

NetBird Policy Configuration Recommendation:

Create a policy allowing the “All Users” (or a “Domain Machines” group) source to reach the “Domain Controllers” destination group on:

TCP: 53, 88, 135, 389, 445, 464, 636, 3268, 3269, 9389, 49152-65535
UDP: 53, 88, 123, 389, 464

This can be simplified to “All protocols” for the DC destination if granular port control is not required.

DNS-Specific NetBird Configuration:

Configure match domains for your AD domain (e.g., gsisg.local, gsisg.com)
Point to internal DC IP addresses as nameservers
Do NOT use Domain Controllers as NetBird routing peers (they interfere with AD DNS services)
Use a dedicated routing peer on the same subnet as the DCs
If DCs run Windows DNS Server, exclude port 51820 from the DNS socket pool

Sources:

Question 10: NetBird Access Control Policies for Role-Based Access

Confidence: HIGH (verified from official NetBird documentation)

YES — NetBird can absolutely restrict general users to DC-only access while giving engineers full LAN access.

How NetBird Access Control Works:

Groups: Organize users and resources into logical groups
Policies: Define which source groups can access which destination groups, on which protocols/ports
Default behavior: NetBird starts with a “Default” policy creating a full mesh. This MUST be removed/modified.

Implementation for GSISG:

Step 1: Create Groups

General Users — synced from Entra ID “Standard Users” group
Engineers — synced from Entra ID “IT/Engineering” group
Domain Controllers — contains DC peers/resources
Full LAN — contains all LAN resources (servers, printers, etc.)

Step 2: Create Policies

Policy Name	Source Group	Destination Group	Protocols/Ports	Direction
Users to DCs	General Users	Domain Controllers	TCP 53,88,135,389,445,464,636,3268,3269 + UDP 53,88,123,389,464	One-way
Engineers to LAN	Engineers	Full LAN	All protocols	One-way
Engineers to DCs	Engineers	Domain Controllers	All protocols	One-way

Step 3: Remove Default Policy

Delete or disable the “Default” full-mesh policy

Additional Features:

Port ranges: Supported (e.g., 49152-65535 for RPC ephemeral)
Traffic direction: Can enforce one-way access (source -> destination only)
Posture checks: Can attach compliance requirements to policies (e.g., Intune compliance for engineers accessing production)
Protocol filtering: TCP, UDP, ICMP, or All
Network resources: For resources that don’t have NetBird agents installed (like DCs), use “routing peers” to bridge traffic

NetBird Networks Feature (for resources without agents):

Create a “Network” for your on-prem LAN
Add “Resources” (e.g., DC IPs, server subnets)
Assign “Routing Peers” (a machine on-prem with NetBird installed that forwards traffic)
Create access control policies referencing these resources

Sources:

Gaps & Uncertainties

Confirmed Gaps

NetBird sync interval: The exact IdP sync frequency is not publicly documented. “Regular intervals” and “every few minutes” are the only descriptions available. Testing would be needed to confirm the exact cadence.
Pre-logon user authentication: NetBird does NOT support user-authenticated pre-logon VPN (PLAP/credential provider). Only machine-level pre-logon via setup keys. This is a known feature request with community demand but no ETA from NetBird.
Domain membership posture check: NetBird cannot natively verify AD domain membership. The Intune integration partially addresses this (Intune can verify domain join status as a compliance policy), but it requires Intune enrollment.

Moderate Uncertainties

GPO over WireGuard latency: While WireGuard tunnel overhead is minimal, there is no published benchmark data for GPO processing times specifically over NetBird/WireGuard tunnels. Real-world testing is recommended, particularly for Folder Redirection and large software deployment policies.
SSPR at Windows login screen with NetBird: The SSPR “Reset Password” link on the Windows login screen uses a temporary defaultuser1 account that needs internet access (port 443 to passwordreset.microsoftonline.com). It is unclear whether NetBird’s tunnel routing would interfere with this internet connectivity. If NetBird is configured as a full tunnel (all traffic routed), this should work. If split tunnel, the SSPR endpoints must be routable.
Multi-site DC affinity: With DCs at Honolulu and Boulder, it is unclear how NetBird routing peer configuration would handle DC site affinity. Windows uses AD Sites and Services / SRV records to find the nearest DC. The routing peer location and DNS configuration would determine which DC the client contacts.

Low-Risk Unknowns

Entra Connect Cloud Sync vs Classic Connect: Both support password writeback, but Cloud Sync is newer and may have different behavior in edge cases. If GSISG already uses classic Entra Connect, it should continue to work.
NetBird + Windows Hello for Business: Microsoft documentation states that Windows Hello for Business bypasses the cached credential problem entirely. If GSISG deploys WHfB alongside NetBird, the SSPR issue may become irrelevant for PIN/biometric users.

Architecture Recommendation Summary

For GSISG with 100+ users, on-prem AD at Honolulu + Boulder, and Entra Connect:

Deploy NetBird with setup keys on all domain-joined laptops (machine-level always-on)
Configure routing peers at both sites (one at each office, NOT the DCs themselves)
Configure DNS match domains for the AD domain pointing to DC IPs
Create access control policies: general users get DC-only access; IT engineers get full LAN
Enable SSPR with password writeback (requires Entra ID P1 or M365 Business Premium)
Sync Entra ID groups to NetBird for automated user provisioning
Migrate to Hybrid Azure AD Join for devices (if not already) for best cloud+on-prem integration
Long-term: Consider Azure AD Join + Intune to eliminate the cached credential problem entirely

Sources & Tool Usage Log

Tool Calls Made

Tool	Query/URL	Purpose
tavily_search	”NetBird Microsoft Entra ID Azure AD integration setup app registration permissions”	Q1: Integration details
tavily_search	”Microsoft SSPR self-service password reset writeback hybrid AD on-premises technical flow”	Q2: SSPR writeback flow
tavily_search	”Windows cached credentials domain controller VPN always-on password reset update Kerberos NTLM”	Q3: Cached credential update
tavily_search	”NetBird pre-logon VPN Windows before user login WireGuard service mode”	Q5: Pre-logon support
tavily_search	”NetBird access control policies network segmentation ACL restrict users specific resources”	Q10: ACL policies
tavily_search	”NetBird device posture checks domain membership OS version disk encryption endpoint compliance”	Q7: Posture checks
tavily_search	”Group Policy GPO application over VPN tunnel WireGuard latency timeout issues remote domain joined”	Q8: GPO over tunnel
tavily_search	”Active Directory required ports protocols LDAP Kerberos SMB DNS Global Catalog full list firewall”	Q9: AD ports
tavily_search	”domain joined vs hybrid Azure AD joined vs Azure AD joined SSPR password reset differences”	Q6: Device join types
tavily_search	”Windows cached credentials computer account password expired secure channel broken domain controller 30 days”	Q4: Edge cases
tavily_search	”NetBird IdP sync interval frequency how often synchronize users groups automatic”	Q1: Sync interval
tavily_search	”NetBird network routes routing peers Windows DNS resolution domain controller access”	Q3/Q9: DNS/routing
exa_search	”NetBird Windows service mode runs as SYSTEM pre-logon machine tunnel device authentication”	Q5: Pre-logon deep dive
exa_search	”SSPR password reset cached credentials domain controller line of sight VPN always-on tunnel solution”	Q3: Real-world experiences
WebFetch	docs.netbird.io/manage/team/idp-sync/microsoft-entra-id-sync	Q1: Entra ID sync details
WebFetch	learn.microsoft.com/…/concept-sspr-writeback	Q2: Writeback technical flow
WebFetch	learn.microsoft.com/…/howto-sspr-windows	Q3/Q6: SSPR on Windows
WebFetch	docs.netbird.io/manage/access-control/posture-checks	Q7: Posture check types
WebFetch	learn.microsoft.com/…/group-membership-changes-not-updating-over-some-vpn-connections	Q8: GPO over VPN
WebFetch	docs.netbird.io/…/intune-mdm	Q7: Intune integration
WebFetch	learn.microsoft.com/…/concept-sspr-licensing	Q2: SSPR licensing
WebFetch	docs.azure.cn/…/devices/faq	Q3/Q6: Entra device FAQ
WebFetch	techcommunity.microsoft.com/…/secure-channel-expired-machine-account-password	Q4: Secure channel
WebFetch	docs.netbird.io/manage/dns/internal-dns-servers	Q9: NetBird DNS for AD

Primary Sources

NetBird Documentation: docs.netbird.io (official)
Microsoft Learn: learn.microsoft.com (official Microsoft documentation)
Microsoft TechCommunity: techcommunity.microsoft.com (Microsoft engineering team blogs)
GitHub Issues: github.com/netbirdio/netbird (feature requests and community discussions)
Richard Hicks Consulting: directaccess.richardhicks.com (authoritative Always On VPN resource)
ManageEngine: ebook on cached credentials over VPN (third-party vendor documentation)