rss.livelink.threads-in-node

Purpose For Your PKI (Practical PKI Part 3)

RonArestia — Mon, 04 May 2026 04:00:00 GMT

My name is Ron Arestia, and I am a Security Researcher with Microsoft’s Detection and Response Team (DART). We respond to customer cybersecurity incidents to assist with containment and recovery from threat actors. In this brief blog post, we will discuss the “why” behind your PKI. This is part 3 of a series on practical PKI implementation based on my experience with customer interactions working as a Microsoft engineer.

Feel free to catch up on previous blog posts or jump right into this one

Secure Configuration and Hardening of Active Directory Certificate Services

Implementing and Managing an ADCS Offline Root Certificate Authority (Practical PKI Part 1)

CRL & AIA Publishing Guidance (Practical PKI Part 2)

In Part 3 of our series, understanding why you are implementing and managing PKI is critical to understanding the level of effort you should endeavor to start using one or keep one going. This brief non-technical discussion is meant as a primer to determine if what you are about to implement is truly going to benefit your organization as a whole.

Determine Your Technical Outcomes

This subject is the target of much debate and disagreement across my peer groups. On the one side, you have engineers who argue for or against the very provisioning of a PKI while on the other side, you have engineers who argue that regardless of purpose, administration is more important. Far be it for me to be a fence-sitter, so I stand firmly in the former group arguing that if you do not need it, you should not bother standing it up in the first place.

A few years ago, I was working with a customer with a substantial PKI presence: three issuing CAs, fully redundant HTTP CRL publishing, CEP/CES, and cross-forest publishing. When we were assessing their environment, I noticed immediately that they had a scant few templates published across those three issuers, but they had over 100,000 issued, active certificates. I dug deeper and noticed that every one of their templates except two were configured with autoenrollment. Every user and every computer in their organization was getting a certificate that was published to Active Directory. They were issuing server authentication certificates with enrollee-supplied Subject Alternative Names (SANs) without manager approval. And they were even issuing code signing certificates without manager approval albeit to a constrained group.

After lengthy discussions with them about their reasons for managing a PKI, I discovered a few very telling things:

Despite aspirations to use 802.1x for user and computer authentication, the infrastructure was never implemented and remained in a state of development for the last few years.
Despite a project to setup smart card authentication, they never moved past a pilot group of developers and administrators who were not bothering to leverage this powerful method of authentication across most of their enterprise anyway.
Approximately 90% of their certificates issued for web endpoints were either development endpoints that never made it to production or misconfigured certificates that had to be reissued to correct spelling errors or to add or remove nodes from SANs that were not in the original configuration.
More than 1,000 code signing certificates were issued, but no official code was signed by their recollection.

By the end of the engagement, they realized how much administrative overhead was going into maintaining a massive solution with little actual value for the organization. They had short root CA CRL lifetimes requiring quarterly “signing parties,” and despite a very astute team of engineers maintaining the PKI, they had built in “automation” paths that left their environment vulnerable to attack if a threat actor ever found their way in. All told, we determined that less than 2% of the total number of issued certificates (approximately 2,500) were actively used for a regular production task.

Even after discussing options to downsize, streamline, and harden their PKI infrastructure, we eventually discussed options to offload much of their certificate needs to third-party solutions. Why would I convince a customer to rid themselves of an in-house PKI?

Are You Experienced?

I believe the most important fundamental question to ask as an enterprise is if you have the staff to manage and maintain a PKI, and if so, to what extent? I would argue that having at least two engineers dedicated to this task is critical for personnel fault tolerance. If one engineer goes on vacation or suddenly resigns, you have someone who can continue to operate the environment to the same level of fidelity expected of it. This guidance scales upwards the larger your PKI grows. If you are a multinational enterprise with issuing CAs spread around the globe, you need, at the least, regional expertise to navigate administration and maintenance tasks. Ideally, you would have a resource local to each environment to ensure someone can put hands on the systems without relying on global networking.

The second fundamental question you should ask: what is the primary purpose of my public key infrastructure? Are you using it to manage an 802.1x authentication scheme across your enterprise? Are you managing smart cards or certificate-based authentication for your organization? Are you looking to issue a large number of server authentication certificates to support internal web endpoints or development efforts? Or do you believe that by maintaining your own PKI you are maintaining some level of sovereignty over your cryptographic operations that you do not want to offload to a third-party or a cloud provider?

All of these are perfectly valid reasons to maintain your own PKI, but each comes with challenges and interoperability requirements that should be documented and thoroughly understood. In 802.1x configurations, you should ensure all of your subordinate infrastructure is prepared and up to the task of handling authentication traffic and overall maintenance. One network appliance outage overnight could mean an entire office is unable to work the next morning. Smartcard and certificate-based authentication require a robust infrastructure and a team of individuals dedicated to the task of identity attribution for assignment and provisioning of those certificates. Web endpoint certificate management can quickly grow into a full-time role for an engineer in an environment with rapid iteration, and there is a delicate balance to be struck between reasonable validity periods and the possibility of regular revocation due to changes that can balloon a CRL. Finally, the decision to maintain sovereignty over certificates is often driven by cost. A true cost-benefit analysis can aid in reinforcing or diminishing from the need to stand up a dedicated PKI, and the reality is that having publicly-trusted certificates is often a much simpler solution than relying on visibility to internal publishing endpoints that require a number of security solutions.

Decisions, Decisions

The decision to stand up a dedicated, in-house PKI is not one that should be taken lightly. Sit down with your management and leadership team to outline the high-level outcomes expected of the solution and be the sober voice in the room to explain both the benefits and disadvantages of the proposed solution. If the determination to proceed is not grounded in realistic capabilities of the enterprise, do not be afraid to pull the security card, at a minimum. The security of your PKI is paramount. Without it, you are paying money to power infrastructure that is, at best, churning out unnecessary certificates, and at worst, putting your entire enterprise at risk of a cybersecurity incident.

How do we secure and maintain your PKI once the decision is made to deploy one? In Part 4, we will get back into the technical discussions about your PKI security and how to maximize your security without compromising functionality.

Hardening OpenClaw on AKS: Mitigating Container Escapes with Kata microVM Isolation

jianshn — Thu, 30 Apr 2026 01:57:02 GMT

What is OpenClaw, and what security challenges does it pose with container escapes?

OpenClaw is an open-source autonomous AI agent designed for power users and developers to automate tasks, such as managing emails, files, and scheduling via chat apps like WhatsApp or Telegram.

While OpenClaw functions as a powerful autonomous assistant, its runtime model creates a massive security paradox: to be truly useful, the agent requires broad permissions to your filesystem and APIs, yet this "God Mode" access often lacks the rigorous containerized isolation typical of enterprise workloads. Because many users run the framework natively rather than within a hardened sandbox, the primary security challenge is that a single malicious "Skill" or an indirect prompt injection can escalate into full system compromise. This structural vulnerability, exemplified by high-profile exploits like CVE-2026-25253, transforms the agent from a helpful tool into a high-risk entry point for lateral movement and data exfiltration within a private network.

Why container escapes matter in OpenClaw-style deployments: because containers share the host kernel, a successful container escape turns a single compromised container into a host compromise (or at least a compromise of other co-located workloads). This is especially important when OpenClaw runs code from many tenants, many teams, or varying trust levels on the same worker nodes. That soft isolation is often permeable due to the following structural and configuration-based weaknesses:

Shared-kernel attack surface: the container boundary is not a hypervisor boundary. Kernel vulnerabilities (e.g., privilege escalation bugs) can allow a process in a container to gain host-level privileges.
Excessive privileges / misconfiguration: running with --privileged, broad Linux capabilities, hostPath mounts, access to the Docker socket, or device passthrough (e.g., /dev/kvm, /dev/fuse) can provide direct paths to host control.
Filesystem and namespace boundary breaks: mount namespace confusion, writable host mounts, or mistakes in chroot/pivot_root handling can expose host files and credentials.
Supply-chain and image risk: a malicious image or dependency can execute within the container and then attempt escalation/escape.
Blast radius: once the host is compromised, attackers can access node-level secrets (service account tokens, registry creds), tamper with the runtime, sniff traffic, or pivot to other containers and the broader cluster.

In short, OpenClaw’s security challenge is not that containers are inherently insecure, but that the isolation boundary is thinner than a VM boundary. When the threat model includes adversarial code execution, a “container-only” isolation strategy often requires additional hardening or a stronger sandbox.

What are MicroVMs and Kata Containers, and how do they help mitigate OpenClaw container-escape risks?

MicroVMs are lightweight virtual machines optimized for running short-lived or container-like workloads with much lower overhead than traditional VMs. They use hardware virtualization (via a hypervisor such as KVM) but keep the device model and boot path minimal, reducing startup time and the overall attack surface compared to a full general-purpose VM.

Kata Containers is an “OCI-compatible containers in a VM” approach: it runs each container (or pod sandbox) inside a dedicated microVM by default (implementation varies by runtime/config). To the orchestration layer (e.g., Kubernetes), it still looks like a container runtime, but isolation is provided by a hypervisor boundary rather than only namespaces/cgroups.

Stronger isolation boundary: a container escape that relies on Linux kernel exploitation is far less likely to directly compromise the host, because the workload’s “host” kernel is typically the guest kernel inside the microVM.
Reduced blast radius: compromise is contained to the microVM/pod sandbox; lateral movement to other workloads on the same node becomes significantly harder.
Smaller and more controllable attack surface: minimal device models, tighter default privileges, and fewer host mounts/devices exposed to the workload.
Defense-in-depth with container controls: you still can (and should) apply seccomp, capabilities dropping, read-only root filesystems, and LSMs inside the guest, but the hypervisor boundary becomes an additional layer.
Better fit for hostile multi-tenant workloads: when OpenClaw executes third-party jobs/plugins, Kata-style sandboxing aligns better with an adversarial threat model.

Solution overview

Figure 1 illustrates a Kubernetes-based sandboxing architecture for running OpenClaw workloads with stronger isolation. The design keeps the developer experience and packaging model of containers (OCI images, Kubernetes scheduling) while ensuring that untrusted agent code executes inside a microVM boundary using Kata Containers. This reduces the likelihood that a container escape can compromise the underlying node or other co-located workloads.

Key components: (1) Application gateway for HTTPS traffic to the backend, (2) Kubernetes as the orchestration, scheduling and policy enforcement plane, (3) a container runtime (e.g., containerd) configured with a Kata Containers runtime class, (4) KVM-backed microVMs that provide the isolation boundary for each untrusted workload and (5) Azure files for persistent storage which allows scaling of OpenClaw.

Figure 1: Solution architecture diagram

End-to-end flow:

Traffic Entry via Application Gateway: Incoming user requests (e.g., from WhatsApp or Discord) first hit the Azure Application Gateway.
Orchestration in AKS: The traffic is routed into an Azure Kubernetes Service (AKS) cluster, which manages the lifecycle of the OpenClaw agent and its associated "Skills."
Hardened Execution via Kata Containers: Instead of running in standard shared-kernel containers, the OpenClaw agent runs inside Kata Containers. This provides a dedicated lightweight VM for the agent, creating a hardware-level isolation boundary that prevents "container escapes" from compromising the host.
Stateful Storage in Azure Files: The agent interacts with Azure Files to read and write persistent data, such as conversation history, configuration files, and downloaded assets, ensuring data remains available even if the container is restarted.

Security posture: by shifting isolation from “shared-kernel containers” to “containers inside microVMs,” the architecture limits the blast radius of kernel-level exploits and common escape paths. Even if an attacker achieves code execution within an OpenClaw container, they must additionally break the microVM/hypervisor boundary to affect the node or neighboring workloads, providing a strong defense-in-depth improvement over standard container alone.

Implement the solution

This section describes how to deploy the solution architecture.

In this post, you’ll perform the following tasks:

Create a Kata VM-isolated AKS node pool
Mount a NFS persistent storage
Create the application ConfigMap
Deploy the OpenClaw gateway
Expose the gateway internally
Set up TLS termination
Route external traffic through the Azure application gateway for containers.

Ensure that you have the following prerequisites deployed before moving to the next section:

An AKS cluster provisioned in Azure
An Azure NFS File Share with private link enabled.
An Application gateway for containers managed by ALB controller
Kubectl configured and pointing to the cluster
Az CLI authenticated with the correct subscription

Initialise environment variables

In your Linux terminal, export these variables with your own values. They will be used in later commands.

export cluster_name=<CLUSTER_NAME> export resource_group=<RESOURCE_GROUP>

Create the AKS Node Pool with Kata VM Isolation

The OpenClaw gateway pods require Kata VM isolation (runtimeClassName: kata-vm-isolation). You must create a dedicated AKS node pool that supports this runtime before deploying any workloads.

Use the Azure CLI to add a node pool with the Kata VM isolation workload runtime to your existing AKS cluster:

az aks nodepool add \ --resource-group $resource_group \ --cluster-name $cluster_name \ --name katanp \ --node-count 2 \ --node-vm-size Standard_D4s_v3 \ --os-sku AzureLinux \ --workload-runtime KataMshvVmIsolation \ --labels agentpool=katanp

**Important:** The `--workload-runtime KataMshvVmIsolation` flag enables the `kata-vm-isolation` runtime class on the node pool. The VM size must support nested virtualization (D-series v3/v5, E-series v3/v5, etc.).

Create NFS Persistent Volume

The deployment uses an Azure Files NFS share for persistent workspace storage. The PersistentVolume must exist before the PVC can bind to it. Replace volumeHandle and volumeAttributes with your own Azure Files values.

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolume metadata: name: openclaw-nfs-pv spec: capacity: storage: 100Gi accessModes: - ReadWriteMany persistentVolumeReclaimPolicy: Retain mountOptions: - sec=sys - noresvport - actimeo=30 csi: driver: file.csi.azure.com volumeHandle: <resource-group>#<storage-account>#<share-name> volumeAttributes: resourceGroup: <resource-group> shareName: <share-name> protocol: nfs server: <storage-account>.privatelink.file.core.windows.net EOF

Verify that the persistent volume is created.

kubectl get pv openclaw-nfs-pv

Figure 2: Persistent volume

Create the NFS PersistentVolumeClaim

The PVC binds to the PV created. The deployment references this PVC by name (`pvc-openclaw-nfs`).

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: PersistentVolumeClaim metadata: # The name of the PVC name: pvc-openclaw-nfs spec: accessModes: - ReadWriteMany resources: requests: # The real storage capacity in the claim storage: 50Gi # This field must be the same as the storage class name in StorageClass storageClassName: "" volumeName: openclaw-nfs-pv EOF

Verify that the persistent volume claim is created successfully. The status should show bound.

Figure 3: Persistent Volume Claim

Create the ConfigMap

The ConfigMap provides the openclaw.json configuration file to the gateway pods. It configures allowed CORS origins for the control UI and the gateway token. Replace the allowed origins with your own ALB frontend URL. The ConfigMap also stores the gateway auth token, so DO NOT hardcode your token here. Always keep it as a variable rather than storing it in plain text so that, if attackers gain access to this file, they cannot see the OpenClaw gateway auth token.

cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ConfigMap metadata: name: openclaw-config data: openclaw.json: | { "gateway": { "auth": { "token": "${AUTH_TOKEN}" }, "controlUi": { "allowedOrigins": [ "https://<YOUR ALB FRONTEND URL>.alb.azure.com" ] } } } EOF

Create the Auth Token Secret

The OpenClaw gateway requires an authentication token to secure access. The deployment references a Kubernetes Secret named openclaw-auth-token and injects it into the container as the AUTH_TOKEN environment variable via secretKeyRef.

Generate a random token (or use an existing one) and create the kubernetes secret.

# Generate a random 32-byte hex token AUTH_TOKEN=$(openssl rand -hex 32) echo "$AUTH_TOKEN" # save this — you'll need it to authenticate with the gateway kubectl create secret generic openclaw-auth-token \ --from-literal=token="$AUTH_TOKEN"

If the secret does not exist when the deployment is applied, pods will fail with `CreateContainerConfigError`.

Deploy the OpenClaw Gateway

This is the main application deployment. It depends on all previous steps:

- Kata node pool (pods require runtimeClassName: kata-vm-isolation and nodeSelector: agentpool=katanp)

- PVC (pvc-openclaw-nfs for persistent workspace data)

- ConfigMap (openclaw-config for openclaw.json)

Key details:

- Runs 2 replicas with a rolling update strategy

- Uses an init container to copy the config file to a writable volume

- Exposes port 18789

- Includes liveness and readiness probes on /health

- Resource requests: 500m CPU, 512Mi memory

- Resource limits: 2 CPU, 2Gi memory

cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: openclaw-gateway spec: replicas: 2 selector: matchLabels: app: openclaw-gateway strategy: type: RollingUpdate rollingUpdate: maxUnavailable: 1 maxSurge: 1 template: metadata: labels: app: openclaw-gateway spec: runtimeClassName: kata-vm-isolation nodeSelector: agentpool: katanp securityContext: fsGroup: 1000 initContainers: - name: copy-openclaw-config image: alpine/openclaw:latest env: - name: HOME value: /writable command: - sh - -c - | cp /config/openclaw.json /writable/openclaw.json \ && chown 1000:1000 /writable/openclaw.json \ && echo "--- Config file contents ---" \ && cat /writable/openclaw.json volumeMounts: - name: openclaw-config-volume mountPath: /config - name: openclaw-writable mountPath: /writable containers: - name: gateway image: alpine/openclaw:latest ports: - containerPort: 18789 env: - name: NODE_OPTIONS value: "--max-old-space-size=4096" - name: AUTH_TOKEN valueFrom: secretKeyRef: name: openclaw-auth-token key: token # Start gateway the way the tutorial indicates command: ["openclaw", "gateway"] args: ["run", "--allow-unconfigured", "--bind", "lan"] volumeMounts: - name: openclaw-writable mountPath: /home/node/.openclaw - name: openclaw-data mountPath: /home/node/workspace subPath: workspace resources: requests: cpu: "500m" memory: "2Gi" limits: cpu: "1000m" memory: "4Gi" livenessProbe: httpGet: path: /health port: 18789 initialDelaySeconds: 60 periodSeconds: 15 failureThreshold: 3 readinessProbe: httpGet: path: /health port: 18789 initialDelaySeconds: 10 periodSeconds: 5 volumes: - name: openclaw-data persistentVolumeClaim: claimName: pvc-openclaw-nfs - name: openclaw-config-volume configMap: name: openclaw-config items: - key: openclaw.json path: openclaw.json - name: openclaw-writable emptyDir: {} --- apiVersion: v1 kind: Service metadata: name: openclaw-gateway-service spec: type: ClusterIP selector: app: openclaw-gateway ports: - protocol: TCP port: 18789 targetPort: 18789 EOF

Verify that the deployment succeeds. Wait until all pods show `Running` and `READY 2/2`.

kubectl get deployment openclaw-gateway kubectl get pods -l app=openclaw-gateway

Figure 4: OpenClaw deployment

Create the TLS secret (for HTTPS)

The Application Gateway for Containers references a TLS secret (gateway-tls-secret) for HTTPS termination. This blog post uses a self-signed certificate; in a production environment, use a certificate signed by a certificate authority. Replace `<path-to-tls-cert>` and `<path-to-tls-key>` with paths to your TLS certificate and private key files.

kubectl create secret tls gateway-tls-secret \ --cert=<path-to-tls-cert> \ --key=<path-to-tls-key>

Create the Gateway

The Gateway resource defines the HTTPS listener on the Azure Application Load Balancer (ALB). Update the `alb.network.azure.com/application-gateway-id` annotation to match your ALB traffic controller resource ID. You will also need to reference the gateway-tls-secret to enable HTTPS.

cat <<EOF | kubectl apply -f - apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: https annotations: alb.network.azure.com/application-gateway-id: /subscriptions/<subscription id>/resourceGroups/mc_openclaw_openclaw-cluster_centralus/providers/Microsoft.ServiceNetworking/trafficControllers/<alb id> alb.networking.azure.io/alb-namespace: default alb.networking.azure.io/alb-name: alb-openclaw spec: gatewayClassName: azure-alb-external listeners: - name: https protocol: HTTPS port: 443 allowedRoutes: namespaces: from: All tls: mode: Terminate certificateRefs: - kind: Secret group: "" name: gateway-tls-secret EOF

kubectl get gateway https

Wait until the Gateway shows a `Programmed=True` condition.

Create the HTTPRoute

The HTTPRoute connects the Gateway to the backend Service. It routes all traffic (`/` prefix) from the HTTPS Gateway to `openclaw-gateway-service` on port 18789.

cat <<EOF | kubectl apply -f - kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 metadata: name: http-route spec: parentRefs: - name: https rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: openclaw-gateway-service kind: Service namespace: default port: 18789 EOF

Test OpenClaw application

Get the external endpoint.

kubectl get gateway https -o jsonpath='{.status.addresses[0].value}'

Paste the endpoint into your browser to reach the OpenClaw application. If you are using a self-signed certificate, you will see a “Not secure” warning; click Advanced to proceed. In a production environment with a certificate signed by a certificate authority, you should not see that warning.

Figure 5: OpenClaw Authentication

Paste in your Gateway Token (the auth token created earlier). You will notice that even though the token is valid, it throws back a “pairing required” error. Pairing is required in OpenClaw whenever a new device, browser profile, or CLI client attempts to connect to the gateway for the first time, ensuring only authorized clients can control the AI agent.

POD=$(kubectl get pod -l app=openclaw-gateway -o jsonpath='{.items[0].metadata.name}') POD2=$(kubectl get pod -l app=openclaw-gateway -o jsonpath='{.items[1].metadata.name}') TOKEN=$(kubectl get secret openclaw-auth-token -o jsonpath='{.data.token}' | base64 -d) kubectl exec "$POD" -c gateway -- openclaw devices approve --latest --token "$TOKEN" kubectl exec "$POD2" -c gateway -- openclaw devices approve --latest --token "$TOKEN"

You should see a message like the one in the image below. You can now open the OpenClaw application and start using it.

Figure 6: OpenClaw pairing success message

Figure 7: OpenClaw Application

You have successfully deployed OpenClaw within a microVM hosted on Azure Kubernetes Service.

Test microVM kernel isolation

From within the OpenClaw pod, try to read the host’s root filesystem via /proc/1/root. You should see an error like: ls: cannot access '/proc/1/root/etc/kubernetes': No such file or directory.

kubectl exec -it "$POD" -c gateway -- ls /proc/1/root/etc/kubernetes 2>&1

In a standard container deployment, PID 1 inside the container is still running on the host kernel, so traversing /proc/1/root/ exposes the host's root filesystem — including sensitive paths like /etc/kubernetes (which holds kubelet credentials). With Kata VM isolation, the picture is completely different. When we run ls /proc/1/root/etc/kubernetes from inside the OpenClaw pod, it returns "No such file or directory". This is because PID 1 is no longer a process on the host — it's running inside a dedicated guest VM with its own kernel. The /proc/1/root/ path leads to the microVM's root filesystem, not the host's, and that microVM has no knowledge of the node's Kubernetes configuration or machine identity. The host is simply invisible. This is the core security guarantee of Kata Containers: even if an attacker achieves a full container escape, there is nothing to escape to — they land inside a lightweight VM boundary, not on the shared host, making lateral movement to other pods or the node itself impossible.

Conclusion

