Sensitivity label "Certificate Error"
When applying Sensitivity Labels in Microsoft Office applications, we receive the following certificate warning: "The certificate issuer for this site is untrusted or unknown. Do you wish to proceed?" We have already excluded the required Microsoft Azure URLs from the firewall and disabled SSL/TLS inspection, but the issue still persists. Observations: 1.On the same domain-joined computer, when signed in with a local user account, Sensitivity Labels work correctly without any errors. 2.When signed in with a domain user account, the certificate warning appears while applying or accessing Sensitivity Labels. Could you please help us identify the root cause and provide a solution? Your assistance in troubleshooting this issue would be greatly appreciated.Primer: How to Use RBAC for Applications to Control App Use of the Mail.Send Permission
The temptation to use the Mail.Send application permission in scripts can lead PowerShell developers into trouble because the permission allows access to all mailboxes, including sensitive executive and financial mailboxes. Fortunately, RBAC for Applications allows tenants to control the access that apps have to mailboxes and other Exchange content. All explained here with an example script to test RBAC of Applications. https://office365itpros.com/2026/02/17/mail-send-rbac-for-applications/
My Azure login is stuck at MFA and cannot proceed
In August, I was still able to log in to Azure, and by logging in through GitHub I could bypass 2FA. But now, no matter how I try, logging in via GitHub always requires 2FA. I can’t access my Azure account anymore—nothing works. The system prompts me to use Microsoft Authenticator to confirm a two-digit code in real time. My Microsoft Authenticator on my iPhone is logged into the same Microsoft account, but I’m not receiving any verification requests for Azure login. No matter how much I refresh, nothing shows up. I’ve already updated the Microsoft Authenticator app to the latest version from the App Store. However, my personal Microsoft account works fine and can log in without any issues.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.
Issues with Sensitivity Labels and "Specific email addresses or domains" - Not working
Hello! We have enabled Sensitivity Labels in our tenant. The access control settings for the label states that a specific domain gets the permission "Co-Author". When we enable the Sensitivity label on a document and sent it towards the approved domain, it results in an error message when authenticating to open the document: "Selected user account does not exist in tenant 'Veni AS' and cannot access the application in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account." After doing some research I did some changes to the external domain within the Cross-tenant settings. The external domain now has the following settings: Inbound access: Allow access on external users and groups, within B2B Collaboration Allow access on external users and groups, within B2B direct connect Trust multifactor authentication from Microsoft Entra tenants, within Trust settings. Outbound access: Allow access on users and groups, within B2B Collaboration Allow access on users and groups, within B2B direct connect External Identities: Block access for external users and groups. (Inherited from default) After doing this change, I no longer get the same error message as above when authenticating to open the labeled document. Now I get the following error message: "You are not signed in to office with an account that has permission to open this document. You may sign in a new account into Office that has permission or request permission from the content owner" I have this working from another tenant to the same external domain and I have cross-checked the settings. Any idea on how to proceed, or if it is any obvious change I need to make in order to get this to work? All feedback appreciated! :-)
Empowering Data Security with Azure Rights Management and Azure Information Protection
In today’s digital world, data is one of the most valuable assets a business can have. Whether it’s customer information, financial records, or internal documents, keeping that data safe is absolutely necessary. As more companies move to cloud-based systems and work in hybrid environments, the need for smart and reliable data protection tools is growing fast. That’s where Azure Rights Management (RMS) and Azure Information Protection (AIP) come in. These tools help businesses organize, label, and secure their data across different platforms, making sure it stays protected no matter where it goes. Understanding Azure Rights Management (RMS) Azure RMS is a cloud-based service designed to safeguard digital information through encryption, identity, and authorization policies. It ensures that data remains protected regardless of where it resides—on a local device, in the cloud, or in transit. Core Protection Workflow The Azure RMS protection process is straightforward yet powerful: Encryption: When a user initiates protection, the content is encrypted using strong cryptographic standards. Policy Attachment: An access policy is embedded within the file, defining what actions are permitted (e.g., read-only, no print, no forward). Authentication: Access is granted only after successful authentication via Azure Active Directory (Azure AD). Decryption and Enforcement: Once authenticated, the file is decrypted and the access policy is enforced in real time. Encryption Standards in Use Azure RMS employs: AES 128-bit and 256-bit encryption for securing documents. RSA 2048-bit encryption for protecting customer-specific root keys. These standards ensure that even if data is intercepted, it remains unreadable and unusable without proper authorization. Azure Information Protection: Beyond Encryption While Azure RMS focuses on securing content, Azure Information Protection (AIP) adds a layer of intelligence through classification and labeling. AIP enables organizations to define and apply sensitivity labels that reflect the value and confidentiality of their data. From Classic to Unified Labeling Microsoft has transitioned from the classic AIP client to the Unified Labeling Client, which integrates directly with Microsoft 365 compliance solutions. This shift simplifies management and enhances compatibility with modern Office applications. Sensitivity Labels in Action Sensitivity labels help organizations manage data access and usage by categorizing content into levels such as: Public: Safe for public distribution. General: Internal use only. Confidential: Restricted to specific internal groups. Highly Confidential: Limited to named individuals with strict usage controls (e.g., no printing or downloading). Labels can be applied manually by users or automatically based on content inspection, context, or metadata. Built-In Labeling in Office Apps Modern Office apps now support built-in labeling, eliminating the need for separate add-ins. This native integration ensures a smoother user experience and reduces the risk of compatibility issues or performance degradation. Licensing Overview To leverage AIP features, organizations must have the appropriate licensing: Office 365 E3 and above: Basic classification and labeling. AIP Plan 1: Included in Microsoft 365 E3 and EMS E3. AIP Plan 2: Included in Microsoft 365 E5 and EMS E5, offering advanced capabilities like automatic labeling and document tracking. Real-World Use Cases Access Control: Limit access to sensitive documents based on user roles or departments. Version Management: Use labels to distinguish between draft and final versions. Automated Workflows: Trigger encryption or archiving when documents reach a certain sensitivity level. Why Azure Information Protection Matters Implementing AIP brings a host of benefits: Persistent Protection: Data remains secure even when shared externally or accessed offline. Granular Control: Define who can access data and what they can do with it. Visibility and Auditing: Monitor access patterns and revoke access if needed. Hybrid Compatibility: Protect data across cloud and on-premises environments using the Rights Management connector. Centralized Management: Streamline policy creation and enforcement across the organization. Conclusion Azure RMS and AIP together form a powerful duo for modern data protection. By combining encryption, identity management, and intelligent labeling, organizations can confidently secure their most valuable asset information while enabling seamless collaboration and compliance.
AIP padlock icon missing in encrypted message
Hi, I have enabled AIP in my tenant along with sensitivity labels and encryption. I can send encrypted messages succesfully however the secure message - which contains a padlock icon referring to a microsoft website - is broken and fails to load. I’ve viewed the source of the message and tried to load the image in my browser. The image failed to load and I believe the image location is not valid anymore. Could you please validate and provide a fix so that the padlock icon loads successfully? Currently the secure message looks like a phishing email and will probably be treated as such.Track Sensitivity Label Downgrades and Removals with Audit Log Data
The Purview Insider Risk Management solution can do all sorts of clever things, like tracking sensitivity label downgrades and removals as an indicator that a user might be preparing to exfiltrate data. The same kind of checking can be done by using the events captured in the audit log when people remove or change sensitivity labels. All in a few lines of PowerShell… https://office365itpros.com/2024/11/20/sensitivity-label-downgrades/
