Feedback by UserVoice

Office 365 Security & Compliance

We have partnered with UserVoice, a third-party service and your use of the portal and your submission is subject to the UserVoice Terms of Service & Privacy Policy. Please do not send any novel or patentable ideas, copyrighted materials, samples or demos for which you do not want to grant a license to Microsoft.

Welcome to the Security (Protection) & Compliance UserVoice forum. We’re happy you’re here! If you have suggestions or ideas on how to improve Security or Compliance related features in O365, we’d love to hear them!

How it works
◾Check out the ideas others have suggested and vote on your favorites
◾If you have a suggestion that’s not listed yet, submit your own — 25 words or less, please
◾Include one suggestion per post

Thanks for joining our community and helping improve these features in Office 365!

Need Tech Support? Please see the O365 Community for the product or feature you are having issues with, or open a support ticket through your Office 365 administrator portal.

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback
  1. Add ability to deny EWS and MAPI clients using Basic Authentication, with Client Access Rules for Exchange Online

    Currently, MFA for Azure AD / O365 is useless regarding protection of mailboxes in Exchange Online, as EWS and MAPI clients can still connect to mailboxes using Basic Authentication, even with Conditional Access rules in place to require MFA, and there's no way of denying this server-side on EXO.

    The newly-released Client Access Rules feature promises this functionality in its documentation (see https://technet.microsoft.com/library/mt842508.aspx and https://technet.microsoft.com/en-us/library/dn913650(v=exchg.160).aspx), but unfortunately the functionality is crippled. You can only make rules in the following combinations (info from EXO Engineering team):

    OutlookWebApp: BasicAuthentication, AdfsAuthentication
    ExchangeAdminCenter: BasicAuthentication, AdfsAuthentication
    RemotePowerShell: BasicAuthentication, NonBasicAuthentication
    ExchangeActiveSync: BasicAuthentication, OAuthAuthentication, CertificateBasedAuthentication
    IMAP4/POP3/OfflineAddressBook/PowerShellWebServices/ExchangeWebServices/REST:…

    386 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    11 comments  ·  Advanced Security Management  ·  Flag idea as inappropriate…  ·  Admin →

    Thanks for taking the time to provide this feedback. We’ve updated the TechNet documentation (https://technet.microsoft.com/library/mt842508(v=exchg.150).aspx) to clear up confusion around which authentication type and protocol combinations are supported in CARs. Expanding support for more combinations could prevent bad actors with valid credentials from accessing mailbox content, but it wouldn’t help with scenarios like password spray attacks or malicious lockout attempts because CARs are evaluated post-authentication. There’s work underway on a solution that covers a broader array of basic authentication scenarios – we’ll share more details as soon as possible. In the interim, this blogpost (https://cloudblogs.microsoft.com/enterprisemobility/2018/03/05/azure-ad-and-adfs-best-practices-defending-against-password-spray-attacks/) outlines the recommended approach for forcing multi-factor authentication when using AAD and ADFS.

  2. Disable TLS 1.0

    At some point to maintain PCI compliance we will need to disable TLS 1.0. I have been told more than one time that we cannot disable TLS 1.0 now on our hybrid Exchange 2016 on-premise servers without losing functionality. We need a patch or update that would allow us to disable TLS 1.0 and still have full Exchange functionality.

    40 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    3 comments  ·  Advanced Security Management  ·  Flag idea as inappropriate…  ·  Admin →

    While it is likely that Office 365 will need to leave TLS 1.0 enabled broadly for the near future, we are rolling out TLS 1.2 by default which will allow us to publish updated guidance for Exchange on-premises. Please stay tuned to EHLO blog for further updates — several configuration changes will be necessary to ensure everything works smoothly.

  3. Allow use of TLS 1.1 and higher

    It would be nice to be able to remove TLS 1.0 from our current environments and be able to use our online services such as Skype for Business. Currently, we are unable to connect back to Skype after disabling TLS 1.0 in our environment. Is there a timeline for these changes?

    13 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    working on it  ·  1 comment  ·  Advanced Security Management  ·  Flag idea as inappropriate…  ·  Admin →
  • Don't see your idea?

Feedback and Knowledge Base