This post discussed why running OpenClaw workloads in standard containers can be risky when the workload includes untrusted or semi-trusted code: containers share the host Linux kernel, so a single container escape or privileged misconfiguration can expand into node-level compromise and a much larger blast radius. To address this, we introduced microVM-based sandboxing with Kata Containers on Azure Kubernetes Service (AKS) and walked through an implementation approach (a node pool with Kata VM isolation, storage, gateway deployment, and ingress). Finally, we validated the isolation properties by demonstrating that common host-visibility techniques (for example, probing /proc/1/root) no longer reveal host paths when the workload runs inside a microVM.

Separate kernel boundary: Kata runs the container inside a microVM, so the workload executes against a guest kernel rather than the shared host kernel—kernel exploits and escape attempts don’t directly translate into host control.
Host filesystem is no longer “in scope”: paths that often leak host context in standard containers (for example, traversals via /proc) resolve inside the microVM’s filesystem, not the node’s root filesystem.
Reduced blast radius per workload: each sandbox has its own VM boundary, making it much harder to pivot from one compromised workload to other pods/containers on the same node.
Stronger default device and privilege separation: the hypervisor boundary and minimal virtual device model limit exposure to host devices and privileged interfaces that commonly enable breakouts.
Defense-in-depth still applies: you can keep container hardening (seccomp, capability dropping, read-only filesystems, restricted mounts) while gaining an additional isolation layer that is independent of Linux namespaces/cgroups.

Overall, this post helps you deploy OpenClaw on AKS with Kata microVM isolation so you can run agent workloads with a significantly reduced risk of host-kernel compromise from container escape techniques.

How to Manage RC4 Hardening – Definitive Guide

Elanor92 — Wed, 29 Apr 2026 15:59:22 GMT

How to Manage RC4 Hardening – Definitive Guide

This article is a technical continuation of the RC4 deprecation / Kerberos hardening work I covered in my previous article last month. If you already went through the “why” (risk of RC4, what changes Microsoft is rolling out, and the high-level migration approach), the goal here is to get hands-on and precise: what exactly changes across the three rollout phases, which registry keys and AD attributes drive KDC behavior, what you should expect to see in security logs, and how to turn those signals into concrete remediation steps.

Prerequisites: ensure the January update that introduces the RC4/Kerberos hardening telemetry is installed on all Domain Controllers. Without that patch, the Security log will not emit the new KDC events (201–209) and the Domain Controllers will not evaluate the related registry keys (RC4DefaultDisablementPhase and DefaultDomainSupportedEncTypes).

Note: The information in this article applies only to supported operating systems released before 2025. I haven’t had the time to validate how these keys behave on 2025 versions.

Hardening Phases

Let's begin with a brief walkthrough of the hardening phases. For a detailed walkthrough of the rollout phases, see my previous article. Below is a technical summary of each phase of the RC4 hardening update.

Phase 1 - Auditing - January 2026:
- starting from the January update, you can create the RC4DefaultDisablementPhase registry key. Set it to 1 to enable logging of the new events (201-209) on domain controllers.
- Nothing else changes, for now.
Phase 2 – Soft enforcement – April 2026: the KDC will reject automatically requests that only support RC4. In this phase:
- RC4DefaultDisablementPhase is set to 2 but can be reverted to 1. If the value was previously set to 1, the patch won’t override the value.
- DefaultDomainSupportedEncTypes: if the value of this key was not set when Phase 2 starts, the value is set to 0x18 by default (AES-only). You can roll it back to 0x1C or 0x24 (you will understand the difference between those two values later in this article) if needed. However, if you had previously defined this key, Microsoft will not override it.
Phase 3 – Hard enforcement – July 2026:
- the RC4DefaultDisablementPhase is no longer read
- In this phase, the only way to allow RC4 encryption is to manually set the msDS-SupportedEncryptionTypes attribute to 0x1C (to allow RC4 only for the account) or to set the DefaultDomainSupportedEncTypes to 0x1C or 0x24 to allow RC4 for the entire environment.

Note that, if you want to apply the msDS-SupportedEncryptionTypes to allow RC4 at AD object level, but at the same time have the DefaultDomainSupportedEncTypes set to 0x18 you’ll need to set the SupportedEcryptionType policy for the support of RC4 (more details in the scenarios section of this article).

Registry keys and attributes involved

In this section, you’ll find the list of all the registry keys, AD attributes, and GPOs involved in this hardening. The values shown are not exhaustive, I have listed only the specific values relevant to this hardening.

DefaultDomainSupportedEncTypes:

Path: HKLM\System\CurrentControlSet\Services\KDC

This key need to be created manually if needed

Possible values:

0x27: enable DES, RC4 and AES session key (default before hardening for pre-2025 OSs)
- Flags enabled: DES-CBC-CRC, DES-CBC-MD5, RC4-HMAC, AES256-CTS-HMAC-SHA1-96-SK
0x24: Enable RC4 and AES session key:
- Flags Enabled: RC4-HMAC, AES256-CTS-HMAC-SHA1-96-SK
0x1C: allow RC4 and AES:
- Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
0x3C: enable RC4, AES and AES session key
- Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
0x18: enable AES only (default value pre hardening for 2025)
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96
0x38: enable AES and AES session key
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK

Possible values and their meaning during all the phases:

Phase 1:
- The value of this key won’t be changed during phase 1. if the key has not been manually set, you'll have the default value of you operating system during this phase
Phase 2:
- 0x18: default value for this phase. Block the use of RC4 encryption, only AES-128 and AES-256 are allowed. If this key was already explicitly set to any other value before the starting of phase 2, the patch won’t override its value.
- 0x24, 0x1C and 0x3C: these values can be used for manual rollback to allow RC4, I’ll advise using the value 0x1C for increased security. *
Phase 3:
- 0x18: default value for this phase. Block the use of RC4 encryption, only AES-128 and AES-256 are allowed. If this was already explicitly set to any other value, the patch won’t override its value.
- 0x24, 0x1C and 0x3C: these values can be used for manual rollback to allow RC4, I’ll advise using the value 0x1C for increased security. *

Later in this article, you’ll find common scenarios to help you choose the right values based on your audit findings.

* In our labs, setting the DefaultDomainSupportedEncTypes to 0x1C caused login issues on Windows Server 2003 and Windows XP. If you still have these operating systems, test this value carefully in your environment. We tried to set the key to 0x24 and we did not observe the same issues.

RC4DefaultDisablementPhase

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters

Note that this key must be manually created and set and will be evaluated only after the installation of the January 2026 update.

Here you can find all the possible values during all phases:

Phase 1:
- 1: audit mode enabled, the events 201-209 are logged onto the domain controller when RC4 is being used (see the table below for details)
- 2: Kerberos will start assuming that RC4 has been disabled and will start to negotiate AES encryption by default
Phase 2:
- The values are the same reported for phase 1. With the April patch the value will change to 2 only if the key was not explicitly set to 1 during phase 1. Anyway, it can be reverted to 1
Phase 3:
- The key is no longer evaluated

msDS-SupportedEncryptionTypes

This attribute is found on all domain objects in the attribute editor tab.

Value available for the attribute:

Null, not set or 0x0: the encryption used depends on the value reported on the DefaultDomainSupportedEncTypes key
0x3C: enables RC4 AES and AES encryption key
- Flags enabled: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
0x38: enables AES and AES encryption key only
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK
0x18: enables AES only
- Flags enabled: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96

See the section reporting the common scenarios to understand how to correctly use this attribute in your environment.

SupportedEncryptionTypes

This registry key is populated by a GPO on the DCs: “Network security: Configure encryption types allowed for Kerberos”. The path of the GPO is "Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options".

You can find the related registry key at the path: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\

The values of the registry key depend on the GPO settings. The possible values are:

0x7FFFFFFC: this configuration is needed to support RC4 in your environment
- Encryption type supported: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK, FAST-supported, Compound-identity-supported, Claims-supported, Resource-SID-compression-disabled, Future encryption types
0x7FFFFFF8: this is value for the recommended configuration
- Encryption types supported: AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96-SK, FAST-supported, Compound-identity-supported, Claims-supported, Resource-SID-compression-disabled, Future encryption types

See the section with the common scenarios to understand how to use this key.

Audit

This section lists the auditing events for this hardening and briefly explains what each one indicates. Starting in January 2026, some existing events were enhanced to surface additional encryption details, and new events were introduced that are available only after installing the January 2025 patch. Microsoft also made two really helpful scripts to collect and analyze events, you can find more details about those scripts at the end of this section.

Existing enhanced events

Some existing events has been enhanced, and can be used for the auditing of RC4 usage, like:

4768: A TGT ticket has been requested
4769: A Kerberos service ticket has been requested

Beyond identifying the client and account requesting the ticket, both events include several fields that are useful for analysis:

msDS-SupportedEncryptionTypes: show the value of this attribute for the account reported in the event
Available keys: shows all the available keys that has been found in AD for that object
Ticket Encryption Type: the actual ciphers used for the ticket encryption:
- 0x17 = RC4
- 0x12 or 0x13 = AES
Session Encryption Type: the actual ciphers used for the session Encryption
- 0x17 = RC4
- 0x12 or 0x13 = AES
Advertised Etypes: lists the encryption types the client supports. If you see only RC4 or DES in this field, it means that we are looking at a legacy client; modern clients should advertise both RC4 and AES.

Note: 4768 events are not correlated with any 201-209 event, while for the 4769 events you can find the related 201-209 event to help you during the troubleshooting.

New events available

During the audit phase we can see the system event log:

Event ID	Type/Phase	Meaning
201	Warning	The client only supports RC4 and the target service's msDS-SupportedEncryptionTypes is not defined. This will fail under enforcement.
202	Warning	The target service account's msDS-SupportedEncryptionTypes is not defined and the service account only has insecure (RC4) keys.
205	Warning	The KDC detected that the domain controller has DefaultDomainSupportedEncTypes explicitly defined to include insecure encryption (RC4) Microsoft will not automatically override this
206	Warning	The target service's msDS-SupportedEncryptionTypes is explicitly set to AES-only, but the client doesn't advertise AES-SHA1
207	Warning	The target service's msDS-SupportedEncryptionTypes is explicitly set to AES-only, but the service account doesn't have AES-SHA1 keys (password not reset).

During the enforcement phase, you can find these events in the system event log:

Event ID	Type/Phase	Meaning
203	Error	The KDC blocked a service ticket because the client only supports insecure types and the service has no explicit encryption config.
204	Error	The KDC blocked a service ticket because the service account only has insecure keys and has no explicit encryption config.
205	Warning	The KDC detected that the domain controller has DefaultDomainSupportedEncTypes explicitly defined to include insecure encryption (RC4) Microsoft will not automatically override this
208	Error	The KDC denied a service ticket because the client doesn't support AES-SHA1 and the service requires it.
209	Error	The KDC denied a service ticket because the service requires AES-SHA1 but has no AES keys.

Below is a list of possible remediation steps based on the events you observe:

201 and 203: these events usually indicate that we are looking to a legacy device. My advice is to correlate this finding to the related 4769 event. The goal is understand if the device is legacy or not:
- The device is legacy: the device does not support AES and needs to be updated. If the update is not feasible now, you can set the msDS-SupportedEncryptionTypes to 0x1C to allow RC4
- The device is not legacy: investigate the reason why the device does not have any AES keys available. Maybe the password of the AD account has not been reset in a long time, or there may be a policy applied to this object to enforce the use of RC4 only
202 and 204: these events usually indicate that the password for the account is too old, so the account cannot generate any AES key for encryption.
- Reset the password and try the authentication again to confirm the resolution of the problem.
206 and 208: these events usually indicate a mismatch between the client and the account configuration. The account may be set to allow AES only but the client may be legacy one.
- You need to update the client, if the update is not feasible now, you can set the msDS-SupportedEncryptionTypes to 0x1C to allow RC4
207 and 209: the account is set to AES but cannot generate an AES ticket.
- Usually, you'll need to reset the password of the account to solve this issue.

See the common scenarios section for more details

Scripts

Microsoft provided two scripts to help us investigate the RC4 usage in our environment:

List-AccountKeys.ps1 to query event logs to enumerate available encryption keys for accounts.
Get-KerbEncryptionUsage.ps1 to identify Kerberos encryption types in use, with filtering options for specific algorithms like RC4.

The scripts are available in this repository: Microsoft's Kerberos-Crypto GitHub repository

Get-KerbEncryptionUsage.ps1

This script can identify the usage of RC4 encryption in the environment by analyzing the events recorded on the domain controllers. The info are collected primarily from the events 4768 and 4769. In the output you’ll find date and time of the event, the requestor and the type of ticket and session encryption used.

Example:

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_DC01.csv -NoTypeInformation -Encoding UTF8

List-AccountKeys.ps1

This script is useful to identify which key are available for an object (service account, user, computer account).

Event forwarding

If you have a SIEM available on your environment: lucky you! There is a wonderful article that explains how to collect and forward the event to the SIEM to analyze them: So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub

Common Scenarios

This section will cover the common scenarios that we may find in the customer’s environment and how to approach it

I have only few objects that are using RC4

Scenario:

During the audit phase I found few legacy devices and applications not compatible with AES
I cannot update those devices/applications before the July 2026 phase (enforcement phase)
I need to leave RC4 enabled for only those objects

DOs:

SupportedEncryptionTypes: you need to set this key to 0x7FFFFFFC to allow the support of RC4 using the GPO (see the "Registry keys and attributes involved" section of this article), otherwise even if the attribute msDS-SupportedEncryptionTypes is set to support RC4, the authentication will break, because the KDC won't know how to interpret RC4.
msDS-SupportedEncryptionTypes: this attribute needs to be set to 0x1C to support RC4
DefaultDomainSupportedEncTypes: can be set to 0x18, this sets AES as the default encryption type for the domain. So, all the account that have the msDS-SupportedEncryptionTypes not set, will use AES by dafault

In this scenario, new accounts and computers will use AES by default, while accounts with the attribute msDS-SupportedEncryptionTypes set to 0x1C will still use RC4. This works because the KDC is configured to allow RC4 even though AES remains the domain’s default.

Note that having devices and applications that rely on RC4, will lower the security posture of your environment, my advice would be to remediate those devices/applications asap.

Many services rely on RC4

Scenario:

During the audit phase I found many devices not compatible with AES
I cannot update those devices/applications before the July 2026 phase (enforcement phase)

If there are too many devices to be remediated using the msDS-SupportedEncryptionTypes attribute, you’ll need to keep RC4 enabled by default at the domain level:

DefaultDomainSupportedEncTypes: needs to be set to 0x1C to allow both AES and RC4
SupportedEncryptionTypes: needs to be set to 0x7FFFFFFC (see the "Registry keys and attributes involved" section for more information about this setting)
msDS-SupportedEncryptionTypes: this attribute does not need to be changed in this scenario.

In this scenario you can evaluate the possibility to use the attribute msDS-SupportedEncryptionType to secure some critical modern devices and applications by setting the attribute to 0x18 or 0x38 to allow only AES encryption for those objects.

No services rely on RC4

Congratulations!! This is the best scenario, you don’t have any legacy devices or applications that can rely only on RC4.

DOs:

DefaultDomainSupportedEncTypes: you can leave it to the July 2026 default (0x18)
SupportedEncryptionTypes: can be set to 0x7FFFFFF8 (see the "Registry keys and attributes involved" section for more information about this setting)
msDS-SupportedEncryptionTypes: there is no need to change this attribute in this scenario

Conclusion

The RC4 hardening rollout is one of those changes that looks simple on paper “move everything to AES”, but succeeds or fails based on how well you turn Kerberos telemetry into an inventory of real dependencies. Across the three phases (audit, soft enforcement, hard enforcement), the KDC gradually shifts from observing RC4 usage to actively rejecting it, and by Phase 3 the domain-wide “allow RC4” escape hatch is gone.

Use Phase 1 and the first part of Phase 2 to build a remediation backlog from the new KDC events (201–209) and the enhanced 4768/4769 fields.

Also keep in mind the blind spots: the absence of KDCSVC audit events does not guarantee that all systems will function correctly after enforcement. These events focus on service ticket requests involving default/implicit encryption behavior; explicitly configured accounts, TGT requests, and non-Windows or embedded Kerberos stacks can still fail in ways that are not surfaced by 201–209 alone.

FAQs

Are there impacts in the forest trusts?

Test external trusts for impact. Trusts between domains in the same forest have used AES since the November 2022 patch. Before enforcing AES-only across a forest, validate that the trusted forest supports AES.

I don’t see any 201-209 events in my environment, does it means that my environment won’t be impacted?

No, the absence of KDCSVC audit events does not guarantee that all systems will function correctly after enforcement. These events focus on service ticket requests involving default/implicit encryption behavior; explicitly configured accounts, TGT requests, and non-Windows or embedded Kerberos stacks can still fail in ways that are not surfaced by 201–209 alone.

Is the msDS-SupportedEncryptionTypes key evaluated by Windows XP and Windows 2003 OSs?

No, those operating systems are not capable to read the msDS-SupportedEncryptionTypes key. In this case, to allow the use of RC4 you’ll need to use the DefaultDomainSupportedEncTypes set to 0x24

Useful Resources

Encryption Type Calculator: Encryption Type Calculator - Kerberos in Active Directory
What is going on with RC4 in Kerberos? | Microsoft Community Hub
Supported Encryption Types Bit Flags [MS-KILE]: Supported Encryption Types Bit Flags | Microsoft Learn
How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 - Microsoft Support
Event 4769: 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn
How to manage the Kerberos protocol changes related to CVE-2022-37966 KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966 - Microsoft Support
Detect and remediate RC4 usage Detect and Remediate RC4 Usage in Kerberos | Microsoft Learn

Disclaimer

The content of this article is based on available public documentation and test performed on a personal lab environment. The information is provided AS IS without a warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use of the reported information contained in this documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the document be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the data in this documentation, even if Microsoft has been advised of the possibility of such damages.
In short: Every environment is different, please test the changes before the implementation in your production environment

Extracting and Auditing Azure DevOps Permissions at Scale with PowerShell

skissel — Tue, 28 Apr 2026 06:38:27 GMT

Introduction

Azure DevOps organizations accumulate permissions over time. Groups are created, users are added, Entra (Azure AD) groups are nested into project groups, and team structures evolve. For organizations subject to compliance requirements, security reviews, or simply wanting to understand who has access to what, the Azure DevOps portal provides a per-group, per-namespace view that does not scale.

The Azure DevOps REST APIs expose the underlying security model — security namespaces, Access Control Lists (ACLs), Access Control Entries (ACEs), and bitmask-encoded permissions — but consuming these APIs and translating raw data into actionable output requires significant effort.

The blog post introduces ADO Permissions Output, an open-source PowerShell toolset that extracts Azure DevOps security permissions across 30+ security namespaces, resolves cryptic tokens and GUIDs into human-readable names, and produces structured JSON and CSV output suitable for auditing, compliance, and import into Power BI.

The toolset is available on GitHub: ADO-Permissions-Output

The Problem

Consider a typical Azure DevOps organization with multiple projects, dozens of custom groups, Entra-backed security groups, and permissions set at the repository, build pipeline, release pipeline, area path, and service endpoint levels. An auditor needs to answer questions like:

Which groups have Deny permissions on a specific Git repository?
Who has Edit build pipeline access across all projects?
Are there disabled Entra users still showing as members of ADO groups?
Which users have access but have never logged in?

The ADO portal answers these one group at a time. The REST APIs answer them in bitmasks and GUIDs. This tool bridges the gap.

What the Tool Does

At a high level, the tool:

Authenticates to Azure DevOps using a Personal Access Token (PAT)
Enumerates all security namespaces in the organization
Fetches all groups, users, and teams
For each namespace, retrieves ACLs with extended info (effective and inherited permissions)
Decodes bitmask permissions against the namespace action list
Resolves security tokens (GUIDs, paths) to friendly names (project names, repo names, query paths, etc.)
Outputs structured JSON per project with Allow, Deny, Effective, and Inherited permissions clearly labeled
Optionally generates a group membership report with user entitlement status

Architecture Overview

Flowchart of PowerShell and JSON files, their purposes, the REST API endpoints that are called, and the outputs files.

The solution consists of three PowerShell files:

File	Purpose
SecurityMain.ps1	Entry point — loads modules, sets up directories, orchestrates execution
SecurityHelper.psm1	Core engine — namespace enumeration, ACL fetching, bitmask decoding, token resolution
ProjectAndGroup.psm1	Group membership reporting, user entitlement enrichment, directory setup

Configuration is driven by ProjectDef.json, which specifies output directories, filenames, and which namespaces to extract.

All REST API calls route through a centralized Invoke-AdoRestMethod wrapper that provides automatic retry with exponential back-off for HTTP 429 (throttle) and transient server errors.

Setting Up the Pipeline

The tool is designed for unattended execution in an Azure Pipelines pipeline. The included `main.yml` defines a parameterized pipeline that can be run manually from the ADO UI. Additionally, a trigger can be configured to run on a schedule.

Prerequisites

A Personal Access Token with read permissions across security, graph, build, release, work items, service endpoints, dashboards, and analytics scopes
A Variable Group named ADOPermissions containing the PAT as a secret variable
The Build Service identity needs Contribute permission on the repository (for committing output back)

Running the Pipeline

When you run the pipeline, the "Run pipeline" dialog presents parameters for the organization name, project name, and optional features like the membership report and AAD group recursion.

Azure DevOps Pipeline Run dialog from YAML configuration.

The pipeline extracts permissions, commits the output back to the repository, and optionally publishes the output as a pipeline artifact.

Understanding the Permissions Output

The primary output is a JSON file per project. Each entry represents a single permission assignment:

{ "Namespace": "Git Repositories", "Project": "MyProject", "Object": "my-repo", "Type": "Group", "UserGroupName": "Contributors", "PermissionType": "Allow", "Permission": "Contribute", "Bit": 4 }

Permissions are reported as:

Allow — Explicitly granted
Deny — Explicitly denied
Allow (Effective) — Granted through inheritance
Allow (Inherited) — Inherited from a parent scope
Deny (Effective) and Deny (Inherited) — Same patterns for deny permissions

Token Resolution

One of the most valuable features is that raw security tokens are resolved inline. Instead of seeing repoV2/c847308e-d632-4e7f-a7fb-6f4db280bbaa/a1b2c3d4-..., the output shows the actual repository name, build definition name, query path, area path, or service endpoint name.

This resolution covers:

Project names
Git repository names
Build and release definitions
Work item queries (including nested folder paths)
Area paths and iterations
Dashboards (project and team level)
Service endpoints
Variable groups and secure files
Agent pools
Environments
Plans and process templates
Analytics views

The Membership Report

When -IncludeMembership is enabled, the tool generates a separate report showing who belongs to each group and what parent groups each group belongs to.

JSON output of user and group memberships per Azure DevOps group.

Detecting Stale and Ghost Members

The membership report includes Status and LastAccessedDate from the User Entitlements API, along with a ResolvedVia field that indicates how each member was discovered.

ResolvedVia	Status	LastAccessedDate	Meaning
ADO Membership API	active	Recent date	Active user, using ADO
ADO Membership API	active	Null or very old	Has access, never logged in
ADO Membership API	disabled	Any	Admin disabled their ADO access
ADO Membership API	Null	Null	ADO identity exists but entitlement removed
Hierarchy Group Expansion	active	Recent date	Active user, also in an Entra group
Hierarchy Group Expansion	Null	Null	Ghost member — visible in ADO UI via Entra group but has no ADO entitlement

