MFA helps secure user sign-ins for cloud services beyond just a single password. With MFA for Office 365, users are required to acknowledge a phone call, text message, or app notification on their smart phones after correctly entering their passwords. They can sign in only after this second authentication factor has been satisfied.

A form of multi-factor authentication is included with Office 365, but you can also purchase Azure Multi-Factor authentication that includes extended functionality. For more information see feature comparison of Azure Multi-Factor Authentication versions.

To set up multi-factor authentication for Office 365

1. Sign in to the Office 365 admin center.
2. In the admin center, choose users and groups > Active Users.
3. Next to Set Multi-factor authentication requirements, choose Set up.

• Find the user or users that you want to enable for MFA. In order to see all the users, you might need to change the view at the top.

The views have the following values based on the MFA state of the users:

Disabled

This is the default state for a new user not enrolled in multi-factor authentication.

Enabled

The user has been enrolled in multi-factor authentication, but has not completed the registration process. They will be prompted to complete the process the next time they sign in.

Enforced

The user may or may not have completed registration. If they have completed the registration process then they are using multi-factor authentication. Otherwise, the user will be prompted to completer the process at next sign-in

In non-browser apps (such as …Outlook etc.) will not work until app passwords are created and entered into the non-browser apps.

• Check the check box next to the names you chose.
• This will reveal two options on the right: Enable and Manage user settings. Choose Enable.
• In the dialog box that opens, choose enable multi-factor auth.

To allow MFA users to create App Passwords for Office client applications

1. Multi-factor authentication is enabled per user. This means that if a user has been enabled for multi-factor authentication and they are attempting to use non-browser clients, such as Outlook 2013 with Office 365, they will be unable to do so. An app password allows this to occur. An app password, is a password that is created within the Azure portal that allows the user to by-pass the multi-factor authentication and continue to use their application.

   Important   All the Office 2013 client applications support Multi-Factor Authentication through the use of the Active Directory Authentication Library (ADAL). This means that o app passwords are not required for Office 2013 clients.

   Sign in to the Office 365 admin center.

2. In the admin center, choose users and groups > Active Users.
3. Next to Set Multi-factor authentication requirements, choose Set up.
4. On the multi-factor authentication page, choose service settings.
5. Under app passwords, choose Allow users to create app passwords to sign into non-browser applications.

This allows users to use client Office applications, but they will have to enter a password of their choosing first.

1. Click Save, and then Close.

To manage user settings

1. Find the user or users you want to manage and select the checkbox next to their names.
2. This will bring up two options on the right, Enable and Manage user settings. Choose Manage User settings. In the dialog select one or more of Require selected users to provide contact methods again, Delete all existing app passwords generated by the selected users, or Restore Multi-Factor Authentication on all suspended devices. Make your selections and choose Save.

Bulk Update Options

GUI

1. Sign in to the Office 365 admin center.
2. In the admin center, choose users and groups > Active Users.
3. Next to Set Multi-factor authentication requirements, choose Set up.
4. On the multi-factor authentication page, you will find a "Bulk Update" button.

1. Clicking the button allows you to upload a CSV file with the list of users for whom multi-factor authentication is to be enabled.

    

   

    

    

PowerShell

1. Prerequisites: Download and Install the following modules.

   The Azure AD Module is supported on the following Windows operating systems with the default version of Microsoft .NET Framework and Windows PowerShell: Windows 8.1, Windows 8, Windows 7, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2.

   First install the Microsoft Online Services Sign-In Assistant for IT Professionals RTW from the Microsoft Download Center.

   Then install the Azure Active Directory Module for Windows PowerShell (64-bit version), and click Run to run the installer package.

2. Open Windows PowerShell
3. Run the following command.

   Get-ExecutionPolicy

   If the output is anything other than "unrestricted", run the following command.

   Set-ExecutionPolicy Unrestricted –Scope CurrentUser

   Confirm the change of settings.

4. NOTE: As of when I am writing this blog, it is a good idea NOT to enable multifactor authentication for an administrator who extensively uses PowerShell to administer Office 365. I have come across issues with authentication via PowerShell thereof.

    

5. Step 1: Connect to MsolService via PowerShell

   Running the command below will bring up a popup would require you to enter your Office 365 Administrator Credentials.

   $UserCredential = Get-Credential

   Import-Module MSOnline

   Connect-MsolService –Credential $UserCredential

    

6. Step 2: Run the following commands.

   $auth = New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement

   $auth.RelyingParty = "*"

    

7. Step 3: Choose the MFA State. (As documented above)

   You can choose between "Enabled" and "Enforced"

   $auth.State = "Enabled"

    

8. Step 4: Choose the date – Any devices issued for a user before this date would require MFA setup. Normally, we would select the date of running the command.

   $auth.RememberDevicesNotIssuedBefore = (Get-Date)

    

9. Command to Enable MFA for a single user.

   Set-MsolUser -UserPrincipalName <UserPrincipalName> -StrongAuthenticationRequirements $auth

    

10. Command to Enable MFA for all users.

    Get-MsolUser –All | Foreach{ Set-MsolUser -UserPrincipalName $_.UserPrincipalName -StrongAuthenticationRequirements $auth}

     

Wrap up tasks

• Please read the deployment guide if you haven't already.
• If your users do not regularly sign in through the browser, you can send them to this link to register for multi-factor auth: https://aka.ms/MFASetup

   

Have a nice day!

Who am I?
https://in.linkedin.com/in/anshumanmansingh

