External people can't open files with Sensitivity Label encryption.
Question: What are the best practices for ensuring external users can open files encrypted with Sensitivity Labels? Hi all. I've been investigating proper setup of sensitivity labels in Purview, and the impact on user experience. The prerequisites are simple enough, creating and configuring the labels reasonably straightforward, and publishing them is a breeze. But using them appears to be a different matter! Everything is fine for labels that don't apply encryption (control access) or when used internally. However, the problems come when labels do apply encryption and information is sent externally. The result is that we apply a label to a document, attach that document to an email, and send it externally - and the recipient says they can't open it and they get an error that their email address is not in our directory. This is because due to the encryption, the external user needs to authenticate back to our tenant, and if they're not in our tenant they obviously can't do this so the files won't open. So, back to the question above. What's the easiest / most secure / best way to add any user we might share encrypted content with to our tenant. As I see it we have the following options: Users have to request Admins add the user as a Guest in our tenant before they send the content. Let's face it, they'll not do this and/or get frustrated. Users share encrypted content directly from SharePoint / OneDrive, rather than attaching it to emails (as that would automatically add the external person as a Guest in the tenant). This will be fine in some circumstances, but won't always be appropriate (when you want to send them a point-in-time version of a doc). With good SharePoint setup, site Owners would also have to approve the share before it gets sent which could delay things. Admins add all possible domains that encrypted content might be shared with to Entra B2B Direct Connect (so the external recipient doesn't have to be our tenant). This may not be practical as you often don't know who you'll need to share with and we work with hundreds of organisations. The bigger gotcha is that the external organisation would also have to configure Entra B2B Direct Connect. Admins default Entra B2B Direct Connect to 'Allow All'. This opens up a significant attack surface and also still requires any external organisation to configure Entra B2B Direct Connect as well. I really want to make this work, but it need to be as simple as possible for the end users sharing sensitive or confidential content. And all of the above options seem to have significant down-sides. I'm really hoping someone who uses Sensitivity Labels on a day-to-day basis can provide some help or advice to share their experiences. Thanks, Oz.
Locked out from O365 admin account
Hi! I am locked out from my non-protif organizations O365 admin-account. When trying to login, it ask for the authenticator code, but my authenticator app tells me to login and to login it needs an authenticator code..... I cant contact the O365 support since I cannot login. I found a phone number and talked to some AI bot, but it could not understand when I said the domain name of our organization and shut me down after 3 attempts. So - I have no way to login and handle my organizations account. Can someone please advice how to solve this, or how to get in touch with an actual human being in O365 support???
BioEnrollmentHost.exe failes setting up Windows Hello (August 2025)
Hello, when trying to add another fingerprint, there is a failure. The editing interface does not open - it disappears without displaying an error message. The eventlog shows the error: Log Name: Application Source: Application Error Date: 25.08.2025 9:09:22 Event ID: 1000 Task Category: Application Crashing Events Level: Error Description: Faulting application name: BioEnrollmentHost.exe, version: 10.0.26100.4484, time stamp: 0x3a2c5e36 Faulting module name: Windows.UI.Xaml.dll, version: 10.0.26100.4946, time stamp: 0x4374ba0f Exception code: 0xc000027b Fault offset: 0x0000000000903d13 Faulting process id: 0x3B10 Faulting application start time: 0x1DC158F2982572A Faulting application path: C:\Windows\SystemApps\Microsoft.BioEnrollment_cw5n1h2txyewy\BioEnrollmentHost.exe Faulting module path: C:\Windows\System32\Windows.UI.Xaml.dll Report Id: da35663e-a5e8-4638-b202-5afed9fd901c Faulting package full name: Microsoft.BioEnrollment_10.0.19587.1000_neutral__cw5n1h2txyewy Faulting package-relative application ID: App There is no problem with OS integrity > PS C:\WINDOWS\system32> DISM.exe /Online /Cleanup-image /Scanhealth Deployment Image Servicing and Management tool Version: 10.0.26100.1150 Image Version: 10.0.26100.4946 [==========================100.0%==========================] No component store corruption detected. The operation completed successfully. PS C:\WINDOWS\system32> PS C:\WINDOWS\system32> DISM.exe /Online /Cleanup-image /Restorehealth Deployment Image Servicing and Management tool Version: 10.0.26100.1150 Image Version: 10.0.26100.4946 [==========================100.0%==========================] The restore operation completed successfully. The operation completed successfully. PS C:\WINDOWS\system32> PS C:\WINDOWS\system32> sfc /scannow Beginning system scan. This process will take some time. Beginning verification phase of system scan. Verification 100% complete. Windows Resource Protection did not find any integrity violations. PS C:\WINDOWS\system32> chkdsk c: /scan /perf The type of the file system is NTFS. ... Windows has scanned the file system and found no problems. No further action is required. ... PS C:\WINDOWS\system32> PS C:\WINDOWS\system32> systeminfo | findstr /B /C:"OS Name" /B /C:"OS Version" OS Name: Microsoft Windows 11 Enterprise LTSC OS Version: 10.0.26100 N/A Build 26100 PS C:\WINDOWS\system32> Any ideas?
Securing the Modern Workplace: Transitioning from Legacy Authentication to Conditional Access
Authored by: Gonzalo Brown Ruiz, Senior Microsoft 365 Engineer & Cloud Security Specialist Date: July 2025 Introduction In today’s threat landscape, legacy authentication is one of the weakest links in enterprise security. Protocols like POP, IMAP, SMTP Basic, and MAPI are inherently vulnerable — they don’t support modern authentication methods like MFA and are frequently targeted in credential stuffing and password spray attacks. Despite the known risks, many organizations still allow legacy authentication to persist for “just one app” or “just a few users.” This article outlines a real-world, enterprise-tested strategy for eliminating legacy authentication and implementing a Zero Trust-aligned Conditional Access model using Microsoft Entra ID. Why Legacy Authentication Must Die No support for MFA: Enables attackers to bypass the most critical security control Password spray heaven: Common vector for brute-force and scripted login attempts Audit blind spots: Limited logging and correlation in modern SIEM tools Blocks Zero Trust progress: Hinders enforcement of identity- and device-based policies Removing legacy auth isn’t a nice-to-have — it’s a prerequisite for a modern security strategy. Phase 1: Auditing Your Environment A successful transition starts with visibility. Before blocking anything, I led an environment-wide audit to identify: All sign-ins using legacy protocols (POP, IMAP, SMTP AUTH, MAPI) App IDs and service principals requesting basic auth Users with outdated clients (Office 2010/2013) Devices and applications integrated via PowerShell, Azure Sign-In Logs, and Workbooks Tools used: Microsoft 365 Sign-In Logs Conditional Access insights workbook PowerShell (Get-SignInLogs, Get-CASMailbox, etc.) Phase 2: Policy Design and Strategy The goal is not just to block — it’s to transform authentication securely and gradually. My Conditional Access strategy included: Blocking legacy authentication protocols while allowing scoped exceptions Report-only mode to assess potential impact Role-based access rules (admins, execs, vendors, apps) Geo-aware policies and MFA enforcement Service account handling and migration to Graph or Modern Auth-compatible apps Key considerations: Apps that support legacy auth only Delegates and shared mailbox access scenarios BYOD and conditional registration enforcement Phase 3: Staged Rollout and Enforcement A phased approach reduced friction: Pilot group enforcement (IT, InfoSec, willing users) Report-only monitoring across business units Clear communications to stakeholders and impacted users User education campaigns on legacy app retirement Gradual enforcement by department, geography, or risk tier We used Microsoft Entra’s built-in messaging and Service Health alerts to notify users of policy triggers. Phase 4: Monitoring, Tuning, and Incident Readiness Once policies were in place: Monitored Sign-in logs for policy match rates and unexpected denials Used Microsoft Defender for Identity to correlate legacy sign-in attempts Created alerts and response playbooks for blocked sign-in anomalies Results: 100% of all user and app traffic transitioned to Modern Auth Drastic reduction in brute force traffic from foreign IPs Fewer support tickets around password lockouts and MFA prompts Lessons Learned Report-only mode is your best friend. Avoids surprise outages. Communication beats configuration. Even a perfect policy fails if users are caught off guard. Legacy mail clients still exist in vendor tools and old mobile apps. Service accounts can break silently. Replace or modernize them early. CA exclusions are dangerous. Every exception must be time-bound and documented. Conclusion Eliminating legacy authentication is not just a policy update — it’s a cultural shift toward Zero Trust. By combining deep visibility, staged enforcement, and a user-centric approach, organizations can securely modernize their identity perimeter. Microsoft Entra Conditional Access is more than a policy engine — it is the architectural pillar of enterprise-grade identity security. Author’s Note: This article is based on my real-world experience designing and enforcing Conditional Access strategies across global hybrid environments with Microsoft 365 and Azure AD/Entra ID. Copyright © 2025 Gonzalo Brown Ruiz. All rights reserved.Implementing Privileged Identity Management (PIM): Enhancing Security Through Just-in-Time Access
Authored by: Gonzalo Brown Ruiz, Senior Microsoft 365 Engineer & Cloud Security Specialist Date: July 2025 Introduction In today’s rapidly evolving cybersecurity landscape, privileged accounts remain among the highest-value targets for attackers. Administrative privileges grant broad access to systems, configurations, and sensitive data. Mismanagement or compromise can result in catastrophic breaches, compliance violations, and operational disruptions. Microsoft Entra Privileged Identity Management (PIM) is a critical security and governance tool for any organization leveraging Entra ID (formerly Azure Active Directory). It provides just-in-time (JIT) privilege elevation, drastically reducing risk exposure while maintaining operational efficiency. Why Should Organizations Implement PIM? Traditional privilege models assign permanent, standing permissions to administrators. While convenient, this creates continuous risks: Expanded attack surface: Standing admin rights are prime targets for credential theft. Limited visibility and control: Lack of activation records hinders auditing and investigations. Non-compliance: Security standards require least privilege and JIT access. Implementing PIM enforces JIT activation, ensuring privileges are: Granted only when necessary Time-bound with automatic expiration Auditable and justifiable Protected by multi-factor authentication (MFA) and approval workflows Key Benefits of Entra PIM Enhanced Security Posture: Eliminates standing elevated privileges, minimizing lateral movement risks. Regulatory Compliance: Meets ISO 27001, PCI-DSS, NIST, and other strict privileged access requirements. Operational Accountability: Records who activated which role, when, why, and for how long. Reduced Insider Threat Risk: Ensures privileged access is intentional, reviewed, and limited. Improved Governance and Audit Readiness: Provides clear trails for internal audits, external assessments, and breach investigations. How to Use PIM Properly: Standard Activation Process 1. Access Entra PIM Log into https://entra.microsoft.com Navigate to Privileged Identity Management in the left menu. 2. View Eligible Roles Click My roles. Review roles under Azure AD roles marked as eligible. 3. Activate the Required Role Click Activate next to the needed role. Provide a business justification. Select the activation duration (up to allowed maximum). Complete MFA authentication if prompted. If approvals are required, wait for completion. 4. Confirm Activation The role will appear under Active assignments. Perform privileged tasks as needed. 5. Allow Activation to Expire Elevated access automatically expires after the activation period. Reactivate the role for future privileged tasks. Best Practice Recommendations Activate roles only when required Use minimal durations to limit exposure Provide clear, specific business justifications Monitor activation logs regularly for anomalies Educate administrators on PIM as part of security onboarding and ongoing awareness programs Conclusion Privileged Identity Management is not just a feature – it is a security imperative. Implementing PIM strengthens defenses against internal and external threats, fulfills compliance requirements, and fosters operational discipline and accountability. Empowering administrators to understand and properly use PIM ensures privileged access transforms from a high-risk liability to a controlled, auditable asset aligned with modern cybersecurity best practices. Copyright © 2025 Gonzalo Brown Ruiz. All rights reserved.
Citrix - O365 apps go unauthenticated when updating to version 2408
Hi, My Citrix environment uses Citrix UPM and FSlogix all on server 2019 using PVS versioning. I have been running for a year regularly updating O365 to the latest version and build but this time when I have updated to Version 2408 Build 17928.20468 after around 1 hours (assume this is the licence token refresh time) users are being asked to "fix your account" Has anyone experienced the same and got to the bottom of it? If I roll back the update to a previous build there is no issue. Cheers, Jeff
Microsoft 365 automatically unchecks the Authenticated SMTP under a user
Do you know why Microsoft 355 is automatically unchecking the "Authenticated SMTP" under a user? Our server and configuration have not changed, or update and we never had this problem. Last week we noticed that the "Authenticated SMTP" was unchecked, for the only user that is setup, and we corrected the problem by checking the box but a day later we are facing the same problem and having to constantly go to Microsoft 360 to check the "Authenticated SMTP" Can you please let me know what to do to fix this problem? Thank youPractical Graph: Nag Users to Upgrade to a Strong Authentication Method
Convincing people to use MFA is one challenge. Convincing them to use a stronger authentication method than SMS is another. This article explains how to use PowerShell to find people still using SMS for MFA and send email to ask them to upgrade their authentication method. https://practical365.com/upgrade-stronger-authentication-method-mfa/
