Azure Entra Security Copilot: How It’s Changing Identity Protection
Overview Azure Entra Security Copilot is revolutionizing how organizations approach identity protection. By combining the power of generative AI with Microsoft’s deep security insights, it enables faster threat detection, smarter policy recommendations, and simplified incident response. Hands-On Experience After integrating Security Copilot into our Azure Entra environment, here’s what stood out: Natural Language Queries: You can ask things like “Show me risky sign-ins from last week” and get instant, actionable insights. Automated Investigations: It correlates signals across Entra ID, Defender, and Sentinel to surface threats. Policy Recommendations: Based on your environment, it suggests Conditional Access policies to reduce risk. Use Cases 1. Breach Detection Detects anomalies like impossible travel, unfamiliar sign-in patterns, and token theft. Automatically flags high-risk users and suggests remediation steps. 2. Policy Optimization Recommends Conditional Access policies tailored to your org’s risk profile. Helps reduce over-permissive access and enforce least privilege. 3. Incident Response Generates incident summaries and timelines. Suggests next steps and integrates with Microsoft Sentinel for deeper investigation. Comparison with Traditional SIEM Workflows Discussion Starter Have you tried Security Copilot in your environment yet? What use cases have you explored? How does it compare with your existing SIEM or XDR tools? Let’s share insights and build a stronger identity protection strategy together!
Token Protection by using Microsoft Entra ID.
As organizations move to the cloud and adopt SaaS applications, identities are becoming increasingly crucial for accessing resources. Cybercriminals exploit legitimate and authorized identities to steal data and access credentials through methods like phishing, malware, data breaches, brute-force/password spray attacks, and prior compromises. As in past years, password-based attacks on users constitute most identity-related attacks. As MFA blocks most password-based attacks, threat actors are shifting their focus, moving up the cyberattack chain in three ways: 1) attacking infrastructure, 2) bypassing authentication, and 3) exploiting applications. They are leaning more heavily into adversary-in-the-middle (AiTM) phishing attacks and token theft. Over the last year, as Microsoft Digital Defense Report (MDDR 2024) a 146% rise in AiTM phishing attacks. In AiTM attack , the attackers steal tokens instead of passwords. The Frameworks used by attackers go far beyond credential phishing, by inserting malicious infrastructure between the user and the legitimate application the user is trying to access. When the user is phished, the malicious infrastructure captures both the credentials of the user, and the token. By compromising and replaying a token issued to an identity that has already completed multifactor authentication, the threat actor satisfies the validation of MFA and access is granted to organizational resources accordingly. Now it is imperative that tokens must be protected from token theft. Let us understand more on tokens. An Entra identity token is a security token issued by Microsoft Entra ID for authentication and authorization. There are several types: Access Tokens: Grant access to resources on behalf of an authenticated user, containing user and resource information. ID Tokens: Authenticate users, issued in the OpenID Connect flow, containing user identity and authentication details. Refresh Tokens: Obtain new access tokens without re-authentication, usually issued with access tokens and have a longer lifespan. Ensuring Token Security By following best practices, you can significantly enhance the security of your tokens and protect your applications from unauthorized access. Use Secure Transmission: Always transmit tokens over secure channels such as HTTPS to prevent interception by unauthorized parties. Token Binding: Implement Token Protection (formerly known as token binding) to cryptographically tie tokens to client secrets. This prevents token replay attacks from different devices. Conditional Access Policies: Use Conditional Access policies to enforce compliant network checks. This ensures that tokens are only used from trusted networks and devices. Continuous Access Evaluation (CAE): Implement CAE to continuously evaluate the security state of the session. This helps in detecting and revoking tokens if there are changes in the user's security posture, such as network location changes. Short Token Lifetimes: Use short lifetimes for access tokens and refresh tokens to limit the window of opportunity for attackers. Secure Storage: Store tokens securely on the client side, using secure storage mechanisms provided by the operating system, such as Keychain on iOS or Keystore on Android. Regular Audits and Monitoring: Regularly audit token usage and monitor for any unusual activity. This helps in early detection of potential security breaches. Now we will discuss Entra ID new features for Token Protection. Token protection using conditional access : This feature will provide refresh token protection. Compliant network check with Conditional Access: This feature will provide both refresh token and Access token protection. Token protection using conditional access: Token protection (sometimes referred to as token binding in the industry) attempts to reduce attacks using token theft by ensuring a token is usable only from the intended device. When an attacker is able to steal a token, by hijacking or replay, they can impersonate their victim until the token expires or is revoked. Token theft is thought to be a relatively rare event, but the damage from it can be significant. Token protection creates a cryptographically secure tie between the token and the device (client secret) it's issued to. Without the client secret, the bound token is useless. When a user registers a Windows 10 or newer device in Microsoft Entra ID, their primary identity is bound to the device. What this means: A policy can ensure that only bound sign-in session (or refresh) tokens, otherwise known as Primary Refresh Tokens (PRTs) are used by applications when requesting access to a resource. Token protection is currently in public preview Create a Conditional Access policy Users who perform specialized roles like those described in Privileged access security levels are possible targets for this functionality. We recommend piloting with a small subset to begin. The steps that follow help create a Conditional Access policy to require token protection for Exchange Online and SharePoint Online on Windows devices. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Protection > Conditional Access > Policies. Select New policy. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies. Under Assignments, select Users or workload identities. Under Include, select the users or groups who are testing this policy. Under Exclude, select Users and groups and choose your organization's emergency access or break-glass accounts. 6.Under Target resources > Resources (formerly cloud apps) > Include > Select resources Under Select, select the following applications supported by the preview: Office 365 Exchange Online Office 365 SharePoint Online Choose Select. 7. Under Conditions: Under Device platforms: Set Configure to Yes. Include > Select device platforms > Windows. Select Done. Under Client apps: Set Configure to Yes Under Modern authentication clients, only select Mobile apps and desktop clients. Leave other items unchecked. Select Done. 8. Under Access controls > Session, select Require token protection for sign-in sessions and select Select. 9. Confirm your settings and set Enable policy to Report-only. 10.Select Create to create to enable your policy. After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On. Capture logs and analyze Monitoring Conditional Access enforcement of token protection before and after enforcement. Sign-in logs Use Microsoft Entra sign-in log to verify the outcome of a token protection enforcement policy in report only mode or in enabled mode. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Identity > Monitoring & health > Sign-in logs. Select a specific request to determine if the policy is applied or not. Go to the Conditional Access or Report-Only pane depending on its state and select the name of your policy requiring token protection. Under Session Controls check to see if the policy requirements were satisfied or not. You can refer below link to know more about license requirements, prerequisites & limitations. Token protection in Microsoft Entra Conditional Access - Microsoft Entra ID | Microsoft Learn Enable compliant network check with Conditional Access Organizations who use Conditional Access along with the Global Secure Access, can prevent malicious access to Microsoft apps, third-party SaaS apps, and private line-of-business (LoB) apps using multiple conditions to provide defense-in-depth. These conditions might include device compliance, location, and more to provide protection against user identity or token theft. Global Secure Access introduces the concept of a compliant network within Microsoft Entra ID Conditional Access. This compliant network check ensures users connect from a verified network connectivity model for their specific tenant and are compliant with security policies enforced by administrators. The Global Secure Access Client installed on devices or users behind configured remote networks allows administrators to secure resources behind a compliant network with advanced Conditional Access controls. This compliant network feature makes it easier for administrators to manage access policies, without having to maintain a list of egress IP addresses. This removes the requirement to hairpin traffic through organization's VPN. Compliant network check enforcement Compliant network enforcement reduces the risk of token theft/replay attacks. Compliant network enforcement happens at the authentication plane (generally available) and at the data plane (preview). Authentication plane enforcement is performed by Microsoft Entra ID at the time of user authentication. If an adversary has stolen a session token and attempts to replay it from a device that is not connected to your organization’s compliant network (for example, requesting an access token with a stolen refresh token), Entra ID will immediately deny the request and further access will be blocked. Data plane enforcement works with services that support Continuous Access Evaluation (CAE) - currently, only SharePoint & Exchange Online. With apps that support CAE, stolen access tokens that are replayed outside your tenant’s compliant network will be rejected by the application in near-real time. Without CAE, a stolen access token will last up to its full lifetime (default 60-90 minutes). This compliant network check is specific to each tenant. Using this check, you can ensure that other organizations using Microsoft's Global Secure Access services can't access your resources. For example: Contoso can protect their services like Exchange Online and SharePoint Online behind their compliant network check to ensure only Contoso users can access these resources. If another organization like Fabrikam was using a compliant network check, they wouldn't pass Contoso's compliant network check. The compliant network is different than IPv4, IPv6, or geographic locations you might configure in Microsoft Entra. Administrators are not required to review and maintain compliant network IP addresses/ranges, strengthening the security posture and minimizing the ongoing administrative overhead. Enable Global Secure Access signaling for Conditional Access To enable the required setting to allow the compliant network check, an administrator must take the following steps. Sign in to the Microsoft Entra admin center as a Global Secure Access Administrator. Browse to Global Secure Access > Settings > Session management > Adaptive access. Select the toggle to Enable CA Signaling for Entra ID (covering all cloud apps). This will automatically enable CAE signaling for Office 365 (preview). Browse to Protection > Conditional Access > Named locations. a. Confirm you have a location called All Compliant Network locationswith location type Network Access. Organizations can optionally mark this location as trusted. You can refer below link to know more about license requirements, prerequisites & limitations Protect your resources behind the compliant network The compliant network Conditional Access policy can be used to protect your Microsoft and third-party applications. A typical policy will have a 'Block' grant for all network locations except Compliant Network. The following example demonstrates the steps to configure this type of policy: Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator. Browse to Protection > Conditional Access. Select Create new policy. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies. Under Assignments, select Users or workload identities. Under Include, select All users. Under Exclude, select Users and groupsand choose your organization's emergency access or break-glass accounts. 6. Under Target resources > Include and select All resources (formerly 'All cloud apps'). If your organization is enrolling devices into Microsoft Intune, it is recommended to exclude the applications Microsoft Intune Enrollmentand Microsoft Intune from your Conditional Access policy to avoid a circular dependency. 7. Under Network. Set Configureto Yes. Under Include, select Any location. Under Exclude, select the All Compliant Network locationslocation. 8. Under Access controls: Grant, select Block Access, and select Select. 9. Confirm your settings and set Enable policy to On. 10. Select the Create button to create to enable your policy. User exclusions Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies: Emergency access or break-glass accounts to prevent lockout due to policy misconfiguration. In the unlikely scenario all administrators are locked out, your emergency-access administrative account can be used to log in and take steps to recover access. More information can be found in the article, Manage emergency access accounts in Microsoft Entra ID. Service accounts and Service principals, such as the Microsoft Entra Connect Sync Account. Service accounts are non-interactive accounts that aren't tied to any particular user. They're normally used by back-end services allowing programmatic access to applications but are also used to sign in to systems for administrative purposes. Calls made by service principals won't be blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to define policies targeting service principals. If your organization has these accounts in use in scripts or code, consider replacing them with managed identities. Try your compliant network policy On an end-user device with the Global Secure Access client installed and running, browse to https://outlook.office.com/mail/ or https://yourcompanyname.sharepoint.com/, you have access to resources. Pause the Global Secure Access client by right-clicking the application in the Windows tray and selecting Pause. Browse to https://outlook.office.com/mail/ or https://yourcompanyname.sharepoint.com/, you're blocked from accessing resources with an error message that says You cannot access this right now. You can refer below link to know more about license requirements, prerequisites & limitations Enable compliant network check with Conditional Access - Global Secure Access | Microsoft LearnPower Up Your Open WebUI with Azure AI Speech: Quick STT & TTS Integration
Introduction Ever found yourself wishing your web interface could really talk and listen back to you? With a few clicks (and a bit of code), you can turn your plain Open WebUI into a full-on voice assistant. In this post, you’ll see how to spin up an Azure Speech resource, hook it into your frontend, and watch as user speech transforms into text and your app’s responses leap off the screen in a human-like voice. By the end of this guide, you’ll have a voice-enabled web UI that actually converses with users, opening the door to hands-free controls, better accessibility, and a genuinely richer user experience. Ready to make your web app speak? Let’s dive in. Why Azure AI Speech? We use Azure AI Speech service in Open Web UI to enable voice interactions directly within web applications. This allows users to: Speak commands or input instead of typing, making the interface more accessible and user-friendly. Hear responses or information read aloud, which improves usability for people with visual impairments or those who prefer audio. Provide a more natural and hands-free experience especially on devices like smartphones or tablets. In short, integrating Azure AI Speech service into Open Web UI helps make web apps smarter, more interactive, and easier to use by adding speech recognition and voice output features. If you haven’t hosted Open WebUI already, follow my other step-by-step guide to host Ollama WebUI on Azure. Proceed to the next step if you have Open WebUI deployed already. Learn More about OpenWeb UI here. Deploy Azure AI Speech service in Azure. Navigate to the Azure Portal and search for Azure AI Speech on the Azure portal search bar. Create a new Speech Service by filling up the fields in the resource creation page. Click on “Create” to finalize the setup. After the resource has been deployed, click on “View resource” button and you should be redirected to the Azure AI Speech service page. The page should display the API Keys and Endpoints for Azure AI Speech services, which you can use in Open Web UI. Settings things up in Open Web UI Speech to Text settings (STT) Head to the Open Web UI Admin page > Settings > Audio. Paste the API Key obtained from the Azure AI Speech service page into the API key field below. Unless you use different Azure Region, or want to change the default configurations for the STT settings, leave all settings to blank. Text to Speech settings (TTS) Now, let's proceed with configuring the TTS Settings on OpenWeb UI by toggling the TTS Engine to Azure AI Speech option. Again, paste the API Key obtained from Azure AI Speech service page and leave all settings to blank. You can change the TTS Voice from the dropdown selection in the TTS settings as depicted in the image below: Click Save to reflect the change. Expected Result Now, let’s test if everything works well. Open a new chat / temporary chat on Open Web UI and click on the Call / Record button. The STT Engine (Azure AI Speech) should identify your voice and provide a response based on the voice input. To test the TTS feature, click on the Read Aloud (Speaker Icon) under any response from Open Web UI. The TTS Engine should reflect Azure AI Speech service! Conclusion And that’s a wrap! You’ve just given your Open WebUI the gift of capturing user speech, turning it into text, and then talking right back with Azure’s neural voices. Along the way you saw how easy it is to spin up a Speech resource in the Azure portal, wire up real-time transcription in the browser, and pipe responses through the TTS engine. From here, it’s all about experimentation. Try swapping in different neural voices or dialing in new languages. Tweak how you start and stop listening, play with silence detection, or add custom pronunciation tweaks for those tricky product names. Before you know it, your interface will feel less like a web page and more like a conversation partner.
Moving from MDT/WDS to Autopilot – Real-World Lessons, Wins & Gotchas
Hi all, We’ve been moving away from an ageing WDS + MDT setup and over to Windows Autopilot, and I thought I’d share a few key lessons and experiences from the journey. In case anyone else is working through the same transition (...or about to). Why the change? MDT was becoming unreliable, drivers/apps would randomly fail to install, WDS is on the way out, and we needed a more remote-friendly approach. We also wanted to simplify things for our small IT team and shift from Hybrid Azure AD Join to Azure AD Join only. We’re doing this as a phased rollout. I harvested existing device hashes using a script from a central server, and manually added machines that weren’t online at the time (most of which were just unused spares, we haven't introduced new hardware yet). If you want a copy of this auto-harvest, please see my next post, this script is useful as it'll just go off and import the hardware hashes into Intune, and can run against multiple computers at a time. (I will add the link to the post once made). Some of the biggest hurdles: • 0x80070002 / 0x80070643 errors (typically due to incomplete registration or app deployment failures) • Enrollment Status Page (ESP) hangs due to app targeting issues (user vs device) and BitLocker config conflicts • Wi-Fi setup with RADIUS (NPS) was complex, Enterprise Certificates and we're still using internal AD for authentication, so user accounts exist there and sync over to Azure. • Legacy GPOs had to be rebuilt manually in Intune, lots of trial and error • Some software (like SolidWorks) wouldn’t install silently via Intune, so I used NinjaOne to handle these, along with remediation scripts in Intune where needed We also moved from WSUS to Windows Autopatch, which improved update reliability and even helped with driver delivery via Windows Update. What’s gone well: Device provisioning is more consistent, updates are more reliable, build time per machine has dropped, and remote users get systems faster. It’s also reduced our reliance on legacy infrastructure. What I’m still working on: Tightening up compliance and reporting, improving detection/remediation coverage, figuring out new errors that may occur, and automating as much manual processes as possible. Ask me anything or share your own experience! I’m happy to help anyone dealing with similar issues or just curious about the move. Feel free to reply here or message me. Always happy to trade lessons learned, especially if you’re in the middle of an Autopilot project yourself. Cheers, Timothy JeensConverting Azure Registered device into hybrid azure ad joined
Dear All, We are in the process of planning conditional access to manage devices. So far devices only sync to azure ad and status showing azure ad registered. How can we convert those azure ad registered device into hybrid azure ad joined. What will happen on user end if enable hybrid azure ad joined from AAD connect. Thank you all in advanced.
Custom permission to enable diagnostic setting in Entra ID
Custom permissions doesnt works when tried to enable diagnostic settings, in Microsoft Entra ID portal. Error: "does not have authorisation to perform action 'microsoft.aadiam/diagnosticSettings/write' over scope '/providers/microsoft.aadiam/diagnostic Settings/resourcename" Selective permissions that I applied to user account. My approach is to use custom role specific permissions. Appreciate your help to knows the right permission required. Regards, Rajkumar
User Authentication Method last used date
We have an issue with our users getting the latest iPhone and never notifying IT that they have turned in the old one. This means that the old device is still registered in our system as a valid MFA method for the user. I would like to run a script that would tell me per user, their MFA methods and the last time they used it, Or even better the last time that device checked in. The goal would be to delete any devices that have not been used or checked in for over a year as a starting point. Running Get-MgBetaUserAuthenticationMethod -Userld $UserID I Select • -ExpandProperty AdditionalProperties There is only Create date / Time not usage. Do I need to be looking anywhere else?
Shared channel not adding external users (One way issue)
Hello everyone, Hope someone can provide insight to this, i've been trying to find solution for the past few days to no avail. Background: Create shared channel between 2 organizations (My organization and the opposite organization) Both organizations have set up all B2B Direct connect inbound/outbound settings in cross-tenant access settings (Azure AD) Both organizations have ensured teams settings and shared channels are enabled. (Teams admin control centre) My organization is able to add the opposite organization into the teams channel as guest (in standard channel) Issue: The opposite organization is able to add me into their shared channel without any issue. When i try to add the member of the opposite organization, the following message popped up Solutions attempted: Adding the member from the Microsoft Teams admin control centre. Checked and confirmed that settings under admin.microsoft.com > settings > org settings > services | Microsoft Teams & Microsoft 365 Groups are identical for both organizations. Deleted the guest user and re-created again in admin.microsoft.com > users > Guest users > add new guest users via invitation (AzureAD) which led to the above screen cap scenario B2B collaboration and B2B direct connect in azure AD cross-tenant access settings all set up properly and identical for both organizations References: https://learn.microsoft.com/en-US/microsoft-365/solutions/collaborate-teams-direct-connect?WT.mc_id=TeamsAdminCenterCSH&view=o365-worldwide https://learn.microsoft.com/en-us/MicrosoftTeams/shared-channels#shared-channel-limits https://learn.microsoft.com/en-us/microsoftteams/shared-channels-errors https://learn.microsoft.com/en-us/microsoftteams/teams-policies https://learn.microsoft.com/en-us/azure/active-directory/external-identities/cross-tenant-access-settings-b2b-direct-connectGet AzADGroupMembers from nested groups
Hi, I'm trying to get all members of a group (including nested groups members) to add to a teams private channel. We have a script to add members of a group to a private channel, but it will not add nested groups members. $members = Get-AzADGroupMember -ObjectId 'source_groupID_here' | select mail $tal = 0 foreach ($member in $members) { $User = $member.mail Add-TeamChannelUser -GroupId 'teams_groupID_here' -DisplayName 'Private_channel_name' -user $User $tal += 1 } $tal Is there a way to add those who are members of the nested groups without having to add each nested group individually?