AAD/Entra Group Recursion

When -RecurseAADGroups is enabled, the tool resolves the actual members of Entra (Azure AD) groups that are nested inside ADO groups. This uses the ADO Contribution HierarchyQuery API — the same API that the ADO portal uses to display group members.

This is significant because the standard ADO Graph Memberships API does not return individual members of Entra groups — it only shows the Entra group itself as a member. The HierarchyQuery approach reveals the real users, including those whose Entra accounts have been disabled or deleted but still appear in the ADO UI through group membership.

Importing into Power BI

The JSON output is directly importable into Power BI for visualization and analysis.

Open Power BI Desktop
Get Data > JSON
Select the permissions or membership JSON file
The data loads as a table ready for filtering, pivoting, and visualization

Alternatively, use the -OutputFormat CSV parameter to produce CSV files for direct import via Data > From Text/CSV.

Power BI Dashboard layout of Namespaces, project permissions, user and group names, and count of project permissions.

Common Power BI analyses:

Permission heatmap by namespace and group
Users with Deny permissions across all projects
Group membership overlap between projects
Stale users (active entitlement but no recent access)
Ghost members from Entra group expansion

Key Design Decisions

Sequential execution. The tool processes namespaces sequentially rather than in parallel. This avoids the ADO API throttle penalty box (HTTP 429), which can delay an entire pipeline run. The retry wrapper handles transient 429s with Retry-After header respect, but sequential processing prevents them from occurring in the first place.

PAT authentication only. The tool uses Personal Access Token authentication with Basic auth headers. This keeps the solution simple — no Entra app registrations, managed identities, or module dependencies. The PAT is stored in an ADO Variable Group marked as secret.

Read-only operation. The tool does not modify any permissions, groups, or resources. All API calls are GET or POST (for subject lookups and HierarchyQuery). It is safe to run against production organizations.

Getting Started

Clone the repository: git clone https://github.com/sckissel/ADO-Permissions-Output.git
Create a PAT with the required scopes (see the README for the full list)
For pipeline execution, follow the setup instructions in the README to create the Variable Group and pipeline definition.
For local testing:

./SecurityMain.ps1 ` -PAT "<your-pat>" ` -VSTSMasterAcct "yourorg" ` -projectName "YourProject" ` -allProjects "False" ` -DirRoot "C:\ADOSecurity" ` -IncludeMembership "True" ` -RecurseAADGroups "True" ` -OutputFormat "Both"

Conclusion

Auditing Azure DevOps permissions at scale requires more than the portal provides. This toolset bridges the gap between the raw security APIs and actionable audit output, resolving cryptic tokens into readable names, surfacing effective and inherited permissions, and detecting stale or ghost group members through Entra group expansion.

The tool is open source, requires only PowerShell 7 and a PAT, and is designed for unattended pipeline execution with output committed back to the repository for version-tracked audit history.

Feedback, issues, and contributions are welcome on GitHub: ADO-Permissions-Output

Thanks for reading!

Disclaimer

The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

Designing Outbound Connectivity for "Private Subnets" in Azure

alexeyn1 — Thu, 23 Apr 2026 21:28:09 GMT

Why Private Subnets Change Everything

Historically, Azure virtual machines relied on default outbound internet access, where the platform automatically assigned a dynamic SNAT IP from a shared pool. This was convenient but problematic:

❌ No deterministic outbound IP addresses
❌ No traffic inspection or filtering
❌ No FQDN or URL governance
❌ Difficult to audit for compliance
❌ Susceptible to noisy neighbor SNAT exhaustion

With private subnets, outbound access is disabled by default. This shifts the responsibility to the architect — deliberately. The result is an environment where:

✅ Every outbound flow is intentional
✅ Every outbound IP is known and documented
✅ Every egress path can be governed and logged
✅ Compliance evidence is straightforward to produce

The question is no longer "does my VM have internet access?" but rather "how exactly does my VM reach the internet, and is that path appropriate for this workload?"

The Three Outbound Patterns at a Glance

Option	Primary Role	Inspection	Scale	Cost	Best For
NAT Gateway	Managed outbound SNAT	❌ None	⭐⭐⭐ High	💲 Low	Simple, scalable egress
Azure Firewall	Secure governed egress	✅ Full L3–L7	⭐⭐⭐ High	💲💲💲 Higher	Security boundaries
Load Balancer	Legacy SNAT	❌ None	⭐⭐ Limited	💲 Low	Legacy / transitional

Scenario 1: NAT Gateway

What is NAT Gateway?

Azure NAT Gateway is a fully managed, zone‑resilient, outbound‑only SNAT service. It attaches at the subnet level and automatically handles all outbound flows from that subnet using one or more static public IP addresses or prefixes.

It is purpose‑built for one thing: providing predictable, scalable outbound internet access — without routing complexity or inline devices.

Key flow are depicted below:

VM → NAT Gateway: Automatic SNAT (no UDR required)

NAT Gateway → Internet: Static, deterministic public IP

Inbound: NOT supported (outbound only)

How it works (step by step)

VM initiates an outbound connection (e.g., HTTPS to an API)
NAT Gateway intercepts the flow at the subnet boundary
Source IP is translated to the NAT Gateway's static public IP
The packet is forwarded to the internet
Return traffic is automatically tracked and delivered back to the VM

No UDRs. No routing tables. No inline devices. It just works.

Strengths

Massive SNAT scale — no port exhaustion concerns at typical enterprise scale
Deterministic outbound IPs — easy to allowlist with external services
Zone resilient — survives availability zone failures
Subnet scoped — applies to all VMs in the subnet automatically
No routing configuration required

Limitations

❌ No traffic inspection or filtering
❌ No FQDN or URL policy enforcement
❌ No threat intelligence integration
❌ Cannot restrict which internet destinations are allowed

Best Fit Use Cases

✅ Application tiers calling external SaaS APIs
✅ VMs requiring OS updates and patch downloads
✅ CI/CD build agents and pipeline runners
✅ Spoke VNets in hub‑and‑spoke where east‑west goes through firewall, but simple internet egress is acceptable
✅ Dev/test environments

Scenario 2: Azure Firewall

What is Azure Firewall?

Azure Firewall is a cloud‑native, stateful, L3–L7 network security service. When used for outbound egress, it transforms the egress path from a connectivity function into a security enforcement boundary.

Unlike NAT Gateway, Azure Firewall inspects every packet, evaluates it against policy, and either allows or denies it based on network rules, application rules, and threat intelligence feeds.

KEY Flow are depicted below:

VM → UDR: Forces ALL outbound traffic to Firewall

Firewall: Evaluates against policy before allowing

Firewall → Internet: Only explicitly permitted flows pass

All denied flows: Logged and alertable

How it works (step by step)

VM initiates an outbound connection
UDR intercepts the flow and redirects to Azure Firewall's private IP
Azure Firewall evaluates the traffic:

Network rules (IP/port match)
Application rules (FQDN/URL match)
Threat intelligence (known malicious IPs/domains)

If allowed: traffic is forwarded via Firewall's public IP
If denied: traffic is dropped and logged
All flows (allowed and denied) are logged to Log Analytics / Sentinel

Strengths

✅ Full L3–L7 inspection
✅ FQDN and URL‑based filtering (application rules)
✅ Threat intelligence integration (Microsoft TI feed)
✅ TLS inspection (Premium SKU)
✅ Centralized governance across multiple VNets via Firewall Manager
✅ Rich logging — every allowed and denied flow is recorded
✅ IDPS (Intrusion Detection and Prevention) available in Premium

Limitations

❌ Higher cost (hourly + data processing charges)
❌ Requires UDR configuration on each spoke subnet
❌ Adds latency (small but non‑zero)
❌ Requires careful SNAT configuration at scale

Best Fit Use Cases

✅ Regulated industries (financial services, healthcare, government)
✅ Any workload where outbound internet is a security boundary
✅ Environments requiring egress allowlisting for compliance
✅ Hub‑and‑spoke architectures with centralized control plane
✅ SOC environments needing outbound flow telemetry

Scenario 3: Load Balancer Outbound

What is Load Balancer Outbound?

Azure Load Balancer outbound rules were historically the primary mechanism for providing SNAT to VMs behind a Standard Load Balancer. While newer patterns (NAT Gateway, Azure Firewall) have largely replaced this approach for new designs, outbound rules remain valid in specific scenarios.

Key flows are depicted below:

VMs → Load Balancer: Backend pool members get SNAT

LB Outbound Rules: Define port allocation per VM

⚠️ Port exhaustion risk at scale

⚠️ No inspection or policy enforcement

How it works (step by step)

VM in the backend pool initiates an outbound connection
Load Balancer applies SNAT using the frontend public IP
Ephemeral ports are allocated per VM from a fixed pool
Return traffic is tracked and delivered back to the correct VM
If port pool is exhausted: connections fail (SNAT exhaustion)

Strengths

Lower cost than NAT Gateway or Firewall
Tightly integrated with existing load‑balanced workloads
Familiar operational model for legacy teams

Limitations

❌ SNAT port pool is fixed and must be manually managed
❌ Risk of SNAT exhaustion at scale
❌ No traffic inspection
❌ Less flexible than NAT Gateway
❌ Not recommended for new designs

Best Fit Use Cases

✅ Existing architectures already built around Azure Load Balancer
✅ Low outbound connection volume workloads
✅ Transitional architectures during modernization to NAT Gateway

Decision Framework: Choosing the Right Outbound Pattern

Common Pitfalls to Avoid

⚠️ Pitfall 1: Forgetting SNAT scale limits

Load Balancer outbound rules allocate a fixed number of ephemeral ports per VM. At scale this exhausts quickly. Use NAT Gateway instead.

⚠️ Pitfall 2: Over‑securing low‑risk workloads

Not every workload needs Azure Firewall for outbound. Dev/test and patch traffic are better served by NAT Gateway — simpler, cheaper, faster.

⚠️ Pitfall 3: Mixing outbound models in the same subnet

NAT Gateway and Load Balancer outbound rules cannot coexist on the same subnet. NAT Gateway always takes precedence. Plan your subnet boundaries carefully.

⚠️ Pitfall 4: Blocking Azure platform dependencies

Many Azure services still use public endpoints (even when Private Link is available). Ensure your outbound policy allows required Azure service tags before enforcing egress controls.

⚠️ Pitfall 5: Relying on platform defaults

Default outbound access is retired for new VNets. Do not assume VMs can reach the internet without explicit configuration.

Summary and Key Takeaways

Scenario	Best Choice	Why
Simple internet egress at scale	NAT Gateway	Scalable, predictable, no complexity
Security boundary for egress	Azure Firewall	Inspection, FQDN rules, threat intel
Legacy load‑balanced workloads	Load Balancer Outbound	Transitional only
Regulated / compliance environments	Azure Firewall	Audit logs, policy enforcement
Dev / test / patch traffic	NAT Gateway	Low cost, low friction

The core principle

Private subnets make outbound access intentional. Choose the outbound pattern that matches the risk level of the workload — not the most complex option available.

References

https://learn.microsoft.com/azure/nat-gateway/nat-overview
https://learn.microsoft.com/azure/firewall/overview
https://learn.microsoft.com/azure/load-balancer/outbound-rules
https://azure.microsoft.com/blog/default-outbound-access-for-vms-in-azure-will-be-retired

Strengthening Identity Resilience: A Deep Dive into Microsoft Entra Backup and Recovery

Farooque — Tue, 21 Apr 2026 14:49:07 GMT

In the modern security landscape, we often say that "Identity is the new perimeter." We spend significant resources on Conditional Access, Phishing-Resistant MFA, and Identity Protection to keep the "bad guys" out. But what happens when the threat is already inside, or when a legitimate administrative action goes sideways?

If our identity data the "brain" of our Microsoft 365 and Azure ecosystem is corrupted or maliciously altered, usr entire security posture collapses. Today, we’re exploring the new Microsoft Entra Backup and Recovery capability, a native safety net designed to ensure usr identity infrastructure remains resilient against both accidents and attacks.

Why Native Backup Matters

For years, Entra ID administrators relied on the Recycle Bin for deleted objects. However, a major gap existed: Attribute Corruption. If a script accidentally wipes the department and manager attributes for 10,000 users, or if a malicious actor modifies our most restrictive Conditional Access policies to create a backdoor, the Recycle Bin can't help us the objects aren't deleted; they are just wrong. Restoring these specific states previously required complex PowerShell scripting or expensive third-party tools. Entra Backup and Recovery closes this gap by providing a native, automated way to "roll back" the state of usr objects.

Core Capabilities: How it Works

The service is currently available in Public Preview for customers with Entra ID P1 or P2 licenses. It operates on a simple yet powerful "Snapshot" model:

Automated Daily Snapshots

The system automatically captures a point-in-time view of our tenant every day. Currently, the service maintains a 5-day retention window. This allows us to look back at the state of our environment from yesterday or earlier in the week to find a "known good" configuration.

Visibility via Difference Reports

One of the most powerful features is the Difference Report. Before committing to a restoration, we can compare a specific snapshot against the live state of our tenant. The report provides a granular view of:

Object ID: Exactly which user, group, or policy is affected.
Attribute Changes: A side-by-side comparison showing the "Old Value" (from the backup) versus the "Current Value" (live in the tenant).
Metadata Loading: While the first report may take a moment to load metadata, subsequent reports are lightning-fast, allowing for quick triaging during an incident.

Granular Restoration

We aren't forced into an "all or nothing" recovery. We can choose to restore:

An entire object class (e.g., all Conditional Access Policies).
Specific object types (e.g., only Service Principals).
Individual Object IDs for targeted fixes.

The "Defense in Depth" Identity Strategy

Entra Backup and Recovery is not a standalone silo; it is the third pillar of a complete identity resilience strategy. To truly harden our tenant, we must coordinate these three features:

Pillar 1: Soft Delete (The Recycle Bin)

Used for Deleted Objects. If a user or Microsoft 365 group is deleted, it sits in the Recycle Bin for 30 days. We can restore these easily via the portal or Graph API to maintain the original Object ID and SID.

Pillar 2: Protected Actions (The Vault)

To prevent an attacker from "hard deleting" our objects (purging them from the Recycle Bin so they can't be recovered), we must implement Protected

Actions.

How it works: we assign a "Conditional Access Authentication Context" to sensitive actions like Microsoft.Directory/deletedItems/delete.
The Result: Even a Global Admin cannot permanently purge an object unless they meet strict requirements, such as using a Phishing-Resistant MFA key or working from a Secure Access Workstation (SAW).

Pillar 3: Backup and Recovery (The Time Machine)

Used for Corruption and Configuration Drift. When the object exists but its properties are compromised, this is our "Time Machine" to revert attributes and policy logic to a functional state.

Real-World Scenario: Recovering from a Bulk Logic Error

Imagine an admin runs a bulk update script intended to update the JobTitle for the Sales team. Due to a logic error in the CSV, the script instead clears the SecurityGroup memberships and ExtensionAttributes for the entire department.

Detection: Users lose access to apps because their group memberships are gone.
Analysis: The Admin generates a Difference Report between today and yesterday’s snapshot.
Validation: The report confirms that 500 users now have "null" values for the affected attributes.
Recovery: The Admin selects those 500 User IDs and hits Restore. Within minutes, the attributes are repopulated, and dynamic group memberships begin to recalculate automatically.

Conclusion and Next Steps

The preview of Microsoft Entra Backup and Recovery is a significant step forward in native tenant protection. By combining it with Protected Actions and the Recycle Bin, organizations can finally achieve a "circular" protection model for identity.

Ready to try it? Navigate to the Microsoft Entra Admin Center, look for Backup and Recovery in the left-hand navigation, and explore usr first snapshot today.

Running multimedia AI models on Container Apps with Serverless GPU (A100 & T4)

HoussemDellai — Mon, 20 Apr 2026 17:14:39 GMT

A video format is available for watching.

Prerequisites

- An Azure account with sufficient permissions to create resources.

- Terraform installed on your local machine.

Infrastructure Provisioning

Clone the Github repository and navigate to the project directory.
Initialize Terraform and apply the configuration to provision the necessary Azure resources, including a resource group, virtual network, log analytics workspace, container app environment, storage account, and container app for downloading models.

terraform init terraform apply --auto-approve

The following resources will be created:

ComfyUI Deployment

The ComfyUI application is deployed as a containerized workload on Azure Container Apps. The deployment includes a job that downloads the necessary models for ComfyUI to function properly.

The aca_job_download_models.tf file defines a job that runs a container with the necessary commands to download the models for ComfyUI. The job is configured to run on Consumption worksload profile and has a timeout of 1200 seconds.
The download-models-comfyui.sh script contains the commands to download the models from Hugging Face and save them to the appropriate directory in the ComfyUI application.

Monitoring and Analytics

The Azure Log Analytics workspace is set up to collect logs and metrics from the container app environment. You can use Azure Monitor to view and analyze the logs and metrics for your ComfyUI deployment.

To view the properties and the usage of the GPU behind Container Apps, the command nvidia-smi is helpful.

Start using ComfyUI

Now that ComfyUI is provisioned, accessible on the FQDN exposed by Container Apps and the models are downloaded, you can run the Text to Image workflow in ComfyUI. You can also change the parameters as needed like the prompt.

When ready, click the Run blue button at the top right to start generating the image. It will take some time depending on the size of the image and the complexity of the prompt. Then you should see the generated image in the output node.

Using ComfyUI for Text to Video

To use ComfyUI for Text to Video generation, you can select a Text to Video template from the Workflows section. Choose Wan 2.2 Text to Video as an example. This will open the workflow to generate a video based on a text input.

Important Notes

The storage account key is required to create the storage link in your Container Apps environment. Container Apps does not support identity-based access to Azure file shares. For that it is mandatory to disable Secure Transfer at the Storage Account (more details).

Because of an issue with the Terraform provider, it won't create the Serverless GPU (A100 & T4) workload profiles. You will need to create them manually in the Azure Portal after running terraform apply.

Azure File Shares supports both SMB and NFS. Container Apps also supports both.

To mount NFS Azure Files, you must use a Container Apps environment with a custom VNet. The Storage account must be configured to allow access from the VNet either using Service Endpoint or Private Endpoint (more details)

The NFS protocol can only be used from a machine inside of a virtual network, that is why we use a Private Endpoint.

🔍 SMB vs NFS — What’s the Difference?

SMB (Server Message Block) and NFS (Network File System) are two protocols used to provide shared file storage over a network.

They serve similar purposes but have different strengths, performance characteristics, and typical use cases. NFS is native for Linux.

Consumption profile details

Profile names	vCPU range	Memory range	GPU type	Regions
Consumption	0.25 - 4	0.5 - 8 GB	N.A	All supported regions
Consumption-GPU-NC8as-T4	0.25 - 8	0.5 - 56 GB	NVIDIA T4	To see a full list of available regions, see serverless GPU supported regions
Consumption-GPU-NC24-A100	0.25 - 24	0.5 – 220 GiB	NVIDIA A100

In Serverless GPU profiles, the GPU cost is in addition to the active usage vCPU and RAM prices for your Container App. You pay for the entire GPU cost, even if your Container App only uses a fraction of the GPU's resources. But, for CPU and Memory, you only pay for the resources your Container App actually reserves. To reduce cost, it is very important to right-size the vCPU and Memory for your Container App when using Serverless GPU profiles. You can use Azure Monitor to track the actual resource usage of your Container App and adjust the vCPU and Memory accordingly.

To get the supported profiles for a specific region, you can use the Azure CLI command:

az containerapp env workload-profile list-supported --location swedencentral -o table # Location Name # ------------- ------------------------- # swedencentral D4 # swedencentral D8 # swedencentral D16 # swedencentral D32 # swedencentral E4 # swedencentral E8 # swedencentral E16 # swedencentral E32 # swedencentral Consumption # swedencentral Flex # swedencentral Consumption-GPU-NC24-A100 # swedencentral Consumption-GPU-NC8as-T4

Here is the vCPU, Memory and GPU consumption for the NC A100 v4 and NC T4 v3 Serverless GPU profiles with ComfyUI when running typical workloads.

You can notice that ComfyUI doesn't consume the entire compute power in terms of vCPU and Memory. That is why in Terraform, it is specified that the resource request is less than what the VM offers. That allows to reduce the cost.

Disclaimer

Maintaining Azure Public IP Inventory by Retrieving Exact Deleted Public IP Using Activity Logs

AswiniSurendran — Fri, 17 Apr 2026 12:10:31 GMT

Azure Activity Logs provide strong visibility into resource lifecycle operations across a subscription. Among these are lifecycle events related to Azure Public IP addresses, including creation and deletion.

However, when a Public IP address is deleted, the corresponding delete operation in Azure Activity Logs includes only the Resource ID of the Public IP — not the actual IP address that was assigned to the resource.

Once deletion is complete:

The Public IP resource no longer exists

The Resource ID cannot be resolved

The assigned Public IP address is permanently unretrievable through Azure APIs

For organisations that rely on accurate IP inventory data for:

Security monitoring

Compliance audits

Incident response

Network forensics

This blog presents a production‑ready implementation approach that enables organisations to reliably capture and retain the assigned Public IP address of Azure Public IP resources — even after they are deleted — using Azure Activity Log alerts, Azure Automation, and a persistent resource mapping cache.

The Core Challenge

When a Public IP resource is deleted, Azure emits an Activity Log event like:

---

OperationName: Microsoft.Network/publicIPAddresses/delete

ResourceId:

/subscriptions/<subscription-id>/resourceGroups/<rg-name>/providers/Microsoft.Network/publicIPAddresses/<pip-name>

---

The alert correctly identifies the operation and the affected resource.

However:

The Activity Log does not include the assigned Public IP address.
After deletion, the associated Resource ID no longer resolves to a live Azure resource.

Maintaining Accurate IP Inventory

Enterprises rely on centralised Public IP inventories mapped to workloads and ownership. Since delete Activity Log events emit the Resource ID, inventory systems require the exact Public IP address associated with the deleted resource.

Preventing False Security Investigations

Azure Public IP addresses are globally reused. If a deleted IP remains recorded as owned internally, it may later be assigned to another tenant. This can lead to threat intelligence alerts and internal investigations against an IP address no longer under organisational ownership.

Supporting High‑Churn Dynamic Workloads

Ephemeral workloads such as Azure Machine Learning, CI/CD pipelines, and autoscaling deployments frequently create and delete Public IPs. In such environments, manual lifecycle tracking of assigned IP addresses is not operationally feasible.

Solution Overview

The recommended approach is based on the following principle:

Capture and persist the assigned Public IP address while the resource still exists and retrieve the stored value later when only the Resource ID is available.

This can be implemented using:

Azure Activity Logs
Log Analytics alerts
Azure Automation Runbooks
Persistent mapping cache of Resource ID to IP address

The solution comprises four primary components:

Azure Activity Logs routed to Log Analytics
Log Analytics alert rules detecting Public IP lifecycle operations
Azure Automation Runbooks triggered through webhook actions
Persistent cache storing Resource ID → IP address mappings

Implementation Guide

Step 1: Route Activity Logs to Log Analytics

Public IP lifecycle events are published through the Azure Activity Log under the Administrative category.

To enable lifecycle detection through KQL queries:

Navigate to: Azure Monitor → Activity Log → Diagnostic Settings
Select: Add Diagnostic Setting
Configure the following:

Category: Administrative
Destination: Send to Log Analytics Workspace

4.Select your target Log Analytics Workspace.

5.Click Save.

This allows lifecycle operations to be queried by alert rules from Log Analytics.

Step 2: Deploy an Azure Automation Account

Azure Automation will be used to execute runbooks that process Activity Log alerts and resolve Public IP address details during resource lifecycle operations.

To begin:

Navigate to the Azure Portal.
In the search bar, search for Automation Accounts.
Select Create, provide the following details and Select "Review + Create" to complete the deployment.

Subscription
Resource Group
Automation Account Name
Region

Once the Automation Account has been created:

Navigate to the Automation Account.
Go to Identity under the Account Settings section.
Enable System‑assigned Managed Identity.
Click Save.

This Managed Identity will later be used by the runbooks to securely retrieve Public IP metadata from Azure Resource Manager during alert execution.

Step 3: Assign Managed Identity Permissions

The Automation Account requires read‑only permissions to resolve Public IP resource information securely.

Navigate to:

Subscription → Access Control (IAM) → Add Role Assignment

Assign the following roles to the Automation Account Managed Identity:

Role	Scope
Reader	Subscription
Reader	Log Analytics Workspace

This ensures the runbooks are able to:

Query Public IP resources

Resolve resource metadata

Interpret Activity Log–driven lifecycle operations

Step 4: Create a Persistent Cache Variable

The assigned IP address must be captured and persisted in advance before it is deleted. To maintain this mapping, create a persistent Automation variable to store the following relationship:

Public IP Resource ID → Assigned IP Address

Within the Automation Account:

Navigate to: Shared Resources → Variables
Select + Add.
Configure the variable as follows:

Name: PipLastKnownIps
Type: String
Value: {}
Encryption: Disabled

4.Select Create.

This variable will act as a persistent cache that is dynamically updated during Public IP lifecycle events.

Step 5: Create Required Automation Runbooks

Two Azure Automation Runbooks are required for this implementation.

Runbook Name	Purpose
CacheSeedingRunbook	Builds initial Resource ID → IP mapping
MainLifecycleRunbook	Processes Activity Log alerts

Step 5.1: Create Cache Seeding Runbook

Create Cache Seeding Runbook

This runbook will enumerate all currently existing Public IP resources and populate the cache variable with their assigned IP address mappings.

Navigate to: Automation Account → Runbooks
Select Create a runbook.
Provide the following details:

Name: CacheSeedingRunbook
Runbook Type: PowerShell
Runtime Version: 7.2

4. After the runbook is created, paste the script here CacheSeedingRunbook.

Select Publish.

This runbook will initialise the cache by capturing the current state of all Public IP resources prior to enabling lifecycle‑based Activity Log processing.

Step 5.2: Create Main Lifecycle Runbook

This runbook will be triggered via webhook whenever a Public IP lifecycle event is detected through Activity Logs.

Navigate to: Automation Account → Runbooks
Select Create a runbook.
Provide the following details:

Name: MainLifecycleRunbook
Runbook Type: PowerShell
Runtime Version: 7.2
After the runbook is created, paste the required lifecycle processing script MainLifecycleRunbook

4. Select Publish once configuration is complete.

This runbook will process Activity Log‑based lifecycle events and dynamically update the PipLastKnownIps cache variable in response to Public IP creation or deletion.

Step 6: Create Runbook Webhook

Configure Runbook Webhook

To allow Activity Log alerts to invoke the runbook:

Navigate to: Automation Account → Runbooks → MainLifecycleRunbook
Go to: Resources → Webhooks
Select Add Webhook.
Provide the following details:

Webhook Name
Expiration Date

5. Copy the generated Webhook URL.

This URL will be used by the Alert Action Group in a later step to trigger the runbook upon detection of Public IP lifecycle events.

Step 7: Seed Cache with Existing Public IPs

Before activating the alert‑driven workflow, populate the cache with currently active Public IP resources.

Navigate to: CacheSeedingRunbook → Start and Run the job once.

This will initialise the PipLastKnownIps mapping with all existing Public IP resources. Future lifecycle events will update this cache dynamically.

Step 8: Create Activity Log Alert Rule

Navigate to: Azure Monitor → Alerts → Create Alert Rule
Scope the alert rule to the relevant Log Analytics Workspace.

Under Condition:

Select: Custom Log Search
Use the KQL query available here: query.json
Configure the following parameters as required:
- Evaluation Frequency
- Query Time Range

This alert rule will detect Public IP lifecycle events and trigger the associated Action Group for downstream runbook execution.

Please find the configuration in the attached screenshot below:

Step 9: Configure Action Group to Trigger Runbook

Create an Action Group that invokes the Lifecycle Runbook webhook.
Add a new action.
Configure the action with the following details:

Action Type: Webhook
Paste the previously generated Runbook Webhook URL

3.Enable:

Use Common Alert Schema

(Optional)
Add an Email Notification action to receive lifecycle alerts for troubleshooting or monitoring purposes.

4. Attach this Action Group to the alert rule.

Step 10: Validate the Implementation

To validate:

Create a Public IP resource.
Delete the same resource.
Navigate to: Automation Account → Jobs → MainLifecycleRunbook
Observe the runbook execution output related to:

Public IP creation
Public IP deletion

Although the delete alert contains only the Resource ID, the runbook retrieves the exact assigned Public IP address from the cache.

See the sample output below:

You can extend this workflow using Azure Logic Apps to forward events to Email , SIEM platforms or CMDB systems.

Conclusion

In addition to tracking Public IP deletions using Activity Logs, proactively capturing and persisting Resource ID–to–IP mappings through Automation‑driven lifecycle alerts, organisations can maintain an accurate Public IP inventory—ensuring traceability, reducing false‑positive security investigations, and strengthening audit and incident response readiness.

Microsoft Defender for Endpoint (MDE) — Custom Role Design for Troubleshooting Mode–Only Access

SantoshPargi — Mon, 13 Apr 2026 05:43:59 GMT

1) Introduction

