Shielded VM Template Creation in a Hyper-V Guarded Fabric
To set up a shielded virtual machine template on a Hyper-V guarded fabric, you need to prepare a secure environment (Host Guardian Service, guarded hosts) and then create a BitLocker-protected, signed template disk. This document assumes that all Windows Server instances used are running Windows Server 2022 or Windows Server 2025. Prerequisites and Environment Setup Host Guardian Service (HGS): Deploy an HGS cluster (typically 3 nodes for high availability) in a separate Active Directory forest dedicated to HGS. For production, HGS should run on physical (or highly secured) servers, ideally as a three-node cluster. Ensure the HGS servers have the Host Guardian Service role installed and are up to date with software updates. Attestation Mode: TPM-Based: Ensure that HGS is configured for TPM-trusted attestation. In TPM mode, HGS uses each host’s TPM 2.0 identity (EKpub) and measured boot sequence to verify the host’s health and authenticity. This requires capturing each Hyper-V host’s TPM identifier and establishing a security baseline: TPM 2.0 and Boot Measurements: On each Hyper-V host, retrieve the TPM’s public endorsement key (EKpub) and add it to the HGS trust store (e.g. using Get-PlatformIdentifier on the host and Add-HgsAttestationTpmHost on HGS). HGS will also require a TPM baseline (PCR measurements of the host’s firmware/boot components) and a Code Integrity (CI) policy defining allowed binaries. Generate these from a reference host and add them to HGS so that only hosts booting with the approved firmware and software can attest successfully. Host Requirements: Each guarded host (Hyper-V host) must meet hardware/OS requirements for TPM attestation. This includes TPM 2.0, UEFI 2.3.1+ firmware with Secure Boot enabled, and support for IOMMU/SLAT (for virtualization-based security). On each host, enable the Hyper-V role and install the Host Guardian Hyper-V Support feature (available in Datacenter edition). This feature enables virtualization-based protection of code integrity (ensuring the host hypervisor only runs trusted code), which is required for TPM attestation. (Test this configuration in a lab first as VBS/CI can affect some drivers). Guarded Fabric Configuration: Join Hyper-V hosts to the fabric domain and configure networking so that guarded hosts can reach the HGS servers (set up DNS or DNS forwarding between the fabric domain and HGS domain). After setting up HGS and adding host attestation data, configure each Hyper-V host as a guarded host by pointing it to the HGS cluster for attestation and key retrieval (using Set-HgsClientConfiguration to specify the HGS attestation and key protection URLs and any required certificates). Once a host attests successfully, it becomes an authorized guarded host able to run shielded VMs. HGS will release the necessary decryption keys only to those hosts that pass health attestation. Step 1: Create and Configure the Template VM (Gen 2) Prepare a Generation 2 VM: On a Hyper-V host (it can be a regular host or even a non-guarded host for template creation), create a new Generation 2 virtual machine. Generation 2 with UEFI is required for Secure Boot and virtual TPM support. Attach a blank virtual hard disk (VHDX) for the OS. Install Windows Server on this VM using standard installation media. Partition and File System Requirements: When installing the OS on the template VM, ensure the VHDX is initialized with a GUID Partition Table (GPT) and that the Windows setup creates the necessary partitions: there should be at least a small System/EFI boot partition (unencrypted) and the main OS partition (which will later be BitLocker-encrypted). The disk must be a basic disk (not dynamic within the guest OS) and formatted with NTFS to support BitLocker. Using the default Windows setup on a blank drive typically meets these requirements (the installer will create the EFI and OS partitions automatically on a GPT disk). Configure the OS: Boot the VM and perform any baseline configuration needed. Do not join this VM to any domain and avoid putting sensitive data on it as it should be a generic base image. Apply the latest Windows Updates and install any required drivers or software that should be part of the template OS (e.g. common management agents). Ensuring the template OS is fully updated is important for a reliable shielding process. Enable Remote Management: Because shielded VMs can only be managed remotely (no console access), consider configuring the template to enable Remote Desktop and/or PowerShell WinRM, and ensure the firewall is configured accordingly. You may also install roles/features that many VMs will need. However, do not configure a static IP or unique machine-specific settings in this template as those will be supplied via an answer file during provisioning. Step 2: Generalize the VM with Sysprep Run Sysprep: In the VM, open an elevated Command Prompt and run: C:\Windows\System32\Sysprep\Sysprep.exe /oobe /generalize /shutdown Choose “Enter System Out-of-Box Experience (OOBE)”, check “Generalize”, and set Shutdown option to “Shutdown” if using the GUI. This strips out machine-specific details and prepares the OS for first-boot specialization. The VM will shut down upon completion. Do Not Boot After Sysprep: Leave the VM off after it shuts down. The OS on the VHDX is now in a generalized state. Do not boot this VM again (doing so will boot into OOBE and break its generalized state). At this point you have a prepared OS disk (the VHDX) ready for sealing. (Optional) Backup the VHDX: It’s a good idea to make a copy of the sysprep’ed VHDX at this stage. After the next step (sealing the template), the disk will be BitLocker-encrypted and cannot be easily modified. Keeping an unencrypted copy allows you to easily update the template image in the future if needed. Step 3: Protect and Seal the Template Disk (Shielded Template Wizard) Next, seal the template VM’s OS disk using the Shielded VM Template Disk Creation process. This will encrypt the disk (preparing it for BitLocker) and produce a signed catalog so that the disk’s integrity can be verified later. Install Shielded VM Tools: On a machine with GUI (this can be a management server or even Windows 11 with RSAT), install the Shielded VM Tools component. On Windows Server, use PowerShell: Install-WindowsFeature RSAT-Shielded-VM-Tools -IncludeAllSubFeature (and reboot if prompted). This provides the Template Disk Wizard (TemplateDiskWizard.exe) and PowerShell cmdlets like Protect-TemplateDisk. Obtain a Signing Certificate: Acquire a certificate to sign the template disk’s Volume Signature Catalog (VSC). For production, use a certificate issued by a trusted CA that both the fabric administrators and tenants trust (e.g. an internal PKI or a certificate from a mutually trusted authority). The certificate’s public key will be referenced later by tenants to trust this template. (For a lab or demo, you can use a self-signed cert, but this is not recommended for production.) Import the certificate into the local machine’s certificate store if it’s not already present. Launch the Template Disk Wizard: Open Template Disk Wizard (found in Administrative Tools after installing RSAT, or run TemplateDiskWizard.exe). This wizard will guide you through protecting the VHDX: Certificate: Select the signing certificate obtained in the previous step. This certificate will be used to sign the template’s catalog. Virtual Disk: Browse to and select the generalized VHDX from Step 2 (the sysprep’ed OS disk). Signature Catalog Info: Provide a friendly name and version for this template disk (e.g. Name: “WS2025-ShieldedTemplate”, Version: 1.0.0.0). These labels help identify the disk and version to tenants. Proceed to the final page and Generate. The wizard will now: o Enable BitLocker on the OS volume of the VHDX and store the BitLocker metadata on the disk (but it does not encrypt the volume yet as encryption will finalize when a VM instance is provisioned with this disk). o Compute a cryptographic hash of the disk and create a Volume Signature Catalog (VSC) entry (which is stored in the disk’s metadata) signed with your certificate. This ensures the disk’s integrity can be verified; only disks matching this signed hash will be recognized as this template. Wait for the wizard to finish (it may take some time to initialize BitLocker and sign the catalog, depending on disk size). Click Close when done. The VHDX is now a sealed template disk. It’s marked internally as a shielded template and cannot be used to boot a normal VM without going through the shielded provisioning process (attempting to boot it in an unshielded way will likely cause a blue screen). The disk’s OS volume is still largely unencrypted at rest (encryption will complete when a VM is created), but it’s protected by BitLocker keys that will be released only to an authorized host via HGS. Extract the VSC File (for Tenant Use): It’s recommended to extract the template’s Volume Signature Catalog to a separate file. This .vsc file contains the disk’s identity (hash, name, version) and the signing certificate info. Tenants will use it to authorize this template in their shielding data. Use PowerShell on the RSAT machine: Save-VolumeSignatureCatalog -TemplateDiskPath "C:\path\WS2022-ShieldedTemplate.vhdx" -VolumeSignatureCatalogPath "C:\path\WS2022-ShieldedTemplate.vsc" This saves the .vsc file separately. Share this .vsc with the VM owners (tenants) or have it available for the shielding data file creation in the next step. Alternatively to the wizard, you can use PowerShell: after installing RSAT, run Protect-TemplateDisk -Path <VHDX> -Certificate <Cert> -TemplateName "<Name>" -Version <X.Y.Z.W> to seal the disk in one step. The wizard and PowerShell achieve the same result. Step 4: Create the Shielding Data File (PDK) A shielding data file (with extension .pdk) contains the sensitive configuration and keys required to deploy a shielded VM from the template. This includes the local administrator password, domain join credentials, RDP certificate, and the list of guardians (trust authorities) and template disk signatures the VM is allowed to use. For security, the shielding data is created by the tenant or VM owner on a secure machine outside the fabric, and is encrypted so that fabric admins cannot read the contents. Prerequisites for Shielding Data: Obtain the Volume Signature Catalog (.vsc) file for the template disk (from Step 3) to authorize that template. If the VM should use a trusted RDP certificate (to avoid man-in-the-middle when connecting via RDP), obtain a certificate (e.g. a wildcard certificate from the tenant’s CA) to include. This is optional; if the VM will join a domain and get a computer certificate or if you’re just testing, you may skip a custom RDP certificate. Prepare an unattend answer file or have the information needed to create one (admin password, timezone, product key, etc.). Use the PowerShell function New-ShieldingDataAnswerFile to generate a proper unattend XML for shielded VMs. The unattend will configure the VM’s OS on first boot (e.g. set the Administrator password, optionally join a domain, install roles, enable RDP, etc.). Ensure the unattend enables remote management (e.g. turn on RDP and firewall rules, or enable WinRM) because console access is not available for shielded VMs. Also, do not hardcode any per-VM values in the unattend that should differ for each instance; use placeholders or plan to supply those at deployment time. Creating the .PDK file: On a secure workstation (not on a guarded host) with RSAT Shielded VM Tools installed, launch the Shielding Data File Wizard (ShieldingDataFileWizard.exe). This tool will collect the needed info and produce an encrypted PDK file. Owner and Guardian Keys: First, set up the guardians. “Guardians” are certificates that represent who owns the VM and which fabrics (HGS instances) are authorized to run it. Typically: The Owner Guardian is a key pair that the tenant/VM owner possesses (the private key stays with the tenant). Create an Owner guardian (if not already) via the wizard’s Manage Local Guardians > Create option. This generates a key pair on your machine. Give it a name (e.g. “TenantOwner”). The Fabric Guardian(s) correspond to the HGS of the hosting fabric. Import the HGS guardian metadata file provided by the hoster (this is an XML with the HGS public key, exported via Export-HgsGuardian on the HGS server). In the wizard, use Manage Local Guardians > Import to add the hoster’s guardian(s) (for example, “Contoso HGS”). For production, you might import multiple datacenter guardians if the VM can run in multiple cloud regions, include each authorized fabric’s guardian. After adding, select all the guardian(s) that represent fabrics where this VM is allowed to run. Also select your Owner guardian (the wizard may list it separately). This establishes that the VM will be owned by your key and can only run on hosts approved by those fabric guardians. Template Disk (VSC) Authorization: The wizard will prompt to add Volume ID Qualifiers or trusted template disks. Click Add and import the .vsc file corresponding to the template disk prepared in Step 3. You can usually choose whether the shielding data trusts only that specific version of the template or future versions as well (Equal vs. GreaterOrEqual version matching). Select the appropriate option based on whether you want to allow updates to the template without regenerating the PDK. This step ensures the secrets in the PDK will only unlock when that specific signed template disk is used. Unattend and Certificates: Provide the answer file (Unattend.xml) for the VM’s specialization. If you created one with New-ShieldingDataAnswerFile, load it here. Otherwise, the wizard may have a simplified interface for common settings (depending on version, it may prompt for admin password, domain join info, etc.). Also, if using a custom RDP certificate, import it at this stage (so the VM will install that cert for remote desktop). Create the PDK: Specify an output file name for the shielding data (e.g., MyVMShieldingData.pdk) and finish the wizard. It will create the .pdk file, encrypting all the provided data. The Owner guardian’s private key is used to encrypt secrets, and the Fabric guardian’s public key ensures that HGS (holding the corresponding private key) is needed to unlock the file. The PDK is now ready to use for provisioning shielded VMs. (You can also create PDKs via PowerShell with New-ShieldingDataFile for automation.) Note the PDK is encrypted such that only the combination of the owner’s key and an authorized fabric’s HGS can decrypt it. Fabric admins cannot read sensitive contents of the PDK, and an unauthorized or untrusted host cannot launch a VM using it. Keep the PDK file safe, as it contains the keys that will configure your VM. Step 5: (Optional) Prepare a Shielding Helper VHDX In some scenarios, especially if you need to convert an existing VM into a shielded VM or if you are not using SCVMM for provisioning, a Shielding Helper disk is used. The Shielding Helper is a special VHDX containing a minimal OS that helps encrypt the template disk and inject the unattend inside a VM without exposing secrets to the host. SCVMM can automate this, but if you need to do it manually or for existing VMs, prepare the helper disk as follows: Create a Helper VM: On a Hyper-V host (not necessarily guarded), create a Gen 2 VM with a new blank VHDX (do not reuse the template disk to avoid duplicate disk IDs). Install a supported OS (Windows Server 2016 or higher, a Server Core installation is sufficient) on this VM. This VM will be temporary and its VHD will become the helper disk. Ensure you can log into it (set a password, etc.), then shut it down. Initialize the Helper Disk: On a Hyper-V host with RSAT Shielded VM Tools, run the PowerShell cmdlet: Initialize-VMShieldingHelperVHD -Path "C:\VMs\ShieldingHelper.vhdx" This command should point to the VHDX of the helper VM. This injects the necessary provisioning agent and settings into the VHDX to make it a shielding helper disk. The VHDX is modified in-place (consider making a backup beforehand). Do Not Boot the Helper VM Again: After initialization, do not start the helper VM from Step 1. The VHDX is now a specialized helper disk. You can discard the VM’s configuration. Only the VHDX file is needed going forward. Reuse for Conversions / Non-VMM Deployments: For manually shielding an existing VM, you would attach this helper VHDX to the VM and use PowerShell (e.g. ConvertTo-ShieldedVM or a script) to encrypt the VM’s OS disk using the helper. The helper boots in place of the VM’s OS, uses the PDK to apply BitLocker and the unattend to the OS disk, then shuts down. The VM is then switched to boot from its now-encrypted OS disk with a virtual TPM. (Note: Each initialized helper VHDX is typically one-time-use for a given VM; if you need to shield multiple VMs manually, create or copy a fresh helper disk for each to avoid BitLocker key reuse). Step 6: Prepare the Template Disk and PDK on the Host Copy the VHDX and PDK: Transfer the sealed template .vhdx and the .pdk file to the Hyper‑V host (or a cluster shared volume if the host is part of a Hyper‑V cluster). For example, place them in C:\ShieldedVM\templates\ on the host. This ensures the host can read the files during VM provisioning. Verify File Trust: (Optional) Double-check that the template disk’s signature is recognized by the tenant’s shielding data. The template’s .vsc file (volume signature catalog) should have been used when creating the PDK, so the PDK will “trust” that specific template hash. Also verify that the HGS guardian in the PDK matches your fabric’s HGS public key. These must align, or the VM provisioning will be rejected by HGS. Note: The PDK is encrypted and cannot be opened by the fabric admin as it’s designed so that only HGS (and the VM owner) can decrypt its contents. The host will use it as-is during provisioning. Make sure you do not modify or expose the PDK’s contents. PowerShell to finalize the shielded VM setup. Set up the key protector on the existing VM. For a clean process, you can use New-ShieldedVM on the guarded host: New-ShieldedVM -Name "Finance-App1" ` -TemplateDiskPath "C:\ShieldedVM\Templates\WS2025-ShieldedTemplate.vhdx" ` -ShieldingDataFilePath "C:\ShieldedVM\Templates\TenantShieldingData.pdk" -Wait This single command will create a new VM named “Finance-App1” using the specified template disk and shielding data file. It automatically configures the VM’s security settings: attaches a vTPM, injects the Key Protector (from the PDK) into the VM’s security settings, and attaches the shielding helper disk to boot and apply the unattend. The -Wait flag tells PowerShell to wait until provisioning is complete before returning. Note: Ensure the VM name is unique in your Hyper-V inventory. The New-ShieldedVM cmdlet requires the GuardedFabricTools module and will fail if the host isn’t a guarded host or if guardians are not properly configured. It uses the host’s configured HGS connection to request keys when provisioning. If your shielding data’s unattend file included placeholders for unique settings (for example, a static IP address, custom computer name, etc.), you can supply those values with the -SpecializationValues parameter on New-ShieldedVM. This takes a hashtable mapping the placeholder keys to actual values. For instance: $specVals = @{ "@ComputerName@" = "Finance-App1" "@IP4Addr-1@" = "10.0.0.50/24" "@Gateway-1@" = "10.0.0.1" } New-ShieldedVM -Name "Finance-App1" -TemplateDiskPath C:\ShieldedVM\Templates\WS2025-ShieldedTemplate.vhdx ` -ShieldingDataFilePath C:\ShieldedVM\Templates\TenantShieldingData.pdk -SpecializationValues $specVals -Wait This would replace placeholders like @ComputerName@ in the unattend with “Finance-App1”, etc. Use this only if the unattend (inside the PDK) was set up with such tokens. In many cases, the shielding data might already contain all required settings, so specialization values are optional. Step 7: Monitoring Provisioning and First Boot Once the shielded VM deployment is initiated (either by WAC or PowerShell), the provisioning process begins on the guarded host. This process is automatic and involves several stages behind the scenes: The host registers a new Key Protector for the VM (containing the VM’s BitLocker key, sealed to the VM’s virtual TPM and the fabric’s HGS). It then contacts the HGS. HGS verifies the host’s health (attestation) and, if the host is authorized and healthy, releases the key protector to the host. The VM is initially started using a temporary shielding helper OS (often a small utility VHD). This helper OS boots inside the new VM and uses the unattend file from the PDK to configure the main OS disk. It injects the administrator password, domain or network settings, enables RDP/WinRM, and then finalizes BitLocker encryption of the VM’s OS volume using the VM’s vTPM. This encryption locks the OS disk so it can only be decrypted by that VM’s vTPM (which in turn is only released by HGS to trusted hosts). When specialization is complete, the VM will shut down automatically. This shutdown is a signal that provisioning is finished. The helper disk is then automatically detached, and the VM is now fully shielded. As an administrator, you should monitor this process to know when the VM is ready: In Windows Admin Center’s VM list, you may see the VM’s state change (it might show as “Off” or “Stopped” after the provisioning shutdown). You may not get a detailed status in WAC during provisioning. Refresh the view to see if the VM has turned off after a few minutes. Using PowerShell, you can query the status: run Get-ShieldedVMProvisioningStatus -VMName <Name> on the guarded host to check progress. This cmdlet shows stages or any errors during provisioning. (If the provisioning fails, the cmdlet or Hyper-V event logs will show error details. Common causes include guardian mismatches or unattend errors.) Once the VM has shut down indicating success, you can proceed to start it normally. In WAC, select the VM and click Start (or use Start-VM -Name <Name> in PowerShell). The VM will boot its now-configured OS. On first boot, it will go through final OS specialization (the standard Sysprep specialize/pass completion). Step 8: Post-Deployment Access and Management Your new VM is now running as a shielded VM. Key points for management: Limited Host Access: Because it’s shielded, the Hyper-V host admin cannot view the VM’s console or use PowerShell Direct on this VM. In WAC (or Hyper-V Manager), if you try to connect to the VM’s console, it will be blocked (you might see a black screen or an error). This is expected as shielded VMs are isolated from host interference. All management must be done through the network. Accessing the VM: Use the credentials set in the unattend/PDK to log on to the VM via Remote Desktop (RDP) or another remote method (e.g. PowerShell Remoting). Ensure the VM is connected to a network and has an IP (via DHCP or the unattend’s settings). The unattend should have enabled RDP or WinRM as configured earlier. For example, if the PDK joined the VM to a domain, you can RDP with a domain account; if not, use the local Administrator and the password from the shielding data. Verify Shielded Status: In WAC’s inventory, the VM should show as a generation 2 VM with a TPM. You can confirm it’s shielded by checking VM’s Security settings (they will show that the VM is using a Key Protector and is shielded, often the UI will have those options greyed-out/enforced). You can also use PowerShell: Get-VMSecurity -VMName <Name>. It should show Shielded: True and list the Key Protector ID, etc. Routine Management: You can manage the VM (start/stop/reset) in WAC like any other VM. Backups, replication, etc., should be done with shielded VM-compatible methods (e.g. use Hyper-V checkpoints or backup APIs as the VM’s disks are encrypted but manageable through Hyper-V). Fabric admins cannot alter the VM’s settings that would compromise its security (for instance, you cannot remove the vTPM or turn off shielding without the VM owner’s consent). Further Reading: Install HGS in a new forest | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-install-hgs-default Guarded fabric and shielded VMs | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node Capture TPM-mode information required by HGS | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware Guarded host prerequisites | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-guarded-host-prerequisites Review HGS prerequisites | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs Create a Windows shielded VM template disk | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-template Shielded VMs for tenants - Creating shielding data to define a shielded VM | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data Shielded VMs - Preparing a VM Shielding Helper VHD | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-vm-shielding-helper-vhdUsing OSConfig to manage Windows Server 2025 security baselines
OSConfig is a security configuration and compliance management tool introduced as a PowerShell module for use with Windows Server 2025. It enables you to enforce security baselines, automate compliance, and prevent configuration drift on Windows Server 2025 computers. OSConfig has the following requirements: Windows Server 2025 (OSConfig is not supported on earlier versions) PowerShell version 5.1 or higher Administrator privileges OSConfig is available as a module from the PowerShell Gallery. You install it using the following command Install-Module -Name Microsoft.OSConfig -Scope AllUsers -Repository PSGallery -Force If prompted to install or update the NuGet provider, type Y and press Enter. You can verify that the module is installed with: Get-Module -ListAvailable -Name Microsoft.OSConfig You can ensure that you have an up-to-date version of the module and the baselines by running the following command: Update-Module -Name Microsoft.OSConfig To check which OSConfig cmdlets are available, run: Get-Command -Module Microsoft.OSConfig Applying Security Baselines OSConfig includes predefined security baselines tailored for different server roles: Domain Controller, Member Server, and Workgroup Member. These baselines enforce over 300 security settings, such as TLS 1.2+, SMB 3.0+, credential protections, and more. Server Role Command Domain Controller Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/DomainController -Default Member Server Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer -Default Workgroup Member Set-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/WorkgroupMember -Default Secured Core Set-OSConfigDesiredConfiguration -Scenario SecuredCore -Default Defender Antivirus Set-OSConfigDesiredConfiguration -Scenario Defender/Antivirus -Default To view compliance from a PowerShell session, run the following command, specifying the appropriate baseline: Get-OSConfigDesiredConfiguration -Scenario SecurityBaseline/WS2025/MemberServer | ft Name, @{ Name = "Status"; Expression={$_.Compliance.Status} }, @{ Name = "Reason"; Expression={$_.Compliance.Reason} } -AutoSize -Wrap Whilst this PowerShell output gets the job done, you might find it easier to parse the report by using Windows Admin Center. You can access the security baseline compliance report by connecting to the server you’ve configured using OSConfig by selecting the Security Baseline tab of the Security blade. Another feature of OSConfig is drift control. It helps ensure that the system starts and remains in a known good security state. When you turn it on, OSConfig automatically corrects any system changes that deviate from the desired state. OSConfig makes the correction through a refresh task. This task runs every 4 hours by default which you can verify with the Get-OSConfigDriftControl cmdlet. You can reset how often drift control runs using the Set-OSConfigDriftControl cmdlet. For example, to set it to 45 minutes run the command: Set-OSConfigDriftControl -RefreshPeriod 45 Rather than just using the default included baselines, you can also customize baselines to suit your organizational needs. That’s more detail that I want to cover here, but if you want to know more, check out the information available in the GitHub repo associated with OSConfig. Find out more about OSConfig at the following links: https://learn.microsoft.com/en-us/windows-server/security/osconfig/osconfig-overview https://learn.microsoft.com/en-us/windows-server/security/osconfig/osconfig-how-to-configure-security-baselinesStep-by-Step Guide: How to setup conditional access reauthentication policy for PIM?
Once a user is authenticated through Entra ID, they remain signed in as long as the session is valid—even if they close and reopen the browser. However, in scenarios involving sensitive tasks or high-risk operations, it’s beneficial to require reauthentication. Forcing a fresh sign-in adds an extra layer of security by reducing the risk of session hijacking and token replay attacks. It also prevents attackers from maintaining persistence across services and devices, limiting their ability to move laterally within the environment. A common example is when a user elevates their permissions to a higher-privileged role using Entra ID Privileged Identity Management (PIM). By leveraging Conditional Access reauthentication policies, we can require users to reauthenticate before gaining privileged access—adding an important layer of security. In this blog post, I’ll Walk through how to configure this policy step by step. High-Level Configuration Tasks The following steps outline the configuration process for enforcing reauthentication using Conditional Access and Privileged Identity Management (PIM): Create an Authentication Context in Conditional Access. Update Entra ID Privileged Identity Management (PIM) to associate the relevant role with the Authentication Context. Create a Conditional Access policy that enforces reauthentication based on the defined context. Step 1: Create an Authentication Context Authentication Context allows you to define a label that represents a specific authentication requirement (e.g., MFA, compliant device, reauthentication). This label can be referenced in PIM configurations and Conditional Access policies. To create an Authentication Context: Sign in to the Microsoft Entra admin center. Navigate to Protection > Conditional Access > Authentication context. Click + New authentication context. 4.In the creation pane, provide a Name and Description for the context. 5. Click Save to create the context. Step 2: Update PIM Configuration In this setup, the Security Administrator role is already managed via Privileged Identity Management (PIM). For more information on configuring PIM roles, refer to the official documentation: 🔗 Configure Microsoft Entra PIM The next step is to associate the previously created Authentication Context with the PIM role to enforce conditional access policies during role activation. To update PIM with Authentication Context: Sign in to the Microsoft Entra admin center. Navigate to Identity Governance > Privileged Identity Management, and select the role you want to modify (in this example, Security Administrator). Click on Settings. 4. In the Role settings pane, select Edit. 5. Under the On activation, require section, choose Microsoft Entra Conditional Access authentication context. 6. From the dropdown menu, select the Authentication Context you created earlier. 7. Click Update to save and apply the changes. Step 3: Create a Conditional Access Policy to Enforce Reauthentication The final step is to create a Conditional Access policy that forces reauthentication whenever a user activates a privileged role protected by the authentication context. To create the Conditional Access policy: Sign in to the Microsoft Entra admin center. Navigate to Protection > Conditional Access. Click + Create new policy. In the policy creation pane: o Provide a meaningful name for the policy. o Under Users, select the users or groups this policy should apply to. o Under Target resources, choose Authentication context, and then select the context you created earlier. Go to the Session section and configure Sign-in frequency to Every time. This setting ensures that users are prompted for reauthentication each time the context is invoked. Enable the policy by toggling On, then click Create to finalize it. Testing the Configuration With all the required configurations in place, the next step is to test the Conditional Access reauthentication policy in action. I signed in to the Azure portal using a user account that is eligible for the Security Administrator role. Navigating to PIM > My roles > Eligible assignments, I located the Security Administrator role and clicked Activate. At this stage, a message appears on the activation page: "A Conditional Access policy is enabled and may require additional verification. Click to continue." No further action can be taken on this screen until this prompt is addressed, so I clicked the link as instructed. As expected, I was prompted to reauthenticate, in line with the policy we configured. After successfully reauthenticating, I was redirected back to the role activation page, where I could now enter the required justification and additional details. Clicking Activate completed the role activation process successfully. ✅ This confirms that the Conditional Access policy enforcing reauthentication is working as intended for PIM role activation. This concludes the blog post. I hope it has provided you with a clear understanding of how to configure and enforce Conditional Access reauthentication for Privileged Identity Management roles using Authentication Context.Understanding the Windows Server Event Log
What is the Event Log? Each event log records events that happen on the Windows Server computer. Examining the events in these logs can help you trace activity, respond to events, and keep your systems secure. Configuring these logs properly can help you manage the logs more efficiently and use the information that they provide more effectively. Windows Server saves event log files as XML files that can be reported on and managed as part of a collective reporting schema. There are several additional log providers and categories that you can monitor. Event Viewer is the tool most people use to interact with their event logs. Event viewer tracks information in a number of logs termed the “Windows Logs”, which include the application, security, setup, system, and forwarded event logs. Application. The application log records events logged by applications and services running on the system. Events in this Windows log are classified as error, warning, or information, depending on the severity of the event. An error is a significant problem, such as loss of data. A warning is an event that is not necessarily significant but might indicate a possible future problem. An information event describes the successful operation of a program, driver, or service. Security. This Windows log contains security-related events, which are called "audit events," and are described as successful or failed, depending on the event, such as whether a user's attempt to log on to Windows was successful. Setup. This Windows log records events related to installing programs and services on the computer. Computers that are configured as domain controllers have additional logs displayed in this category. System. This Windows log records system events that are sent by Windows and Windows system services, and are classified as error, warning, or information. Forwarded Events. This Windows log records events are forwarded to this log by other computers. Event log forwarding is a built in technology that allows you to centralize your event logs on a single computer. It’s pretty basic compared to dedicated telemetry tools like System Center Operations manager or your favorite third party alternative. Applications and Services Logs. Each application or service installed on the computer probably has an individual log. These logs store events from a single application or service rather than events that might have systemwide impact. This category of logs includes four subtypes for which the application or service can provide events: Admin, Operational, Analytic, and Debug logs. Admin. Events that are found in the Admin channels indicate a problem and a well-defined solution that an administrator can act on. An example of an admin event is an event that occurs when an application fails to connect to a printer. These events are either well documented or have a message associated with them that gives the reader direct instructions of what must be done to rectify the problem. Operational. Events that are found in the Operational channels are used for analyzing and diagnosing a problem or occurrence. They can be used to trigger tools or tasks based on the problem or occurrence. An example of an operational event is an event that occurs when a printer is added or removed from a system. Analytic. Events that are found in the Analytic channels aid in performance evaluations and troubleshooting. These events are published in high volume, so they should only be enabled and logged for limited amounts of time as part of a diagnostic process. They describe program operation and may indicate problems that cannot be handled by user intervention. Debug. Events that are found in the Debug channels can be used by developers when troubleshooting issues with their programs. You should Note that Both Analytic and Debug logs are hidden and disabled by default. To use these logs: Start Event Viewer Click the View menu, and then select Show Analytic and Debug Logs to make these logs visible. Then select the Analytic or Debug log that you want to enable and on the Action menu, click Properties. On the properties dialog box, select Enable logging and click OK. Each of these logs has attributes, such as maximum log size, access rights for each log, and retention settings and methods, each of which can be defined in the appropriate Event Log section in Group Policy. Event Log Settings You can configure the event log settings in the following locations within the Group Policy Management Console: Computer Configuration\Administrative Templates\Windows Components\Event Log Service\ Subordinate folders exist for the following event logs by default: Application Security Setup System The same set of policy settings is available for each event log. The Setup folder has an additional policy setting that allows logging to be turned on. The following sections describe the options and issues for configuring event log settings for better system management and security. Maximum log size (KB) The maximum log size policy setting specifies the maximum sizes of the log files. An individual setting may be specified for each of the Application, Security, Setup, and System event log channels. The user interfaces of both the Local Group Policy Editor and the Microsoft Management Console Event Viewer snap-in allow you to enter values as large as 2 terabytes. If this setting is not configured, event logs have a default maximum size of 20 megabytes. Although there is no simple equation to determine the best log size for a particular server, you can calculate a reasonable size by multiplying the average event size by the average number of events per month, assuming that you back your logs up on a monthly schedule. The average event takes up about 500 bytes within each log, and the log file sizes must be a multiple of 64 KB. If you can estimate the average number of events that are generated each day for each type of log in your organization, you can determine a good size for each type of log file. For example, if your file server generates 5,000 events per day in its Security log and you want to ensure that you have at least four weeks of data available at all times, you should configure the size of that log to about 70 MB (calculated as 500 bytes * 5000 events per day * 28 days = 70,000,000 bytes). Then check the servers occasionally over the following four weeks to verify that your calculations are correct and that the logs retain enough events for your needs. Event log size and log wrapping should be defined to match the business and security requirements that you determined when you designed your organization's security plan. You can set a maximum log size value of between 1024 and 2,147,483,647 kilobytes in multiples of 64 kilobytes. That's an approximate maximum log file size of 2 TB if you're feeling relaxed about the amount of storage you have. Microsoft’s current recommendation for how to configure this setting is 4GB. The approximate maximum events per second that can be recorded is over 300,000. From a practical perspective if you're thinking about log files that big, you should be using a tool like Azure Monitor or Systems Center Operations Manager to query and analyze your event data. If you were mucking around with log files that size in event viewer, you’re probably going to run into some issues. Log File Location The Control the location of the log file policy allows you to configure where event logs are written. By default event log files are located in the %WinDir%\System32\Winevt\Logs folder. You can move these logs manually or by using policy. To move the event log files to a specified folder, follow these steps: Open Event Viewer. Right-click the log that you want to configure, and then select Properties. In the Log path box, type the desired location for the event log, and then select OK. This change takes effect immediately. However, the events that were already logged are still saved in the previous location. If you relocate the event log files to an unavailable disk, the events will be lost. If you significantly increase the number of objects to audit in your organization and if you enabled the Audit: Shut down system immediately if unable to log security audits setting, there is a risk that the Security log will reach its capacity and force the computer to shut down. If such a shutdown occurs, the computer is unusable until an administrator clears the Security log. To prevent such a shutdown, you can disable the Audit: Shut down system immediately if unable to log security audits setting. Log Access Policies The following default log access rights are enforced: Log Access Policy Application and Setup logs All authenticated users can write/read/clear the log. System log Only system software and administrators can write or clear the log. Any authenticated user can read events from it. Security log Only system software and administrators can read or clear the log. The Log Access Policy setting determines which user accounts have access to log files and what usage rights are granted. Individual setting may be specified for each of the Application, Security, Setup, and System event log channels. This policy requires you use Security Descriptor Definition Language (SDDL) to identify security principals rather than just selecting a user or group. This makes it a lot more cumbersome to use than it should be. Enabling this policy allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. Control Event Log Behavior The Control Event Log behavior when the log file reaches its maximum size policy setting controls Event Log behavior when the log file reaches its maximum size. If you enable this policy setting and the "Retain old events" policy setting is enabled, the Event Log file is automatically closed and renamed when it is full. A new file is then started. When this policy setting is disabled and a log file reaches its maximum size, new events overwrite old events in the same log file. If this policy setting is enabled and a log file reaches its maximum size and the Retain Old Events policy is not enabled, new events are not written to the log and are lost. Backup log automatically when full The "backup log automatically when full" policy setting controls Event Log behavior when the log file reaches its maximum size and takes effect only if the Retain old events policy setting is enabled. If you enable this policy setting and the Retain old events policy setting is enabled, the Event Log file is automatically closed and renamed when it is full. A new file is then started. If you disable this policy setting and the Retain old events policy setting is enabled, new events are discarded and the old events are retained. When this policy setting is not configured and the Retain old events policy setting is enabled, new events are discarded and the old events are retained. You should archive logs to an external location at scheduled intervals and you ensure that the maximum log size is large enough to accommodate the interval. Alternatively use a monitoring solution that ingests and archives logs in an external location. Summary The event logs record events that happen on the computer. Examining the events in these logs can help you trace activity, respond to events, and keep your systems secure. Configuring these logs properly can help you manage the logs more efficiently and use the information that they provide more effectively. Ensure that you configure log file policies so that log file size is appropriate and that important event log data is not overwritten or goes unlogged.Step-by-Step Guide : How to enable QR code authentication for Microsoft Entra ID (Preview) ?
Microsoft Entra ID supports a long list of Authentication methods. Windows Hello for Business Microsoft Authenticator app Authenticator Lite Passkey (FIDO2) Certificate-based authentication Hardware OATH tokens (preview) Software OATH tokens External authentication methods (preview) Temporary Access Pass (TAP) Short Message Service (SMS) sign-in and verification Voice call verification Password This enables organizations to select the most secure and productive authentication methods for their business. While the most secure method may not always be the most productive, and vice versa, having a variety of supported authentication methods helps to strike a balance between these two aspects. Microsoft Entra ID now supports QR authentication, a method specifically designed for frontline workers who use shared devices. This provides a convenient and secure login experience for these workers. How it works ? 1) An account with Authentication Policy Administrator permission or higher can enable QR code as an authentication method. 2) Once the method is enabled, a QR code and temporary PIN can be generated for the user. 3) The QR code should be made available to the user. It can be downloaded, printed, or added to a badge. 4) The QR code is unique but cannot be used without the PIN. 5) The temporary PIN must be reset when the user authenticates for the first time. 6) Once the QR code and PIN are set up, the user can use them for subsequent logins. Things to remember ! 1) QR authentication is designed for frontline workers and should not be widely used. Phishing-resistant authentication is recommended wherever possible. 2) Do not enable this authentication method for all users; only enable it for required users. 3) QR authentication is currently only supported on mobile devices running iOS/iPadOS or Android. 4) QR authentication does not allow self-service PIN reset for users. In this blog post I am going to demonstrate how to configure QR authentication for the Microsoft Entra ID users. Let’s start with enabling authentication method. Log in to the Entra admin portal at https://entra.microsoft.com/as an Authentication Policy Administrator or higher. Navigate to Protection | Authentication Methods. Under Policies, click on QR code (Preview). In the QR code (Preview) settings page, click on Enable to turn on the authentication method. Then, select the relevant user group as the target. Click on the Configure tab. Here, you can adjust the PIN length and the lifetime of the QR code. The default is 365 days, but it can be extended up to 395 days. Once changes are made, click on Save to apply them. This enables the QR code as an authentication method for the tenant. Next, let's see how to generate a QR code for a user. Generate QR code authentication for a user To generate QR code for user, Navigate to Users | All users. Select the user from the target group configured in the previous section. Click on Authentication methods. Click on + Add authentication method. From the dropdown, select QR code (Preview). In the settings page, define the expiration date and activation time. Click on Generate PIN to create a temporary PIN. Note down the PIN and click on Add. This will generate the QR code. Download it for use with authentication. Now that we have generated a QR code for a user, let's proceed with some testing. Testing For testing, I used an iOS device to log in to the office portal. On the login page, I typed the username and then clicked on Sign-in options. In the Sign-in options page, I selected Sign in to an organization. On the next page, I chose Sign in with QR code. I clicked on Allow to grant access to the camera. After that, I scanned the QR code downloaded in the previous step. Once the QR code was successfully detected, I entered the temporary PIN that was generated and clicked on Sign in. On the next page, I was prompted to define a new PIN since this was the first login. After defining the PIN, I clicked on Sign in. As expected, I was able to log in successfully. This marks the end of the blog post, and I believe you now have a better understanding of how to enable and use QR code for authentication.Step-by-Step Guide : How to use Temporary Access Pass (TAP) with internal guest users
Passwords are fundamentally weak and vulnerable to being compromised. Even enhancing a password only delays an attack; it does not render it unbreakable. Multi-Factor Authentication (MFA) offers more security but still depends on passwords. This is why passwordless authentication is a more secure and convenient alternative. Source : https://learn.microsoft.com/entra/identity/authentication/media/concept-authentication-passwordless/passwordless-convenience-security.png Microsoft Entra ID supports password less authentication natively. It supports six different password less authentication options. Windows Hello for Business Platform Credential for macOS Platform single sign-on (PSSO) for macOS with smart card authentication Microsoft Authenticator Passkeys (FIDO2) Certificate-based authentication Based on the organisation's requirements, they can select the most convenient options. However, the initial setup requires a method to authenticate the user before onboarding other passwordless authentication methods. For this, we can use: 1) Existing Microsoft MFA methods 2) Temporary Access pass (TAP) A Temporary Access Pass (TAP) is a time-limited passcode that can be configured for single use or multiple sign-ins. Organisations not only have internal users to manage but also guest users. Until now, the TAP method was only available for internal users, and guest users were not permitted to use this method. This makes sense because if guest users also need to use passwordless authentication, it should occur in their home tenant. But now Entra ID supports TAP for “Internal Guest” users. Internal Guests Guest users are typically categorised as user accounts that exist in a remote tenant. However, some organisations prefer to use user accounts in their own directory but with guest-level access. This is typically for contractors, suppliers, vendors, etc. These are known as 'internal guest accounts'. Such accounts were also used for guest users in the past when B2B collaboration wasn't in place. In this demo I am going to demonstrate how to use TAP with internal Guest user. Enable TAP as Authentication method Before we configure TAP for user we need to make sure TAP is enabled as authentication method. To do that, Log in to the Entra portal as an Authentication Policy Administrator or higher. Navigate to Protection > Authentication methods > Policies. Click on Temporary Access Pass Ensure it is enabled and the target is defined. If not, make the necessary changes and click Save. Create TAP for Internal Guest User I already have an internal guest user for this task. As you can see below, the user type is Guest, but the user is still part of the same tenant. To create TAP, Click on the selected user from the Entra ID users list to go to user properties. Next, Click on Authentication methods Then Click on + Add authentication method From the drop-down, select the Temporary Access Pass method. In the settings window, make the adjustments based on the requirements and then click on Add. It will create TAP as expected. Testing To verify the configuration, I am attempting to log in as the test user. This is the user's very first login. As expected, the initial login prompts for the TAP. After a successful login, it allows me to configure the account with passwordless authentication. As we can see, the TAP for the internal guest feature is working as expected.
