Compliance licenses at tenant level
Hi, We are a small organization of about 200 employees, and we have following requirements. DLP policies configuration at Exchange, OneDrive, SharePoint BYOD security Users should not be able to send files outside the org And so on as we evaluate We already have M365 Business Premium. However, after researching we figured out that M365 Business premium will alone not solve our requirements. May be compliance license will. We want to apply security policies at tenant level in our organization but definitely do not want every user to get licenses as this will be expensive for us and there is no requirement at all for our users. The question is, Is there a way to solve the above scenario?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! :-)Modifying Outlook Email Encryption Options
I'm trying to modify our existing Outlook email encryption options a bit, and I cannot find where this is located anymore on the admin side of things. How/where do I find the admin portal that manages this list?: I'm accessing this list by opening a new email > options > Encrypt
Using Email Encryption: Remote tenants not able to authenticate / open encrypted messages
We are using automation plus a flow rule to force encrypted emails via flow rules that apply Office 365 Message Encryption and Rights Protection with the "Encrypt Only" policy. However, when we send to people who are on remote tenants, we run into an unusual problem. Some tenants "just work", while other tenants hard fail with a notice that says the following: Selected user account does not exist in tenant 'Tenant Name' and cannot access the application 'UUID Here' in that tenant. The account needs to be added as an external user in the tenant first. Please use a different account. Unfortunately, there's no option to bypass this for those recipients and no way to force one time password authentication options where they have to request a OTP and then use that. It enforces the use of MS365 Tenant auth rather than OTP, which is unusual and problematic because while *certain* remote tenants "just work" others do not. I'm confused as to where to look next. Is there a way to force OTP-only in the outgoing encryption for a message with transport rules on the Outlook 365 admin panel? Alternatively, is there a way to automatically permit external tenant accounts/recipients to just work? Please feel free to ask any questions necessary to solve this on our end, it's a core component of one of our information sending systems to partners and it's not working as intended.
Email Encryption Issues
We have an Outlook rule in place that anything that includes “Secure:” in the subject line, that email will be sent out encrypted. The issue that has been escalated recently is that if the email has “Secure:” in the subject link, plus an attachment that is not encrypted such as a PDF or Excel file, the recipient receives the email but cannot open the file. They get an error message that says your Outlook account does not have permission to open this file, please contact [senders’ email] We have O365 E1 licensing. One user has E3 and does not experience this issue.Outlook desktop client is encrypting emails despite the sensitivity label setting
We have 3 different sensitivity labels set up - General, Internal and Confidential. The General label does not encrypt content, internal and confidential do. The default label for emails is Confidential. When someone uses the Outlook Desktop client (release 2407) and switches from Confidential to General, the email is still encrypted. This doesn't happen with the Outlook web client. If the switch from Confidential to Internal and then to General, the email is not encrypted. Has anyone else seen this behavior?How to Handle an Unwanted Sensitivity Label
Sometimes sensitivity labels defined for use within a Microsoft 365 tenant turn out to be unnecessary. The question then is what to do with these unwanted sensitivity labels. The answer is to pause for thought, gather information, and then make an informed decision, all of which we discuss here. https://practical365.com/how-to-handle-an-unwanted-sensitivity-label/
General Availability: Purview Customer Key Using Managed HSM
We are excited to announce the general availability of Purview Customer Key using Managed HSM. This new feature enhances your data security by allowing you to manage and control your own encryption keys using Azure Managed HSM. This release is the result of the efforts Microsoft 365 Data-At-Rest Encryption Engineering team. With Customer Key using Managed HSM, you can: Achieve higher security: Managed HSM provides dedicated, FIPS 140-2 Level 3 validated hardware for key protection, offering enhanced security over standard Azure Key Vaults. Ensure compliance: Meet stringent regulatory and compliance requirements with the advanced security features of Managed HSM. Maintain control: Enjoy full control over your encryption keys, including key lifecycle management, within a highly secure, tamper-resistant environment. Enhance performance: Benefit from the high availability and scalability of Managed HSM for critical workloads. Purview Customer Key now supports three different options for key storage including Standard Azure Key Vault, Premium Azure Key Vault and Managed HSM. For more details about the differences between these options, see How to choose the right key management solution. Start leveraging the enhanced security and compliance benefits of Customer Key using Managed HSM today. For more information, visit Set Up Customer Key or learn more about Azure Key Vault and Managed HSM. With Gratitude, M365 Data-at-Rest Encryption