In customer environments, Security Operations (SOC) teams and Windows infrastructure teams frequently need to investigate endpoint issues in the Microsoft Defender for Endpoint portal—often under time pressure—while still preserving strong governance over who can change security controls.

Because Troubleshooting Mode can enable temporary modification of Defender Antivirus settings even when devices are governed by organizational policies (for example, when policy protections are in place using Tamper protection settings), granting this capability broadly can introduce configuration drift, increase operational risk, and blur accountability.

To address this, customers typically require a least‑privilege, scoped access model that enforces Segregation of Duties (SoD):

Investigators (Security Reader) retain visibility and investigation capability but cannot create or modify MDE security policies.
Only an explicitly authorized group is granted the minimum permissions required to enable Troubleshooting Mode, and that access is restricted to a defined device scope using device groups—supporting both risk reduction and clear governance.

This approach ensures teams can perform required investigations and controlled troubleshooting while maintaining least privilege, SoD, and predictable operational impact across the customer’s environment.

This document describes an approach to providing controlled access to Troubleshooting Mode on a scoped set of devices.

- An Entra ID user group to collect eligible users

- A custom Defender XDR role with only the minimum required permissions

- Microsoft Defender for Endpoint device groups to scope where those permissions apply

The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.

2) Prerequisite & Coverage

- An Entra ID user group to collect eligible users

- A custom Defender XDR role with only the minimum required permissions

- Microsoft Defender for Endpoint device groups to scope where those permissions apply

The goal is to enable safe troubleshooting while maintaining least privilege and preventing unintended policy changes.

This setup is necessary to:

- Enforce least privilege (only the permissions needed for Troubleshooting Mode and limited operational actions)

- Scope powerful actions to a defined device group instead of all devices

- Support a split model where one Security Reader group gets Troubleshooting Mode access and another Security Reader group remains view/operate without TS Mode

- Preserve governance: users can investigate and perform limited actions but cannot create or modify MDE policies

- Improve auditability by ensuring key actions are observable via device telemetry and the Action Center (while acknowledging that some telemetry may not include the initiating username).

3) Implementation Steps for Troubleshooting Mode (TO BE PERFORMED IN MICROSOFT DEFENDER PORTAL / ENTRA ID)

3.1 Prepare Entra ID User Group

Identify an existing Entra ID user group that contains users (IT Infra Team) with the Security Reader role or create a new dedicated Entra ID user group for this purpose.

- This group will be used consistently for:

- Assigning the custom Defender XDR role

- Scoping access to Defender for Endpoint device groups

3.2 Create and Assign Custom Defender XDR Role

Create a custom Defender XDR role with Microsoft Defender for Endpoint (MDE) Security Settings Management permissions.

- While creating the custom role, select only the minimum required permissions to maintain a least-privilege model.

- Assign this custom Defender XDR role to the Entra ID user group identified in Step 1.

Reference: See screenshots below for role creation, permission selection, and Entra ID group assignment.

3.3: Assign Entra ID User Group to Device Group

Assign the same Entra ID user group (used in Steps 1 and 2) to a Microsoft Defender for Endpoint device group.

- Devices in the device group should be dynamically grouped using supported criteria such as:

- Device tags

- Device name patterns

- Other supported device attributes

- This scoping ensures that the custom role permissions apply only to the intended set of devices.

Reference: See screenshot under below showing device group creation and Entra ID group-to-device group assignment.

3.4 Resulting User Experience and Permissions

After completing Steps 3.1 through 3.3, users who sign in with:

- Security Reader role, and

- Custom Defender XDR role

will observe the following behavior in the Microsoft Defender portal:

- Troubleshooting Mode is available on the scoped devices

- Users cannot create or modify MDE policies

- Users have access only to a controlled set of operational and investigative actions, including:

- Exclude

- Go hunt

- Download force release from isolation script

- Ask Defender Experts

This configuration enables safe troubleshooting while preventing configuration drift or unauthorized security policy changes.

Reference: See screenshot under below illustrating the available actions and the absence of policy creation/modification options.

Reference: See screenshot below where creation of AV policy failed as User will not have access to Intune to create policy.

4. In an alternate scenario, two separate Security Reader groups are maintained: one group requires access to Troubleshooting Mode, while the other should have no Troubleshooting Mode access. Users in the latter group (no TS Mode requirement) can continue to use standard Microsoft Defender for Endpoint (MDE) operational capabilities such as managing tags, setting device criticality, running antivirus scans, collecting an investigation package, reporting device inaccuracy, initiating advanced hunting (Go hunt), triggering policy sync, and running automated investigations. Users in the Troubleshooting Mode-enabled Security Reader group must also be assigned to the appropriate MDE device group to ensure their device-level access and workflows continue to function as expected.

Reference: See the screenshot below, which illustrates the additional MDE capabilities available to users who also have access to the device group

5: Auditing and Event Visibility

- Events related to Tamper Protection changes and Troubleshooting Mode enablement are captured in Microsoft Defender for Endpoint telemetry.

- These events are logged and visible for audit and investigation purposes.

- The username is not recorded in these specific event entries, which is expected behavior in the current Defender auditing model. However, the activation of Troubleshooting Mode is still logged and visible in the device Action Center, which allows confirmation that the mode was enabled on the device and the username.

Reference: See screenshot under Step 6 showing the relevant audit and event records in Timeline of Device Page. Similarly ,correlate using KQL across two Event Tables (DeviceEvents & EntraIdSignInEvents).

Below is the KQL query

let TimeWindow = 10m;

let Lookback = 7d;

// Portal sign-ins (Security & Compliance Center)

let DefenderPortalSignins =

materialize(

EntraIdSignInEvents

| where Timestamp >= ago(Lookback)

| where Application == "Microsoft 365 Security and Compliance Center"

| project

SignInTime = Timestamp,

PortalUserUpn = AccountUpn,

PortalUserObjectId = AccountObjectId,

SignInIP = IPAddress,

CorrelationId

| extend TimeBucket = bin(SignInTime, TimeWindow)

);

// Tamper-protection related events (broaden as needed)

let TamperEvents =

materialize(

DeviceEvents

| where Timestamp >= ago(Lookback)

| where ActionType has "Tamper" or ActionType == "TamperingAttempt"

| project

TamperTime = Timestamp,

DeviceId,

DeviceName,

ActionType,

AdditionalFields

| extend TimeBucket = bin(TamperTime, TimeWindow)

);

// Output rows: (UPN, TamperTime) within +/- window

TamperEvents

| join kind=inner (DefenderPortalSignins) on TimeBucket

| where abs(datetime_diff("minute", TamperTime, SignInTime)) <= toint(TimeWindow / 1m)

| project

PortalUserUpn,

TamperTime,

SignInTime,

DeviceName,

DeviceId,

ActionType,

SignInIP,

CorrelationId,

AdditionalFields

| order by TamperTime desc

This query correlates by time proximity. It indicates “user signed into the portal around the time a tamper event happened.”
It does not prove that the portal user caused the tamper event (that requires audit telemetry for the action). If you later want attribution (“who enabled troubleshooting mode / changed settings”), we should pivot to Defender Action Center message and then confirm the user.
The query can be used for generating alert using custom detection rule and take this alert to Security Operations center using API integration.

Below is reference to the sample output of the query.

6) Summary

Option 3 enables a controlled Troubleshooting Mode experience by combining Entra ID group-based user assignment, a custom Defender XDR role with minimal permissions, and device group scoping in MDE.

With this approach, eligible users can troubleshoot only the intended devices and perform a limited, operationally safe set of actions, while policy creation/modification remains restricted.

Audit and investigation are supported through MDE telemetry and device Action Center visibility, with the known limitation that certain telemetry entries may not include the initiating username.

Customer Offerings: Azure Local - Implementation, Migration, and Management

BrandonWilson — Sun, 12 Apr 2026 19:55:01 GMT

Hi everyone!

Brandon here, back once again to talk to you about a couple of new offerings that have just been released to assist our Unified customers with their on-premises virtualization needs! I continue to have the privilege of leading a great program and team helping customers to migrate from VMware to more cost-effective and/or modern solutions. These new offerings are <drum roll>:

Hyper-V - Implementation, Migration, and Management
Azure Local - Implementation, Migration, and Management

NOTE: These offerings do not provide hands on keyboard support, do not create custom documentation for customers, and cannot provide direct support for any 3^rd party products that may be used in the process of migrations.

Many customers are reassessing their virtualization strategies and are actively exploring alternatives to VMware that align with long‑term hybrid cloud goals. Azure Local offers a purpose‑built platform that combines proven Windows Server–based virtualization with Azure services and management tooling, enabling customers to modernize on‑premises infrastructure while maintaining tight integration with Azure management, security, and governance capabilities.

Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you.

If you are a Unified customer and looking to move off of VMware to Azure Local, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me!

Planning to go at it alone??

Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up prior to our review will have configuration issues, at times warranting extensive efforts to correct.

Problem 1: There are some potentially significant differences between the way VMware and Azure Local are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Azure Local environment.

Problem 2: Your management method must also change. Additionally, if you are converting/migrating to Azure Local, the available methods need to be determined, the terminology and functional differences identified and learned…there can be a lot to unpack in this area.

Problem 3: Perhaps the most obvious is that this may be a new platform for your team, and its important for them to gain experience through guided actions and knowledge transfer on the fly for those questions they really have, which is exactly what we aim to provide in guiding implementations and migrations!

A Structured Engagement Model

Successful Azure Local implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help!

Key Phases of an Azure Local Implementation and/or Migration

Most Azure Local implementation and migration engagements progress through a common set of phases:

Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers)
Planning and design aligned to business and operational outcomes, with a limited scope
Deployment and configuration validation to ensure platform readiness
Security and migration testing to reduce risk and confirm workload compatibility
Feature enablement, including Azure Arc, to extend governance and management

While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives.

Key Outcomes for Customers

Organizations that engage in Azure Local implementation or migration efforts commonly achieve:

Deeper familiarity with Microsoft virtualization technologies
Successful deployment of PoC, pilot, or production environments
Validated test migrations of virtual machines
Identification and resolution of technical blockers
Increased confidence in operational readiness

These engagements are advisory and collaborative in nature, prioritizing customer enablement and success.

Knowledge Transfer and Operational Readiness

A central focus of the Azure Local engagements is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well.

Looking Beyond Migration

An Azure Local migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Azure Local becomes a platform for long‑term innovation and a step to modernizing your infrastructure, not just a replacement hypervisor.

Conclusion

Moving from VMware to Azure Local is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth.

Thanks for reading, and maybe we’ll talk soon!

Customer Offerings: Hyper-V - Implementation, Migration, and Management

BrandonWilson — Mon, 13 Apr 2026 02:50:50 GMT

Happy April everyone!

Hyper-V - Implementation, Migration, and Management
Azure Local - Implementation, Migration, and Management

Many customers are taking a closer look at Microsoft Hyper‑V as a strategic alternative to traditional virtualization platforms. Whether driven by changing licensing models, cost optimization, or the need for deeper hybrid cloud integration, a successful transition requires more than a technology shift—it requires a structured, outcome‑focused approach. While we are providing these new offerings to customers, you do also have the option of more extended engagements as well that are broader in scope and more tailored to the end goals while we work side by side with you.

If you are a Unified customer and looking to move off of VMware to Hyper-V, or you just need help with your on-premises Microsoft virtualization technologies in general, have your account manager (CSAM) reach out to me!

Planning to go at it alone??

I’m starting here for a very good reason… Virtually (no pun intended) every environment reviewed by my team (and that is a LOT) that was set up for a VMware migration, will have configuration issues, many times warranting a complete redesign and re-deployment.

Problem 1: There are some potentially significant differences between the way VMware and Hyper-V are architected from the start, especially in areas of networking and storage, where mimicking methods used in the VMware world can actually lead to performance degradation in your target Hyper-V environment.

Problem 2: To achieve feature parity, or near feature parity, your management method must also change. Additionally, if you are converting/migrating to Hyper-V, the available methods need to be determined, the terminology and functional differences identified and learned, well, honestly, I could go on for awhile on this, but I’ll spare you until we talk…

You mentioned management and conversion tools, what do you mean??

Hyper‑V has several methods for management, which can vary based on the feature needs and environment size. As a simple example, if I have 1500 virtualization hosts and 30,000 virtual machines spread out globally, its probably not going to be as efficient to manage everything only through locally available consoles. The capabilities of these management methods are continuing to grow and improve based on customer feedback, along with feedback from the field team. Let’s take a quick look at these options:

Native Windows tools: Hyper-V management console, Failover Clustering management console, Server Manager, etc
- This management method is typically used for small labs or smaller production environments (for migrations/conversions these methods do not provide feature parity with VMware).

System Center Virtual Machine Manager (SCVMM)
- This management method is fully supported for environments of all sizes. For migrations/conversions this method provides feature parity with VMware for management and features, along with offering VMware migration/conversion capability (offline). If you are already using any product from the System Center suite (SCCM, SCOM, SCORCH, SCSM, or DPM) then this can prove to be a great no cost option for you!

Windows Admin Center: Administration Mode (aMode)
- This management method is fully supported for environments of all sizes, however, is not designed as an infrastructure wide virtualization management method, but for server management and administration. If your environment isn’t extremely large, and VMware feature parity is not a necessity, this can provide a great no cost option for management of your physical and virtual servers. In addition, this method provides an online conversion option (currently public preview), allowing for a more seamless migration from VMware.

Windows Admin Center: Virtualization Mode (vMode) (currently public preview)
- This management method is fully supported for environments of all sizes, and is designed solely for the purpose of managing the Hyper-V virtualization infrastructure, tying together the primary needs for virtualization fabric into an easy to navigate web-based UI.

Azure
- You can Arc enable any Windows host or virtual machine and have a method of management and integration with cloud based services. In addition, these can work in conjunction with all of the above options to improve your management experience for your platform, and allows for the easy implementation and integration of many cloud based technologies (such as Hyper-V replica backups to ASR)

NOTE: You can learn more about Windows Admin Center evolution here: Windows Admin Center Architectural Changes | Microsoft Community Hub

A Structured Engagement Model

Successful Hyper‑V implementations are built around a guided engagement model rather than a one‑size‑fits‑all checklist. Each engagement is tailored to the customer environment, acknowledging that differences in scale, workloads, hardware, and operational maturity directly influence the migration approach. The framework emphasizes collaboration, clarity of expectations, and incremental progress instead of disruptive “lift‑and‑shift” execution. Whether we are talking about a migration from another virtualization platform, or simply trying to reduce costs by implementing a new virtualization infrastructure, we’re here to help!

Key Phases of a Hyper‑V Implementation and/or Migration

Most Hyper‑V engagements progress through a common set of phases:

Engagement scoping and technical discovery to understand goals and current state (this is the conversation I, or one of the TZ Leads in the VMware Migration Program have with customers)
Planning and design aligned to business and operational outcomes, with a limited scope
Deployment and configuration validation to ensure platform readiness
Security and migration testing to reduce risk and confirm workload compatibility
Optional feature enablement, including Azure Arc, to extend governance and management

While these phases provide structure, the sequence and depth of each stage are adapted based on the customer environment and objectives.

Key Outcomes for Customers

Organizations that engage in Hyper-V implementation or migration efforts commonly achieve:

Deeper familiarity with Microsoft virtualization technologies
Successful deployment of PoC, pilot, or production environments
Validated test migrations of virtual machines
Identification and resolution of technical blockers
Increased confidence in operational readiness

These engagements are advisory and collaborative in nature, prioritizing customer enablement and success.

Knowledge Transfer and Operational Readiness

A central focus of a Hyper‑V engagement is ensuring that IT teams are prepared to operate the platform long after deployment completes. Knowledge transfer is embedded throughout the engagement through working sessions and direct participation in implementation activities. This approach helps organizations move confidently into steady‑state operations without relying on long‑term external support. As I mentioned above, if you do feel you will need longer term support, we have your back on that front as well.

Looking Beyond Migration

A Hyper‑V migration is often the first step in a broader transformation journey. Many organizations use this transition to enable hybrid management, strengthen security posture, and prepare for future application or cloud modernization initiatives. When approached strategically, Hyper‑V becomes a platform for long‑term innovation, not just a replacement hypervisor.

Conclusion

Moving from VMware to Hyper‑V is not simply a technical migration—it is an opportunity to modernize how infrastructure is managed and governed. With structured planning, guided execution, and a focus on operational readiness, organizations can transition with confidence to a virtualization platform built for today’s hybrid cloud realities and tomorrow’s growth.

Thanks for reading, and maybe we’ll talk soon!

Auditing FIDO2 authentication for Windows Sign-in

LijuV — Thu, 09 Apr 2026 11:10:08 GMT

Hello everyone, my name is Liju and I am a Cloud Solutions Architect helping customers secure their cloud and hybrid identities. With this post, I would like to show how FIDO2 security key authentication for Windows sign‑in can be audited on client devices.

Recently, a customer of mine asked how they could:

Audit each use of a FIDO2 security key on a Windows client device
Track all PIN verification attempts on the security key, including both successful and unsuccessful attempts
Determine which user successfully authenticated to a Windows device using a FIDO2 security key

While standard Windows logon events such as 4624 and 4625 report the user and logon type, they do not indicate whether a FIDO2 security key was used. We can find this information in the Microsoft‑Windows‑WebAuthN/Operational event log, although interpreting these events requires additional decoding and correlation.

