Introducing the Secure Future Initiative Tech Tips show!
Introducing the Secure Future Initiative: Tech Tips show! This show provides bite-sized technical tips from Microsoft security experts about how you can implement recommendations from one of the six engineering pillars of Microsoft's Secure Future Initiative in your own environment to uplift your security posture. Hosted by Sarah Young, Principal Security Advocate (_@sarahyo) and Michael Howard, Senior Director Microsoft Red Team (@michael_howard), the series interviews a range of Microsoft security experts giving you practical advice about how to implement SFI controls in your organization's environment. The first episode about phishing resistant creds is live on YouTube and MS Learn. Upcoming episodes include: Using managed identities Using secure vaults to store secrets Applying ingress and egress control Scanning for creds in code and push protection Enabling audit logs for cloud and develop threat detections Keep up to date with the latest Secure Future Initiative news at aka.ms/sfiMicrosoft Security in Action: Deploying and Maximizing Advanced Identity Protection
As cyber threats grow in sophistication, identity remains the first line of defense. With credentials being a primary target for attackers, organizations must implement advanced identity protection to prevent unauthorized access, reduce the risk of breaches, and maintain regulatory compliance. This blog outlines a phased deployment approach to implement Microsoft’s identity solutions, helping ensure a strong Zero Trust foundation by enhancing security without compromising user experience. Phase 1: Deploy advanced identity protection Step 1: Build your hybrid identity foundation with synchronized identity Establishing a synchronized identity is foundational for seamless user experiences across on-premises and cloud environments. Microsoft Entra Connect synchronizes Active Directory identities with Microsoft Entra ID, enabling unified governance while enabling users to securely access resources across hybrid environments. To deploy, install Microsoft Entra Connect, configure synchronization settings to sync only necessary accounts, and monitor health through built-in tools to detect and resolve sync issues. A well-implemented hybrid identity enables consistent authentication, centralized management, and a frictionless user experience across all environments. Step 2: Enforce strong authentication with MFA and Conditional Access Multi-Factor Authentication (MFA) is the foundation of identity security. By requiring an additional verification step, MFA significantly reduces the risk of account compromise—even if credentials are stolen. Start by enforcing MFA for all users, prioritizing high-risk accounts such as administrators, finance teams, and executives. Microsoft recommends deploying passwordless authentication methods, such as Windows Hello, FIDO2 security keys, and Microsoft Authenticator, to further reduce phishing risks. Next, to balance security with usability, use Conditional Access policies to apply adaptive authentication requirements based on conditions such as user behavior, device health, and risk levels. For example, block sign-ins from non-compliant or unmanaged devices while allowing access from corporate-managed endpoints. Step 3: Automate threat detection with Identity Protection Implementing AI-driven risk detection is crucial to identifying compromised accounts before attackers can exploit them. Start by enabling Identity Protection to analyze user behavior and detect anomalies such as impossible travel logins, leaked credentials, and atypical access patterns. To reduce security risk, evolve your Conditional Access policies with risk signals that trigger automatic remediation actions. For low-risk sign-ins, require additional authentication (such as MFA), while high-risk sign-ins should be blocked entirely. By integrating Identity Protection with Conditional Access, security teams can enforce real-time access decisions based on risk intelligence, strengthening identity security across the enterprise. Step 4: Secure privileged accounts with Privileged Identity Management (PIM) Privileged accounts are prime targets for attackers, making Privileged Identity Management (PIM) essential for securing administrative access. PIM allows organizations to apply the principle of least privilege by granting Just-in-Time (JIT) access, meaning users only receive elevated permissions when needed—and only for a limited time. Start by identifying all privileged roles and moving them to PIM-managed access policies. Configure approval workflows for high-risk roles like Global Admin or Security Admin, requiring justification and multi-factor authentication before privilege escalation. Next, to maintain control, enable privileged access auditing, which logs all administrative activities and generates alerts for unusual role assignments or excessive privilege usage. Regular access reviews further enable only authorized users to retain elevated permissions. Step 5: Implement self-service and identity governance tools Start by deploying Self-Service Password Reset (SSPR). SSPR enables users to recover their accounts securely without help desk intervention. Also integrate SSPR with MFA, so that only authorized users regain access. Next, organizations should implement automated Access Reviews on all users, not just privileged accounts, to periodically validate role assignments and remove unnecessary permissions. This helps mitigate privilege creep, where users accumulate excessive permissions over time. Phase 2: Optimize identity security and automate response With core identity protection mechanisms deployed, the next step is to enhance security operations with automation, continuous monitoring, and policy refinement. Step1: Enhance visibility with centralized monitoring Start by Integrating Microsoft Entra logs with Microsoft Sentinel to gain real-time visibility into identity-based threats. By analyzing failed login attempts, suspicious sign-ins, and privilege escalations, security teams can detect and mitigate identity-based attacks before they escalate. Step 2: Apply advanced Conditional Access scenarios To further tighten access control, implement session-based Conditional Access policies. For example, allow read-only access to SharePoint Online from unmanaged devices and block data downloads entirely. By refining policies based on user roles, locations, and device health, organizations can strengthen security while ensuring seamless collaboration. Phase 3: Enable secure collaboration across teams Identity security is not just about protection—it also enables secure collaboration across employees, partners, and customers. Step 1: Secure external collaboration Collaboration with partners, vendors, and contractors requires secure, managed access without the complexity of managing external accounts. Microsoft Entra External Identities allows organizations to provide seamless authentication for external users while enforcing security policies like MFA and Conditional Access. By enabling lifecycle management policies, organizations can automate external user access reviews and expirations, ensuring least-privilege access at all times. Step 2: Automate identity governance with entitlement management To streamline access requests and approvals, Microsoft Entra Entitlement Management lets organizations create pre-configured access packages for both internal and external users. External guests can request access to pre-approved tools and resources without IT intervention. Automated access reviews and expiration policies enable users retain access only as long as needed. This reduces administrative overheads while enhancing security and compliance. Strengthening identity security for the future Deploying advanced identity protection in a structured, phased approach allows organizations to proactively defend against identity-based threats while maintaining secure, seamless access. Ready to take the next step? Explore these Microsoft identity security deployment resources: Microsoft Entra Identity Protection Documentation Conditional Access Deployment Guide Privileged Identity Management Configuration Guide The Microsoft Security in Action blog series is an evolving collection of posts that explores practical deployment strategies, real-world implementations, and best practices to help organizations secure their digital estate with Microsoft Security solutions. Stay tuned for our next blog on deploying and maximizing your investments in Microsoft Threat Protection solutions.Learn more about Microsoft Security Communities.
In the last five years, Microsoft has increased the emphasis on community programs – specifically within the security, compliance, and management space. These communities fall into two categories: Public and Private (or NDA only). In this blog, we will share a breakdown of each community and how to join.
Entra hybrid join issue caused maybe by 2 M365 accounts
Hello to everyone, one of my collegue has 2 Microsoft 365 accounts on its notebook when we tried to do the procedure to hybrid join his device; I suppose the other account give us problem in the procedure; now, there is only one account even if I can see in event log, in AAD log, that there is an error and 2 warnings bound to the old account. However, I tried to repeat the procedure but without any luck; what I see that it is different from the other devices, if I give the cmd dsregcmd /status is in these 2 lines: DisplayNameUpdated : YES OsVersionUpdated : YES while on other devices I see: DisplayNameUpdated : Managed by MDM OsVersionUpdated : Managed by MDM We have all a Microsoft 365 Business subscription and the configuration and steps for the other devices was: We have all devices with Entra registered user, we started with this when we have only the Microsoft 365 Basic subscription We enrolled all devices, with group policy, in MDE when we upgraded to the business Installed the Azure AD Connect Users sync Devices sync So, in the Entra portal we have first only the entry for registered, then when we synced the devices we have a second entry with hybrid registered and finally only one entry with Owner, MDM and Settings field filled with correct data; for example, when I make an hybrid join device, initially in the row I see MDE as MDM, then when the hybrid and registered compose one row I see Intune in that field. For the device that give us problems, I see a row like this in Entra portal while in Intune Any help is greatly appreciated.
Entra Private Access Licensing
I'm a bit stuck trying to figure out what licensing we need to get us working on BYOD devices such as iPads if we want to use the Private Access part of Global Secure Access. A few places on Microsoft's website mention that as long as we have an Entra ID P1 or P2 license and a Private Access license assigned to a user, we should be able to enrol mobile devices without any issues. However, when I try to sign into MS Defender on an iPad (tried 2 different ones), I get an error saying invalid license. One of the users I am currently testing has an Office 365 E3 license assigned as well. Where am I going wrong?Q: Restricting access to Business Web Application/Non-Enterprise Application
Hi all, We are in the middle of moving our on-prem infrastructure to Intune and more specifically, building out conditional access policies. All but one of our business applications have been straightforward with the process to limit access unless certain conditions are met from an authentication, device, or location compliance perspective. The one business application we are needing to find a solution for is a web-based application that we do not control outside of user administration and limited-customization. Typically this would be fine if SSO was leveraged, but this web application, unfortunately and not without several conversations with the developers due to the sensitive nature of the data being stored, does not have SSO on their roadmap. Users can access this application from any web browser using their username and password credentials and an application specific 2FA process using SMS code. There is no connection between our MS tenant and this web application. Due to the sensitive nature of the information stored within this application and the availability of this application from any device with a web browser has raised my antenna with security concerns. Especially in the case of a user downloading information from this site on their BYOD mobile device as they would may need to do in the course of their duties, but if they left the organization, we have no way of wiping that data through the removal of the work profile like we do with all other work data through Intune device compliance measures. We can limit what devices are allowed to connect to work resources (Complaint) and access work applications (all but one, and they need to be compliant to do so), but is there a way to not allow the personal profile of any BYOD device that is compliant, from accessing or logging into this specific URL in any browser from the personal profile web browser?
Some users repeatedly prompted for MFA
All our devices are Intune joined. MFA turned on with a conditional access policy: Grant Access to: Require multifactor authentication; Session only configured Sign in frequency: x days. When majority users sign in apps without any issue, and only required to re authenticated with MFA after the defined x days. We have a small group of users are asked to MFA every time they opens a new app. Intune indicates these users' computers "Compliant". However, Entra - Monitoring - Signin logs shows: The same monitoring for other users, Authentication Details are "previously satisfied'. For these users, even they are working on the same app on a desktop, they are still returned with "Mobile app notification" and therefore are asked to MFA: DSREGCMD /status returns some different Diagnostic Data results to other devices without MFA issues: Last HostName Update : NONE. ********************************************************************* +----------------------------------------------------------------------+ | Device State | +----------------------------------------------------------------------+ AzureAdJoined : YES EnterpriseJoined : NO DomainJoined : NO Virtual Desktop : NOT SET Device Name : [COMPUTER_NAME] +----------------------------------------------------------------------+ | Device Details | +----------------------------------------------------------------------+ DeviceId : [COMPUTER_ID] Thumbprint : [COMPUTER_THUMBPRINT] DeviceCertificateValidity : [ 2023-08-05 04:25:23.000 UTC -- 2033-08-05 04:55:23.000 UTC ] KeyContainerId : [COMPUTER_KEYCONTAINERID] KeyProvider : Microsoft Platform Crypto Provider TpmProtected : YES DeviceAuthStatus : SUCCESS +----------------------------------------------------------------------+ | Tenant Details | +----------------------------------------------------------------------+ TenantName : [TENANTNAME] ... ... ... +----------------------------------------------------------------------+ | User State | +----------------------------------------------------------------------+ NgcSet : NO WorkplaceJoined : NO WamDefaultSet : YES WamDefaultAuthority : organizations WamDefaultId : https://login.microsoft.com WamDefaultGUID : [...] (AzureAd) +----------------------------------------------------------------------+ | SSO State | +----------------------------------------------------------------------+ AzureAdPrt : YES AzureAdPrtUpdateTime : 2024-09-03 23:32:02.000 UTC AzureAdPrtExpiryTime : 2024-09-17 23:32:01.000 UTC AzureAdPrtAuthority : [...] EnterprisePrt : NO EnterprisePrtAuthority : OnPremTgt : NO CloudTgt : YES KerbTopLevelNames : .windows.net,.windows.net:1433,.windows.net:3342,.azure.net,.azure.net:1433,.azure.net:3342 +----------------------------------------------------------------------+ | Diagnostic Data | +----------------------------------------------------------------------+ AadRecoveryEnabled : NO Executing Account Name : AzureAD\[USERNAME], [USEREMAILADDRESS] KeySignTest : PASSED DisplayNameUpdated : Managed by MDM OsVersionUpdated : Managed by MDM HostNameUpdated : YES Last HostName Update : NONE +----------------------------------------------------------------------+ | IE Proxy Config for Current User | +----------------------------------------------------------------------+ Auto Detect Settings : YES Auto-Configuration URL : Proxy Server List : Proxy Bypass List : +----------------------------------------------------------------------+ | WinHttp Default Proxy Config | +----------------------------------------------------------------------+ Access Type : DIRECT +----------------------------------------------------------------------+ | Ngc Prerequisite Check | +----------------------------------------------------------------------+ IsDeviceJoined : YES IsUserAzureAD : YES PolicyEnabled : NO PostLogonEnabled : YES DeviceEligible : YES SessionIsNotRemote : YES CertEnrollment : none PreReqResult : WillNotProvision ************************************************************************** Can someone help here and shade some light on the issue.Anomalies with Conditional Access Policy "Terms of Use" Failures
Hello Microsoft Community, I'm reaching out with a bit of a puzzle regarding our "Terms of Use" Conditional Access policy, and I'm eager to tap into the collective wisdom here for some insights. In our Entra ID User Sign-In logs, we've identified intermittent "failure" entries associated with the "Terms of Use" Conditional Access policy. Interestingly, even for users who had previously accepted the "Terms of Use". There appears to be no discernible impact, and they continue their tasks without interruption. This observation became apparent during the troubleshooting of unrelated Surface Hub and Edge Sync issues at some client sites. What adds to the complexity of the situation is that for the same users, both before and after these "failure" entries, the Conditional Access policy is marked as "success". Hence, it doesn't seem to be a straightforward case of the policy erroneously detecting non-acceptance of the "Terms of Use". The mystery lies in understanding why these intermittent "failure" entries occur for users who have already accepted the terms, especially when the policy consistently reports "success" for the same users. Furthermore, the Insights for the "Terms of Use" Conditional Access policy show around 1.48k successes and 1.43k failures in the last 90 days, yet there's no discernible impact on user functionality. Observations: "Failure" entries in Sign-In logs don't seem to disrupt users' day-to-day activities. The ratio of successes to failures is balanced, yet users experience no noticeable problems. The issue complicates troubleshooting efforts but doesn't significantly affect the user experience. I'm turning to the community for guidance on interpreting and resolving this discrepancy between "failure" entries in the Conditional Access policy logs and the seemingly unaffected user experience. Any insights into why these failures occur without user impact would be greatly appreciated. For additional context, I've attached screenshots of a user's Sign-In log entry and the insight chart from the Conditional Access policy. Sign-In log of a user (failure): Sign-In log of same user (success): Current Conditional Access insights: Thank you in advance for your time and assistance. I look forward to any guidance or solutions you can provide. Best regards, Leon Tüpker
