📣 MSLE Onboarding Session — Português
Olá, 👋 Espero que estejam bem! ✨Participe da sessão de introdução ao programa MSLE para Educadores! Nesta sessão: ✅ Vamos explorar os benefícios e o alcance do programa ✅ Conhecer em detalhe os dois portais principais aos quais você terá acesso ✅ Esclarecer todas as suas dúvidas em um ambiente colaborativo Este é o seu primeiro passo rumo a uma experiência enriquecedora, onde conhecimento, inovação e comunidade se unem para impulsionar você ao próximo nível. No horário indicado, favor realizar acesso ao link.
Is "Endpoint Security Policies" available to us? (error getting Intune policies)
Question We'd like to use Defender \ Endpoint Security Policies. Is that possible for my tenant's environment? Getting below error on "Defender \ Endpoint Security Policies" page "There seems to be an issue getting your Intune policies" Details of our environment Purpose of defender To protect our server fleet that's running outside of Azure Tenant GCC - Moderate Scoped Region Commercial Azure East US 2 Subscription Microsoft Defender for Servers Plan 1 (No other subscription, etc.) Defender Client OS Windows 2016, 2019, 2022 RHEL8, 9 (No desktops\laptops) Agents installed on each Windows and Linux server Defender is onboarded Arc is onboarded Configured Settings and Errors Defender \ Settings \ Configuration management \ Enforcement scope https://security.microsoft.com/securitysettings/endpoints/configuration_management2 Error at top of page "Intune is not configured to allow Microsoft Defender for Endpoint to manage security configuration settings." Use MDE to enforce security configuration settings from Intune Set to ON Enable configuration management Windows Server devices On tagged devices Windows Server Domain Controller devices On tagged devices Linux devices On tagged devices Security settings management for Microsoft Defender for Cloud onboarded devices. Set to ON Manage Security settings using Configuration Manager Set to OFF Defender \ Settings \ Configuration management \ Intune Permissions https://security.microsoft.com/securitysettings/endpoints/intune_permissions Getting error "Access needed You don't have the right permissions in AAD to view this information (in addition to those you already have in MDE). To adjust your permissions, go to the AAD portal." Defender \ Endpoint Security Policies https://security.microsoft.com/policy-inventory On main page, getting below error There seems to be an issue getting your Intune policies If I try to make a new policy There seems to be an issue loading the policy authoring wizard. Intune \ Endpoint security https://intune.microsoft.com/#view/Microsoft_Intune_Workflows/SecurityManagementMenu Getting Error You don't have access Intune roles | My permissions https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/RolesLandingMenuBlade/~/myPermissions You're an administrator with full permissions to all Microsoft Intune resources. Intune roles | Administrator Licensing https://intune.microsoft.com/#view/Microsoft_Intune_DeviceSettings/RolesLandingMenuBlade/~/administratorLicensing Allow admins without an Intune license to access Intune. Their scope of access is determined by the Intune roles you've assigned them. I've clicked the box "Allow access to unlicensed admins" Alternatives If Defender \ Endpoint Security Policies isn't available, as alternatives, I guess we could use SCCM Antimalware policies to manage Windows servers Deploying a central mdatp_managed.json to manage Linux servers However, it would be greatly preferred to use the Defender \ Endpoint Security Policies feature for Windows and Linux
Operational Notes on Microsoft Security Copilot Agents in Defender XDR and Microsoft Entra ID
Microsoft Security Copilot is now becoming more visible inside day-to-day security operations, especially through embedded experiences and agent-based workflows across Microsoft Defender XDR, Microsoft Entra ID, Microsoft Intune, and Microsoft Purview. Instead of looking at Security Copilot only as a standalone prompt interface, SOC and identity teams should also understand how Security Copilot agents are deployed, how they consume Security Compute Units, how they appear in operational workflows, and where activity can be monitored. This post summarizes practical observations from a security operations perspective, with a focus on Microsoft Defender XDR, Microsoft Entra ID, usage monitoring, and KQL-based activity review. Licensing & Capacity Units Requirements Requires eligible Microsoft security licensing, typically: Microsoft 365 E5 Microsoft 365 E7 Security Compute Units (SCUs) Security Copilot capacity is measured using Security Compute Units (SCUs). SCUs are billed based on provisioned capacity. Indicative pricing: $4 per Provisionied SCU/hour $6 per Overage SCU/hour Billing is calculated hourly, based on the amount of SCUs provisioned. Included Capacity Organizations with: 1,000 Microsoft 365 E5 licenses Receive: 400 included SCUs Included SCUs are shared across the tenant within a common capacity pool. Scaling SCU capacity can be scaled dynamically based on operational requirements and workload demand. Data Retention Security Copilot session and interaction data without active SCU-backed retention is typically retained for: 90 days Security Copilot Agents - Microsoft Defender This section outlines the Microsoft Security Copilot agents currently available in the Microsoft Defender portal. NameKey characteristics Security Alert Triage Agent (Preview) Manual setup from Defender portal Automatically creates Unified RBAC custom role Runs automatically when a user reports a suspicious email or when a new supported alert is generated, supported alert sources: MDI, MDC, MDO If an alert tuning rule is enabled, it will be automatically disabled when the agent is deployed. Creates and connects with agentic user account: Phishing Triage Agent (Security Copilot) Automatic alert assignment to SecurityCopilotAgentUser-db16fec3-f1fb-4632-843e-46d07408c584@<tenant-domain>Alert was assigned to Phishing Triage Agent (Security Copilot). Adds Tag Agent to the created Incidents Threat Hunting Agent Manual setup from Defender portal Automatically creates Unified RBAC custom role This agent runs manually. There isn't an automatic trigger. Creates and connects with agentic user account: Threat Hunting Agent (Security Copilot) Analyst Questions in natural language Generates and executed KQL queries in Advanced hunting Provides charts, dynamic follow-up questions and remediation actions recommendations No activity is identified from agent's identity during agent execution Threat Intelligence Briefing Agent Manual setup from Defender portal Provides automated TI briefing summary Configured from https://security.microsoft.com/securitysettings/defender/agent_configuration-threatintelligencebriefingagent Security Analyst Agent Manual setup from Defender portal Dynamic Threat Detection Agent (Preview) Automatically enabled always-on, runs continuously in the background Correlates: Alerts, Security events, Behavioral anomalies, TI signals Generates Alerts with Detection Source: Security Copilot The Alerts can be correlated with existing Multi-Stage Incidents No agentic user account identity is used by this agent Available free of charge during public preview, will begin consuming Security Compute Units (SCUs) once generally available (GA) Incidents handled by Security Alert Triage Agent: Alerts created by Dynamic Threat Detection Agent: Execution of Threat Hunting Agent: View agents in use: https://security.microsoft.com/security-copilot/agents View Unified RBAC custom roles: https://security.microsoft.com/mtp_roles View Security Copilot user identities in Microsoft Entra ID: Notes: CloudAppEvents activity logs only from the following agents: Phishing Triage Agent Conditional Access Optimization Agent Security Copilot Agents - Microsoft Entra ID Conditional Access Optimization Agent Usage Monitoring Sign-in to Security Copilot portal using Global Admin account and navigate to the following location: https://securitycopilot.microsoft.com/usage-monitoring Reference: https://learn.microsoft.com/en-us/copilot/security/manage-usage Logging Activity Copilot Agents Management: CloudAppEvents | where ActionType contains "CopilotAgent" | extend AgentName = RawEventData.AgentName | extend Workload = RawEventData.Workload | extend ResultStatus = RawEventData.ResultStatus | project TimeGenerated, ActionType, ResultStatus, AgentName, Application, Workload All Copilot Workload data: CloudAppEvents | extend Workload = RawEventData.Workload | where Workload == "Copilot" | summarize EventCount = count() by ActionType, AccountDisplayName📣 MSLE Onboarding Session — Português
Olá, 👋 Espero que estejam bem! ✨Participe da sessão de introdução ao programa MSLE para Educadores! Nesta sessão: ✅ Vamos explorar os benefícios e o alcance do programa ✅ Conhecer em detalhe os dois portais principais aos quais você terá acesso ✅ Esclarecer todas as suas dúvidas em um ambiente colaborativo Este é o seu primeiro passo rumo a uma experiência enriquecedora, onde conhecimento, inovação e comunidade se unem para impulsionar você ao próximo nível. No horário indicado, favor realizar acesso ao link.MSLE Onboarding Session — English
✨ Ready to take your teaching to the next level? Join Carlos, our MSLE Community Manager (English), for an exclusive induction session on the MSLE Program for Educators! ✅ Discover the benefits and scope of the program ✅ Explore the two main portals you’ll have access to ✅ Get your questions answered in a collaborative environment This is your first step toward an enriching experience where knowledge, innovation, and community come together to empower you. 📅 Don’t miss it—your journey starts here! MSLE Onboarding Session — English | Meeting-Join | Microsoft Teams
MSLE Onboarding Session — French
✨ Envie de faire évoluer votre manière d'enseigner ? Rejoignez la séance de présentation exclusive du programme MSLE (Microsoft Learn pour les Enseignants ) ! ✅ Découvrez les avantages du programme ✅ Explorez les deux principaux portails auxquels vous aurez accès ✅ Posez vos questions dans un environnement collaboratif C’est votre première étape vers une expérience enrichissante où savoir, innovation et communauté se rejoignent pour vous accompagner. 📅 Ne manquez pas cette opportunité. Votre parcours commence ici ! Rejoignez la réunion ici
Easy Auth Configuration for Logic App Standard through CI/CD
Problem Statement When Easy Auth (Azure App Service’s built-in authentication and authorization) is enabled on a Logic App Standard, users frequently report that they cannot open the run history. Specifically, the inputs and outputs of the trigger and actions fail to load on the run details page, even though the workflow itself runs and the user has access to the resource. Background — How Easy Auth Interacts with Logic Apps Easy Auth is a feature of Azure App Service. Every request that reaches a Logic App Standard is first routed through the App Service layer, and only then handed off to the Logic App runtime for further processing. When Easy Auth is enabled, App Service authenticates each incoming request and decides whether it should be allowed or blocked — before the Logic App runtime ever sees it. This dual-layer model is what causes the run-history symptom: The Logic App runtime authenticates run-history requests using a SAS token specific to that run, generated from the Logic App access keys. The portal calls that load the inputs and outputs of historical runs do not carry a bearer token — they carry the SAS. Because App Service only knows how to validate Easy Auth tokens (not SAS), it blocks these requests whenever unauthenticatedClientAction is set to disallow unauthenticated traffic. The request never reaches the runtime, so the runtime cannot apply its SAS validation, and the inputs/outputs panel stays empty. Solution There are two ways to fix this, depending on what your security policy allows. Option 1 — Allow unauthenticated requests The simplest fix is to configure Easy Auth to allow unauthenticated requests. This does not mean anyone can invoke the workflow. Instead, all calls (failed and successful) are routed through to the Logic App runtime, and the runtime decides how to handle them: A workflow trigger call with no token → the runtime applies its own auth (SAS, AAD, etc.) and rejects unauthorized invocations. A run-history call carrying a valid SAS → App Service marks it as “failed Easy Auth” but still forwards it; the runtime sees the valid SAS and returns the data. The underlying App Service platform has no knowledge of SAS or any other Logic-App-specific auth scheme, so letting the runtime arbitrate is what makes the run-history experience work. Option 2 — Keep Easy Auth strict, but exclude the runtime paths In many enterprises the security team will not permit “Allow unauthenticated requests.” For those cases, you can leave authentication required but add the runtime endpoints to the excludedPaths list, so App Service skips Easy Auth specifically for those calls. The Logic App runtime continues to authenticate them via SAS. Important: The Azure portal lets you toggle Easy Auth, but it does not expose the excludedPaths setting. You must configure it through ARM, Bicep, the REST API, or CLI — which is exactly why this needs to live in your CI/CD pipeline. There are two ways to apply this through CI/CD. Approach 1 — ARM Template ( Microsoft.Web/sites/config ) Add a Microsoft.Web/sites/config resource of type authsettingsV2 to the same ARM template that deploys the Logic App. Below is the sample template: { "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#", "contentVersion": "1.0.0.0", "parameters": { "logicAppName": { "type": "string" }, "location": { "type": "string", "defaultValue": "[resourceGroup().location]" }, "tenantID": { "type": "string" }, "ClientID": { "type": "string" } }, "variables": {}, "resources": [ { "type": "Microsoft.Web/sites", "apiVersion": "2022-03-01", "name": "[parameters('logicAppName')]", "location": "[parameters('location')]", "kind": "functionapp,workflowapp", "identity": { "type": "SystemAssigned" }, "properties": { "serverFarmId": "<App Service Plan ID>", "siteConfig": { "appSettings": [ { "name": "FUNCTIONS_EXTENSION_VERSION", "value": "~4" }, { "name": "FUNCTIONS_WORKER_RUNTIME", "value": "dotnet" }, { "name": "AzureWebJobsStorage", "value": "<Storage Account Connection String>" }, { "name": "APP_KIND", "value": "workflowApp" } ] }, "httpsOnly": true } }, { "type": "Microsoft.Web/sites/config", "apiVersion": "2021-02-01", "name": "[concat(parameters('logicAppName'), '/authsettingsV2')]", "location": "[parameters('location')]", "properties": { "platform": { "enabled": true, "runtimeVersion": "~1" }, "globalValidation": { "requireAuthentication": true, "unauthenticatedClientAction": "Return401", "excludedPaths": ["/runtime/*"] }, "identityProviders": { "azureActiveDirectory": { "enabled": true, "registration": { "openIdIssuer": "[concat('https://sts.windows.net/', parameters('tenantID'), '/v2.0')]", "clientId": "parameters('ClientID')", "clientSecretSettingName": "OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID" }, "login": { "disableWWWAuthenticate": false }, "validation": { "jwtClaimChecks": {}, "allowedAudiences": [], "defaultAuthorizationPolicy": { "allowedPrincipals": {}, "allowedApplications": ["<LIST OF ALLOWED APPLICATIONS ID>"] } } } } }, "dependsOn": [ "[resourceId('Microsoft.Web/sites', parameters('logicAppName'))]" ] } ], "outputs": {} } Key things to notice in the template: requireAuthentication: true and unauthenticatedClientAction: Return401 keep Easy Auth strict for the public surface. excludedPaths: ["/runtime/*"] carves out the runtime endpoints so the SAS-authenticated run-history calls aren’t blocked. allowedApplications lets you whitelist specific AAD app IDs that are allowed to call the workflow. Reference: Microsoft.Web/sites/config — authsettingsV2 (ARM template) · Bicep variant This is the easiest way to add or update Easy Auth on a new or existing Logic App. Approach 2 — REST API call as a post-deployment pipeline step If you’d rather keep your infra template lean (or you’re updating Easy Auth on a Logic App that already exists), add a step to your CI/CD pipeline that calls the App Service authsettingsV2 REST API after the Logic App infra deployment completes. The payload mirrors the properties block from the ARM example above — including excludedPaths: ["/runtime/*"] . This approach is useful when: The Logic App is provisioned by a different pipeline or team than the one owning auth configuration. You need to update Easy Auth settings without redeploying the site. You want to apply environment-specific values (tenant ID, client ID, allowed application list) at release time rather than template-compile time. Reference: Web Apps - Update Auth Settings V2 - REST API (Azure App Service) | Microsoft Learn · GlobalValidation Summary The “inputs/outputs don’t load on run history” symptom after enabling Easy Auth is caused by App Service blocking SAS-authenticated runtime calls before the Logic App runtime can see them. Either allow unauthenticated requests (and let the runtime do all the auth), or keep Easy Auth strict and exclude /runtime/* . Because the portal doesn’t expose excludedPaths , the production-grade fix is to deploy it through CI/CD — either by adding an authsettingsV2 config resource to your ARM template or by calling the App Service auth REST API as a pipeline step after deployment.