Entra ID
FIDO2 Security Key authentication in Windows
- Authentication flow (high-level)
- Mapping the steps to WebAuthN events
WebAuthN Events
Tying it all together

But first, let us see how Entra ID stores the information when a user registers a FIDO2 security ley as an authentication method.

Entra ID

For each user that has registered a FIDO2 security key, the keys are represented as a fido2AuthenticationMethod resource on the user object. The identifier for the key is stored with a Base64URL encoding.

In the example below the value is 7ebzDmVTSreLsJkrjm1mNA2

When a FIDO2 key is registered, an audit event is generated in Entra ID. The KeyIdentifier is stored using standard Base64 encoding.

In the example below the value is 7ebzDmVTSreLsJkrjm1mNA==

If diagnostic logging is enabled for Entra ID and if the AuditLogs are sent to a Log Analytics Workspace, this information can be queried using KQL.

AuditLogs | where Category == "UserManagement" | where OperationName == "Add Passkey (device-bound)" | extend UserUPN = tostring(TargetResources[0].userPrincipalName) | extend FIDOkeyId = tostring(TargetResources[0].displayName)

Top👆

FIDO2 Security Key authentication in Windows

When a user signs in with a FIDO2 security key, Windows is trying to answer one question:

Can this authenticator (security key) prove possession of the private key associated with a registered credential for this user?

This proof is provided in the form of a WebAuthN assertion, which is a cryptographic response generated by the authenticator.

Authentication flow (high-level)

Challenge generation
During FIDO2 authentication for a Microsoft Entra user, a challenge is generated by the relying party (for example, login.microsoft.com) and provided to the client (Windows).

Request construction
Windows initiates a WebAuthN GetAssertion request, which is encoded using CBOR (Concise Binary Object Representation), a compact binary format used by the FIDO2 protocol.
The request contains the clientDataHash which is a hashed JSON object containing the challenge sent by Entra (along with other parameters).

Authenticator processing
The request is sent to the authenticator using CTAP (Client to Authenticator Protocol).
The authenticator then locates a matching credential for the relying party, performs user verification if required (for example, PIN or biometric) and constructs the authenticatorData, which includes the hash of the relying party ID (rpIdHash)
The authenticator finally generates the assertion by signing (authenticatorData + clientDataHash) using the credential’s private key

Response processing
The authenticator returns the assertion (encoded in CBOR) to Windows.
Windows then decodes the CBOR response, extracts the assertion components (credential ID, authenticatorData, signature), evaluates the result and completes the WebAuthN operation.

Top👆

Mapping the steps to WebAuthN events

Before we take a look at the WebAuthN events on the Windows client, let us see how the logon process maps directly to the Event Log task categories.

Step	Details	Event entry
Challenge generation	Windows initiates authentication using a FIDO2 credential A TransactionId is created that ties all related events together.	WebAuthN Ctap GetAssertion started (Event ID 1003)
Request construction	Windows builds the CTAP2 request to send to the key Encoded in the request are the rpId and clientDataHash. For Entra ID, the rpId is login.microsoft.com	Cbor encode GetAssertion request (Event ID 1103)
Authenticator processing	Windows transitions from WebAuthN to the CTAP layer, and authenticator interaction begins	Ctap GetAssertion started (Event ID 2100)
Authenticator processing	Windows exchanges CTAP commands with the key This includes: PIN verification (authenticatorClientPIN / getPINToken) Authentication request (authenticatorGetAssertion)	Ctap Usb Send Receive (Event ID 2225)
Response processing	Authenticator returns result to Windows	Ctap GetAssertion completed (Event ID 2102 / 2103)
	Windows interpret the authenticator’s response	Cbor decode GetAssertion response (Event ID 1104)
	Windows completes WebAuthN operation	WebAuthN Ctap GetAssertion completed (Event ID 1004 / 1005)

Top👆

WebAuthN Events

Challenge generation

The WebAuthN Ctap GetAssertion started event (Event ID 1003) indicates that Windows has initiated a WebAuthN authentication operation and is beginning the process of requesting an assertion from an authenticator. This marks the start of the FIDO2 authentication flow but does not yet involve communication with the security key or indicate whether authentication will succeed.

Request construction

The Cbor encode GetAssertion request event (Event ID 1103) shows Windows encoding a targeted WebAuthN GetAssertion request.

When the Request begins with 0x02, it indicates that this is a authenticatorGetAssertion CTAP command.

Note that whether or not a credential ID is present in this event depends on the scenario. When AllowCredentialCount is greater than zero, the request includes one or more specific credential IDs (making it a “targeted” WebAuthN GetAssertion request). When it is zero, the authenticator is performing a credential discovery.

The description may be parsed to get the credential Id and will match the key identifier from Entra ID when Base64 encoded.

The Cbor encode GetAssertion request event (Event ID 1103) is generally the most useful event for auditing each authentication attempts of a FIDO2 security key on a Windows client device.

Top👆

How to parse the CBOR-encoded request

Let us take the Cbor Encode GetAssertion Request event (ID 1103) and parse the CBOR-encoded data in its description

TransactionId: {3443b0f7-a6a2-4b1c-9026-aea3ab93f662}
RpId: login.microsoft.com
ClientDataHashAlgId: S256
ClientDataLength: 176
ClientDataHash: 0x0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3
AllowCredentialCount: 1

Request: 0x02A401736C6F67696E2E6D6963726F736F66742E636F6D0258200E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF30381A262696450EDE6F30E65534AB78BB0992B8E6D663464747970656A7075626C69632D6B657905A1627570F5

The first byte gives us the CTAP command.
- In this case it is 0x02 which means authenticatorGetAssertion (Client to Authenticator Protocol (CTAP))
Everything after that first byte is the CBOR payload (A401736C6F67696E2E6D6963726F736F66742E636F6D0258200E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF30381A262696450EDE6F30E65534AB78BB0992B8E6D663464747970656A7075626C69632D6B657905A1627570F5).
- Note that The CBOR payload starts with A4. This means that the CBOR body is a map with 4 entries or named fields.
If you do not want to decode the bytes by hand, a simple way to inspect the payload is to paste it into an online CBOR decoder such as CBOR Playground. The site accepts hex input and can parse it into a readable CBOR structure.
Paste the CBOR payload into the input area. Make sure the input mode is Hex, then use Parse.

For this example, the decoded result is:

{
1: "login.microsoft.com",
2: h'0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3',
3: [
    {
      "id": h'EDE6F30E65534AB78BB0992B8E6D6634',
      "type": "public-key"
    }
],
5: {
    "up": true
}
}

This output is still using the CTAP numeric field keys (1-5), so the next step is to translate those numbers into the field names used by the GetAssertion request based on the table at Client to Authenticator Protocol (CTAP):
- 1 = rpId
- 2 = clientDataHash
- 3 = allowList
- 5 = options
So in plain English, the payload says:

{
"rpId": "login.microsoft.com",
"clientDataHash": "0E3A6FC2C6941563481563AFADF439276A2280A9F59E85197478BB748E625DF3",
"allowList": [
    {
      "id": "EDE6F30E65534AB78BB0992B8E6D6634",
      "type": "public-key"
    }
],
"options": {
    "up": true
}
}

For a bit more detail about each field:
- Key 1 contains the relying party ID
- Key 2 contains the 32-byte clientDataHash
- Key 3 contains an allowList array with one credential descriptor
- Key 5 contains an options map
- Inside options, up: true means user presence was requested

For details on how to decode the CBOR payload yourself see RFC 8949: Concise Binary Object Representation (CBOR)

Top👆

Translating Entra key identifier to WebAuthN Credential Id

The key identifier from Entra ID when Base64 decoded will match the CredentialId in the event.

A sample PowerShell function that does this is given below:

