PROJECT 01COMPLETE
Windows LAPS & Advanced Group Policy
Encrypted local administrator passwords, scoped Group Policy, delegated readers, and positive and negative access tests.
Project directory / 13 complete
Every project connects its implementation to retained validation. Completion refers to the documented scope; simulations and limitations stay explicit.
Encrypted local administrator passwords, scoped Group Policy, delegated readers, and positive and negative access tests.
Scoped AD-to-Entra provisioning with source-anchor correlation, Password Hash Sync, and lifecycle validation.
A Microsoft-centered infrastructure lab with documented directory services, virtualization, networking, and bounded recovery tests.
Centralized Windows administration backed by connectivity, authentication, and remote-management validation.
A managed nested Hyper-V host, VMM logical networking, and validated APP01 lifecycle operations.
Two Arc-connected Windows Server lab machines, agent validation, and one SQL Server Developer instance.
A scoped virtual-disk change with checkpoint handling, guest storage inspection, and final NTFS validation.
A repeatable support method across Windows, Linux, macOS, identity, and infrastructure.
An approved catalog request progressing through Procurement and Field Services to automatic lifecycle completion.
Mailbox delegation, message delivery, Defender review, Conditional Access remediation, and bounded licensing evidence.
Physical-device provisioning through branded OOBE, ESP, Entra join, security policy, and final Intune compliance.
Real Microsoft-side configuration paired with explicitly simulated Apple enrollment and endpoint workflows.
Seven validated read-only scripts for tenant, user, group, license, role, stale-account, and Intune reporting.
No projects match these filters.
Project 01 / Identity & security
Encrypted local administrator passwords, scoped Group Policy, delegated readers, and positive and negative access tests.
Encrypted local administrator passwords, scoped Group Policy, delegated readers, and positive and negative access tests.
Classification: Validated lab work.
Protect local administrator credentials with encrypted AD backup while proving that authorized readers can retrieve metadata and unauthorized users cannot.
Personal AD lab: DC01 and the WS01 endpoint in a dedicated LAPS-Test OU; an enabled LocalAdmin account and a delegated reader group.
Personal AD lab: DC01 and the WS01 endpoint in a dedicated LAPS-Test OU; an enabled LocalAdmin account and a delegated reader group.
Project 01 · COMPLETE
Enterprise-style local administrator password management with encrypted AD backup, delegated readers, policy validation, and documented troubleshooting.
Scope
Modern Windows LAPS was implemented against WS01 in a dedicated protected OU under the existing AD domain. The project intentionally reused working identity infrastructure and avoided unnecessary rebuilds.
Design
The design uses modern Windows LAPS, encrypted Active Directory password storage, a dedicated reader group, OU-scoped permissions, and a managed local LocalAdmin account instead of enabling the built-in Administrator.
Implementation
The AD schema was extended for modern LAPS. WS01 was moved into the LAPS-Test OU. Computer self-permission and reader delegation were applied. A GPO configured AD backup, password complexity, 14-character passwords, 30-day age, encryption, authorized decryptors, and the managed account name.
Validation
Validation included gpresult, RSOP, LAPS operational events, safe metadata retrieval, forced password rotation, encrypted AD attribute presence, delegated reader success, and an unauthorized-user test that returned no LAPS record.
Troubleshooting
RSOP initially failed because WS01 WMI firewall rules were disabled. Enabling only the required Domain-profile WMI rules restored remote WMI and Group Policy Results. A separate mstsc client hang was isolated to the administrative laptop, not DC01.
Evidence
COMPLETE
\nThis project demonstrates a validated deployment of modern Windows LAPS in the ad.jeremyfontenot.online Active Directory lab using a dedicated test OU, Group Policy, encrypted password storage, least-privilege delegation, event-log validation, and forced password rotation.
| Component | \nConfiguration | \n
|---|---|
| AD domain | \nad.jeremyfontenot.online | \n
| NetBIOS | \nJFAD | \n
| Domain controller | \nDC01 - Windows Server 2022 | \n
| Test endpoint | \nWS01 - Windows 10 Pro 10.0.19045 | \n
| Test OU | \nOU=LAPS-Test,OU=Workstations,OU=JFAD,DC=ad,DC=jeremyfontenot,DC=online | \n
| LAPS GPO | \nGPO - Workstations - Windows LAPS | \n
| Managed account | \nLocalAdmin | \n
| Reader group | \nJFAD\\GG-LAPS-Password-Readers | \n
Update-LapsADSchema completed and six msLAPS-* attributes validatedLAPS-Test OU created and WS01 moved into scopeSet-LapsADComputerSelfPermissionSet-LapsADReadPasswordPermissiongpupdate, gpresult, and GUI Group Policy Results/RSOP validatedThe built-in RID-500 Administrator account remains disabled. Windows LAPS manages the existing enabled WS01\\LocalAdmin account instead. Passwords are stored using encrypted Windows LAPS attributes in Active Directory. The actual password is intentionally excluded from all portfolio evidence.
Deploy modern Windows LAPS in a controlled Active Directory test scope using Group Policy, encrypted password storage, and delegated least-privilege access.
\nAdministrative laptop -> DC01 -> LAPS-Test OU -> WS01 -> LocalAdmin
The administrative laptop is not domain joined, so domain-integrated administration was performed through DC01 by PowerShell remoting and RDP.
\nad.jeremyfontenot.onlineDC01WS01OU=LAPS-Test,OU=Workstations,OU=JFAD,DC=ad,DC=jeremyfontenot,DC=onlineThe schema was first queried for msLAPS-* attributes. None were present. Update-LapsADSchema was then run with temporary Schema Admin membership, after which the membership was removed.
Validated attributes:
\nmsLAPS-PasswordmsLAPS-PasswordExpirationTimemsLAPS-EncryptedPasswordmsLAPS-EncryptedPasswordHistorymsLAPS-EncryptedDSRMPasswordmsLAPS-EncryptedDSRMPasswordHistoryGPO: GPO - Workstations - Windows LAPS
Settings:
\nLocalAdminJFAD\\GG-LAPS-Password-ReadersSet-LapsADComputerSelfPermission grants managed computers permission to update their own LAPS attributes. Set-LapsADReadPasswordPermission delegates password-read rights to JFAD\\GG-LAPS-Password-Readers.
The final test reader account laps.reader01 belongs only to Domain Users and GG-LAPS-Password-Readers, demonstrating delegated access independent of Domain Admin privileges.
This folder contains portfolio-safe evidence reconstructed from the validated command output captured during the lab. Managed passwords and authentication secrets are intentionally excluded.
\nNever publish:
\nThe repository intentionally records only non-secret metadata such as account name, timestamps, encryption source, decryption status, authorized decryptor, event IDs, and GPO configuration.
mstsc.exe AppHangB1 / Event ID 1002mstsc /public /admin /v:dc01.ad.jeremyfontenot.onlineInitial WMI result:
\nThe RPC server is unavailable. (Exception from HRESULT: 0x800706BA)\nWMI firewall rule source:
\nPolicyStoreSourceType : Local\nPolicyStoreSource : PersistentStore\nEnabled : False\nProfile : Domain\nAfter enabling the Domain-profile PersistentStore WMI rules:
\nCSName : WS01\nCaption : Microsoft Windows 10 Pro\nVersion : 10.0.19045\nThe Group Policy Results wizard then completed successfully.
Post-extension query returned all required modern attributes:
\nmsLAPS-EncryptedDSRMPassword\nmsLAPS-EncryptedDSRMPasswordHistory\nmsLAPS-EncryptedPassword\nmsLAPS-EncryptedPasswordHistory\nmsLAPS-Password\nmsLAPS-PasswordExpirationTime\nWS01 final OU:
\nOU=LAPS-Test,OU=Workstations,OU=JFAD,DC=ad,DC=jeremyfontenot,DC=online\nExtended-right holders:
\nNT AUTHORITY\\SYSTEM\nJFAD\\Domain Admins\nJFAD\\GG-LAPS-Password-Readers\nFinal reader group membership:
\nName : LAPS Reader Test\nSamAccountName : laps.reader01\nObjectClass : user\nlaps.reader01 group memberships:
Domain Users\nGG-LAPS-Password-Readers\ngpresult /r /scope computer included:
GPO - Workstations - Windows LAPS\nPolicy source: GPO\nBackup directory: Active Directory\nLocal administrator account name: LocalAdmin\nPassword age in days: 30\nPassword complexity: 4\nPassword length: 14\nPassword expiration protection enabled: 1\nPassword encryption enabled: 1\nPassword encryption target principal: JFAD\\GG-LAPS-Password-Readers\nComputerName : WS01\nAccount : LocalAdmin\nPasswordUpdateTime : 9/11/2026 7:06:17 PM\nExpirationTimestamp : 10/11/2026 7:06:17 PM\nSource : EncryptedPassword\nDecryptionStatus : Success\nAuthorizedDecryptor : JFAD\\GG-LAPS-Password-Readers\nName : WS01\nmsLAPS-PasswordExpirationTime : 134362343115244738\nEncryptedPasswordPresent : True\n10014 - Administrator-initiated password update\n10020 - LocalAdmin password successfully updated\n10018 - Active Directory successfully updated\n10004 - LAPS policy processing succeeded\nACCESS TEST RESULT: No LAPS record returned for unauthorized user.\nNo managed password value is present in this evidence.
LAPS PowerShell module on DC01 and WS01.msLAPS-* attributes before making changes.jeremy.fontenot to Schema Admins, refreshed the logon token, and ran Update-LapsADSchema -Verbose.OU=LAPS-Test under OU=Workstations with accidental-deletion protection.LAPS-Test.Set-LapsADComputerSelfPermission.GG-LAPS-Password-Readers and delegated read permission with Set-LapsADReadPasswordPermission.GPO - Workstations - Windows LAPS to the LAPS-Test OU.GG-LAPS-Password-Readers as the authorized decryptor.LocalAdmin account.LocalAdmin rather than enabling the built-in Administrator account.laps.reader01, added it to the reader group, and validated encrypted retrieval.Reset-LapsPassword and validated the new timestamps and Event IDs 10014, 10020, 10018, and 10004.msLAPS-* schema state before running Update-LapsADSchema.gpresult and GUI RSOP validate complementary layers of Group Policy application.TCP 3389 to DC01 was reachable, but the local Remote Desktop Connection client hung or closed. Windows Error Reporting showed mstsc.exe AppHangB1 / Application Hang Event ID 1002.
Resolution:
\nmstsc /public /admin /v:dc01.ad.jeremyfontenot.online\nThe administrative RDP session then opened successfully.
\nThe Group Policy Results wizard initially failed to query WS01. A direct WMI test returned 0x800706BA - The RPC server is unavailable.
Inspection showed all Windows Management Instrumentation (WMI) firewall rules were disabled and originated from the local PersistentStore.
The Domain-profile WMI rules were enabled in PersistentStore. A subsequent Get-WmiObject Win32_OperatingSystem -ComputerName WS01 succeeded and the GUI Group Policy Results report generated correctly.
LAPS Event ID 10067 reported that the built-in Administrator account was disabled. WS01 already had an enabled custom LocalAdmin account in the local Administrators group.
The LAPS GPO was updated to manage LocalAdmin. Event IDs 10021 and 10020 then confirmed the intended account and successful password update.
laps.reader01 intentionally lacked administrative/WinRM rights on DC01. Rather than granting unnecessary remote-administration permission, Get-LapsADPassword -Credential and -DecryptionCredential were used inside the existing administrative remoting session to validate the delegated reader credentials.
gpupdate /force completed successfully on WS01. gpresult /r /scope computer listed GPO - Workstations - Windows LAPS under Applied Group Policy Objects. The Group Policy Results wizard was also generated after WMI/RPC remediation.
Event ID 10021 reported:
\nPolicy source: GPO\nBackup directory: Active Directory\nLocal administrator account name: LocalAdmin\nPassword age in days: 30\nPassword complexity: 4\nPassword length: 14\nPassword expiration protection enabled: 1\nPassword encryption enabled: 1\nPassword encryption target principal: JFAD\\GG-LAPS-Password-Readers\nSanitized final retrieval:
\nComputerName : WS01\nAccount : LocalAdmin\nPasswordUpdateTime : 9/11/2026 7:06:17 PM\nExpirationTimestamp : 10/11/2026 7:06:17 PM\nSource : EncryptedPassword\nDecryptionStatus : Success\nAuthorizedDecryptor : JFAD\\GG-LAPS-Password-Readers\nThe Password property was deliberately excluded.
Event sequence:
\nLocalAdmin password updatedlaps.reader01 was validated with only Domain Users and GG-LAPS-Password-Readers memberships and successfully decrypted the encrypted LAPS record.
A standard user outside the reader group produced:
\nACCESS TEST RESULT: No LAPS record returned for unauthorized user.\nName : WS01\nmsLAPS-PasswordExpirationTime : 134362343115244738\nEncryptedPasswordPresent : True\nRSOP failed with RPC error 0x800706BA because WS01 WMI firewall rules were disabled. Enabling the required Domain-profile rules restored WMI and Group Policy Results. Event 10067 also led to targeting the existing LocalAdmin account instead of the disabled built-in Administrator.
Encrypted attribute presence, delegated retrieval, unauthorized-access denial, effective policy, and forced-rotation events support the completed Windows LAPS scope.
STRONG — implementation, validation, troubleshooting, sanitized evidence, and a reusable validation script are documented.
Maintenance-only unless the lab changes; revalidate after material AD/GPO/LAPS changes.
Continue exploring
Scoped AD-to-Entra provisioning with source-anchor correlation, Password Hash Sync, and lifecycle validation.
Centralized Windows administration backed by connectivity, authentication, and remote-management validation.
Project 02 / Identity & security
Scoped AD-to-Entra provisioning with source-anchor correlation, Password Hash Sync, and lifecycle validation.
Scoped AD-to-Entra provisioning with source-anchor correlation, Password Hash Sync, and lifecycle validation.
Classification: Validated lab work.
Synchronize only the intended identities, retain AD source authority, and validate provisioning and password synchronization without introducing an unnecessary second sync engine.
Retained project architecture: DC01 supplies AD DS; SYNC01 hosts the provisioning agent. The tested dedicated OU limits synchronization to selected users and groups.
Retained project architecture: DC01 supplies AD DS; SYNC01 hosts the provisioning agent. The tested dedicated OU limits synchronization to selected users and groups.
Project 02 · COMPLETE
Hybrid identity provisioning from on-premises Active Directory to Microsoft Entra ID with scoped users, groups, Password Hash Sync, and troubleshooting evidence.
Scope
Microsoft Entra Cloud Sync is already working in the lab. The project focuses on scoped provisioning, source authority, password synchronization, agent health, and evidence-driven troubleshooting without rebuilding the working sync service.
Design
Cloud-bound identities are organized in a dedicated AD OU and use the verified jeremyfontenot.online UPN domain. Test users and groups are separated from unrelated directory objects.
Validation
Validation covers users, groups, AD source authority, Cloud Sync agent state, and the expected fixed provisioning interval. Password Hash Sync is treated as a separate flow with different timing.
Troubleshooting
Provisioning-agent trace logs and directory state are used before any restart or rebuild. The 20-minute Cloud Sync provisioning interval is accounted for before treating changes as failures.
Evidence
COMPLETE
\nThis project demonstrates a validated hybrid identity implementation using Microsoft Entra Cloud Sync to synchronize selected Active Directory users and groups from an on-premises Windows Server environment to Microsoft Entra ID.
\nThe project focuses on controlled identity lifecycle validation, source-of-authority verification, Password Hash Synchronization, security-group synchronization, provisioning-log analysis, and troubleshooting without rebuilding the existing working Cloud Sync deployment.
\nad.jeremyfontenot.onlineJFADDC0110.10.20.10SYNC0110.10.20.105jeremyfontenot.onlineSynchronization is intentionally limited to:
\nOU=Cloud Sync,OU=JFAD,DC=ad,DC=jeremyfontenot,DC=online
This provides a controlled boundary for hybrid identity testing without synchronizing unrelated Active Directory objects.
\nThe project successfully validated:
\nThe primary test identity was:
\ncloudsync.test01@jeremyfontenot.online
The lifecycle test validated:
\nDepartment attributeGG-CloudSync-TestFor the synchronized objects tested in this project, on-premises Active Directory remained the authoritative identity source.
\nThe identity relationship was validated by correlating:
\nobjectGUIDSourceAnchorObserved Cloud Sync intervals:
\nThese separate intervals were accounted for during validation and troubleshooting.
\nDuring validation, the Cloud Sync agent reported a permissions-related metrics error involving access to the registry key Global.
The provisioning agent gMSA was added to the local Performance Log Users group on SYNC01.
After the agent service restarted:
\nThe existing Cloud Sync installation was preserved.
\nPortfolio evidence is sanitized.
\nThe project does not publish:
\nA reusable PowerShell validation script is included at:
\nscripts/Test-CloudSyncADState.ps1
The script validates the current on-premises source state for:
\ncloudsync.test01GG-CloudSync-TestThe script is designed to be executed against a domain controller with the Active Directory PowerShell module available.
\nExample execution from the administrative workstation:
\nInvoke-Command -Session $dc -FilePath \".\\scripts\\Test-CloudSyncADState.ps1\"\nThe script provides repeatable evidence of the Active Directory state without modifying directory objects.
\nI built and validated a hybrid identity lab using Microsoft Entra Cloud Sync between an on-premises Active Directory environment and Microsoft Entra ID.
\nThe environment uses Windows Server 2022 with a dedicated Cloud Sync server and a scoped synchronization OU. I preserved the existing working Cloud Sync deployment rather than rebuilding it.
\nFor the validation, I created a controlled Active Directory user and confirmed that it provisioned to Microsoft Entra. I then changed a supported on-premises attribute, verified the cloud update, changed the user password on-premises, and validated Password Hash Synchronization by successfully authenticating to Microsoft Entra with the new password.
\nI also created a security group, synchronized the group and its membership, reviewed provisioning logs, and correlated the Active Directory objectGUID with the Cloud Sync source anchor and the Microsoft Entra immutable ID.
\nDuring troubleshooting, I identified a permissions issue affecting Cloud Sync metrics, corrected the gMSA permissions on SYNC01, and validated that the agent remained healthy. I also documented the difference between the 20-minute Users and Groups provisioning interval and the 5-minute Password Hash Sync interval so that normal propagation delay is not mistaken for a failure.
\nThe project demonstrates hybrid identity administration, Active Directory, Microsoft Entra ID, Cloud Sync, Password Hash Synchronization, group synchronization, PowerShell remoting, provisioning-log analysis, and evidence-based troubleshooting.
\nBuilt and validated a Microsoft Entra hybrid identity lab integrating Windows Server 2022 Active Directory with Microsoft Entra ID through Microsoft Entra Cloud Sync.
\nThe project included controlled user provisioning, attribute synchronization, Password Hash Synchronization, security-group and group-membership synchronization, source-anchor correlation, provisioning-log analysis, and PowerShell-based remote administration.
\nI also troubleshot Cloud Sync agent permissions using event logs, validated the provisioning agent gMSA configuration, and confirmed the difference between the 20-minute Users and Groups provisioning cycle and the separate 5-minute Password Hash Sync cycle.
\nTechnologies used: Windows Server 2022, Active Directory Domain Services, Microsoft Entra ID, Microsoft Entra Cloud Sync, Password Hash Synchronization, gMSA, PowerShell, PowerShell Remoting, and Entra provisioning logs.
COMPLETE
\nThis project uses Microsoft Entra Cloud Sync to synchronize selected identities from on-premises Active Directory to Microsoft Entra ID.
\nad.jeremyfontenot.onlineJFADDC0110.10.20.10Directory services provided by DC01 include:
\nSYNC0110.10.20.105The Cloud Sync agent runs under an existing group Managed Service Account.
\njeremyfontenot.onlineCloud Sync is intentionally limited to:
\nOU=Cloud Sync,OU=JFAD,DC=ad,DC=jeremyfontenot,DC=online
This dedicated OU provides a controlled boundary for synchronized users and groups without broadly synchronizing unrelated Active Directory objects.
\nThe validated identity path is:
\nDC01 Active Directory\n→ Dedicated Cloud Sync OU\n→ SYNC01 Microsoft Entra Cloud Sync Agent\n→ Microsoft Entra ID
Password changes follow a separate Password Hash Synchronization process through the same Cloud Sync deployment.
\nThe project validated synchronization of:
\nFor the identities tested in this project, on-premises Active Directory is the authoritative source.
\nMicrosoft Entra receives synchronized identity data through Cloud Sync.
\nThe identity relationship was validated through:
\nobjectGUIDSourceAnchorObserved configuration intervals:
\nThese are separate processing cycles and should be considered during troubleshooting.
\nThe administrative laptop is not domain joined.
\nAdministration is therefore performed primarily through:
\nDC01SYNC01This avoids relying on laptop Kerberos or domain-integrated RSAT functionality.
\nThe architecture preserves the existing working Cloud Sync deployment.
\nNo additional synchronization engine was introduced, and Microsoft Entra Connect Sync was not installed simply to obtain manual delta-sync capability.
\nThis lab uses Microsoft Entra Cloud Sync rather than Microsoft Entra Connect Sync.
\nCloud Sync uses a lightweight provisioning agent installed on SYNC01.
In this lab it provides:
\nThe observed Users and Groups provisioning interval is 20 minutes.
\nMicrosoft Entra Connect Sync uses the traditional synchronization engine installed on a Windows Server.
\nA key operational difference relevant to this lab is that Connect Sync supports administrator-triggered synchronization cycles, such as a delta synchronization, whereas the Cloud Sync Users and Groups provisioning job operates on its service-managed schedule.
\nConnect Sync was not installed in this project because the existing Cloud Sync deployment was already functioning and introducing another synchronization engine was unnecessary for the project objectives.
\nCloud Sync was retained because it already met the requirements of this controlled hybrid identity implementation.
\nThe architecture therefore remained:
\nActive Directory\n→ Microsoft Entra Cloud Sync\n→ Microsoft Entra ID
rather than adding Microsoft Entra Connect Sync solely to obtain manually triggered synchronization cycles.
\nThis preserves the existing working infrastructure and avoids overlapping synchronization engines for the same test objects.
COMPLETE
\nThis folder contains sanitized evidence and supporting visuals for the Microsoft Entra Hybrid Identity & Cloud Sync project.
\n02-cloudsync-test01-initial-provisioning.pngInitial synchronized user in Microsoft Entra
\n03-cloudsync-test01-attribute-sync.png
Department attribute synchronized to Hybrid Identity Lab
04-cloudsync-test01-password-hash-sync.png
Successful Microsoft Entra authentication after on-premises password change
\n05-cloudsync-group-membership.png
Cloud Sync Test 01 synchronized as a member of GG-CloudSync-Test
06-cloudsync-user-provisioning-log.png
Successful user import, scope evaluation, and provisioning
\n07-cloudsync-user-modified-properties.png
User attribute and source-anchor processing
\n08-cloudsync-source-authority.png
On-premises synchronization and immutable-ID evidence
\n09-cloudsync-overview-health.png
Healthy Cloud Sync configuration and synchronization counts
\n10-cloudsync-no-failures.png
Final provisioning-log failure review with no results
\n11-cloudsync-group-provisioning-log.png
12-cloudsync-group-modified-properties.png
13-cloudsync-group-summary.png
14-cloudsync-agent-status.png
15-cloudsync-ou-scope.png
16-cloudsync-group-attribute-mapping.png
01-cloudsync-architecture.png02-identity-lifecycle.png03-source-anchor-correlation.png04-sync-timing.png05-troubleshooting-flow.png06-validation-summary.png07-cloudsync-vs-connect-sync.pngThese visuals summarize only validated Project 2 lab architecture, workflow, timing, troubleshooting, and validation results.
\nThe original pre-test OU baseline was captured as PowerShell output rather than as a screenshot. No screenshot was fabricated for that step.
\nBefore publishing evidence, verify screenshots do not expose:
\nDirectory object GUIDs, source anchors, lab UPNs, server names, and lab IP addresses may remain where intentionally used as technical evidence.
COMPLETE
\nThis project uses an existing Microsoft Entra Cloud Sync deployment. The synchronization infrastructure was already operational before this validation project and was not rebuilt.
\nad.jeremyfontenot.onlineJFADDC0110.10.20.10DC01 provides:
\njeremyfontenot.onlineSYNC0110.10.20.105Synchronization is intentionally limited to the dedicated organizational unit:
\nOU=Cloud Sync,OU=JFAD,DC=ad,DC=jeremyfontenot,DC=online
The scope was validated in the Microsoft Entra admin center before performing the controlled identity lifecycle test.
\nA dedicated test identity was created in the Cloud Sync OU:
\nCloud Sync Test 01cloudsync.test01cloudsync.test01@jeremyfontenot.onlineThe account was created on-premises and allowed to synchronize through the existing Cloud Sync configuration.
\nThe on-premises Department attribute was changed to:
Hybrid Identity Lab
The value was first validated in Active Directory and subsequently verified in Microsoft Entra.
\nThe controlled user's password was changed on-premises.
\nThe change was validated by:
\nPasswordLastSet timestamp in Active Directory.No password value was recorded in project evidence.
\nA controlled Active Directory security group was created:
\nGG-CloudSync-Testcloudsync.test01 was added as a direct member.
After the normal Cloud Sync provisioning cycle, Microsoft Entra showed:
\nThe Cloud Sync configuration reports:
\nThese separate synchronization schedules were accounted for during validation to distinguish expected propagation delay from actual synchronization failures.
\nThe existing agent on SYNC01 was retained.
Agent validation confirmed:
\nAADConnectProvisioningAgentThe agent runs under its existing group Managed Service Account and was not reinstalled or replaced.
\nAll lifecycle changes originated in on-premises Active Directory. Microsoft Entra was treated as the synchronized target for the tested identities and attributes.
\nExisting Cloud Sync infrastructure was preserved throughout the project.
COMPLETE
\nThe existing Microsoft Entra Cloud Sync deployment was already functioning and did not need to be rebuilt.
\nA key operational lesson from this project was to validate the current state before making changes. The working agent, OU scope, Password Hash Synchronization, and existing synchronized users provided a known-good baseline.
\nMicrosoft Entra Cloud Sync uses separate synchronization intervals for different functions.
\nObserved in this lab:
\nA newly created or modified directory object should not be treated as failed until the expected provisioning interval has been considered.
\nThis distinction prevents unnecessary troubleshooting, restarts, or configuration changes.
\nFor synchronized identities, on-premises Active Directory remained the authoritative source for the tested attributes.
\nChanges were made in Active Directory first and then validated in Microsoft Entra.
\nThe source relationship was verified using:
\nobjectGUIDThe controlled user's Active Directory objectGUID was converted to its Base64 source-anchor representation.
That value matched the Microsoft Entra on-premises immutable ID and the provisioning-log source anchor.
\nThis provided direct evidence that the cloud identity was linked to the intended on-premises AD object.
\nPassword Hash Synchronization completed on a shorter cycle than Users and Groups provisioning.
\nSuccessful Microsoft Entra authentication after an on-premises password change provided practical proof that Password Hash Synchronization was functioning.
\nCreating a synchronized group is only part of group lifecycle validation.
\nThis project also confirmed that:
\nMember property referenced the synchronized user's source anchorProvisioning logs provided visibility into:
\nThey were more useful for determining actual synchronization behavior than relying only on portal object visibility.
\nThe provisioning agent service was Running while the event log still contained performance-counter errors.
\nReviewing the agent event log identified a permissions issue affecting the metrics collector.
\nAdding the provisioning gMSA to the local Performance Log Users group resolved the registry-access error without reinstalling Cloud Sync.
Test-ADServiceAccount returned False when executed on DC01 because the Cloud Sync gMSA was assigned for use by SYNC01.
The result demonstrated the importance of understanding what a validation command actually tests before interpreting its output as a failure.
\nThe group initially appeared missing from Microsoft Entra because a Users and Groups provisioning cycle had not yet completed.
\nThe object eventually synchronized successfully after the expected Cloud Sync interval.
\nThe main operational lesson is:
\n\n\nConfirm the synchronization schedule before escalating normal propagation delay into troubleshooting.
\n
Useful evidence includes:
\nPasswords, tokens, authentication secrets, private keys, and other credentials should never be included in portfolio evidence.
COMPLETE
\nThe existing Microsoft Entra Cloud Sync agent on SYNC01 was preserved and not reinstalled.
Validation confirmed:
\nAADConnectProvisioningAgentThe provisioning agent runs under:
\nJFAD\\pGMSA_126bbe50$
Active Directory validation confirmed that SYNC01 is authorized to retrieve the gMSA managed password.
A Test-ADServiceAccount command executed from DC01 returned False.
This result was not treated as evidence that the gMSA was broken because Test-ADServiceAccount validates whether the computer executing the command can use the account. The Cloud Sync gMSA is assigned to SYNC01, not DC01.
The Cloud Sync agent event log initially contained:
\n12033Global was deniedThe local Performance Log Users group on SYNC01 contained no members.
The Cloud Sync gMSA was added to the local:
\nPerformance Log Users
group.
\nAfter the agent service was restarted, the previous registry-access error did not recur and the event log reported:
\n14013Metrics Agent was initialized successfully.The agent also logged Event ID 12009 indicating failure to initialize performance counters.
Because:
\nthe agent was not reinstalled based solely on this event.
\nDuring group synchronization testing, the newly created GG-CloudSync-Test group did not immediately appear in Microsoft Entra.
Initial troubleshooting verified:
\ngroupThe Cloud Sync Overview later confirmed that Users and Groups provisioning uses a fixed:
\n20 minute
interval.
\nAfter the expected provisioning cycle completed, the group appeared successfully in Microsoft Entra with its synchronized member.
\nThis behavior was documented as normal propagation delay rather than a synchronization failure.
\nA group was tested through the AD-to-Entra Provision on demand interface.
The request returned:
\nResourceNotFound
with a message indicating the input entry was not found or was out of scope.
\nFurther inspection of the interface showed that this AD-to-Entra provisioning workflow was operating on user objects.
\nThe group test result was therefore not used as evidence of a failed group synchronization.
\nAt the end of testing:
\nThe environment was troubleshot from observed evidence rather than by reinstalling Cloud Sync or changing scope without cause.
\nThe working synchronization infrastructure was preserved throughout the project.
COMPLETE
\ncloudsync.test01cloudsync.test01@jeremyfontenot.onlineOU=Cloud Sync,OU=JFAD,DC=ad,DC=jeremyfontenot,DC=onlineDepartmentHybrid Identity LabHybrid Identity LabGG-CloudSync-TestCloud Sync Test 011e49a065-aa0d-4415-87d2-ee0ad0f4f1d2ZaBJHg2qFUSH0u4K0PTx0g==The controlled hybrid identity lifecycle test successfully validated Active Directory to Microsoft Entra provisioning, attribute synchronization, Password Hash Synchronization, security-group synchronization, membership synchronization, provisioning logs, and source-anchor correlation.
\n| Validation Area | \nSource / Test | \nExpected Result | \nActual Result | \nStatus | \n
|---|---|---|---|---|
| Cloud Sync agent service | \nSYNC01 service state | \nRunning / Automatic | \nRunning / Automatic | \nCOMPLETE | \n
| Cloud Sync agent in Entra | \nCloud Sync Agents page | \nActive | \nActive | \nCOMPLETE | \n
| OU scope | \nDedicated Cloud Sync OU | \nCorrect OU selected | \nCorrect OU selected | \nCOMPLETE | \n
| New user creation | \ncloudsync.test01 | \nEnabled in scoped OU | \nEnabled in scoped OU | \nCOMPLETE | \n
| User provisioning | \nAD → Microsoft Entra | \nUser appears in Entra | \nUser synchronized successfully | \nCOMPLETE | \n
| Attribute synchronization | \nDepartment | \nHybrid Identity Lab in Entra | \nValue synchronized | \nCOMPLETE | \n
| Password Hash Sync | \nOn-prem password change | \nNew password authenticates to Entra | \nAuthentication successful | \nCOMPLETE | \n
| Security group sync | \nGG-CloudSync-Test | \nGroup appears in Entra | \nGroup synchronized | \nCOMPLETE | \n
| Group membership sync | \ncloudsync.test01 membership | \nMember appears in Entra group | \nMembership synchronized | \nCOMPLETE | \n
| Source anchor correlation | \nAD objectGUID → Base64 | \nMatches Entra immutable ID | \nExact match confirmed | \nCOMPLETE | \n
| Provisioning logs | \nUser provisioning event | \nSuccessful processing | \nSuccess | \nCOMPLETE | \n
| Group provisioning logs | \nGroup provisioning event | \nSuccessful processing | \nSuccess | \nCOMPLETE | \n
| Provisioning failures | \nFinal failure review | \nNo current failures | \nNo results | \nCOMPLETE | \n
| Agent outbound connectivity | \nMicrosoft bootstrap endpoint TCP 443 | \nConnection succeeds | \nTcpTestSucceeded = True | \nCOMPLETE | \n
The controlled identity lifecycle test is COMPLETE.
\nThe broader portfolio project remains IN PROGRESS until final portfolio presentation material and evidence files are organized and committed.
Provisioning logs, source-anchor correlation, OU scope, and agent traces were inspected before resets. The retained implementation distinguishes the 20-minute user/group interval from the separate Password Hash Sync process.
User and group synchronization, Password Hash Sync, source authority, provisioning logs, and agent health are documented as validated.
STRONG — lifecycle validation, provisioning logs, source-anchor correlation, Password Hash Sync, group sync, troubleshooting, and a validation script are documented.
Maintenance-only unless Cloud Sync scope, agent placement, or tenant configuration changes.
Continue exploring
Encrypted local administrator passwords, scoped Group Policy, delegated readers, and positive and negative access tests.
Project 03 / Infrastructure
A Microsoft-centered infrastructure lab with documented directory services, virtualization, networking, and bounded recovery tests.
A Microsoft-centered infrastructure lab with documented directory services, virtualization, networking, and bounded recovery tests.
Classification: Validated lab work.
Build and validate a repeatable environment for systems administration while keeping backup inventory, service health, and restore assurance as distinct claims.
Dell PowerEdge R710 with Proxmox VE. The retained platform inventory documents pfSense, DC01, WS01, and Linux01; subsystem records cover nested Hyper-V and management servers.
Dell PowerEdge R710 with Proxmox VE. The retained platform inventory documents pfSense, DC01, WS01, and Linux01; subsystem records cover nested Hyper-V and management servers.
Explore infrastructure architecture →Project 03 · COMPLETE · validated scope
A Microsoft-centered home lab for Windows, identity, networking, virtualization, hybrid management, Linux, macOS, backup, and restore practice.
Architecture
The environment centers on pfSense networking, Windows Server Active Directory, Hyper-V, SCVMM, Windows Admin Center, Azure Arc, Linux, macOS, backup, and restore assurance. Proxmox provides the underlying virtualization platform for several lab systems.
Systems
Core systems include DC01, WS01, HVHOST01, VMM01, APP01, Linux01, macOS, and pfSense. Each system has a defined role and is documented as lab infrastructure, not production enterprise ownership.
Operations
Operational work includes AD DS, DNS, DHCP, WinRM, RDP, Windows Admin Center, virtualization networking, pfSense rules, OpenVPN access, backup schedules, and restore validation.
Restore validation
Restore assurance is treated as an operational control. Validation focuses on recoverability, isolated testing, service checks, and documented evidence.
Scope and limitations
The evidence documents a bounded lab. Restore results include both narrow PASS and INCONCLUSIVE outcomes; no disaster-recovery readiness, RTO, RPO, clustering, or high-availability claim is made.
Evidence
This public evidence folder summarizes reviewer-safe records from the private home-lab operations repository without exposing private repository links. Public claims use stable classifications instead of date-based proof labels. The direct-evidence/ folder contains sanitized direct artifacts for the current infrastructure claims.
Jeremy-Fontenot-On-Premises-Home-Lab-Documentation.docxD7E81A06DCFBD2E91EB8F52A02BDC795AC5B7084A70F343233F1104CCD297BDBeffdbeb0ed8d632a0b0c93328cd593cf85c3eb46fb6c286873285778d88d6d5cfde0b9bd00b96f3610.10.30.20/24; older 10.10.20.x Linux01 evidence is historical.Personal lab evidence does not represent employer production administration, client infrastructure ownership, enterprise scale, guaranteed uptime, full firewall assurance, or full security assurance. Timeout observations remain timeout observations. The restore evidence is one isolated Linux01 restore drill only and does not establish recurring restore assurance, RTO, RPO, SLA, or disaster-recovery readiness.
Direct DC01 inventory supports Windows Server, installed role, domain, Global Catalog, FSMO, and DC01 IP claims for the personal nonproduction lab.
\nAuthenticated DC01 target-local inventory result objects: OperatingSystem, InstalledRolesFeatures, Domain, Forest, and DomainControllers.
\nfontenotjeremy71-hub/jeremy-homelab-ops
\nfb6c286873285778d88d6d5cfde0b9bd00b96f36
\ninventories/dc01-inventory-20260626-022543.json
inventories/dc01-inventory-20260626-022543.json: F60A6DD8C9EE42E90B02B210B1B1A775F89E5C3DED26618B593DEE1362C6DE42
Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed executing account, privileged group details, SIDs, object GUIDs, GPO GUIDs, unrelated installed features, event details, raw time values not needed for the claim, and unrelated command output. Retained DC01 IP because it is already part of the current public home-lab evidence boundary.
\n2026-06-30
\nValidated
Direct Linux01 remediation evidence supports a narrow Linux01-only SSSD responder/socket conflict remediation and post-remediation validation.
\nservices = nss, pam.config_file_version = 2 was rejected by SSSD 2.12 config validation.config_file_version = 2 directive.Linux01 SSSD remediation evidence record.
\nfontenotjeremy71-hub/jeremy-homelab-ops
\nfb6c286873285778d88d6d5cfde0b9bd00b96f36
\nevidence/linux01-sssd-remediation-20260626-110159.md
evidence/linux01-sssd-remediation-20260626-110159.md: 04773570FBE305353F5EB370B8F9629AC335E35A7BEF7151A2CBB98D7371CC49
Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed diagnostic artifact paths, backup filesystem path, account context, raw command history, and implementation details not needed to support the remediation claim. Retained hashes because they are part of the validation evidence.
\n2026-06-30
\nValidated
Direct Linux01 inventory, Proxmox inventory, and source reconciliation evidence support Linux01 VM association, Ubuntu version, kernel, VLAN, IP addressing, DNS, gateway, current-versus-historical address boundary, and directly proven domain integration state.
\nresolved.virtualMachines[] entry for VM 400.fontenotjeremy71-hub/jeremy-homelab-ops
\nfb6c286873285778d88d6d5cfde0b9bd00b96f36
\ninventories/linux01-inventory-20260626-084312.jsoninventories/proxmox-inventory-20260626-010601.jsonevidence/home-lab-source-reconciliation-20260626-012606.mdinventories/linux01-inventory-20260626-084312.json: 75F82AF4882FA9C869C78C1AC127C5D4F37C5CB62F4E8894361A352695EFC40Dinventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3Devidence/home-lab-source-reconciliation-20260626-012606.md: 2D377A7A6703F8C3C5FBB77AA093569806DDB7939CFA88FD6A0ECF801484C3EERecorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed executing account, machine identifiers, link-local IPv6 address, raw boot/session identifiers, unrelated package/service details, unnecessary filesystem paths, and distro metadata not needed for the public claim.
\n2026-06-30
\nValidated
Direct Proxmox backup configuration evidence supports the configured weekly snapshot job for primary lab VMs.
\nsun 02:00).backupJobs[].fontenotjeremy71-hub/jeremy-homelab-ops
\nfb6c286873285778d88d6d5cfde0b9bd00b96f36
\ninventories/proxmox-inventory-20260626-010601.jsonevidence/home-lab-backup-restore-validation-20260629.txtinventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3Devidence/home-lab-backup-restore-validation-20260629.txt: 4637E848C9B318B8C74BB9C6E4569B3CC03E6686CE64FA367CF6DEC05FA52E13Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed scheduling metadata not needed for the claim, command context, host details, and any unrelated storage, VM, or task information.
\n2026-06-30
\nConfigured
Direct backup inventory evidence supports active backup-hdd storage, retained archive presence by VM count, and the boundary that archive presence is not the same as recurring restore assurance.
\n/mnt/pve/backup-hdd.dir, content backup, total 982,809,350,144 bytes, used 172,812,951,552 bytes, available 759,996,993,536 bytes.storage[].inventories/proxmox-inventory-20260626-010601.jsonevidence/home-lab-backup-restore-validation-20260629.txtevidence-library/projects/on-prem-home-lab/validated-2026-06-21/text/proxmox-storage-validation.txtinventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3Devidence/home-lab-backup-restore-validation-20260629.txt: 4637E848C9B318B8C74BB9C6E4569B3CC03E6686CE64FA367CF6DEC05FA52E13evidence-library/projects/on-prem-home-lab/validated-2026-06-21/text/proxmox-storage-validation.txt: 7F069AA31390D90D99F0000D6F6236A2B60F5D28F061668C0BBD5054FA93741FRecorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed PIDs, unrelated filesystems, device identifiers not needed for the claim, snapshot parent names, raw command history, and backup archive filenames. Retained the backup storage path because it is the public claim being validated.
\n2026-06-30
\nDocumented / Limitation
Direct Proxmox inventory supports the personal nonproduction lab platform claim for Proxmox VE, primary VM IDs, VM names, running state, allocated vCPU, memory, disk, bridge placement, guest-agent state, and Linux01 VLAN tag where captured.
\nversion, node.kernel, virtualMachines[], and storage[].fontenotjeremy71-hub/jeremy-homelab-ops
\nfb6c286873285778d88d6d5cfde0b9bd00b96f36
\ninventories/proxmox-inventory-20260626-010601.jsonevidence/home-lab-source-reconciliation-20260626-012606.mdinventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3Devidence/home-lab-source-reconciliation-20260626-012606.md: 2D377A7A6703F8C3C5FBB77AA093569806DDB7939CFA88FD6A0ECF801484C3EERecorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed node uptime, repository ID, host resource details not needed for the public claim, snapshot parent names, raw paths unrelated to the platform claim, and any fields not required to prove the listed inventory values.
\n2026-06-30
\nValidated
Direct restore validation evidence supports one isolated Linux01 restore drill from source VM 400 to temporary VM 401.
\nTASK OK line; those details are therefore not claimed here.Backup and restore validation text: VM state and restore drill sections.
\nfontenotjeremy71-hub/jeremy-homelab-ops
\nfb6c286873285778d88d6d5cfde0b9bd00b96f36
\nevidence/home-lab-backup-restore-validation-20260629.txt
evidence/home-lab-backup-restore-validation-20260629.txt: 4637E848C9B318B8C74BB9C6E4569B3CC03E6686CE64FA367CF6DEC05FA52E13
Recorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed PIDs and retained only the VM IDs, restore scope, network isolation, guest identity, guest-agent response, and cleanup outcome needed to support the public claim.
\n2026-06-30
\nTested
Direct WS01 inventory and Proxmox inventory support the WS01 system, VM association, domain membership, and network-state claims for the personal nonproduction lab.
\nvirtualMachines[] entry for VM 300.fontenotjeremy71-hub/jeremy-homelab-ops
\nfb6c286873285778d88d6d5cfde0b9bd00b96f36
\ninventories/ws01-inventory-20260626-012952.jsoninventories/proxmox-inventory-20260626-010601.jsoninventories/ws01-inventory-20260626-012952.json: 1438FA0F72F241E2613C5D35B797492FFC754B0E818A74154DE38DD74082A6B1inventories/proxmox-inventory-20260626-010601.json: D652D1EF753E14242C07F84F19FBF09F642F07C3B09CFE2E98AA7F2B176ADE3DRecorded in evidence-library/integrity/evidence-hashes.json for this artifact path. The self-hash is recorded outside this file so the digest does not invalidate itself.
Removed executing account, local administrator membership, SIDs, GUIDs, group policy raw details, software inventory, unrelated services, event data, and local profile or path information.
\n2026-06-30
\nValidated
No credentials, private keys, tokens, cookies, or secrets were copied. Public summaries avoid private repository links and retain only reviewer-safe claim context.
\nFor the direct evidence artifacts, usernames, executing accounts, MAC addresses, UUIDs, VM generation IDs, UPIDs, PIDs, SIDs, internal object GUIDs, absolute local Windows user paths, unnecessary root paths, unrelated installed features, unrelated command history, unnecessary timestamps, and snapshot parent names were removed or omitted where they were not required to support the stated public claim.
\nThe Proxmox thin-pool warning is retained as an operational limitation. It is not framed as a failed restore or infrastructure failure.
Partially validated by retained June 24 documentation. No restore test was repeated during the 2026-06-26 read-only operations run.
\nRead-only Proxmox inventory observed an enabled scheduled backup job:
\nbackup-critical-lab-vms100,200,300,400backup-hddsun 02:00snapshotzstdStorage inventory observed backup storage named backup-hdd at /mnt/pve/backup-hdd.
The June 24 IP-address-documented portfolio documentation records isolated startup restore checks for:
\nThe current Proxmox inventory no longer shows VM 500 or VM 600, which is consistent with the documentation stating both temporary restore VMs were removed after validation.
\nBefore claiming recurring restore assurance, perform an approved fresh restore validation that documents:
\nThe current operations repository validates backup job configuration visibility and retains documentation of June 24 isolated startup restore checks. It does not validate current backup archive integrity, recurring restore success, RTO, RPO, or disaster-recovery readiness.
Planned. Approval required before implementation.
\nJune 24 documentation records pfSense forwarding selected system, firewall, authentication, VPN, and gateway events to Linux01 at 10.10.30.20:514, with Linux01 rsyslog listeners and alert-match logging. Current Proxmox metadata validates Linux01 is running on VLAN 30 and QEMU guest agent is responding.
The June 26 authenticated Linux01 target-local inventory validates rsyslog runtime state from inside the guest. Linux01 reports rsyslog active, TCP and UDP 514 listening on 10.10.30.20, remote collector configuration under /etc/rsyslog.d/10-remote-collector.conf, pfSense alert file configuration under /etc/rsyslog.d/05-pfsense-alerts.conf, and rsyslog logrotate configuration under /etc/logrotate.d/rsyslog.
tag=30, guest agent responding.linux01.ad.jeremyfontenot.online resolves to 10.10.30.20.inventories/linux01-inventory-20260626-020257.json: SSH from the management execution path timed out; guest-side rsyslog state was NOT TESTED.inventories/linux01-inventory-20260626-084312.json: authenticated target-local Linux01 inventory validates rsyslog service/listener state, route/DNS state, AD integration indicators, disk capacity, and logrotate summary.evidence/linux01-local-inventory-validation-20260626-035220.md: sanitized evidence for Linux01 target-local inventory import and validation.Expand centralized logging beyond pfSense by adding documented, least-privilege log forwarding or collection for Windows and Proxmox sources without weakening existing firewall policy.
\nCandidate target design, pending implementation approval:
\n10.10.30.20:514 for TCP and UDP, and rsyslog log rotation. UFW source restrictions still require a clearer privileged summary before any new source is added.192.168.0.242Discovery and planning only until approved:
\npwsh -NoProfile -File .\\scripts\\linux\\Get-LinuxReadOnlyInventory.ps1\npwsh -NoProfile -File .\\scripts\\active-directory\\Invoke-DC01LocalReadOnlyCollection.ps1\npwsh -NoProfile -File .\\scripts\\windows-server\\Invoke-WS01LocalReadOnlyCollection.ps1\nImplementation commands are intentionally not authorized in this change plan. Linux01 rsyslog state has been validated, but Windows Event Forwarding, Proxmox logging state, pfSense sender configuration, and any firewall or GPO requirements still need a dedicated approved implementation plan.
\nTarget-local validation commands prepared for the next inventory pass:
\nrun_id=\"$(date -u +%Y%m%d-%H%M%S)\"\nbash ./Invoke-Linux01LocalReadOnlyCollection.sh \"/tmp/linux01-inventory-${run_id}.json\"\nNo firewall openings are approved by this plan. Any proposed log path must identify source, destination, protocol, port, and existing firewall state before implementation.
\nExpected network review before implementation:
\nPositive if implemented carefully: stronger audit trail and troubleshooting visibility. Risk if overbroad: excessive log exposure, sensitive log retention, or unnecessary inter-network access.
\nSecurity controls required in the implementation plan:
\nLow for discovery. Medium for configuration changes because logging service reloads or firewall changes could disrupt visibility or access if done incorrectly.
\nImplementation must avoid service restarts unless the approved plan explicitly requires them. Prefer configuration validation and reload-only workflows where technically appropriate.
\nLinux01 authenticated inventory currently supports:
\n10.10.30.20./var/log/remote/%FROMHOST-IP%/messages.log and /var/log/remote/pfsense-alerts.log are configured.Alerting remains planned. Candidate non-invasive alerts after receiver validation:
\nExplicit Jeremy approval is required before any logging configuration, firewall, service, package, or scheduled-task change.
\nThis plan is implementation-ready documentation only. It does not implement centralized logging expansion, change firewall policy, install software, restart services, or modify any infrastructure system. Linux01 rsyslog receiver state is now validated by target-local inventory; additional sources and alerting remain planned until separately approved and implemented.
2026-06-26T01:06:01.2273166-05:00DESKTOP-MR3F9A1C:\\Users\\jeremy\\Documents\\projects\\jeremy-homelab-ops0mcp__home_lab read-only Proxmox tools.pwsh -NoProfile -File .\\tests\\Test-RepositoryStructure.ps1 -WriteEvidencepwsh -NoProfile -File .\\scripts\\monitoring\\Test-HomeLabConnectivity.ps1 -TimeoutMilliseconds 1000Resolve-DnsName ad.jeremyfontenot.online -Server 10.10.20.10route.exe print -4nltest /dsgetdc:ad.jeremyfontenot.online, nltest /dclist:ad.jeremyfontenot.online, nltest /sc_query:JFADGet-Command Get-ADDomain, Get-Command Get-GPO, Get-Command Get-DhcpServerv4Scope, Get-Command Get-DnsServerZone| Check | \nStatus | \nObserved result | \n
|---|---|---|
| Proxmox API inventory | \nPASS | \nVersion 9.2.3, node proxmox online, VMs 100, 200, 300, and 400 running. | \n
| Proxmox storage inventory | \nPASS | \nlocal-lvm, backup-hdd, and local reported capacity and usage. | \n
| Proxmox backup job inventory | \nPASS | \nJob backup-critical-lab-vms enabled for VMs 100,200,300,400, storage backup-hdd, schedule sun 02:00. | \n
| Proxmox management TCP | \nPASS | \n192.168.0.242:8006 connected in 67 ms. | \n
| DC01 DNS TCP | \nPASS | \n10.10.20.10:53 connected in 6 ms. | \n
| Domain DNS resolution | \nPASS | \nad.jeremyfontenot.online resolved to 10.10.20.10 using server 10.10.20.10. | \n
| VPN route | \nPASS | \nRoute table includes 10.10.20.0/24 via 10.10.40.1 from 10.10.40.2. | \n
| Repository validation | \nPASS | \nRepository validation completed with no failing checks. | \n
| Check | \nStatus | \nObserved result | \n
|---|---|---|
| pfSense LAN HTTPS TCP | \nWARNING | \n10.10.20.1:443 timed out after 1000 ms. | \n
| DC01 Kerberos TCP | \nWARNING | \n10.10.20.10:88 timed out after 1000 ms. | \n
| DC01 LDAP TCP | \nWARNING | \n10.10.20.10:389 timed out after 1000 ms. | \n
| DC01 SMB TCP | \nWARNING | \n10.10.20.10:445 timed out after 1000 ms. | \n
| DC01 WinRM TCP | \nWARNING | \n10.10.20.10:5985 timed out after 1000 ms. | \n
| Domain controller discovery | \nINCONCLUSIVE | \nnltest /dsgetdc:ad.jeremyfontenot.online returned ERROR_NO_SUCH_DOMAIN from the current workstation context. | \n
| Secure channel query | \nINCONCLUSIVE | \nnltest /sc_query:JFAD returned RPC_S_SERVER_UNAVAILABLE from the current workstation context. | \n
| DNS Server module inventory | \nNOT TESTED | \nGet-DnsServerZone is not installed on the management workstation. | \n
| DHCP Server module inventory | \nNOT TESTED | \nGet-DhcpServerv4Scope is not installed on the management workstation. | \n
| Group Policy inventory | \nNOT TESTED | \nGet-GPO is not installed on the management workstation. | \n
| WS01 guest inventory | \nNOT TESTED | \nNo verified WS01 management IP or guest-agent response was available in this run. | \n
This evidence records read-only repository validation, Proxmox connector inventory, local route inspection, DNS resolution, and bounded TCP reachability checks. It does not validate pfSense configuration, firewall policy, NAT policy, VPN configuration correctness, Active Directory health, DNS zone health, DHCP scope health, Group Policy processing, WS01 domain relationship, backup restore integrity, or administrative access to Windows guests.
\nTimeouts, module absence, and nltest failures are recorded observations only. They are not proof that the corresponding infrastructure components are offline, misconfigured, or unavailable.
Current as of the 2026-06-26 read-only reconciliation run.
\njeremy-homelab-ops inventories and evidence.main branch of fontenotjeremy71-hub/jeremyfontenot.| Component | \nCurrent supported value | \nClassification | \nEvidence | \n
|---|---|---|---|
| Physical host | \nDell PowerEdge R710 | \nCurrent documentation | \nPortfolio and operations docs | \n
| Hypervisor | \nProxmox VE 9.2.3 | \nCurrent | \nProxmox API | \n
| Proxmox management | \n192.168.0.242/24, gateway 192.168.0.1 | \nCurrent | \nProxmox API and TCP validation | \n
| pfSense | \nVM 100 pfsense-fw | \nCurrent | \nProxmox API | \n
| pfSense WAN | \n192.168.0.205/24 | \nCurrent documentation, not re-queried from pfSense | \nJune 24 DOCX | \n
| pfSense LAN | \n10.10.20.1/24 | \nCurrent documentation | \nJune 24 DOCX and topology | \n
| Linux VLAN gateway | \n10.10.30.1/24 | \nCurrent documentation | \nJune 24 DOCX | \n
| OpenVPN network | \n10.10.40.0/24 | \nCurrent documentation plus route evidence | \nJune 24 DOCX and local route | \n
| DC01 | \nVM 200, 10.10.20.10/24, Windows Server 2022 domain controller | \nCurrent authenticated guest inventory | \nProxmox API, DNS/RDP validation, inventories/dc01-inventory-20260626-022543.json | \n
| WS01 | \nVM 300, 10.10.20.100/24, Windows domain workstation | \nCurrent authenticated guest inventory | \nProxmox API, inventories/ws01-inventory-20260626-012952.json | \n
| Linux01 | \nVM 400, 10.10.30.20/24, VLAN 30, Ubuntu 26.04 LTS domain member | \nCurrent authenticated guest inventory | \nProxmox API, DNS validation, inventories/linux01-inventory-20260626-084312.json | \n
| AD domain | \nad.jeremyfontenot.online | \nCurrent authenticated guest inventory | \nDC01 target-local inventory, 2026-06-26 | \n
| NetBIOS domain | \nJFAD | \nCurrent authenticated guest inventory | \nDC01 target-local inventory, 2026-06-26 | \n
| Backup storage | \nbackup-hdd at /mnt/pve/backup-hdd | \nCurrent | \nProxmox API | \n
| Backup job | \nbackup-critical-lab-vms, Sunday 02:00, snapshot, zstd, VMs 100/200/300/400 | \nCurrent | \nProxmox API | \n
| Value | \nClassification | \nCurrent handling | \n
|---|---|---|
Linux01 10.10.20.20/24 | \nHistorical | \nRetained as pre-VLAN 30 address only | \n
Linux01 DHCP 10.10.20.101 | \nHistorical | \nRetained as initial setup address only | \n
backup-nvme or /mnt/pve/backup-nvme | \nStale or inconclusive | \nNot current unless future evidence proves rename/replacement | \n
| Direct WAN-side RDP forwarding | \nHistorical | \nCurrent design uses OpenVPN-only RDP path | \n
| June 21 restore outstanding limitation | \nHistorical | \nSuperseded by June 24 isolated restore documentation, not re-run during this ops pass | \n
This file corrects explanatory documentation using current evidence. It does not modify historical evidence and does not claim live guest OS internals unless current command output or explicitly cited retained evidence supports the claim.
\nThe June 26 target-local workflow imported authenticated DC01 evidence in inventories/dc01-inventory-20260626-022543.json and evidence/dc01-local-inventory-validation-20260626-022811.md. It imported authenticated WS01 evidence in inventories/ws01-inventory-20260626-012952.json and evidence/ws01-local-inventory-validation-20260626-033405.md. It also imported authenticated Linux01 evidence in inventories/linux01-inventory-20260626-084312.json and evidence/linux01-local-inventory-validation-20260626-035220.md.
2026-06-26T01:26:06.6980689-05:00DESKTOP-MR3F9A1C:\\Users\\jeremy\\Documents\\projects\\jeremy-homelab-opsC:\\Users\\jeremy\\Documents\\projects\\jeremyfontenothttps://jeremyfontenot.online/on-prem-home-lab.html0| Component | \nResult | \n
|---|---|
| Proxmox version | \n9.2.3 | \n
| VM 100 | \npfsense-fw, running, vmbr0 and vmbr1 | \n
| VM 200 | \ndc01, running, vmbr1 | \n
| VM 300 | \nws01, running, vmbr1, guest agent disabled | \n
| VM 400 | \nlinux01, running, vmbr1, tag=30, QEMU guest agent responding | \n
| Backup storage | \nbackup-hdd, path /mnt/pve/backup-hdd, active | \n
| Backup job | \nbackup-critical-lab-vms, enabled, sun 02:00, snapshot, zstd, VMs 100,200,300,400 | \n
| Linux01 DNS | \nlinux01.ad.jeremyfontenot.online resolves to 10.10.30.20 | \n
| Linux01 PTR | \n10.10.30.20 resolves to linux01.ad.jeremyfontenot.online | \n
| VPN path | \nDC01 DNS TCP 53 and RDP TCP 3389 reachable | \n
| Expected block | \nDC01 SMB TCP 445 and pfSense WAN direct RDP TCP 3389 timed out | \n
| Component | \nHigher-precedence current value | \nLower-precedence conflicting value | \nClassification | \nAction | \n
|---|---|---|---|---|
| Linux01 IP | \n10.10.30.20/24 | \nDeployed website and June 21 evidence show 10.10.20.20/24 | \nStale deployed/historical value | \nOperations docs now treat 10.10.20.20 as historical | \n
| Linux01 VLAN | \nProxmox config has tag=30 | \nDeployed website omits VLAN 30 current state | \nStale deployed value | \nOperations docs use current Proxmox metadata | \n
| Restore status | \nJune 24 DOCX records isolated restore checks for VM 500 and 600 | \nJune 21 redaction log says restore outstanding | \nHistorical difference | \nRecovery docs distinguish June 21 historical limitation from June 24 documentation | \n
| Backup storage | \nProxmox API shows backup-hdd at /mnt/pve/backup-hdd | \nOlder prompt/doc values mention backup-nvme | \nStale or inconclusive historical value | \nOperations docs use backup-hdd and flag backup-nvme as stale unless rename evidence is found | \n
Current Proxmox API output and current DNS/RDP checks are treated as current observed state. Portfolio and DOCX records are retained as documentation evidence where live command output cannot validate guest internals from this client path. Historical evidence is not rewritten.
Linux01 is operating normally using direct SSSD responder activation.
The records distinguish Linux01 SSSD remediation, networking state, backup configuration, and mixed restore outcomes. A platform inventory or a successful backup listing is not treated as proof of guest health or recoverability.
Validated infrastructure scope is complete. Recovery records retain narrow PASS and INCONCLUSIVE outcomes; they do not establish production DR readiness.
VERY STRONG — current-state records, dated validation folders, subsystem case studies, screenshots, restore evidence, and bounded results are preserved.
Continue operational maintenance and add new subsystem evidence only when meaningful; preserve explicit restore-result boundaries.
Continue exploring
Centralized Windows administration backed by connectivity, authentication, and remote-management validation.
Two Arc-connected Windows Server lab machines, agent validation, and one SQL Server Developer instance.