Objective: Providing non-Full Access Permission on a Discovery Mailbox (Exchange Online) and opening it in outlook.

You can have one of the following "Access Rights" on a Discovery Mailbox.

• FullAccess
• ExternalAccount
• DeleteItem
• ReadPermission
• ChangePermission
• ChangeOwner

Create a discovery mailbox

This example creates a discovery mailbox named SearchResults.

New-Mailbox -Name SearchResults -Discovery

For detailed syntax and parameter information, see New-Mailbox.

To display a list of all discovery mailboxes in an Exchange organization, run the following command:

Get-Mailbox -Resultsize unlimited -Filter {RecipientTypeDetails -eq "DiscoveryMailbox"}

For detailed syntax and parameter information, see Get-Mailbox.

Assign permissions to a discovery mailbox

You have to explicitly assign users or groups the necessary permissions to open a discovery mailbox that you've created. Run the following command to assign a user or group permissions to open a discovery mailbox and view search results:

Add-MailboxPermission <Name of the discovery mailbox> -User <Name of user or group> -AccessRights FullAccess -InheritanceType all

For example, the following command assigns the Full Access permission to the Litigation Managers group, so members of the group can open the Fabrikam Litigation discovery mailbox.

Add-MailboxPermission "Fabrikam Litigation" -User "Litigation Managers" -AccessRights FullAccess -InheritanceType all

For detailed syntax and parameter information, see Add-MailboxPermission.

However, viewing the content of a Discovery Mailbox, when the user does not have a full mailbox access has been a bit tricky.

One of the ways that I have tried is by providing a per folder "Reviewer" access.

For instance, if I were to provide Mailbox-Folder permission to Ashlyn (UPN: ashlyn@microsoftace.onmicrosoft.com), I can do so with the following command

Add-MailboxFolderPermission -Identity SearchResults -User ashlyn@microsoftace.onmicrosoft.com -AccessRights Reviewer

However, the above provides permission on the Information Store (Root) Folder. To assign a more granular permission (to rest of the folders) – execute the below command.

foreach($item in (Get-MailboxFolderStatistics SearchResults |where { ($_.foldertype -ne "ConversationActions") -and ($_.foldertype -notlike "Recoverable*") -and ($_.FolderPath -notlike "/Sync*")})){$fname = "SearchResults:" + $item.FolderPath.Replace("/","\"); Add-MailboxFolderPermission $fname -User ashlyn@microsoftace.onmicrosoft.com -AccessRights Reviewer}

The AccessRights (for Add-MailboxFolderPermission) parameter specifies the permissions for the user with the following access rights:

• ReadItems   The user has the right to read items within the specified folder.
• CreateItems   The user has the right to create items within the specified folder.
• EditOwnedItems   The user has the right to edit the items that the user owns in the specified folder.
• DeleteOwnedItems   The user has the right to delete items that the user owns in the specified folder.
• EditAllItems   The user has the right to edit all items in the specified folder.
• DeleteAllItems   The user has the right to delete all items in the specified folder.
• CreateSubfolders   The user has the right to create subfolders in the specified folder.
• FolderOwner   The user is the owner of the specified folder. The user has the right to view and move the folder and create subfolders. The user can't read items, edit items, delete items, or create items.
• FolderContact   The user is the contact for the specified folder.
• FolderVisible   The user can view the specified folder, but can't read or edit items within the specified folder.

The AccessRights parameter also specifies the permissions for the user with the following roles, which are a combination of the rights listed previously:

• None   FolderVisible
• Owner   CreateItems, ReadItems, CreateSubfolders, FolderOwner, FolderContact, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
• PublishingEditor   CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
• Editor   CreateItems, ReadItems, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
• PublishingAuthor   CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, DeleteOwnedItems
• Author   CreateItems, ReadItems, FolderVisible, EditOwnedItems, DeleteOwnedItems
• NonEditingAuthor   CreateItems, ReadItems, FolderVisible
• Reviewer   ReadItems, FolderVisible
• Contributor   CreateItems, FolderVisible

The following roles apply specifically to calendar folders:

• AvailabilityOnly   View only availability data

LimitedDetails   View availability data with subject and location

Opening the Discovery Mailbox in Outlook

And now you will be able to open the Discovery Mailbox in Outlook.

You may run into issues there. Follow the screenshots.

Click on File

Click on "Open & Export" and then on "Other User's Folder"

Click on "Name" Button

Click on "Advanced Find"

Type in the name of the discovery mailbox

If it does not yield any results, click on the "Address Book" drop down and select "Global Address List"

Type in the name of the discovery mailbox in the search field and click on "Go"

The discovery mailbox should appear – and thereof can be selected.

Click on "OK"

And the discovery mailbox opens up.

Live long and prosper!

_Anshuman

Objective:

A configuration to process all emails and,

1. If the email is found to have Sensitive Information (like SSN, DEA number etc. IP Address in this example.), send it for approval before being delivered to the recipient.
2. If approved, apply Office 365 Message Encryption, before delivery.

    

Here's how it is working.

1. Created a mailflow rule to check for Condition 1, and if the email meets criteria – send for approval.

   If sensitive information types like SSN or ITIN are defined in this condition, policy tips can be activated.

2. Created a second mailflow rule with the next priority to encrypt any email that meets Condition 1.

Screenshot 1 – My test policy tips get activated for IP Addresses

Screenshot 2 – Approval Request.

Screenshot 3 – Final Message in Recipient's Mailbox – Encrypted.

Screenshot 4 – Rule 1

Screenshot 5 – Rule 2