function Convert-Base64UrlToBytes { param( [Parameter(Mandatory=$true)] [string]$Base64Url ) # Convert Base64url to normal Base64 $b64 = $Base64Url.Replace('-', '+').Replace('_', '/') # Add padding if required switch ($b64.Length % 4) { 2 { $b64 += "==" } 3 { $b64 += "=" } 0 { } # already aligned 1 { throw "Invalid Base64url string length" } } # Decode Base64 → byte array return [Convert]::FromBase64String($b64) } cls # Conversion from Base64URL encoded identifier (user object) $bytes = Convert-Base64UrlToBytes "7ebzDmVTSreLsJkrjm1mNA2" ($bytes | ForEach-Object { $_.ToString("X2") }) -join "" # Conversion from Base64 encoded identifier (audit log) $bytes = Convert-Base64UrlToBytes "7ebzDmVTSreLsJkrjm1mNA==" ($bytes | ForEach-Object { $_.ToString("X2") }) -join ""

Top👆

Authenticator processing

The Ctap GetAssertion started event (Event ID 2100) shows Windows starting a CTAP GetAssertion operation against a specific FIDO2 key.

Authenticator PIN Validation

All PIN attempts generate a Ctap Usb Send Receive event (Event ID 2225) where the Request starts with 0x06A401010205

06 means this is a PIN-related command
If the request starts with 06A401010205 this denotes a getPinToken flag, meaning a PIN verification attempt.

If the Response starts 0x00, it indicates a Success.

Other possible values for the response field are:

0x31 - Incorrect PIN
0x33 - PIN Auth Invalid
0x34 - PIN Required

Therefore, Ctap Usb Send Receive events (Event ID 2225) where the Request starts with 0x06A401010205 will report all security key PIN attempts, both successful and unsuccessful, on the client device.

Top👆

How to parse the CBOR-encoded request

Let us try and parse the CBOR-encoded data in the event’s description once again.

TransactionId: {3443b0f7-a6a2-4b1c-9026-aea3ab93f662}
Request Command: 0x90
Response Command: 0x90

Request: 0x06A40101020503A5010203381820012158206F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C256541222582027E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA0650746BE172CD2402CFFCC94734BC98D16A

Response: 0x00A1025093B2EE5307CC81EA08684FEBE22D536D

The first byte in the request (0x06) gives us the authenticatorClientPIN CTAP command (Client to Authenticator Protocol (CTAP))
Everything after that first byte is the CBOR payload (A40101020503A5010203381820012158206F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C256541222582027E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA0650746BE172CD2402CFFCC94734BC98D16A).
- As before A4 means that the CBOR body is a map with 4 entries or named fields.
Parsing this payload using CBOR Playground we get:

{
1: 1,
2: 5,
3: {
    1: 2,
    3: -25,
    -1: h'6F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C2565412',
    -2: h'27E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA'
},
6: h'746BE172CD2402CFFCC94734BC98D16A'
}

Using the table at Client to Authenticator Protocol (CTAP) to translate the numeric keys we have:
- key 1 = pinUvAuthProtocol
- key 2 = subCommand
- key 3 = keyAgreement
- key 6 = pinHashEnc
After the translation, the payload says:

{

"pinUvAuthProtocol": 1,
"subCommand": 5,
"keyAgreement": {
    1: 2,
    3: -25,
    -1: h'6F67957900E6BBEC39838F015E3F5D6918F5A8D76E401828363E51F6C2565412',
    -2: h'27E8B11854CE667B8EE19DF3A3DEE4A3F0DB43809811C3A93F2E9C0293E466AA'
},
"pinHashEnc": h'746BE172CD2402CFFCC94734BC98D16A'
}

The information most useful for us here is "subCommand": 5, which as you can see from the second table in Client to Authenticator Protocol (CTAP) tells is a getPinToken subcommand.

In summary, when the request begins with 06 A4 01 01 02 05, it can be identified as a PIN verification attempt. The leading byte 0x06 indicates the CTAP authenticatorClientPIN command. The next byte A4 shows that the CBOR payload is a map with four fields. Within that map, the sequence 01 01 corresponds to pinUvAuthProtocol = 1, and 02 05 corresponds to subCommand = 5. In the Client PIN command set, subcommand 5 represents getPinToken, which is used during PIN verification. Together, this byte pattern reliably indicates that the operation is a PIN-based authentication step rather than a standard assertion request.

Turn on Annotate if you want the CBOR Playground site to show how each byte is interpreted.

Top👆

Authenticator GetAssertion operation

Ctap Usb Send Receive events (Event ID 2225) where the Request begins with 0x02 indicate an authenticatorGetAssertion CTAP2 Operation. The encoded payload includes the RpId and ClientDataHash.

If the Response begins with 0x00 it was successful. Included in the CBOR payload is the id (Credential ID) and the rpIdHash

Top👆

Response processing

The Ctap GetAssertion completed event (Event ID 2102) tells us that the authenticator successfully completed a GetAssertion operation and returned a valid signed assertion to Windows.

Included in the response payload are security key device information, status of the operation (6673746174757300 stands for status = 0), the credential used and authenticator data.

The Cbor decode GetAssertion response event (Event ID 1104) is logged when the authenticator successfully returns a WebAuthN assertion for the relying party using a particular credential.

This is one of the best events to track successful authentication because the important fields are already parsed out.

The RpIdHash of 356C9ED4A09321B9695F1EAF918203F1B55F689DA61FBC96184C157DDA680C81 is the SHA-256 hash of “login.microsoft.com”
A Flags value of 0x85 means 0x80 + 0x04 + 0x01
- 0x01: UP (the user was present and interacted with the key)
- 0x04: UV (user verification succeeded, which in this scenario means PIN was successfully validated)
- 0x80: ED (extension data was included in the assertion)
The CredentialId of EDE6F30E65534AB78BB0992B8E6D6634 when Base64 encoded, will match the key identifier in Entra.

Therefore, Cbor decode GetAssertion response events (Event ID 1104) will tell you which users successfully authenticated to the Windows device using a FIDO2 security key.

Finally, the WebAuthN Ctap GetAssertion completed event (Event ID 1004) tells us that WebAuthN GetAssertion operation completed successfully for this TransactionId.

Top👆

Tying it all together

I started out by outlining what my customer’s monitoring goals were; the table below summarizes the events recommended for monitoring:

What to Monitor	Event	Notes
Each use of a FIDO2 security key on a Windows client device.	Cbor encode GetAssertion request (Event ID 1103)	Filter for events where: Request begins with 0x02 AllowCredentialCount is greater than zero. Parse Request for credential Id. Base64 encode credential Id to match key identifier and user in Entra ID.
All attempts, both successful and unsuccessful, when a PIN was tried to unlock a credential on the FIDO2 security key on the device.	Ctap Usb Send Receive (Event ID 2225)	Filter for events where Request starts with 0x06A401010205. The Response property indicates result.
Which user successfully authenticated to the Windows device using their FIDO2 security key.	Cbor decode GetAssertion response (Event ID 1104)	Base64 encode credential Id to match key identifier and user in Entra ID.

The techniques outlined in this document show how to identify individual FIDO2 credentials, track PIN verification attempts, and conclusively determine which user authenticated to a Windows device using a security key. With this approach, passwordless authentication becomes not only more secure, but also more observable and supportable in enterprise environments.

Azure Database Security Newsletter - April 2026

PieterVanhove — Wed, 01 Apr 2026 08:08:13 GMT

Welcome to the quarterly edition of Azure Database Platform Security Newsletter. In this newsletter we highlight the importance of strong encryption for data security, and call out recent encryption, key management, and auditing enhancements designed to help you strengthen your security posture while simplifying operational management.

Data is one of the most critical assets organizations manage, and protecting it is essential to maintaining trust, resilience, and long‑term success. As cyber threats continue to evolve and regulatory expectations increase, strong encryption has become a foundational requirement rather than an optional safeguard.

Encryption protects sensitive data across its entire lifecycle. Data is encrypted at rest using Transparent Data Encryption (TDE) to protect stored information, in transit using Transport Layer Security (TLS) to secure data as it moves across your application and server, and in use through Always Encrypted to help ensure data remains protected even from high-privileged users. Together, these capabilities reduce risk and support compliance obligations.

Feature highlights 💡

Customer-Managed Keys in Fabric SQL Database

Customer-Managed Keys (CMK) are now generally available for Fabric SQL Database, allowing you to use Azure Key Vault keys to encrypt all workspace data, including all SQL Database data. This feature gives organizations greater control over key management and helps meet data governance and encryption requirements. More information on How to encrypt Fabric SQL Database with Customer Managed Keys (Video).

Versionless keys for Transparent Data Encryption in Azure SQL Database

Azure SQL Database now lets you use versionless key URIs for Transparent Data Encryption (TDE) with customer-managed keys, automatically applying the latest enabled key from Azure Key Vault or Managed HSM. This update simplifies encryption management.

Auditing in Fabric SQL Database

Auditing for Fabric SQL Database is now generally available. Organizations can track and log database activities, addressing questions about data access for compliance, threat detection, and forensic analysis. Audit logs are stored in One Lake, and access is controlled by Fabric workspace roles and SQL permissions.

Best Practices Corner

Retain all historical TDE keys and key versions

Always keep all historical Transparent Data Encryption (TDE) keys and their versions. Databases and backups remain encrypted with the key version that was active at the time of encryption. Restoring an older database requires access to the exact key version used. Deleting older keys or versions can make database restore impossible and result in permanent data loss. See Everything you need to know about TDE key management for database restore.

Apply the Principle of Least Privilege

Always grant users, applications, and services the minimum level of access required to perform their database tasks. Avoid broad administrative or owner-level permissions unless absolutely necessary. Regularly review, restrict, and remove excessive or unused privileges to reduce the attack surface and limit the impact of compromised credentials or configuration errors. This control aligns with established security standards such as NIST SP 800‑53 (AC‑6: Least Privilege), CIS Critical Security Controls, ISO/IEC 27002, and OWASP database security guidance.

Enable Auditing on Azure SQL and SQL Server

Always enable auditing on Azure SQL to record database activities for security monitoring, compliance, and forensic investigation. Auditing provides visibility into database access and changes, helping detect unauthorized or suspicious behavior and supporting incident response and regulatory requirements. See Auditing - Azure SQL Database.

Blogs and Video Spotlight 🅱️

In the last three months, we've published blog posts on major releases and features. These updates offer practical insights and highlight the latest in data security and database management.

Why ledger verification is non-negotiable

How to Enable Microsoft Entra ID for Azure Cosmos DB (NoSQL)

Why Developers and DBAs love SQL’s Dynamic Data Masking (Series-Part 1)

Announcing Preview of bulkadmin role support for SQL Server on Linux

Zero Trust for data: Make Microsoft Entra authentication for SQL your policy baseline

Community & Events 👥

The data platform security team will be on-site at several upcoming events. Come and say hi!

Previous events

SQL Konferenz

FABCON 26 - Microsoft Fabric Community Conference - FABCON

SQLCON - Microsoft SQL Community Conference - SQLCON

Upcoming events

SQLBits

DataGrillen

Call to action 📢

Take 15 minutes this week to validate your database encryption posture: confirm TDE is enabled, review your key management plan (including retaining historical key versions), and ensure TLS is enforced for all connections. If you are using Fabric SQL Database, consider enabling Customer-Managed Keys and turning on Auditing to strengthen governance and investigation readiness. Share this newsletter with your security and DBA partners and align on one concrete improvement you can complete.

Check This Out! (CTO!) Guide (March 2026)

TysonPaul — Mon, 30 Mar 2026 18:45:30 GMT

Member: TysonPaul | Microsoft Community Hub

Automating Large‑Scale Data Management with Azure Storage Actions

Team Blog: ITOps Talk

Author: 1Nataraj

Published: 02/25/2026

Summary: Azure Storage Actions is a fully managed, serverless automation platform that simplifies large-scale data management in Azure Blob and Data Lake Storage. It enables users to automate tasks such as tagging, tiering, deletion, and applying immutability based on customizable conditions—without custom code or infrastructure. Administrators can centrally define tasks and assign them across multiple storage accounts, with built-in preview, monitoring, and audit features. Use cases include compliance, cost optimization, and metadata management, making it ideal for organizations managing millions of items across vast storage estates. Azure Storage Actions is available in over 40 Azure regions.

Migration, Modernization & Agentic Tools

Team Blog: ITOps Talk

Author: OrinThomas

Published: 02/25/2026

Summary: The article discusses how agentic tools, such as those in Azure Copilot and GitHub Copilot, transform cloud migration and modernization from one-time projects into ongoing, autonomous systems. These tools dynamically discover environments, recommend modernization paths, automate migration steps, and continuously optimize workloads for cost, performance, security, and compliance. By embedding governance and leveraging real-time telemetry, agentic tools reduce manual effort, minimize errors, and ensure migrations are efficient, secure, and aligned with enterprise standards, providing continuous improvement post-migration.

What’s new in FinOps toolkit 13 – January 2026

Team Blog: FinOps

Author: Michael_Flanakin

Published: 02/09/2026

Summary: The January 2026 update to the FinOps toolkit focuses on stability, usability, and community engagement. Key enhancements include improved documentation, new features like configurable Key Vault purge protection, and expanded support for Parquet format and compression in Cost Management exports via PowerShell. Security, reliability, and extensibility have been strengthened for FinOps hubs, with numerous bug fixes across Power BI reports, workbooks, and the Azure Optimization Engine. The release highlights ongoing community involvement, upcoming features like AI automation, and premium services to help organizations deploy and scale the toolkit effectively.

Managed Identity on SQL Server On-Prem: The End of Stored Secrets

Team Blog: Core Infrastructure and Security

Author: RyadB

Published: 02/23/2026

Summary: **Summary:** The article explains how SQL Server 2025 on-premises, when connected to Azure Arc, can use Managed Identity to access Azure resources without storing secrets like SAS tokens or keys. This approach eliminates risks of secret storage, rotation, and auditing complexity by leveraging Microsoft Entra ID for identity management and RBAC for permissions. The article details configuration steps, migration from stored credentials, troubleshooting, and current limitations, highlighting improved security and simplified management for on-prem SQL Server accessing Azure services.

Running Text to Image and Text to Video with ComfyUI and Nvidia H100 GPU

Team Blog: Core Infrastructure and Security

Author: HoussemDellai

Published: 02/27/2026

Summary: This article provides a step-by-step guide for setting up and running ComfyUI, a node-based interface for AI-powered text-to-image and text-to-video generation, on Azure VMs with Nvidia H100 GPUs. It details both automated (Terraform) and manual setup methods, including installing drivers, dependencies, and downloading required models. The guide explains accessing ComfyUI’s web portal, workflow configuration, and model management to create high-quality images and videos efficiently. It also includes important notes about GPU driver compatibility and offers links to official documentation and scripts for further reference.

Unlock outbound traffic insights with Azure StandardV2 NAT Gateway flow logs

Team Blog: Azure Networking

Author: cozhang

Published: 02/06/2026

Summary: The article introduces Azure’s StandardV2 NAT Gateway, highlighting its new features such as zone-redundancy, enhanced performance, dual-stack support, and, notably, flow logs. Flow logs provide detailed visibility into outbound traffic, enabling security auditing, compliance, usage analytics, and troubleshooting. The article explains how to enable and use flow logs to diagnose connectivity issues and optimize network architecture. It emphasizes the importance of flow logs for monitoring established outbound connections and offers troubleshooting steps for connection drops, recommending best practices for resilient Azure deployments.

Centralized cluster performance metrics with ReFrame HPC and Azure Log Analytics

Team Blog: Azure High Performance Computing (HPC)

Author: jimpaine

Published: 02/06/2026

Summary: The article outlines how to integrate ReFrame HPC, a flexible high-performance computing testing framework, with Azure Log Analytics for centralized performance monitoring across diverse clusters and environments. It details deploying necessary Azure resources, configuring ReFrame for HTTP logging, and running performance tests with results sent to Log Analytics. This integration enables unified, standardized metrics collection, cross-cluster comparisons, trend analysis, and improved system visibility—supporting migration, development, and operational assurance in heterogeneous HPC environments.

Azure Recognized as an NVIDIA Cloud Exemplar, Setting the Bar for AI Performance in the Cloud

Team Blog: Azure High Performance Computing (HPC)

Author: Fernando_Aznar

Published: 02/18/2026

Summary: Microsoft Azure has been recognized as the first NVIDIA Exemplar Cloud for its world-class, end-to-end AI workload performance, now validated for both H100 and next-generation GB300 (Blackwell) systems. This designation reflects Azure’s optimized full-stack infrastructure—including compute, networking, and software integration—delivering predictable, efficient, and scalable AI training at production scale. Customers benefit from faster time-to-train, improved ROI, and confidence in Azure’s readiness for advanced AI workloads, ensuring consistent high performance from proof-of-concept to deployment without sacrificing cloud flexibility or manageability.

Reference Architecture for Highly Available Multi-Region Azure Kubernetes Service (AKS)

Team Blog: Azure Architecture

Author: rgarofalo

Published: 02/03/2026

Summary: The article presents a reference architecture for highly available, multi-region Azure Kubernetes Service (AKS) deployments. It compares active/active, active/passive, and deployment stamp models, detailing their trade-offs in availability, complexity, and cost. Key components include Azure Front Door for global traffic routing, geo-replicated data services, centralized monitoring, and consistent security controls. The architecture emphasizes resilience through fault isolation, automated recovery, and regular testing. It offers practical guidance for cloud architects to design AKS platforms that withstand regional outages, ensuring business continuity and scalable operations across Azure regions.

Reactive Incident Response with Azure SRE Agent: From Alert to Resolution in Minutes

Team Blog: Azure Architecture

Author: Sabyasachi-Samaddar

Published: 02/18/2026

Summary: **Summary:** The article details how Azure SRE Agent revolutionizes incident response by automating investigation and triage as soon as an alert fires, reducing resolution times from hours to minutes. Through two real-world scenarios—a SQL connectivity outage and a VM CPU spike—the agent autonomously diagnosed issues, proposed remediations, and required minimal human intervention. Custom Incident Response Plans and instructions enable context-aware, consistent, and rapid resolutions, with automated post-incident documentation. Key benefits include faster MTTR, reduced manual toil, and improved knowledge capture, though some technical challenges remain. Azure SRE Agent is currently in preview.

Cross Forest Enrollment – PKISync.PS1

Team Blog: Ask the Directory Services Team

Author: Manuel_Alvarez_V

Published: 02/19/2026

Summary: The article explains how to use the PKISync.ps1 PowerShell script for cross-forest certificate enrollment in Active Directory environments. PKISync synchronizes PKI-related objects, such as certificate templates and CA configurations, from a source forest to a target forest, enabling certificate requests across forests. It details the setup requirements, including two-way forest trusts, LDAP referral configuration, and certificate publishing. Although PKISync is considered legacy, automating its use can facilitate simple cross-forest enrollment, but CEP/CES is recommended for modern, secure deployments. The article concludes with best practices and automation tips for PKISync.

What’s New in Windows Group Policy Preferences Debug Logging

Team Blog: Ask the Directory Services Team

Author: TagoreN

Published: 02/27/2026

Summary: The article outlines a new feature in Windows 11 24H2 and 25H2 (from February 2026 preview updates) that allows administrators to enable Group Policy Preferences (GPP) debug logging directly through Local Group Policy, not just domain-based GPOs. This simplifies troubleshooting by allowing detailed logging on client devices without domain reliance. The article explains how to configure logging, manage trace file locations, and set necessary permissions. Overall, this update enhances flexibility and efficiency for IT professionals managing and debugging GPP issues on Windows client devices.

Public Preview: Restrict usage of user delegation SAS to an Entra ID identity

Team Blog: Azure Storage

Author: ellievail

Published: 02/26/2026

Summary: Microsoft has announced the public preview of user-bound user delegation SAS for Azure Storage, enhancing security by restricting SAS token usage to a specific Microsoft Entra ID identity. This feature extends user delegation SAS, requiring the end user to authenticate with Entra ID to access storage resources. It supports cross-tenant scenarios and incurs no additional cost beyond standard storage transactions. User-bound SAS is available via REST APIs, SDKs, PowerShell, and CLI for all GPv2 storage accounts in public regions, with detailed steps provided for setup and role assignment.

Azure Migrate: Now Supporting Premium SSD V2, Ultra and ZRS Disks as Targets

Team Blog: Azure Storage

Author: Lakshya_Jalan

Published: 02/18/2026

Summary: Azure Migrate now supports Premium SSD v2, Ultra Disk, and ZRS Disks as migration targets, with Premium SSD v2 and ZRS generally available and Ultra Disk in public preview. This update enhances assessment and migration by enabling tailored recommendations based on workload performance needs, offering greater flexibility, performance, and resiliency. Users can now migrate demanding, mission-critical workloads to Azure using these advanced disk options, benefiting from features like zonal redundancy and customizable performance. The enhancements streamline migrations and ensure optimal resource alignment, supporting petabytes of data already migrated during the preview phase.

Public Preview: Automatic zone balance for Virtual Machine Scale Sets

Team Blog: Azure Compute

Author: HilaryWang

Published: 02/17/2026

Summary: Azure has introduced the public preview of automatic zone balance for Virtual Machine Scale Sets, which automatically monitors and redistributes VM instances across availability zones to maintain optimal resiliency. This feature addresses imbalances that can occur over time, minimizing the impact of zone failures without manual intervention. The system uses health checks, respects instance protection policies, and ensures workload capacity during rebalancing. Automatic instance repair is also enabled by default. Users can join the preview by enabling the feature and meeting specific prerequisites. This capability reduces operational overhead while enhancing workload reliability and zone-level resilience.

Azure Automated Virtual Machine Recovery: Minimizing Downtime

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 02/04/2026

Summary: Azure Automated Virtual Machine Recovery is a built-in Azure feature that minimizes VM downtime through fast, intelligent, and automated recovery processes. Without requiring customer setup, it continuously monitors VM health, rapidly detects failures, diagnoses issues, and applies the optimal recovery action, all without customer intervention. Leveraging detailed recovery event annotations, it provides deep visibility into incident timelines and helps optimize recovery strategies. Over the past 18 months, this system has halved average VM downtime, strengthening business continuity, reducing financial impact, and reinforcing customer trust in Azure’s reliable cloud platform.

Support tip: Resolve device noncompliance with Mobile Threat Defense partner apps

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/02/2026

Summary: This article provides guidance for resolving device noncompliance issues when using Mobile Threat Defense (MTD) partner apps, like Microsoft Defender for Endpoint, with Microsoft Intune. It outlines troubleshooting steps for users to restore compliance—installing, activating, refreshing, or reinstalling the MTD app—and checking compliance status. It also details simplified remediation workflows for iOS/iPadOS and methods for resetting the MTD connection on Android if sign-out is blocked, helping users regain access to work or school resources and reducing support overhead.

How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/20/2026

Summary: Starting June 16, 2026, Intune will require HTTPS for Microsoft Connected Cache when delivering Win32 apps. To maintain caching benefits and reduce bandwidth, administrators must configure HTTPS on Connected Cache nodes using a CA-signed TLS certificate. The guide details generating a CSR on the node, signing and importing the certificate, and validating HTTPS on both Windows and Linux hosts. It also covers troubleshooting, maintenance, and renewal. Without HTTPS, devices will revert to using the CDN for Intune app downloads. Other content types remain unaffected. Early configuration ensures seamless transition and continued performance benefits.

The Copilot resource guide to share with your employees

Team Blog: FastTrack

Author: JulieHersum

Published: 02/19/2026

Summary: The article introduces the "Essential Copilot resource hubs for employees," a centralized guide designed to streamline Microsoft Copilot onboarding and support. It helps adoption leaders structure learning paths, IT admins share resources efficiently, and all employees access consistent guidance. The guide consolidates key Microsoft Copilot resources, making it easier for organizations to accelerate adoption and customize internal policies. Additional support is available through FastTrack and the Microsoft 365 Accelerator site, offering expert guidance, templates, and personalized assistance to boost Copilot deployment and change management efforts.

Copilot adoption: Move your org from pilot to production with this guide

Team Blog: FastTrack

Author: JulieHersum

Published: 02/19/2026

Summary: The article introduces a comprehensive guide for IT admins and Copilot adoption leads to streamline the rollout of Microsoft 365 Copilot. Organized around the adoption lifecycle (plan, build, operate), the guide highlights eight essential resource hubs, practical rollout steps, and audience-specific resources to ensure effective, governed adoption. It also promotes Microsoft FastTrack, which offers expert support, self-service resources, and personalized assistance to accelerate and scale Copilot deployment at no extra cost.

Azure Virtual Desktop is now available in US Gov Texas in Azure Government

Team Blog: Azure Virtual Desktop

Author: Ron_Coleman

Published: 02/04/2026

Summary: Azure Virtual Desktop is now available in the USGov Texas region of Azure Government, offering customers a new option for deploying secure and flexible virtual desktop environments. This expansion enables improved connection performance, reduced latency, and enhanced responsiveness by allowing host pool creation directly in the region. It supports mission needs, geographic distribution, and regulatory requirements, while maintaining Azure Government’s compliance and security standards. Customers can now leverage multiple regions for greater flexibility and performance in their virtual desktop deployments.

RDP Shortpath (UDP) over Private Link is now generally available

Team Blog: Azure Virtual Desktop

Author: Rinku_Dalwani

Published: 02/17/2026

Summary: Azure Virtual Desktop now supports UDP-based RDP Shortpath over Private Link, enabling direct, high-performance RDP connections between session hosts and clients using private IPs. This complements existing TCP connectivity, helping customers with strict private network boundaries. Administrators must explicitly enable UDP in Azure portal settings to use this feature. The opt-in model ensures secure and predictable transport, giving full control over UDP introduction. This enhancement is recommended for customers needing precise routing and policy enforcement in regulated environments, while standard AVD connectivity remains suitable for most deployments. Full configuration guidance is available in Azure documentation.

Migrating Workloads from AWS to Azure: A Structured Approach for Cloud Architects

Team Blog: Azure Migration and Modernization

Author: rhack

Published: 02/18/2026

Summary: The article outlines a structured, five-phase approach for migrating workloads from AWS to Azure, emphasizing a like-for-like architecture to minimize risk and maintain operational stability. Key phases include planning, preparation, execution, evaluation, and decommissioning, each requiring thorough documentation, stakeholder alignment, testing, and validation. The recommended migration strategy is blue/green deployment for risk mitigation. The workload team should lead the migration, supported by external Azure experts. Success depends on careful planning, phased execution, and post-migration optimization, with organizational knowledge-sharing encouraged for future improvements.

Modernizing for the AI Era: Accelerating Application Transformation with Agentic Tools

Team Blog: Azure Migration and Modernization

Author: MarcoB

Published: 02/12/2026

Summary: The article highlights the urgent need for organizations to modernize legacy applications to thrive in the AI era. Legacy systems drain resources and hinder innovation, but new agentic tools—such as GitHub Copilot, Azure Migrate, and Azure Copilot—use AI to automate and accelerate application transformation. These tools reduce manual effort, boost accuracy and safety, and make modernization accessible, empowering teams to focus on innovation. The result is faster, safer, and more consistent modernization, enabling organizations to continuously evolve their applications for intelligent, cloud-optimized environments. Practical steps and resources are provided to guide organizations in getting started.

Secure DNS with DoH: Public Preview for Windows DNS Server

Team Blog: Networking

Author: JorgeCañas

Published: 02/09/2026

Summary: Microsoft has launched a public preview of DNS over HTTPS (DoH) for Windows DNS Server, enabling encrypted and authenticated DNS queries within on-premises networks. This upgrade enhances security and privacy by preventing DNS traffic from being exposed or intercepted, aligning with Zero Trust principles and U.S. federal requirements. The DoH feature, included in the February 2026 update for Windows Server 2025, is disabled by default and currently intended for evaluation only. Existing DNS functionality remains unchanged, with new tools added for DoH management. Feedback is encouraged to improve the feature before general availability.

Announcing Public Preview: Simplified Machine Provisioning for Azure Local

Team Blog: Azure Arc

Author: PragyaDwivedi

Published: 02/26/2026

Summary: Microsoft has announced the Public Preview of Simplified Machine Provisioning for Azure Local, streamlining edge infrastructure deployment. The new process centralizes configuration in Azure, requiring minimal on-site expertise—staff only need to rack, power on hardware, and insert a prepared USB. Secure provisioning uses industry standards like FIDO Device Onboarding and Azure Arc Site for consistent, automated deployments across multiple locations. IT teams manage and monitor provisioning remotely, reducing errors and speeding up setup. Once complete, machines are ready for cluster creation and workload deployment, significantly simplifying and scaling Azure Local deployments.

Azure CLI Windows MSI Upgrade Issue: Root Cause, Mitigation, and Performance Improvements

Team Blog: Azure Tools

Author: Alex-wdy

Published: 02/03/2026

Summary: The article discusses a critical issue affecting Azure CLI upgrades on Windows using the MSI installer, where users upgrading from version 2.76.0 (or earlier) to 2.77.0 (or later) encountered startup crashes due to missing Python extension files. The root cause was a versioning conflict during upgrade, leading to incomplete installations. The article details recovery steps, recommends upgrading to version 2.83.0, and highlights improvements to the MSI upgrade process, making installations faster and more reliable by simplifying file replacement logic and eliminating slow version checks. Users are encouraged to upgrade and report issues if encountered.

Navigating the 2025 holiday season: Insights into Azure’s DDoS defense

Team Blog: Azure Network Security

Author: Jdasari

Published: 02/18/2026

Summary: During the 2025 holiday season, Azure observed a rise in burst-style DDoS attacks, with high-intensity, short-lived surges targeting packet processing and connection-handling layers. Most attacks were automated and brief, but the cumulative impact was operationally draining, especially for latency-sensitive sectors like gaming. Botnet-driven attacks rapidly shifted targets, exploiting inconsistent defenses. Azure DDoS Protection mitigated over 174,000 attacks, underscoring the need for always-on, automated, and layered security. Organizations are urged to standardize protections, proactively monitor, and adopt Zero Trust and multi-layered defense strategies to ensure resilience against evolving threats in 2026.

A Practical Guide to Azure DDoS Protection Cost Optimization

Team Blog: Azure Network Security

Author: SaleemBseeu

Published: 02/18/2026

Summary: The article provides strategies for optimizing Azure DDoS Protection costs. It explains the differences between DDoS Network Protection (best for large-scale, centralized management) and DDoS IP Protection (for few, specific endpoints). Key recommendations include consolidating protection plans to reduce base costs, selectively applying protection based on workload exposure, preventing unnecessary spend via regular reviews, and using cost management tools and tagging for visibility. The guide emphasizes aligning protection with actual risk and criticality, and offers scripts and checklists to support ongoing cost-efficient DDoS defense.

Implementing Intune RBAC and Scope Tags for Zero Trust and Least Privilege

ChrisVetter — Mon, 30 Mar 2026 12:48:45 GMT

If you’re rolling out Microsoft Intune at scale, the hardest part usually isn’t creating policies—it’s making sure the right people can manage the right things, without turning every admin account into a “keys to the kingdom” risk. In this guide, you’ll learn how to use Intune RBAC and Scope Tags to enforce least privilege, build clear management boundaries by region/agency/environment, and pair device compliance with Entra Conditional Access to strengthen a Zero Trust posture—plus a practical RACI approach so ownership stays clear as your environment grows.

TL;DR

Use Intune RBAC to align admin permissions to job responsibilities, reducing standing privilege and limiting who can change policies, apps, and security settings.
Use Scope Tags to create visibility/management boundaries (region, agency, environment) so admins only see and manage what they own.
Pair Intune compliance + Entra Conditional Access to enforce “access only from compliant devices / protected apps,” which supports a Zero Trust posture.
Establish a RACI model so ownership is explicit across Endpoint, Identity, Security, Apps, AD, Help Desk, and Compliance teams.
Track outcomes (compliance rates, blocked risky sign-ins, RBAC audit events, scope boundary effectiveness, GPO migration progress) and review on a regular cadence.

Zero Trust and Least Privilege in Modern Endpoint Management

Zero Trust is an approach to security that treats every access attempt as untrusted until it is proven otherwise. Rather than relying on “inside the network = safe,” organizations evaluate each request using signals such as user identity, device health, location, and risk, and they re-check those signals over time. In an endpoint program, Microsoft Intune supports this model by establishing device compliance, applying app protection where appropriate, and working with Conditional Access so that access decisions can depend on verified user and device posture.

A practical way to describe Zero Trust is through three recurring themes: (1) make access decisions using explicit verification (strong authentication plus context and risk signals), (2) minimize privilege by granting only the access needed and reducing standing admin rights where possible, and (3) design for compromise by limiting lateral movement and reducing the impact of any single breach. These concepts align with Microsoft’s published Zero Trust guidance.

Role-Based Access Control (RBAC) in Intune allows organizations to delegate administrative permissions based on roles, responsibilities, and scope. For modern endpoint environments, RBAC ensures that only authorized personnel can manage devices, deploy configurations, or access sensitive data, which is a foundational control in a Zero Trust model where access is granted based on least privilege and verified identity.

By combining Intune's RBAC capabilities with Scope Tags, organizations can create visibility boundaries that align with their organizational structure, whether by region, department, business unit, or function. This prevents over-allowing permissions by assigning only the rights needed for each role, supports Zero Trust by enforcing least privilege and role-based access, and improves operational security by limiting who can manage devices and policies.

Understanding Intune RBAC Roles and Permissions

Microsoft Intune provides nine built-in RBAC roles designed to address common administrative scenarios. Each role has predefined permissions that determine what actions users can perform within the Intune environment, helping organizations delegate administrative tasks while maintaining control over access to sensitive information. The built-in roles include Intune Administrator with full access to all Intune features and settings (This role should not be used for every day management tasks and should be limited to only a few individuals who would be responsible for performing more elevated tasks in the Intune Portal), Policy and Profile Manager who manages device configuration profiles and compliance policies, Application Manager who manages mobile and managed applications, Endpoint Security Manager who manages security and compliance features, Help Desk Operator who performs remote tasks on users and devices, Read-Only Operator with view-only access, School Administrator for Windows 10 devices in Intune for Education, Intune Role Administrator who manages custom roles and assignments, and Cloud PC roles for managing Cloud PC features and Windows Autopatch roles for managing updates.

Built-in Role	Primary Permissions	Use Case
Application Manager	Manages mobile and managed applications, app configuration policies, and app protection policies	Teams responsible for deploying and managing organizational apps across devices
Policy and Profile Manager	Manages device configuration profiles, compliance policies, and conditional access policies	IT administrators configuring device settings and ensuring compliance across the organization
Endpoint Security Manager	Manages security baselines, endpoint detection and response, and BitLocker policies	Security teams focused on device protection and threat mitigation
Help Desk Operator	Performs remote tasks including device restart, password reset, and remote lock	First-line support staff assisting end users with device issues
Read-Only Operator	View-only access to all Intune data and reports without modification rights	Auditors and stakeholders needing visibility without administrative capabilities

Beyond built-in roles, Intune supports custom roles that allow administrators to define specific permissions for users or groups based on their responsibilities. Custom roles enable fine-grained access control by selecting granular permissions for each role, ensuring users have access only to the features and data they require. For example, a custom role could grant only the 'Rotate local administrator password' permission to a specific Helpdesk Managers group, demonstrating the principle of least privilege in action.

Create Custom Roles

Login to the Intune Admin Portal with the Intune Administrator Role and navigate to Tenant Administration> Roles > All Roles > Create then select the type of role you want to create. I will select “Intune Role”

Give your Custom Role a Name and a brief description.

Scroll through the list of permissions as they will all be set to no by default and select the permissions relevant to the responsibility of the custom role.

If you have already created your Scope Tag add it here, then review and select create

Once the role is created you can select the new role and create an assignment. Give it a name and description, then select the admin group to be assigned to the role.

Add the groups that the role will be managing.

Add your relevant Scope Tags then select create.

To take things one step further I would recommend leveraging Privileged Identity Management (PIM) for groups so that you can leverage Just-in-Time Assignments for the Intune roles.

One last note on custom roles if you do not want to start from scratch with the permission sets, you can also duplicate a built-in role and modify the permissions as needed. Just select the 3 dots to the right of the role and select Duplicate

Implementing Scope Tags for Distributed IT Management

Scope Tags are labels that help control what different admins can see and manage in Microsoft Intune. By adding scope tags to Intune items like configuration profiles, apps, policies, or device groups and assigning the same labels to admins, organizations create clear boundaries, so each admin only sees the devices and settings they are responsible for. This capability is essential for distributed IT environments where different teams manage different locations, departments, or business units.

Every Intune tenant includes a default scope tag that is automatically applied to all objects and admins, ensuring everything continues working smoothly even without custom tags configured. The key benefits of using scope tags include enabling distributed IT management by allowing regional or departmental admins to manage their specific resources, controlling access by limiting admin visibility to specific resources, enhancing security by preventing unauthorized access, improving organization by grouping resources by scope, and providing flexibility to support multiple administrative models.

Scope tags work together with RBAC role assignments through three components: the role defining what actions admins can perform, scope tags determining which objects admins can see, and scope groups limiting which users and devices they can affect. Common use cases for scope tags include managed service providers limiting access to specific customer resources, regional IT administrators ensuring teams only manage and see objects relevant to their region, separating testing versus production environments when a dedicated test tenant is not available, and separating Azure Virtual Desktop resources for AVD administrators.

Creating Scope Tags

While still under Tenant Administration> Roles select Scope Tags Then Create.

Give it a name and description.

Assign the proper groups then select create.

If this is all implemented properly, the admin will only be able to see items and devices that have the Scope tag that has been assigned to their role. Here are views of the apps in my tenant when signed in as a Intune Administrator (which Scope tags do not apply t

And here are the same views when logged in with an admin with the iOS admin role that we created.

Establishing a RACI Model for Intune Management

While establishing a RACI model is not something done in the Intune portal, it is crucial in my opinion for enterprise customers since Intune covers such a vast number of capabilities that should not all be done by one team if we are practicing least privilege and zero trust.

A RACI matrix is a powerful tool for defining organizational roles and responsibilities, identifying who is Responsible, Accountable, Consulted, and Informed for each activity. In Microsoft Intune management, implementing a RACI model eliminates ambiguity about which teams handle security policies, application management, patch compliance, Conditional Access, and GPO migration.

The RACI framework defines four key roles: Responsible individuals execute the task or deliverable, Accountable is the single person ultimately answerable for correct completion and decision-making authority, Consulted are experts or stakeholders whose feedback is sought during the task, and Informed are those kept up to date on progress or decisions without actively contributing.

For Intune environments, a well-designed RACI matrix promotes organizational alignment by mapping all key stakeholders across central IT and individual agencies or departments, clarifies decision rights by defining who approves, who executes, and who provides input for each Intune activity, ensures accountability by assigning a single accountable party for each deliverable to prevent diffusion of responsibility, and improves communication by identifying upfront who needs to be consulted and kept informed.

Based on internal implementation experience and with Microsoft Federal customers, organizations should list deliverables not just activities, define roles not individual names to ensure the matrix remains relevant as people change positions, enforce exactly one Accountable person per task, assign Responsible, Consulted, and Informed roles thoughtfully, validate in a short review session, publish where work happens, and evolve the matrix as the project evolves.

RACI Matrix for Security Policies and Compliance

The following are just generic examples of some of the workloads and how they could be managed with a RACI matrix.

Security policies and compliance management in Intune require clear ownership across multiple teams. Organizations must define who creates compliance policies requiring device encryption and minimum OS versions, who deploy security baselines like the Microsoft Defender for Endpoint Security Baseline, who manages Conditional Access policies that require device compliance, and who responds to non-compliant devices. A typical RACI model for security policies assigns the Cloud Security Team as Accountable for overall security policy strategy and compliance requirements, the Endpoint Team as Responsible for creating and deploying compliance policies and security baselines in Intune, the Application Team as Consulted for application-specific security requirements, the Help Desk as Informed about policy changes that may affect device compliance status, and the Compliance Team as Consulted to ensure policies meet regulatory requirements and as Informed about compliance status reports.

For patch management and application compliance, the RACI model shifts slightly with the Endpoint Team becoming Accountable for patch deployment strategy and timing, the Application Team becoming Responsible for testing application compatibility with updates, the Help Desk becoming Responsible for addressing user-reported issues after patches, and the Cloud Security Team becoming Consulted for security update prioritization. Organizations implementing Windows Autopatch benefit from Microsoft managing problematic quality and feature update deployment cancellations using telemetry, automatically splitting devices into rings based on percentage of total devices, and managing patching behavior for Windows, Microsoft 365 Apps, Edge, Teams, and Drivers. This shifts some Accountable and Responsible designations to Microsoft while keeping internal teams Informed and Consulted.

Intune Activity	Accountable	Responsible	Consulted	Informed
Security Policy Creation	Cloud Security Team	Endpoint Team	Application Team, Compliance Team	Help Desk
Compliance Policy Deployment	Cloud Security Team	Endpoint Team	Compliance Team	Help Desk, Application Team
Security Baseline Management	Cloud Security Team	Endpoint Team	Application Team	Help Desk, Compliance Team
Patch Management Strategy	Endpoint Team	Application Team	Cloud Security Team	Help Desk, Compliance Team
Non-Compliance Response	Cloud Security Team	Endpoint Team, Help Desk	Compliance Team	Application Team

Application and Conditional Access Management Responsibilities

Application management and Conditional Access in Intune span multiple organizational functions requiring coordinated responsibility. For application lifecycle management, the Application Team is both Accountable and Responsible for deployment strategy, app protection policies, creating and testing app packages and configurations. The Endpoint Team is Consulted for deployment targeting and device compatibility, while the Help Desk is Informed about new applications and support procedures.

For Conditional Access policy management, multiple teams coordinate their expertise. The Cloud Security Team is Accountable for overall Conditional Access strategy and Zero Trust implementation. The Endpoint Team is Responsible for ensuring device compliance status feeds correctly into Conditional Access decisions. The Identity Team is Responsible for configuring Conditional Access policies in Microsoft Entra ID. The Application Team is Consulted about application-specific access requirements, and the Help Desk is both Informed about access restrictions and Responsible for assisting users blocked by Conditional Access policies.

Conditional Access integration with Intune creates a powerful Zero Trust security model where Intune evaluates device compliance based on compliance policies, compliance status is reported to Microsoft Entra ID, Conditional Access policies check device compliance status, and access is granted or blocked based on compliance status.

For mobile application management, the Application Team is both Accountable and Responsible for app protection policies including data protection settings, access requirements like PIN and biometric authentication, and integration with Conditional Access. The Cloud Security Team is Consulted for security requirements, and the Endpoint Team is Informed about app-level controls that complement device-level policies.

GPO Migration to Intune: Roles and Responsibilities

Migrating Group Policy Objects from on-premises Active Directory to Microsoft Intune represents a critical transformation requiring clear ownership and phased execution. The migration process uses Group Policy Analytics, a built-in tool in Intune that analyzes on-premises GPOs by importing them as XML exports and translating them against the Settings Catalog to determine which policies are supported, deprecated, or unsupported in Intune.

Organizations export GPOs from the Group Policy Management Console by right clicking the GPO, selecting Save Report, and saving as XML format. After importing to Intune via Devices > Group Policy Analytics, the tool generates a percentage-based report showing exactly how many settings have a direct 1:1 mapping to modern Intune settings.

The Group Policy Analytics tool categorizes settings into three distinct types: Supported settings that have a direct counterpart in Intune and can be migrated via Settings Catalog policies, Deprecated settings no longer applicable to modern Windows versions, and Not Supported settings that do not currently have a CSP mapping and often require alternative management methods like PowerShell scripts or Proactive Remediations. Approximately 45% of GPOs can be successfully migrated to Settings Catalog, 30% require alternative approaches via PowerShell remediations, and 25% can be deprecated and retired based on typical migration outcomes.

RACI Model for GPO Migration

For the RACI model, the Endpoint Team is Accountable for the overall GPO migration strategy and timeline, the Active Directory Team is Responsible for exporting GPOs and documenting current policy structures, the Application Team is Consulted to validate that application-specific GPOs migrate correctly and that applications continue functioning, the Cloud Security Team is Consulted to ensure migrated policies maintain security posture, and the Help Desk is Informed about changes to device configurations and becomes Responsible for user communication about policy transitions.

Integrating Conditional Access with Device Compliance

Conditional Access integration with Intune device compliance creates an additional layer of security by enforcing access controls based on device compliance status and app protection policies. This integration ensures that only compliant devices and protected apps can access organizational resources, forming a cornerstone of Zero Trust architecture.

Device-Based Conditional Access Implementation

Device-based Conditional Access uses device compliance status from Intune to control access to organizational resources through a four-step process:

Intune evaluates device compliance based on compliance policies
Compliance status is reported to Microsoft Entra ID
Conditional Access policies check device compliance status
Access is granted or blocked based on compliance status

To implement device compliance Conditional Access, organizations first create and assign device compliance policies in Intune requiring elements like BitLocker encryption, Microsoft Defender antivirus enabled, Windows Firewall enabled, and minimum OS version requirements. Then in the Microsoft Entra Admin Center under Security > Conditional Access, administrators create policies specifying:

Users as target groups like Corporate Users
Cloud apps as All cloud apps or selected Microsoft 365 apps
Device platform as Windows or other platforms
Access control requiring device to be marked as compliant

Measuring Success and Continuous Improvement

Organizations implementing Intune RBAC and Scope Tags should establish metrics to measure success and identify areas for continuous improvement. Key performance indicators include percentage of devices compliant with security policies, time to resolve non-compliance issues, number of unauthorized access attempts blocked by Conditional Access, percentage of GPOs successfully migrated to Intune Settings Catalog, and administrative efficiency measured by reduction in time spent on routine management tasks.

Compliance reporting in Intune provides visibility into device compliance status across the organization, with reports showing compliant versus non-compliant devices, specific compliance policy violations, and trends over time. Organizations typically see compliance rates improve from a 65% baseline to 95% or higher within 12 months of implementing proper RBAC roles and Scope Tags. This improvement results from clearer ownership, faster policy deployment, and more focused administrative oversight.

Conditional Access sign-in logs in Microsoft Entra ID reveal which access attempts are granted or blocked, the reasons for access decisions, and patterns of risky sign-ins that may indicate compromised credentials or devices. For RBAC effectiveness, organizations should monitor audit logs to track which administrators are performing which actions, identify any privilege escalation attempts or suspicious administrative activity, and ensure separation of duties is maintained.

Scope tag effectiveness can be measured by confirming that administrators only see resources within their designated scope, tracking incidents where admins requested access outside their scope, and validating that regional or departmental segregation is working as intended. Organizations should establish a regular review cadence with monthly compliance and security posture reviews, quarterly RBAC and Scope Tag access reviews, bi-annual GPO migration progress assessments, and annual Zero Trust maturity assessments.

Disclaimer

All screenshots are from a non-production lab environment and can/will vary per environment. All processes and directions are of my own opinion and not of Microsoft and are from my years of experience with the Intune product in multiple customer environments

References

Role-based access control (RBAC) with Microsoft Intune - Microsoft Intune | Microsoft Learn

Use role-based access control (RBAC) and scope tags for distributed IT - Microsoft Intune | Microsoft Learn

Aligning responsibilities across teams - Cloud Adoption Framework | Microsoft Learn

How to Require Device Compliance with Conditional Access - Microsoft Entra ID | Microsoft Learn

Configuring Microsoft Intune just-in-time admin access with Azure AD PIM for Groups | Microsoft Community Hub

What Changed in RC4 with the January 2026 Windows Update and Why it is Important

Elanor92 — Sun, 19 Apr 2026 14:11:51 GMT

In case you haven’t heard, RC4 is not secure and has been deprecated. In this article, I will discuss what changed with the January 2026 Windows Update and why it is important to start auditing and remediate RC4 usage is your environment.

Starting with the January 13, 2026, Windows security updates, Microsoft began the first official phase of hardening Kerberos authentication by reducing reliance on RC4 encryption. The RC4 change will mainly impact service accounts and accounts that have the attribute msDS-SupportedEncryptionTypes left blank.

Why Microsoft Is Targeting RC4

RC4 is considered insecure due to cryptographic flaws that produce biased, non-random output, allowing attackers to recover encrypted data.

Despite this, RC4 remains enabled by default in many Active Directory environments for backward compatibility.

Microsoft tied the January changes to a Kerberos information disclosure vulnerability tracked as CVE-2026-20833, using this security update as the entry point to begin the RC4 deprecation process.

Update Timeline: From Audit to Full Enforcement

Microsoft is rolling out the Kerberos RC4 hardening in well-defined phases throughout 2026, giving organizations time to identify dependencies and remediate them before enforcement becomes mandatory. Understanding this timeline is critical to avoid outages.

Phase 1 – Initial Deployment (January 2026)

Starting on January 13, 2026, Windows security updates introduce the initial deployment phase.
This stage is focused on monitoring, not enforcement.

Key points of this phase:

New Kerberos audit events are logged on Domain Controllers (we will analyze them later in this article)
A temporary registry control setting (RC4DefaultDisablementPhase) has been introduced, allowing organizations to optionally enable stricter behavior ahead of time. Mind that this registry key is not created by default, you'll need to create it and set it to 1 to have the new
No default behavior changes are applied

Phase 2 – Enforcement Enabled by Default (April 2026)

Beginning with the April 2026 Windows security update, Microsoft moves to the second deployment phase, where behavior changes start to matter operationally.

During this phase:

Enforcement mode is enabled by default on all supported Windows Domain Controllers, the default value for DefaultDomainSupportedEncTypes is set to allow AES-SHA1 only: 0x18

This changes the Kerberos KDC default behavior for accounts without an explicit msDS-SupportedEncryptionTypes configuration to allow RC4. RC4 is no longer negotiated implicitly for accounts with a blank msDS-SupportedEncryptionTypes, they will only receive AES encrypted tickets

While it is still technically possible to revert to audit behavior temporarily (by changing the value of the registry key mentioned above), it will be important to arrive in this phase with the remediation already completed.

Phase 3 – Full Enforcement (July 2026)

The final phase begins with the July 2026 security updates and represents the end of the transition period.

At this point:

Audit‑only mode is removed
The temporary RC4DefaultDisablementPhase registry value is no longer read
the default value for DefaultDomainSupportedEncTypes is set to AES-SHA1 only (0x18)
With this configuration, Kerberos will issue RC4 tickets only if explicitly configured per account using the attribute “msDS-SupportedEncryptionTypes ”

Organizations that didn’t address RC4 usage earlier will experience persistent service outages for legacy systems and applications not compatible with AES encryption.

How to prepare for the changes

It’s tempting to ignore the January changes because “nothing is broken,” but that would be a mistake. The new audit events are here to help you prepare for the changes.

Let’s analyze how we can leverage audit data to be ready before April 2026

Audit events

After the January Windows security update, some new events will start to appear in the system event log of supported domain controllers if:

Your domain controller is receiving Kerberos service ticket requests that require RC4 cipher to be used but the service account has default encryption configuration
you have created the registry key RC4DefaultDisablementPhase and set it to 1
Your domain controller has an explicit DefaultDomainSupportedEncTypes configuration to allow RC4 encryption

To understand if your environment will be impacted by the change, you’ll need to audit the events 201,202,205,206,207 from the system event log. The events 203,204,208 and 209 will be logged starting from phase 2. See this Microsoft article for more details about the events.

These events are designed to help you identify accounts or services still requesting RC4encrypted tickets and clients or applications that do not support AES. This gives administrators a safe discovery phase to identify dependencies before anything stops working.

Identify High Risk Dependencies

Not all RC4 usage has the same impact. The audit events allow administrators to prioritize remediation by identifying:

Service or computer accounts that rely on RC4 due to missing or outdated encryption keys, such as accounts that have not had password reset in years
Legacy applications or appliances that cannot negotiate AES

Service accounts deserve special attention because they are commonly affected by RC4 dependencies and are high value targets in Kerberoasting scenarios.

Validate Kerberos Encryption Configuration

One of the most important insights provided by the new events is whether accounts are missing AES‑compatible Kerberos keys (msDS-SupportedEncryptionTypes).

In many cases, RC4 usage is not intentional but happens because the account password has never been reset since AES support was introduced or because the encryption types are implicitly inherited rather than explicitly defined.

The audit data allows you to confirm which accounts already support AES and which ones will fail once AESonly behavior becomes the default.

Main Scenarios

Let me list the common scenarios you can find during the auditing phase:

RC4/RC4

This is most critical scenario, where both the session and the ticket are encrypted in RC4. The event associated with this scenario are the 201 and 202. The most possible causes are:

The account password was never reset, and can request only RC4 keys
the client advertises only RC4
the msDS-SupportedEncryptionTypes attribute is not defined

Actions:

Identify the AD object involved
identify the keys available for the account (I recommend the usage of the script List-AccountKeys.ps1, details available here: Detect and Remediate RC4 Usage in Kerberos | Microsoft Learn)
If there no AES keys available, reset the password of the account and check again after a while
change the value of the msDS-SupportedEncryptionTypes attribute. You can decide to change it to AES either for testing or because you saw this account is indeed compatible with AES after a password reset or a remediation. The useful value for this attribute in this scenario are:
- 24 (0x18): The account will only support AES128 and AES256 encryption
- 56 (0x38): some account may need also the enforcement of the AES session key to abandon the use of RC4 encryption, depending on the application.
- 28 (0x1C): this value is used to do a rollback for the account. With this value the account will support both RC4 and AES encryption. Note that this is not a recommended action since it will expose the account by the use of a weak encryption algorithm.

AES/RC4

in this scenario the ticket is encrypted using AES, while the session still uses RC4. The event usually associated with this scenario is the 206.

In this scenario the service may indicates that the client is not advertising for AES encryption.

Actions:

Investigate the client checking if it's compatible with AES and what the client is advertising
Check if there are legacy GPO that enforce RC4 usage for this account
For Linux clients or third‑party applications, review krb5.conf, keytabs, and Kerberos libraries

RC4/AES

this indicates that RC4 is enforced on the KDC side.

actions:

check the value for the registry key DefaultDomainSupportedEncTypes to ensure that RC4 is not enforced on the DC
check the value for the attribute msDS-SupportedEncryptionTypes to ensure that RC4 is not enforced at the account level

Establish a Remediation Baseline Before April

By the time the April 2026 enforcement phase begins, you should already have:

Reviewed Kerberos audit events across all domain controllers
Identified all RC4-dependent accounts and services
Confirmed AES compatibility where possible
Documented any unavoidable legacy dependencies

The January audit data is meant to drive these actions early, while remediation can still be planned and tested calmly.

Why the January Update Matters (Even If Nothing Breaks Yet)

Since the creation of AES-SHA1 tickets has been implemented in Windows Server 2008R2, I’m confident that many organizations won’t have issues with this transition and can use these phases to validate their configurations.

If you didn’t have the chance or the time to address the RC4 usage earlier, don’t give into the temptation to ignore the January changes, because that would be unwise. The audit events that have been introduced are your only early warning system to avoid Kerberos authentication failures, problems with legacy applications, and service accounts failing due to missing AES keys.

In practice, the January update is the last safe window to:

Identify RC4‑only accounts
Detect non-AES-capable clients
Fix misconfigured Kerberos encryption settings on your terms

Organizations that use this phase to audit, remediate, and modernize will transition smoothly.
Those who ignore it risk discovering RC4 dependencies only when enforcement is already active.

Remove Unnecessary Azure Storage Account Dependencies in VM Diagnostics

hspinto — Mon, 16 Mar 2026 07:00:00 GMT

In a recent engagement with a customer willing to decrease Shared Access Signature (SAS) tokens usage in their Storage Accounts, we found out that a good amount of SAS token-based requests was associated with VM diagnostics. One practical way to reduce SAS token usage is to eliminate dependencies that require Storage Accounts in the first place, especially when Azure offers managed alternatives.

This post focuses on two VM-level features that often introduce (or preserve) unnecessary Storage Account coupling:

The legacy IaaS Diagnostics extension (retiring), which can write diagnostic data to Storage
Boot diagnostics configured to use a customer-managed Storage Account, considering Microsoft-managed boot diagnostics works as well without any operational effort.

1) Retire the legacy IaaS Diagnostics extension

If you’re no longer using the legacy IaaS Diagnostics extension for VM monitoring and troubleshooting, removing it is an easy win: it reduces Storage Account coupling and helps you stay ahead of platform deprecations. Microsoft has announced retirement of the extension as of March 31, so now is a good time to inventory and remove it where it’s still present.

How to find affected VMs

Use Azure Resource Graph (ARG) to identify virtual machines with the extension installed across subscriptions at scale. Once you have the list, you can remove the extension directly from the Azure portal or using your preferred automation approach (PowerShell or Azure CLI).

For a proven at-scale removal pattern (including cleanup of the data the extension produced), see How to remove at scale the Azure Diagnostics Extension and its storage data.

2) Switch boot diagnostics to Microsoft-managed storage

Boot diagnostics are invaluable when you need VM boot screenshots/logs and serial console access. Historically, it required a customer-managed Storage Account—often leading teams to create “diagnostics” Storage Accounts, wire up access, and sometimes rely on SAS tokens to make the integration work across tooling.

Today, you can enable boot diagnostics without providing a Storage Account by using managed boot diagnostics (Microsoft-managed storage). In most scenarios, this removes an entire class of dependency without sacrificing functionality. The switch is also operationally friendly: it does not require a VM reboot and doesn’t interfere with the guest OS.

How to find and migrate at scale

As with extensions, Azure Resource Graph is a good starting point to identify VMs that have boot diagnostics enabled against a customer-managed Storage Account. Use the query below to identify those VMs:

resources | where type =~ 'microsoft.compute/virtualmachines' | extend diagProfile = properties.diagnosticsProfile.bootDiagnostics | extend powerState = tostring(properties.extended.instanceView.powerState.code) | extend diagAccount = tostring(split(parse_url(tostring(properties.diagnosticsProfile.bootDiagnostics.storageUri)).Host,'.')[0]) | extend bootDiagnosticsEnabled = tobool(properties.diagnosticsProfile.bootDiagnostics.enabled) | project name, resourceGroup, subscriptionId, powerState, bootDiagnosticsEnabled, diagAccount | where bootDiagnosticsEnabled and isnotempty(diagAccount)

After you’ve validated the impact in a non-production subscription, you can automate migration in bulk to enable managed boot diagnostics, by using the Set-AzVMBootDiagnosticsWrapper.ps1 script. Simply download it, unblock it (file properties > unblock), and upload it to Azure Cloud Shell.

Example PowerShell usage pattern:

./Set-AzVMBootDiagnosticsWrapper.ps1 -Action EnableManaged [-TargetSubscriptionId <sub id>] [-ARGFilter <ARG condition, e.g., resourceGroup =~ 'xyz'>] [-Simulate]

Wrap-up

Reducing SAS token usage isn’t only about replacing tokens with another credential type —it’s also about removing the underlying dependencies that make tokens attractive in the first place. By (1) removing the retiring IaaS Diagnostics extension and (2) migrating boot diagnostics to Microsoft-managed storage, you can simplify your VM baseline, reduce Storage Account sprawl, and stay ahead of deprecations. As a next step, consider standardizing these checks in your provisioning pipelines (Bicep/Terraform), and add periodic ARG-based hygiene queries to keep drift under control.

Bulk enable Azure Arc Connected Machine Agent Automatic Upgrade (Tag Scoped) with Azure Cloud Shell

absharan — Thu, 12 Mar 2026 20:38:28 GMT

Overview

Keeping the Azure Arc Connected Machine agent current is a foundational hygiene task for any hybrid server estate, especially when you’re operating at scale and onboarding hundreds (or thousands) of machines into Arc.

The good news: Azure Arc supports an automatic agent upgrade (preview) capability that can be enabled per Arc machine by setting the agentUpgrade.enableAutomaticUpgrade property via Azure Resource Manager (ARM). Microsoft’s public guidance shows enabling this using a PATCH call (via Invoke-AzRestMethod) against the Arc machine resource with the 2024-05-20-preview API version. Manage and maintain the Azure Connected Machine agent - Azure Arc | Microsoft Learn

In real environments, you rarely want to enable this across every Arc-enabled server in one shot. Instead, you typically:

start with a pilot ring (e.g., Dev/Test or low‑risk servers),
validate results, and then
expand coverage gradually.

The Script: Abhishek-Sharan/ExtensionManagement: Install & Manage Extensions

The script implements exactly that approach by:

prompting an explicit disclaimer acknowledgement (safety gate),
selecting Arc machines by tag (a controlled blast-radius technique),
enabling automatic upgrade using ARM PATCH through Invoke-AzRestMethod,
producing a final summary report of success/failure per machine.

This post walks through what the script does, why each section exists, and what to consider before using it in production.

Why Tag‑Scoped Enablement?

In many enterprise deployments, tags are the simplest way to define a “ring” of servers:

Ring=Pilot
Environment=NonProd
Workload=LowRisk

This script discovers resources of type Microsoft.HybridCompute machines in a given resource group and filters them by a tag/value pair. That makes it easy to:

onboard machines first,
apply tags as part of provisioning,
then flip on agent auto-upgrade only for the right cohort.

Script Details (Walkthrough)

1) Safety Gate: Disclaimer + Explicit User Consent

This script prints a disclaimer block and requires the operator to type Y to proceed. If the user types anything else, the script exits.

Why it matters:

It prevents accidental execution (especially in shared shells or jump boxes).
It reinforces that this is a potentially impactful change across multiple machines.

2) Configuration: Subscription, Resource Group, and Tag Scope

The script sets the active Azure context:

Set-AzContext -Subscription "YOUR SUBSCRIPTION"

Then defines:

$resourceGroup
$tagName, $tagValue

3) Discovery: Find Azure Arc Machines with a Target Tag

Discovery uses:

Get-AzResource -ResourceType "Microsoft.HybridCompute/machines"
filters by tag match on the returned resource object.

This ensures you are only targeting Arc-enabled servers represented as Microsoft.HybridCompute machines resources.

If no machines are found, the script exits cleanly, which avoids the “silent no-op” problem and helps operators quickly validate that scope selection is correct.

4) Update: Enable Automatic Upgrade via ARM PATCH

For each machine, the script uses Invoke-AzRestMethod with:

ResourceProviderName = "Microsoft.HybridCompute"
ResourceType = "Machines"
ApiVersion = "2024-05-20-preview"
Method = "PATCH"
payload:

{"properties":{"agentUpgrade":{"enableAutomaticUpgrade":true}}}

5) Output: Per‑Machine Result + Final Summary Table

The script records results into an array of PSCustomObject entries with:

MachineName
EnableAutomaticUpgrade
Result (Success/Failed)

Then prints a formatted table.

This is useful for:

quick operator confirmation,
change records,
attaching output to internal work items / change tickets.

Conclusion

This script is a solid operational accelerant for teams managing Arc-enabled servers at scale. It combines:

safety (explicit disclaimer + opt-in),
control (tag-based targeting),
automation (bulk enabling via ARM PATCH),
observability (clear per-server results and a final summary).

If you’re trying to standardize operational hygiene across hundreds of Arc machines, tag-scoped enablement like this is one of the cleanest ways to start small, learn safely, and then scale.

Check This Out! (CTO!) Guide (February 2026)

TysonPaul — Wed, 11 Mar 2026 15:55:52 GMT

Member: TysonPaul | Microsoft Community Hub

Secure DNS with DoH: Public Preview for Windows DNS Server

Team Blog: Networking

Author: JorgeCañas

Published: 02/09/2026

Summary: Microsoft has launched a public preview of DNS over HTTPS (DoH) for Windows DNS Server, available in the February 2026 update for Windows Server 2025. DoH encrypts DNS queries and responses, enhancing authentication and privacy while maintaining existing server functions. This move aligns with Zero Trust security principles and supports U.S. federal cybersecurity requirements. The feature is disabled by default, is not production-ready, and currently only encrypts client-to-server traffic. Feedback is encouraged during the preview phase, with future updates planned for upstream encryption support.

Azure Blob Tiering: Clarity, Truths, and Practical Guidance for Architects

Team Blog: Azure Infrastructure

Author: nehatiwari1994

Published: 02/06/2026

Summary: The article explains Azure Blob Storage tiering for backup architects, debunking common misconceptions about tier performance and access. Hot, Cool, and Cold tiers are online and offer immediate data access; minimum retention is a billing rule, not a technical limit. Archive tier requires rehydration before restores. Restore speed depends on throughput architecture, not tier. Cost is influenced by both storage and access patterns. Effective tiering strategies and lifecycle policies are essential for scaling backup repositories from terabytes to petabytes, ensuring operational safety and cost control. The article offers practical design recommendations and clarifies Azure tier behaviors.

AKS Tenant Migration: Considerations and Approach

Team Blog: Azure Infrastructure

Author: SoumyaShet05

Published: 02/05/2026

Summary: 321: No summary could be found for article: [AKS Tenant Migration: Considerations and Approach] [https://techcommunity.microsoft.com/blog/azureinfrastructureblog/aks-tenant-migration-considerations-and-approach/4415198].

What’s new in FinOps toolkit 13 – January 2026

Team Blog: FinOps

Author: Michael_Flanakin

Published: 02/09/2026

Summary: FinOps toolkit 13 (January 2026) delivers stability and usability improvements for cloud cost management, including enhanced documentation, Key Vault purge protection options, Power BI report fixes, and streamlined Cost Management exports via PowerShell with Parquet support. The release strengthens security, reliability, and extensibility for enterprise-scale deployments. Community engagement is emphasized with new office hours. Future plans include AI-driven automation, expanded recommendations, and premium support services. The toolkit remains open-source and continues to evolve with community contributions and ongoing enhancements across Microsoft Cloud environments.

Reading GPSVC Like a Crime Novel

Team Blog: Ask the Directory Services Team

Author: Chris_Cartwright

Published: 02/25/2026

Summary: The article, "Reading GPSVC Like a Crime Novel," explains how to troubleshoot Group Policy issues using the enhanced GPSVC debug log in modern Windows 11 versions. It details the two core phases of Group Policy processing, emphasizes the importance of following log threads, and highlights the benefit of new date and time stamps for better correlation with other events. The post also covers enabling verbose logging, interpreting log entries, and using additional tools like TSS for deeper analysis, ultimately making GPSVC logs more powerful for diagnosing Group Policy problems.

What’s New in Windows Group Policy Preferences Debug Logging

Team Blog: Ask the Directory Services Team

Author: TagoreN

Published: 02/27/2026

Summary: The article outlines enhancements to Windows Group Policy Preferences (GPP) debug logging in Windows 11 versions 24H2 and 25H2 (from February 2026 preview updates). Administrators can now enable verbose GPP debug logging directly via Local Group Policy, not just domain-based GPOs. This change simplifies troubleshooting, reduces reliance on domain controllers, and allows easier, flexible diagnostic workflows on client devices. The article explains how to configure logging settings, log locations, and necessary permissions, highlighting a significant quality-of-life improvement for IT professionals managing GPP issues.

Azure Landing Zone and compliance for Banks (Indian Banks)

Team Blog: Azure Migration and Modernization

Author: srhulsus

Published: 02/12/2026

Summary: **Summary:** Azure Landing Zone (ALZ) provides Indian banks with a secure, compliant, and auditable cloud foundation, aligning with RBI and global standards (ISO 27001, PCI-DSS, FFIEC). It features subscription isolation, centralized IAM, robust network and data security, mandatory encryption, continuous monitoring, and business continuity controls. ALZ ensures India data residency, policy automation, regulatory audit support, and secure exit management. The architecture is regulator-accepted and proven by major banks, supporting governance, risk, and compliance mandates for hosting sensitive, regulated banking workloads on Azure.

Migrating Workloads from AWS to Azure: A Structured Approach for Cloud Architects

Team Blog: Azure Migration and Modernization

Author: rhack

Published: 02/18/2026

Summary: The article outlines a structured, five-phase approach for migrating workloads from AWS to Azure, emphasizing a “like-for-like” architecture to minimize risk and complexity. Key phases include planning, preparation, execution, evaluation, and decommissioning, with blue/green deployment recommended for risk reduction. Success hinges on comprehensive documentation, stakeholder alignment, phased validation, and having the current workload team lead the migration. External partners can assist with planning but should not execute cutovers. Once stability on Azure is achieved, optimization can begin. Thorough preparation and collaboration are essential for a confident, disruption-free migration.

How to enable HTTPS support for Microsoft Connected Cache for Enterprise and Education

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/20/2026

Summary: Starting June 16, 2026, Intune will require HTTPS for Microsoft Connected Cache nodes serving Win32 apps. To retain bandwidth savings and localize content, admins must configure HTTPS on their Connected Cache servers by preparing a TLS certificate, generating a CSR on the node, signing it with a CA, importing the certificate, and validating HTTPS. The process is similar for Windows and Linux hosts. Regular certificate monitoring and renewal are necessary. Without HTTPS, devices will fall back to CDN. Improvements and fixes are underway, and early setup ensures readiness for the upcoming enforcement.

Support tip: Resolve device noncompliance with Mobile Threat Defense partner apps

Team Blog: Intune Customer Success

Author: Intune_Support_Team

Published: 02/02/2026

Summary: The article explains how to resolve device noncompliance issues in Microsoft Intune when using Mobile Threat Defense (MTD) partner apps like Microsoft Defender for Endpoint. It outlines steps for users to restore compliance, including installing or activating the MTD app, refreshing the app’s connection, or reinstalling it. It also details simplified remediation for iOS/iPadOS and steps to refresh the MTD connection on Android if sign-out is blocked. The guidance helps organizations ensure device compliance and secure access to work or school resources while reducing support overhead.

Announcing Public Preview: Simplified Machine Provisioning for Azure Local

Team Blog: Azure Arc

Author: PragyaDwivedi

Published: 02/26/2026

Summary: Microsoft has announced the public preview of Simplified Machine Provisioning for Azure Local, streamlining edge infrastructure deployment by shifting configuration to Azure. IT teams can now centrally define and automate provisioning using Azure Arc, with minimal onsite interaction—staff only need to rack, power on hardware, and use a prepared USB. Built on the FIDO Device Onboarding standard, this approach ensures secure, consistent device onboarding and management at scale, with end-to-end deployment visibility. This new process enables faster, less error-prone deployments, allowing organizations to efficiently provision and manage Azure Local infrastructure across multiple sites.

Unlock outbound traffic insights with Azure StandardV2 NAT Gateway flow logs

Team Blog: Azure Networking

Author: cozhang

Published: 02/06/2026

Summary: The article introduces the Azure StandardV2 NAT Gateway, highlighting new features such as zone-redundancy, enhanced throughput, dual-stack IP support, and the availability of flow logs. Flow logs provide detailed outbound traffic data, improving security, compliance, and troubleshooting. They help monitor traffic patterns, identify issues like connection drops, and optimize network architecture. The article explains enabling and using flow logs for diagnostics, emphasizing their value in validating connectivity and auditing outbound flows, and encourages users to leverage these insights for resilient Azure deployments.

Migration, Modernization & Agentic Tools

Team Blog: ITOps Talk

Author: OrinThomas

Published: 02/25/2026

Summary: The article discusses how agentic tools are transforming cloud migration and modernization by introducing autonomy, continuous optimization, and context-aware decision-making. Rather than a one-time process, migration becomes an ongoing, self-improving system with tools like Azure Copilot and GitHub Copilot. These tools automate environment discovery, recommend modernization paths, execute migrations, validate and optimize workloads, and ensure governance. They classify workloads, automate migration waves, and continuously enhance cost, performance, security, and compliance, reducing manual effort and errors while enabling safe, efficient, and policy-driven cloud transitions.

Automating Large‑Scale Data Management with Azure Storage Actions

Team Blog: ITOps Talk

Author: 1Nataraj

Published: 02/25/2026

Summary: Azure Storage Actions is a fully managed, serverless automation platform that enables customers to automate large-scale data management tasks—such as tiering, tagging, deletion, and applying immutability policies—across Azure Blob Storage and Data Lake Storage without custom code or infrastructure. It uses reusable, condition-based storage tasks and assignments, supporting compliance, cost optimization, and operational efficiency. The platform provides built-in monitoring, auditing, and preview features, making it suitable for scenarios requiring traceability. Common use cases include regulatory compliance, cost control, and metadata management across industries like finance, airlines, and manufacturing.

Securing A Multi-Agent AI Solution Focused on User Context & the Complexities of On-Behalf-Of.

Team Blog: Azure Architecture

Author: Charles_Chukwudozie

Published: 02/11/2026

Summary: The article outlines how an enterprise-grade multi-agent AI system was designed to securely preserve user identity and enforce access controls when AI agents interact with backend services like Databricks. By implementing Microsoft Entra ID’s On-Behalf-Of (OBO) flow, each AI agent operates strictly within the authenticated user’s permissions, maintaining RBAC policies and an audit trail. The solution uses a custom OAuth provider, per-user agent instances, and human-in-the-loop approval for sensitive operations, aligning with Zero Trust principles and ensuring robust AI governance for enterprise applications.

Reference Architecture for Highly Available Multi-Region Azure Kubernetes Service (AKS)

Team Blog: Azure Architecture

Author: rgarofalo

Published: 02/03/2026

Summary: This article presents a reference architecture for deploying Azure Kubernetes Service (AKS) across multiple Azure regions to maximize availability and resilience. It compares active/active, active/passive, and deployment stamp patterns, detailing trade-offs in availability, complexity, and cost. Key components include Azure Front Door for global routing, geo-replicated data services, centralized monitoring, and consistent security. The article emphasizes clear design choices, regular testing, and operational preparedness, highlighting that multi-region resilience requires coordinated patterns, not a simple switch, and should align with business RTO/RPO objectives and operational maturity.

Public Preview: Restrict usage of user delegation SAS to an Entra ID identity

Team Blog: Azure Storage

Author: ellievail

Published: 02/26/2026

Summary: Microsoft has announced the public preview of user-bound user delegation SAS for Azure Storage, enhancing security by restricting SAS token usage to a specific Microsoft Entra ID identity. This extension of user delegation SAS ensures only the designated user can access storage resources, reducing the risk of unintended access. The feature is available at no additional cost in all public regions and supports cross-tenant scenarios. It integrates with existing Azure RBAC and is accessible via REST APIs, SDKs, PowerShell, and CLI. Setup involves assigning the correct roles, obtaining user IDs, and generating the SAS token.

Azure Migrate: Now Supporting Premium SSD V2, Ultra and ZRS Disks as Targets

Team Blog: Azure Storage

Author: Lakshya_Jalan

Published: 02/18/2026

Summary: 321: No summary could be found for article: [Azure Migrate: Now Supporting Premium SSD V2, Ultra and ZRS Disks as Targets] [https://techcommunity.microsoft.com/blog/azurestorageblog/azure-migrate-now-supporting-premium-ssd-v2-ultra-and-zrs-disks-as-targets/4495332].

Bringing AI fluency to every corner of the organization (even yours!)

Team Blog: Microsoft Learn

Author: AshleyMastersHall

Published: 02/19/2026

Summary: The article emphasizes the importance of AI fluency for all roles within organizations, likening AI’s impact to the transformative effect of GPS on navigation. It defines AI fluency as understanding and effectively using generative AI in care tasks, now a critical skill for the modern workplace. The author provides practical, approachable steps to integrate AI into daily workflows, recommends starting small, and highlights Microsoft’s AI Skills Navigator as a resource. The core message: AI is already changing work, and building fluency—starting with familiar tasks—ensures continued relevance and success.

Microsoft Credentials roundup: February 2026 edition

Team Blog: Microsoft Learn

Author: PujaA

Published: 02/26/2026

Summary: Microsoft’s February 2026 Credentials roundup introduces four new AI-focused Certifications and six new Applied Skills, targeting both technical and business professionals. These credentials validate expertise in AI integration, Copilot, and agent solutions, enhancing career prospects in an AI-powered workplace. Applied Skills offer quick, practical assessments in real-world AI tasks. Several older Certifications and Applied Skills are being retired, reflecting Microsoft’s ongoing commitment to current, relevant skills. Additional AI-focused updates are planned for March 2026 and beyond, further expanding learning and credentialing opportunities in AI and cloud technologies.

Public Preview: Automatic zone balance for Virtual Machine Scale Sets

Team Blog: Azure Compute

Author: HilaryWang

Published: 02/17/2026

Summary: Azure has introduced the public preview of automatic zone balance for Virtual Machine Scale Sets, which ensures VMs are evenly distributed across availability zones with no manual intervention. This feature continuously monitors and rebalances VMs, minimizing the impact of zone failures and maintaining optimal resiliency. It uses a create-before-delete approach with health checks and built-in safety measures, reducing operational overhead and ensuring workload stability. Automatic instance repairs are enabled by default. To use this feature, register for the preview, meet prerequisites, and enable it via the Azure portal, CLI, PowerShell, or REST API.

Azure Automated Virtual Machine Recovery: Minimizing Downtime

Team Blog: Azure Compute

Author: Jon_Andoni_Baranda

Published: 02/04/2026

Summary: Azure Automated Virtual Machine Recovery is a built-in Azure feature designed to minimize VM downtime by automatically detecting, diagnosing, and mitigating failures within seconds, without customer intervention. It operates continuously, leveraging multiple detection mechanisms and optimized recovery paths, ensuring business continuity and consistent SLA compliance. Recovery Event Annotations provide deep visibility into the recovery process, helping identify bottlenecks and improve reliability. Over the past 18 months, this system has halved average VM downtime, empowering customers to confidently run resilient applications with reduced risk of service disruption and financial loss. No setup is required; all Azure VMs benefit automatically.

Azure CLI Windows MSI Upgrade Issue: Root Cause, Mitigation, and Performance Improvements

Team Blog: Azure Tools

Author: Alex-wdy

Published: 02/03/2026

Summary:

The Nightmare of renewing NDES Enrollment Agent Certificates

DagmarHeidecker — Mon, 09 Mar 2026 07:28:55 GMT

NDES EA Certificates – Quick Recap

By default, three version 1 certificate templates are assigned to your Certification Authority by the configuration routine of the NDES service:

CEP Encryption - Used by the device to encrypt communication with NDES
Exchange Enrollment Agent (Offline Request) - Used to request certificates on behalf of another subject
IPSec (Offline request) - Default template to enroll certificates to devices

All certificate templates from the list above are version 1 certificate templates. Number 1 and 2 share the common characteristic of having the Extended Key Usage (EKU) extension set to include the OID 1.3.6.1.4.1.311.20.2.1, which corresponds to “Certificate Request Agent”. In this article template number 1 and 2 (from the list above) will be referred to as “NDES Enrollment Agent certificate(s) templates”.

Version 1 certificate templates originated with Windows 2000 and have functional and security limitations. Since the autoenrollment feature did not exist at that time, these templates do not support autoenrollment and instead rely on Automatic Certificate Request Settings, a legacy mechanism that is no longer recommended. Furthermore, the only property that can be modified on a version 1 template is the set of assigned permissions that controls access to the template. Find more details in Certificate Template Concepts.

Certificate Enrollment (or Request) Agents were designed to enable trusted principals to perform certificate enrollment on behalf of other users or devices (aka Enroll-on-behalf). NDES is a concrete implementation of this concept as it enrolls certificates for entities other than itself.

The enrollment of the NDES EA certificates based on certificate templates number 1 and 2 (see above) during NDES configuration is hard‑coded in the configuration routine. This design choice from many years ago introduces several challenges:

Security: in case you misconfigure the default NDES certificate templates security settings, they are vulnerable to CVE-2024-49019. A detailed explanation of this vulnerability is out of scope here; however, as a general best practice, certificate templates version 1 should not be used.
The default “Exchange Enrollment Agent (Offline request)” certificate template (default template number 2. as per above) is a user template and the installation routine “somehow magically” imports this certificate into the machine store. This makes automatic renewal challenging...
Version 1 certificate templates have significant functional limitations, as they cannot be modified (except for security settings):
- The validity period (2 years) cannot be changed. For NDES EA certificate templates the validity period is 2 years.
- The template’s CSP[1] cannot be modified. As a result, NDES Enrollment Agent certificates cannot be enrolled in a Hardware Security Module (HSM).
- Version 1 templates do not support Autoenrollment. Consequently, NDES service certificates therefore must be renewed manually. When the Enrollment Agent certificates expire, NDES stops working.
- Version 1 templates lack template-level access control and modern enrollment safeguards (e.g. Certificate Manager Approval).

[1] NDES does not support KSP for EA certificates.

As you can see, there are several reasonable arguments to replace the default NDES service certificate templates.

Configuring custom NDES Service Certificate Templates

Generally, there are two ways of creating some kind of “fire and forget” certificate templates for NDES:

Common Windows Active Directory Autoenrollment can be used if there is no need for a custom name/subject in the request agent certificates.
We can use key-based renewal (KBR) which allows us to create custom subjects in the certificates even together with automatic renewals.

The NDES service will not verify the certificates’ subject information. It will just verify that the certificates have “request Agent” EKU (1.3.6.1.4.1.311.20.2.1).

In a nutshell, you will need to duplicate two version 1 certificate templates and modify those to fit your needs. See table below for detailed description of settings.

In addition to that, there are a few more things to consider:

NDES service account

There are different options for creating the SCEP IIS App Pool identity. As Microsoft recommends using a hardened Tier 0 domain user account, this article will focus on this configuration. By default, domain user accounts do not have any permissions on private keys in the computer certificate store. Therefore, you must grant READ permissions to the NDES service certificate private keys either manually or in the certificate template configuration. This can be configured on the Request Handling tab as we will see later in this article.

(Source) Certificate Templates to duplicate

Certificate templates include a flag that is hidden from the GUI and determines whether a template is treated as a user or a computer certificate template. If you are curious, the command certutil -ds -v “CEPEncryption” will make it visible. Look out for CT_FLAG_MACHINE_TYPE in the output. This distinction is important in our scenario because the Exchange Enrollment Agent (Offline Request) template does not include this flag. As a result, certificates based on this template can only be enrolled into the user certificate store. To ensure the new template replacing the Exchange Enrollment Agent (Offline Request) template supports enrollment into the computer certificate store, we use the Enrollment Agent (Computer) default template as the source template.

Subject and SAN for NDES Service Certificates

Subject/SAN can either be built from Active Directory or provided in the request.

a) Build (subject) from this Active Directory information (option 1 from above – using common autoenrollment)

Using Common Name and DNS name is common practice. Subject and/or SAN will simply include the NDES computer account name.

As this may not be appropriate in all scenarios, we also have option...

b) Supply (subject) in the request (option 2 from above – using key-based renewal)

While this option gives you the freedom of choosing a proper Enrollment Agent subject information and SAN, it comes at the price of some additional configuration requirements to allow secure and automatic renewal of NDES service certificates. Using the key based renewal feature, we will have to initially enroll the NDES service certificates manually. Renewal will happen automatically. To implement this, both NDES service certificate templates must be configured as described below:

Subject Name tab

Issuance Requirements tab

Extensions tab

“Certificate Request Agent” is the only Application Policy required.

Please note that “Client Authentication” is required as an additional Application Policy in case you use CEP and CES for key based renewal.

Request Handling and Security tab

NDES EA Certificate Template Configuration Summary

Default NDES service certificate template	CEP Encryption	Exchange Enrollment Agent (Offline Request)
Template to duplicate	CEP Encryption	Enrollment Agent (Computer)
Compatibility settings	Certification Authority: Windows Server 2016 Certificate recipient: Windows 10/Windows Server 2016
General	Provide a name for the new certificate template.
Request Handling	In case the SCEP AppPool is configured to run in the security context of a domain account, you must grant READ access to the private key to the NDES service account. Otherwise, no changes are required on this tab.
Cryptography	If available, configure an HSM backed CSP or adjust the key length as required. Note that Key Storage Providers (KSPs) are not supported for NDES service certificates.
Subject Name	Either choose Build from this Active Directory information or choose Supply in the request + key-based renewal.
Issuance Requirements	Because of NDES’ Enroll-on-behalf capability described above, the NDES service certificates are very powerful. We therefore recommend enforcing CA certificate manager approval for enrollment. Please keep in mind that this will interrupt the automatic renewal process of the certificate if not using KBR.
Extensions	The default Application Policy is Certificate Request Agent. Do not change it. In case key based renewal is enabled, Client Authentication must be added as an Application Policy.
Security	Grant ENROLL and AUTOENROLL* permissions to the NDES Computer account only. * Autoenrollment only makes sense for option a - Autoenrollment

Housekeeping

After new EA certificates have been enrolled…

Unassign version 1 certificate templates from all CAs
Revoke all previously issued NDES EA certificates and remove them from NDES server.
Restart NDES service (execute to reload the web service and certificates)

Final Thoughts

NDES Enrollment Agent certificates are highly privileged and should never rely on legacy version 1 templates. Replacing them with custom templates that support HSMs and secure automatic renewal significantly reduces outage risk and closes known security gaps.