Register For Azure AD MFA From On-Premises Or Known Networks Only

Posted on 8 CommentsPosted in Azure Active Directory, Azure AD, conditional access, enterprise mobility + security, Office 365, security, self-service password reset, sspr

A long request within Azure AD/Office 365 has been the request to be able to register your security info from a known location or only on certain other conditions. Well it looks like this has appeared in Azure AD in the last few days!!

Its visible under Azure AD > Conditional Access > New/Existing Policy > Cloud Apps or Actions:

image

So, what does this look like in practice? Lets put this preview to the test.

Create the Conditional Access Policy for User Actions

Open the Azure AD portal at https://aad.portal.azure.com and click Enterprise Applications

From here click Conditional Access (this is also accessible under Azure AD > Security as well)

Click Add Policy and give the policy a name. I have chosen “Register Security Information On-Premises” for here

Click Users and Groups. I have selected “Users and Groups” rather than “All Users” as I plan to test this out first! I have picked the group that I use for testing Conditional Access changes. Eventually I will change this to All Users so that no-one can register security info apart from when on a trusted location. Note that this would also I think include guest users – I need to test that! Guest users are by their very nature not on my network but I might have MFA required for them – so they need to register, but I don’t want to apply the below to them

image

Select Cloud Apps or Actions (this was recently renamed to support this functionality we are describing here)

Select User Actions in the slider and check the option for Register Security Information (Preview)

Select Conditions and select the conditions you want to apply when users are registering security information. Its probably location based, so I will set that up here.

Select Locations, click Yes under Configure and select Any Location under Include and then under Exclude select Trusted Locations. Note that you need to have set up trusted locations in Conditional Access as well – I’m going to assume the public IP of all your offices is added and marked as trusted.

This setting will ensure that all locations other than trusted locations cannot register security information – note that this is the reverse of what you might expect. We need to block the locations we don’t want to access the MFA/SSPR registration process rather than the reverse. This is because we are required to add a control to the rules

image

With Azure AD P2 licences you could user a sign-in risk condition, ensuring that registration does not happen on medium or high risk sign-ins!

Click Done to bring you back to the first blade of settings and set Enable Policy to On to turn on this feature

Under Access Controls, click Grant and choose Block Access – be very careful here – don’t block all your access to everything!

image

Click Done

This takes us back to the first blade in the Conditional Access settings.

Click On in the Enable Policy slider

Now the Create button is available – this is not available if you do not create the reverse of what you might expect to do – block unknown locations rather than allow trusted locations!

image

Click Create

You will get your notification – you can test this in a few minutes:

image

Enable The New Combined MFA/SSPR Registration Page

Though I noticed that this conditional access restriction works against the older MFA registration page, Microsoft have said in their release blog article for this feature that it will only work against the new MFA/SSPR combined registration page. Therefore you should turn this on for your users impacted by the above policy – initially for your pilot users and then for all users.

See https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Cool-enhancements-to-the-Azure-AD-combined-MFA-and-password/ba-p/354271 for more on setting up the combined MFA/SSPR registration page.

Testing Register Security Information (Preview)

In an in-private browser session on the Wi-Fi of your favourite coffee company, browse to https://aka.ms/mfasetup (as this is not a trusted location!)

After logging in you would expect to be take to the registration page for MFA and SSPR – but you are not!

image

Repeat your test from on-premises, and you will get the MFA and SSPR registration pages (or both if you have the new combined MFA+SSPR wizard enabled):

Note that for a brand new user where you have SSPR enabled, they are required to register by default every 180 days. This will mean they have to register at first login – therefore first login needs to be from a trusted network (in this example) – you could use Trusted Device as the only place to register from, but adding a user to a trusted device requires MFA by default, so watch out for an issue here and if you want to do this, test it very well.

I have not had the opportunity to test this with the 180 day refresh of your settings – presumably that should work from any location and only changing them would be blocked, but this is something that needs to be tried out.

Review and Audit Offensive Language in Office 365 Communications

Posted on Leave a commentPosted in cyber bullying, exchange, exchange online, Exchange Server, offensive, Office 365, supervision

A new feature as of May 2018 in Office 365 is to filter communications based upon the offensive language machine learning filter. This is part of the Supervision settings that have been available for a number of years. The Offensive Language model uses a combination of machine learning, artificial intelligence, and keywords to identify inappropriate email messages as part of anti-harassment and cyber bullying monitoring requirements.

Here we will walk through the process of setting up the offensive language filter and testing it out (without offending anyone)!

Setting Up Offensive Language Supervision

Open the Compliance Center at https://compliance.microsoft.com and select Supervision on the left as shown:

image

At the time of writing, the Compliance Center is new and not everything is visible here. By the time you read this article it might be possible to create your supervision reviews from this portal, but for now we need to go to the Security and Compliance Center – so click the link at the top of the page. You will see this:

image

If you cannot see this then you do not have the right permissions. Add yourself to the Supervisory Review role group so you can set up policies. Anyone who has this role assigned can access the Supervision page in the Compliance Center.

Click Create to create a supervision review. Enter a name and a description. You cannot change the name later on.

image

In the next page, select the users to supervise. Start with a test group before editing this policy to add a group that contains everyone.

image

You can also select users who are in the group and specifically exclude them if needed. Communications via Exchange and Teams are included by default. Third party sources can be added as well.

Click Next and move to the Choose communications to review tab. Here select Internal communications (which is not selected by default) and choose Use match data model condition. There is only one model, and that is the Offensive Language model – so that gets selected by default.

image

If you want to scope the filter a bit more then you can select Add a condition and set up rules – for example you could exclude a specific domain inbound.

Click Next and get to the Specify percentage to review tab

image

Here you get to set the percentage of communications to review. The default is 10%. This means that only 10% of all communications are reviewed, and the results you see are based on what was found in that 10%. In large organizations, 10% could be a lot of communications, and therefore could be a fair amount of offensive content. Therefore ensure both your reviewers are able to manage the review process without undue impact and understand that whatever you find – there is 10 times more of it happening. Smaller organizations might want to increase the percentage to review, or at least consider increasing the percentage to review.

Click Next and enter the email addresses of the reviewers. They need to have an Exchange Online mailbox to be able to do this, but the content for review does not go into the reviewers mailbox.

image

Click Next and get to the Review your settings tab. Check everything is okay and click Finish.

image

Your policy will be listed so that you can update it, apart from the name, in the future.

The policy is also displayed in a pop-out as shown:

image

In this pop-out you can see the name of the mailbox that the content for review will go into – therefore those users who are reviewers will need to have access to this mailbox if they want to use Outlook to do their review process. If the reviewers have access to the Compliance Center then review can be done there instead of in Outlook/OWA. Permissions need to be granted to the mailbox using PowerShell. The two cmdlets are, using your supervisory review mailbox as listed in the policy results.

Add-MailboxPermission "SupervisoryReview{GUID}@domain.onmicrosoft.com" -User "alias or email address of the account that has reviewer permissions to the supervision mailbox" -AccessRights FullAccess
Set-Mailbox "SupervisoryReview{GUID}@domain.onmicrosoft.com" -HiddenFromAddressListsEnabled: $false

You can add “-AutoMapping $false” to the Add-MailboxPermission if you want the review mailbox not always to appear as an additional mailbox in Outlook.

To Review Your Supervision Policy

In the Supervision Review pop-out (which you can get back by clicking on the policy name), click Open at the top.

This takes you to:

image

Here I can see I have nothing to review or pending items to look at. If you want to test this, think of something offensive and send it to yourself! It might turn up in the review portal, or it might not – remember only 10% of communications are subject to review.

Note: Emails subject to defined policies are processed in near real-time and can be tested immediately after the policy is configured. Chats in Microsoft Teams can take up to 24 hours to fully process in a policy.

I’m not going to send anything, but I will take a look back here later and I might update this blog if I ever get any hits!

To review the content, the menu across the top for Review and Resolved Items will show you the items and those that have been resolved. The actual HR and discipline process is obviously not covered by anything in this review process. Once resolved in the company, mark it as resolved here.

In OWA, you can open an additional mailbox and enter “super” and the supervisoryreview{GUID} mailbox appears:

image

Inside the supervisory review mailbox, there is a folder for the policy you just created and inside that are subfolders that indicate review (Non-Compliant and Questionable) and Resolved:

image

Blocking Offensive Language

This is just a review process. If you want to block content, then create a DLP policy that uses a dictionary of words to block. For more on the dictionary creation see https://docs.microsoft.com/en-us/office365/securitycompliance/create-a-keyword-dictionary

Read Only And Document Download Restrictions in SharePoint Online

Posted on Leave a commentPosted in AADConnect, AADSync, active directory, Azure Active Directory, Azure AD, compliance, conditional access, device, download, enterprise mobility + security, exchange online, microsoft, Office 365, OneDrive, OneDrive For Business, sharepoint, Uncategorized

Read Only And Document Download Restrictions in SharePoint Online

Both SharePoint Online (including OneDrive for Business) and Exchange Online allow a read only mode to be implemented based on certain user or device or network conditions.

For these settings in Exchange Online see my other post at https://c7solutions.com/2018/12/read-only-and-attachment-download-restrictions-in-exchange-online.

When this is enabled documents can be viewed in the browser only and not downloaded. So how to do this.

Step 1: Create a Conditional Access Policy in Azure AD

You need an Azure AD Premium P1 licence for this feature.

Here I created a policy that applied to one user and no other policy settings. This would mean this user is always in ReadOnly mode.

In real world scenarios you would more likely create a policy that applied to a group and not individual users and forced ReadOnly only when other conditions such as non-compliant device (i.e. home computer) where in use. The steps for this are:

imageimageimageimage

The pictures, as you cannot create the policies in the cmdline, are as follows:

  1. New policy with a name. Here it is “Limited View for ZacharyP”
  2. Under “Users and Groups” I selected my one test user. Here you are more likely to pick the users for whom data leakage is an issue
  3. Under “Cloud apps” select Office 365 SharePoint Online. I have also selected Exchange Online, as the same idea exists in that service as well
  4. Under Session, and this is the important one, select “Use app enforced restrictions”.

SharePoint Online will then implement read only viewing for all users that fall into this policy you have just created.

Step 3: View the results

Ensure the user is licensed for SharePoint Online (and a mailbox if you are testing Exchange Online) and an Azure AD Premium P1 licence and ensure there is a document library with documents in it for testing!

Login as the user under the conditions you have set in the policy (in my example, the conditions where for the specific user only, but you could do network or device conditions as well.

SharePoint and OneDrive Wizard Driven Setup

For reference, in the SharePoint Admin Centre and Policies > Access Control > Unmanaged Devices, here you turn on “Allow limited web-only access” or “Block access” to do the above process of creating the conditional access rule for you, but with pre-canned conditions:

image

In the classic SharePoint Admin Center it is found under that Access Control menu, and in SharePoint PowerShell use Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess

Turning the settings on in SharePoint creates the Conditional Access policies for you, so for my demo I disabled those as the one I made for had different conditions and included SharePoint as well as a service. This is as shown for SharePoint – the banner is across the top and the Download link on the ribbon is missing:

image

And for OneDrive, which is automatic when you turn it on for SharePoint:

image

Save Time! Have All Your Meetings End Early

Posted on 4 CommentsPosted in calendar, exchange online, Exchange Server, monthly channel, Office 365, Office 365 ProPlus, Outlook, semi-annual channel

I am sure you have been in a meeting, where the meeting end time rolls around and there is a knock at the door from the people who want the meeting room now, as their meeting time has started and yours has finished.

What if you could recover five, eight, ten or more minutes per meeting so that the next meeting party can get into the room on time, and you have time to get out and get to your next meeting, and be on time.

Well since the beginning of 2019, Microsoft have come to your rescue.

image

The above are the new calendar “End appointments and meetings early” option. It is available in Outlook for Windows that is part of Office 365 ProPlus and you need to have a version of the software released new in 2019 for the feature to be available – more on the version and what to do in the technical section below.

The above option is found from File > Options > Calendar and then looking under Calendar Options as shown.

Check the option ”End appointments and meetings early” and then choose the time that a meeting under 1 hour will end early, and you can choose 5, 8 or 10 minutes, and then a second option for meetings over 1 hour – these can end 5, 10 or 15 minutes early. You can also enter your own preferred end early time.

Click OK and go create a new meeting. It should not matter how you create the meeting.

As you can see from my options above, my default meeting is 30 minutes – so on creating a new meeting I see the following:

image 

I’ve highlighted the new end time – its 25 minutes after the meeting starts! The adjustment applies to the default meeting length and shortens it for me.

If for this meeting I want it to be the full 30 minutes, I can just write in the new time – all Outlook is doing is setting a new adjustable default for me.

For meetings where you drag out a custom duration in your calendar – it works here as well:

image

As you can see I have dragged out 1pm to 4pm on Thursday. Look what happens when I enter some text for the meeting subject:

image

The meeting is created with an end time ten minutes early (my preferred time saving duration for meetings over one hour). As with the above, I can adjust the time of this meeting to the full hour if I want to very easily – just drag the meeting block to the full hour and it is kept. Its just the default time when I first create the meeting that is adjusted.

Note that existing meetings are not changed – but if you go into an existing meeting and look at the end time drop down, you will see suggestions for the duration that take the early end time into consideration:

image

So, that’s how you can save time on your meetings (or at least one way, being prepared for them is another and technology cannot help there – yet!)

Changing The Defaults For Everyone

But what if you are the HR department or the representative of the department for digital change – what if you want to try and improve company culture and change these defaults across the board – well this is a job for IT, but they can easily roll out a setting to all your computers that set a end early time for both short and longer meeting durations.

They need to deploy a group policy setting that changes the registry at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\Calendar and updates both EndEarlyShort and EndEarlyLong values as well as the EndEventsEarly key. EndEarlyShort is of course the value that affects meetings under one hour – and you do not need to accept the Microsoft suggested durations of 5, 8 and 10 minutes. For example if I edit this DWORD registry key and set the value to 3, upon restarting Outlook my new meetings under one hour end three minutes early:

image

The EndEventsEarly value is the setting that turns the feature on. So as well as setting the end early times, you need to set this value to 1 as well.

If you want to roll out this change centrally and ensure that the end user cannot set their own custom end early time then you can change the registry key policy settings via HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Calendar. Changes in this registry location mean the user cannot adjust the end early times.

image

You can disable this option centrally as well by setting EndEventsEarly DWORD value to 0 – this has the effect of disabling the check box and so users cannot turn the option on.

All these three settings are included in the latest update to the Office365 Administrative Templates, available on Microsoft Download Center: https://www.microsoft.com/en-us/download/details.aspx?id=49030 as well.

Checking Your Outlook Version

Version 1812 or later in use on the Monthly Channel is required before you can use this feature. In most businesses you are probably using the Semi-Annual channel, and this has features deferred by at least six months. So to check, click File > Office Account in any Office application (shown below). To the right hand side you will see the below. You need to check you are running the Subscription Product and that under About Outlook (or whatever Office app you are checking), it reads Version 1812 or later and Monthly Channel. The Semi-Annual Channel is released in January and July each year and is deferred by at least six months, so as this feature was released in Dec 2018, this feature will not appear in the Semi-Annual Channel until at least July 2019 – build 1812 of the Semi-Annual Channel (and possibly not until build 1907). More on this release cycle can be found at https://docs.microsoft.com/en-us/deployoffice/overview-of-update-channels-for-office-365-proplus

image

Convert Office 365 Group to Microsoft Team Totally Failing

Posted on Leave a commentPosted in groups, Microsoft Teams, Office 365, Office 365 Groups, Teams

This one has been annoying me for a while – I had an Office 365 Group that I created many years ago in Office 365 that I cannot convert to a Microsoft Team.

This is what I see in Teams to do this process. First, click “Create a team”

image

Followed by “Create a team from an existing Office 365 group” which is found at the bottom of the creation dialog in the Teams app:

image

I get a list of Office 365 Groups but not the one I want. In my example I see six groups:

image

The rules for converting an Office 365 Group to a Team is the following:

  • Must be private
  • Must have an owner

Both of these are true for the group I want to convert, but the group still does not appear in the Teams conversion page shown above:

So I resort to PowerShell:

Get-UnifiedGroup returns all my groups and shows that the group exists (I know it does – its got content in it!)

image

So I get the Group ID using Get-UnifiedGroup <name> | FL *id*

image

Specifically I am after the ExternalDirectoryObjectID value

Then I try to make a new Team using PowerShell using the ExternalDirectoryObjectID. This is New-Team -Group <ExternalDirectoryObjectID>

image

I get back a lot of red text. In this is reads “Message: Team owner not found”. This is odd, as the Team does have an owner – I can see this in OWA for the Office 365 Group

image

And I can see this using Get-UnifiedGroupLinks as well:

image

So I decide to set the owner back to the owner again using Add-UnifiedGroupLinks PowerShell cmdlet (Add-UnifiedGroupLinks <group_name> -Links <myemailaddress> -LinkType Owner)

image

This returns nothing, so I presume nothing has changed.

I take a look in New Team > Convert Group option – and as if by magic, I can see the Office 365 Group I want to make into a Team

image

Its the one at the top in all these redacted images – the logo matches the group above, and I now have seven Office 365 Groups that are candidates for Teams.

Conversion then happens seamlessly!

Public Folder Sync–Duplicate Name Error

Posted on Leave a commentPosted in AADConnect, exchange, exchange online, Exchange Server, migration, Office 365, Public Folders

I came across this error with a client today and did not find it documented anywhere – so here it is!

When running the Public Folder sync script Sync-ModernMailPublicFolders.ps1 which is part of the process of preparing your Exchange Online environment for a public folder migration, you see the following error message:

UpdateMailEnabledPublicFolder : Active Directory operation failed on O365SERVERNAME.)365DATACENTER.PROD.OUTLOOK.COM. The
object ‘CN=PublicFolderName,OU=tenant.onmicrosoft.com,OU=Microsoft Exchange Hosted
Organizations,DC=)365DATACENTER,DC=PROD,DC=OUTLOOK,DC=COM’ already exists.
At C:\ExchangeScripts\pfToO365\Sync-ModernMailPublicFolders.ps1:746 char:9
+         UpdateMailEnabledPublicFolder $folderPair.Local $folderPair.Remote;
+         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,UpdateMailEnabledPublicFolder

This is caused because you have a user or other object in Active Directory that has the same name as the mail enabled public folder object.

In Exchange Online PowerShell if you run Get-User PublicFolderName you should not get anything back, as its a Public Folder and not a user, but where you see the above error you do get a response to Get-User (or maybe Get-Contact or any other object that is not a Public Folder. This class of object name (common name or cn) means the script can create the public folder in the cloud, but not update it on subsequent runs of the script.

The easiest fix is to rename the common name of the public folder object in Active Directory for all clashing public folders, unless you know you do not need the other object that clashes – as renaming that and letting AADConnect sync process the change is another way to resolve this.

To rename the mail public folder, in Exchange Server management shell run Set-MailPublicFolder PublicFolderName –Name NewPublicFolderName

I have changed my names to start with pf, so PublicFolderName becomes pfPublicFolderName and then the script runs without issue.

Configuring Multi Factor Authentication For Office 365

Posted on 3 CommentsPosted in MFA, Office 365

Given that Office 365 is a user service, the enabling of multi-factor authentication is very much as admin driven action – that is the administrators decide that the users should have it, or that it is is configured via Conditional Access when limiting the login for the user to certain applications and locations.

For a more security conscious user, enabling it themselves if harder! To do this, follow these steps:

  1. Go to My Apps – https://myapps.microsoft.com
  2. Click your picture icon top right and choose Profile from the menu
  3. Click Additional Security Verification from the menu to the right
  4. Select your preferred method of second factor of authentication from the first drop-down box. You need to ensure that the option you choose is enabled below.

You will now be prompted for your second authentication factor that you choose when you try to do a password change or change your verification info.

SSL Inspection and Office 365

Posted on Leave a commentPosted in Azure, Azure Information Protection, cloud, firewall, Office 365, proxy, SSL

Lots of cloud endpoint URL’s break service flow if you enable SSL Inspection on the network devices between your client and the service. My most recent example of this Enterprise State Routing in Windows 10.

Microsoft have a list of URLs for the endpoints to their service, where they are categorised as Default, Allow or Optimize. The URLs that are Allow or Optimize should avoid SSL inspection.

The endpoint list is found at https://support.office.com/en-us/article/managing-office-365-endpoints-99cab9d4-ef59-4207-9f2b-3728eb46bf9a#webservice and the JSON for this can be downloaded, as well as a PowerShell script to return the IPs and URLs.

Within this JSON file you can look for the category and if the category is Allow or Optimize then ensure the matching URLs are not SSL inspected.

Improving Password Security In the Cloud and On-Premises

Posted on 1 CommentPosted in active directory, Azure Active Directory, Azure AD, AzureAD, EM+S, enterprise mobility + security, microsoft, Office 365, password, security

Passwords are well known to be generally insecure the way users create them. They don’t like “complex” passwords such as p9Y8Li!uk%al and so if they are forced to create a “complex” password due to a policy in say Active Directory, or because their password has expired and they need to generate a new one, they will go for something that is easy to remember and matches the “complexity” rules required by their IT department. This means users will go for passwords such as WorldCup2018! and Summ3r!!. Both these exceed 8 characters, both have mixed case, both have symbols and numbers – so both are complex passwords. Except they are not – they are easy to guess. For example, you can tell the date of this blog post from my suggestions! Users will not tend to pick passwords that are really random and malicious actors know this. So current password guidance from NIST and UK National Cyber Security Centre is to have non-expiring unknown, not simple passwords that are changed on compromise. Non-expiring allows the user to remember it if they need to (though a password manager is better) and as it is unknown beforehand (or unique) means its not on any existing password guess list that might exist.

So how can we ensure that users will choose these passwords! One is end user training, but another just released feature in the Microsoft Cloud is to block common passwords and password lists. This feature is called Azure AD Password Protection. With the password management settings in Azure AD, cloud accounts have been blocked from common passwords for a while (passwords that Microsoft see being used to attempt non-owner access on accounts) but with the password authentication restrictions you can link this to block lists and implement it with password changes that happen on domain controllers.

So how does all this work, and what sort of changes can I expect with my passwords.

Well what to expect can look like this:

image

Note all the below is what I currently know Microsoft do. This is based on info made public in November 2018 and documented at https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad and is subject to change as Microsoft’s security graph and machine learning determines change is needed to keep accounts secure.

Password Scoring

First, each password is scored when changed or set by an administrator or a user on first use. A password with a score less than 5 is not allowed. For example:

spring2018 = [spring] + [2018] = 2 points

spring2018asdfj236 = [spring] + [2018] + [asdf] + [f] + [j] + [2] + [3] + [6] = 8 points

This shows that common phrases (like Spring and 2018) can be allowed as part of password that also contains stuff that is hard to guess. In this, the asdf pattern is something straight from a Qwerty keyboard and so gets a low score. In addition to the score needing to exceed 5, other complexity rules such as certain characters and length are still required if you enforce those options. Passwords are also “normalized”, which lower cases them and compares them in lower case – so spRinG2018 is as weak as spring2018. Normalization also does common character replacesments such as $=s, so $PrinG2018 is the same as spring2018 and also just as weak!

You name is not allowed in any password you set and the logic applies to an edit distance of 1 character – that is if “spring” is a blocked word then “sprinh” would also be blocked, h being one character away from g.

Common and Blocked Lists

Microsoft provide the common password lists, and these change as Microsoft see different passwords getting used in account attacks. You provide a custom blocked list. This can contain up to 1000 words, and Microsoft apply fuzzy logic to yours and the common list. For example we added all our office locations as shown:

image

This means that both capetown and C@p3t0wn would be blocked. The @=a, the 3=e and the 0=o. So the more complex one is really not complex at all as it contains common replacements.

In terms of licences, the banned password list that Microsoft provides is licence free to all cloud accounts. You need AAD Basic if you want to add your own custom banned password list. For accounts in Windows Server Active Directory you need the Azure AD Premium (P1) licence for all synced users to allow downloading of the banned password list as well as customising it with your words so that Active Directory can apply it to all users on-premises to block bad passwords (even those users not synced to AzureAD).

Hybrid Password Change Events Protected

The checks on whether a password change should be stopped is included in hybrid scenarios using self-service password reset, password hash sync, and pass-through authentication, though changes to the custom banned password list may take a few hours to be applied to the list that is downloaded to your domain controllers.

On-Premises Changes

There is an agent that is installed on the domain controllers. Password changes are passed to the agent and it checks the password against the common list and your blocked list. The agent does the password check, and it checks it against the most recently downloaded list from Azure AD. The password for on-premises is not passed up to Azure AD, the list is downloaded from Azure AD and processed locally on the domain controller. This download is done by the Azure AD password protection proxy. The list is then downloaded once per hour per AD site to include the latest changes. If your Azure AD password protection proxy fails, then you just use the last list that was successfully downloaded. Password changes are still allowed even if you lose internet access.

Note that the Azure AD password protection proxy is not the same as the Pass-Through Authentication agent or the AAD Connect Health agent. The Azure AD password protection proxy can though be installed on the same servers as the PTA or Connect Health agent. Provisioning new servers for the proxy download service are not required.

The Azure AD password protection proxy wakes up hourly, checks SYSVOL to see the timestamp of the most recently downloaded copy and decides if a new copy is needed. Therefore if your intra-site replication is within the hour, proxy agents in other sites might not need to download the list as the latest is already available via DFSR between the domain controllers.

The Azure AD password protection proxy does not need to run on a domain controller, so your domain controllers do not need internet access to obtain the latest list. The Azure AD password protection proxy downloads the list and places it in SYSVOL so that DFSR replication can take it to the domain controller that needs it.

Getting Started

To set a custom password block list, in the Azure Portal visit the Azure AD page, click Security and then click Authentication Methods (in the Manage section). Enter your banned passwords, lower case will do as Microsoft apply fuzzy logic as described above to match your list to similar other values. Your list should include common words to your organization, such as location, office address keywords, functions and features of what the company does etc.

For Active Directory, download the agent (from the Microsoft Download Center) to one or more servers (for fault tolerance). These will download the latest list and place it in SYSVOL so that the domain controllers can process it. Two servers in two sites would probably ensure one of them is always able to download the latest copy of the list.

The documentation is found at https://aka.ms/deploypasswordprotection.

Microsoft suggests that any deployment start in audit mode. Audit mode is the default initial setting where passwords can continue to be set even if they would be blocked. Those that would fail in Enforce mode are allowed in Audit mode, but when in audit mode entries in the event log record the fact that the password would fail if enforce was turned on. Once proxy server(s) and DC agents are fully deployed in audit mode, regular monitoring should be done in order to determine what impact password policy enforcement would have on users and the environment if the policy was enforced.

This audit mode allows you to update in-house policy, extend training programs and offer password advice and see what users are doing that would be considered weak. Once you are happy that users are able to respond to an password change error because the password is too weak, move to enforce mode. Enforce mode should kick in within a few hours of you changing it in the cloud.

Installing the Proxy and DC Agent

Domain Controllers need to be running Windows Server 2012 and later, though there are no requirements for specific domain or forest functional levels. The Proxy software needs to run on a Windows Server 2012 R2 or later server and be running .NET 4.6.2 or later. Visit the Microsoft Download Center to download both the agent and the password protection proxy. The proxy is installed and then configured on a few (two at most during preview) servers in a forest. The agent is installed on all domain controllers as password changes can be enacted on any of them.

To install the agent, run AzureADPasswordProtectionProxy.msi on the server that has internet connectivity to Azure AD. This could be your domain controller, but it would need internet access to do this.

To configure the agent, you need to run once Import-Module AzureADPasswordProtection followed by Register-AzureADPasswordProtectionProxy and then once the proxy is registered, register the forest as well with Register-AzureADPasswordProtectionForest all from an administrative PowerShell session (enterprise admin and global admin roles required). Registering the server adds information to the Active Directory domain partition about the server and port the proxy servers can be found at and registering the forest settings ensure that information about the service is stored in the configuration partition.

Import-Module AzureADPasswordProtection
Get-Service AzureADPasswordProtectionProxy | FL
$tenantAdminCreds = Get-Credential
Register-AzureADPasswordProtectionProxy -AzureCredential $tenantAdminCreds
Register-AzureADPasswordProtectionForest -AzureCredential $tenantAdminCreds

If you get an error that reads “InvalidOperation: (:) [Register-AzureADPasswordProtectionProxy], AggregateException” then this is because your AzureAD requires MFA for device join. The proxy did not support MFA for device join during the early preview but that should now be resolved – make sure you are using the latest download of the agent and proxy code. you need to disable this setting in Azure AD for the period covering the time you make these changes – you can turn it back on again (as on is recommended) once you are finished configuring your proxy servers. This setting, should you need to disable it, is found at:

  • Navigate to Azure Active Directory -> Devices -> Device settings
  • Set “Require Multi-Factor Auth to join devices” to “No”
  • As shown
    image
  • Then once the registration of your two proxies is complete, reverse this change and turn it back on again.

Once at least one proxy is installed, you can install the agent on your domain controllers. This is the AzureADPasswordProtectionDCAgent.msi and once installed requires a restart of the server to take its role within the password change process.

The PowerShell cmdlet Get-AzureADPasswordProtectionDCAgent will report the state of the DCAgent and the date/time stamp of the last downloaded password block list that the agent knows about.

image

Changes In Forest

Once the domain controller the agent is installed on is rebooted, it comes back online, finds the server(s) running the proxy application and asks it to download the latest password block list. The proxy downloads this to C:\Windows\SYSVOL\domain\AzureADPasswordProtection. Older versions of the proxy and agent used a folder called
{4A9AB66B-4365-4C2A-996C-58ED9927332D} under Policies folder. These versions of the agent stop working in July 2019 and need to be updated to the latest release.

In the Configuration partition at CN=Azure AD Password Protection,CN=Services,CN=Configuration,DC=domain,DC=com some settings about the service are persisted. If the domain controller has the agent installed then

CN=AzureADConnectPasswordPolicyDCAgent,CN=<DomainControllerName>,OU=Domain Controllers,DC=domain,DC=com is created.

And then on each domain controller, in the Event Viewer, you get Application and Services Logs > Microsoft > AzureADPasswordProxy with DCAgent on the DC’s and ProxyService on the proxy servers. The EventID’s are documented at https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-monitor.

The monitoring Event ID will cover things like user password change differently than admin password set. This allows you to audit who (end user or service desk) is setting weak passwords.

Once the proxy starts to work, the above folder starts to get content. In my case in the preview it took over 2 hours from installing the proxy as well as the documented installation and configuration PowerShell cmdlets listed above to get the proxy to download anything. The above listed Configuration folder contained some cfge files and the above listed PasswordPolicies contains what I assume is the downloaded password block list, compressed as its only 12KB. This is the .ppe file and there is one of these per hour downloaded. Older versions of this download are deleted by the proxy service automatically.

Audit Mode

Using the above Event ID’s you can track the users who have changed to weak passwords (in that they are on your or Microsoft’s banned password list) when the user or admin sets (or resets) the users password. Audit mode does not stop the user choosing the password that would “normally have been rejected” but will record different Event IDs depending upon the activity and which block list it would have failed against. Event id DCAgent/30009 for example has the message “The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted.”. This message is a failure against Microsoft’s list on password set. The user doing a password change and the Microsoft list gets DCAgent/30010 Event ID recorded instead.

Using these two Event ID’s along with DCAgent/30007 (logged when password set but fails your custom list) and or DCAgent/30008 (password changed, fails your custom list) allows you to audit the impact of the new policy before you enforce it.

Enforce Mode

This mode ensures that password set or change events cannot have passwords that would fail the list policies. This is enabled in the password policy in Azure AD as shown:

image

Once this is enabled it takes a few hours to be picked up by the proxy servers and then for the agent to start rejecting banned passwords.

When a user changes their password in enforce mode they get the following error (different graphic depending upon Windows versions). If the admin changing the password uses a blocked password then they see the left hand graphic as well (Active Directory Users and Computers).

image
image

or

This is no different to the old error you get when your password complexity, length or history is not met. Therefore there is no indication to the user that the password they chose might be banned rather than not allowed for the given reasons. So though password policy with a banned list is an excellent step forward, there needs to be help desk and end user awareness and communications (even if they are just a simple notification) as the user would not be able to tell from the client error they get. Maybe Microsoft have plans to update the client error?

Password changes that fail once enforce mode is enabled get Event ID’s such as DCAgent/30002, DCAgent/30003, DCAgent/30004 and DCAgent/30005 depending upon which password list the fail happened against and the method of password set or change. For example when I used the password Oxford123, as “oxford” is in the custom banned password list, Event ID 30003 returns “The reset password for the specified user was rejected because it matched at least one of the tokens present in the per-tenant banned password list of the current Azure password policy”. As mentioned above, the sequence of 123 following the banned word is not enough to make to score more than 5 points and so the password change is rejected.

On the other hand, 0xf0rdEng1and! was allowed as England was not on my banned list an so although my new password contained a banned word, there were enough other components of the password to make it secure enough. Based on the above mentioned scoring of 5 or more is required to have a password accepted, [Oxford] + [E] + [n] + [g] + [1] + [a] + [n] + [d] + [!], a total of 9. 9 >= 5 and so the password is accepted.

Finally, when testing users, other password policies like the date that the password can next be changed and “user cannot change password” property etc. will take effect over the banned password list. For example, if you have a cannot change password for 5 days setting, and you set the users password as an administrator – that will work or fail based on the password you enter, but if you change the password as the user within that time period, that will fail as five days have not gone by and not because the user picked a guessable password.

Azure Information Protection and SSL Inspection

Posted on Leave a commentPosted in aadrm, Azure Information Protection, certificates, exchange, exchange online, IRM, Office, Office 365, rms, SSL

I came across this issue the other day, so thought I would add it to my blog. We were trying to get Azure Information Protection operating in a client, and all we could see when checking the download of the templates in File > Info inside an Office application was the following:

02-Setup RMS Menu

03-Setup RMS Menu

04-Setup RMS Menu Error

The sequence of events was File > Info, click Set Permissions. You get the “Connect to Rights Management Servers and get templates” menu item. Clicking this shows a box saying “Retrieving templates from server” (which you might not see as this step takes no real time at all) and then an error that reads “Your machine isn’t set up for Information Rights Management (IRM). To set up IRM, sign into Office, open and existing IRM protected message or document, or contact your helodesk”.

For each of these recommendations, we tried them and still got the same message.

So what was the issue?

In https://docs.microsoft.com/en-us/azure/information-protection/get-started/requirements#firewalls-and-network-infrastructure Microsoft state the the IRM client in Windows uses Certificate Pinning. This is where the client application knows what certificate it expects to see at the service it is connecting to. If it gets a different certificate it will fail to connect. Within enterprise organizations, firewalls and proxy devices that do SSL Inspection change the certificate in use so that they can see the content being sent to the service in the clear. For the IRM client in Windows, this means that IRM does not trust the certificate and so will not work.

You can test for SSL Inspection on a URL by browsing the target URL in Chrome. For example, for IRM go to https://admin.na.aadrm.com/admin/admin.svc and click the Secure banner in the address bar:

image

You will get a popup – hover over the “Certificate (Valid)” message. If the certificate is not valid then either your PC is missing some important updates or SSL inspection is happening, but not implemented correctly!

You can use this same test to check for SSL Inspection on any network.

The certificate listed when you hover over the “Certificate (Valid)” message should read (for AIP) a Microsoft CA issued certificate. It should not list your company or proxy service as the issuer. Do not terminate the TLS client-to-service connections (for example, to do packet-level inspection) to the Azure Rights Management service. Doing so breaks the certificate pinning that RMS clients use with Microsoft-managed CAs to help secure their communication with the Azure Rights Management service.

For network performance, Microsoft also have a list of URLs that they recommend you do not inspect for Office 365 services. This list of endpoints that should not be inspected are those categorised as Optimize or Allowed when you browse

https://endpoints.office.com/endpoints/O365Worldwide?ClientRequestId=GUID. Interestingly at the time of writing this lists aadrm.com as Default, which means it can be inspected – I have reported this to the team that manages the endpoint service so that this URL can be moved up in its classification.

Once you bypass SSL Inspection for *.aadrm.com you will find that the Office and RMS clients work fine (assuming everything else is enabled correctly of course).

Exchange Online Migration Batches–How Long Do They Exist For

Posted on 5 CommentsPosted in exchange, exchange online, Exchange Server, hybrid, microsoft, migration, Office 365

When you create a migration batch in Exchange Online, the default setting for a migration is to start the batch immediately and complete manually. So how long can you leave this batch before you need to complete it?

As you can see from the below screenshot, the migration batch here was created on Feb 19th, which was only yesterday as I write this blog.

image

The batch was created on the morning of the 19th Feb, and set to manual start (rather than the default of automatic start, as did not want to migrate lots of data during the business day) and then it was started close to 5:30pm that evening. By 11:25pm the batch had completed its initial sync of all 28 mailboxes and there were no failures. There were other batches syncing at the same time, so this is not indicative of any expected or determined migration performance speeds.

So what happens next. In the background a new mailbox move request was created for each mailbox in the batch, and each individual mailbox was synced to Exchange Online and associated with the synced Mail User object created in the cloud by the AADSync process. When each move reached 95% complete, the move was suspended. It will be resumed around 24 hours later, so that each mailbox is kept up to date once a day automatically.

If you leave the migration running but not completed you will see from the migration batch status above that the batch will complete in 7,981 years (on the 31st Dec 9999 and one second before the next millennium bug hits). In the meantime the migration batch sync will stop doing its daily updates after two months.

After two months of syncing to the cloud and not being completed, Exchange Online assumes you are still no closer to migrating and they stop keeping the mailbox on-premise and the mailbox in the cloud in sync. You can restart this process by interacting with the migration batch before this time, or if it does stop by just clicking the Resume icon, and this will restart it for a further period of time.

Office 365 Retention Policies and Hybrid Public Folders

Posted on Leave a commentPosted in exchange online, Exchange Server, hybrid, Office 365, Public Folders, retention, retention policies

If you create an Office 365 Retention Policy (in the Security and Compliance Center) that applies to all Exchange Online content then you might find that after the retention policy has been deployed (a day or so later usually) that the policy is in error and there is a message at the top of the retention policy pane that shows “1 distribution result(s) found”.

image

The “Notify support” link does nothing but help you call support, and a post on the Microsoft Tech Community implies that that does not help.

The place to look for the answer is in a Security and Compliance Remote PowerShell session. Here you can run Get-RetentionCompliancePolicy -DistributionDetail | fl Name,Distribution* to return the name of each of your retention policies along with the DistributionStatus (which will be “Error”) and DistributionResults.

In my example I found I had a DistributionResults message of “{[Exchange]AllPublicFolderUnderRoot:Recipient not found: }”.

image

In the example that I was trying to resolve this issue for, the Exchange Online organization was utilizing on-premises Public Folders for Exchange Online mailboxes. That is, in Exchange Online, the PublicFoldersEnabled property of Get-OrganizationConfig was set to remote and we had a few RemotePublicFolderMailboxes (aka mailboxes that proxy the online mailboxes connection to the on-premises organization).

image

Therefore there seems to be an error in Office 365 Retention Policies where the retention policy distribution fails when you set it to archive public folders, but your public folder infrastructure is still on-premises.

So what can you do – either you ignore the error, after all it is telling you that your retention does not include objects that do not yet exist – but when you do have public folders in Exchange Online, the retention policy should take effect without you doing anything else.

The other thing you could do is to to remove public folders as a retention source, not forgetting to enable it again when you have moved your public folders to the cloud.

image

Journal Rule Testing In Exchange Online

Posted on 2 CommentsPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, journal, journaling, Office 365, smtp

I came across two interesting oddities in journaling in Exchange Online in the last few weeks that I noticed where not really mentioned anyway (or anywhere I could find that is). The first involces routing of journal reports and the second the selection of the journal target.

The journal report, that is the message that is sent to the journal target mailbox when an email is sent or received from the mailbox(es) under the control of the Journal Rule. This journal report is a system message, that is Exchange Online marks it as such so that it is treated and considered differently within the Office 365 service. This though means that Conditional Routing does not apply to journal reports. Conditional routing is where you have a mail flow (or transport) rule, that routes the emails based on passing the conditions in the rule. Journal messages are never subject to rules, and this includes conditional routing as well.

This means that journal rules leaving Exchange Online will always route via the default connector or a standard connector for the SMTP namespace of the journal report target. If Centralized Mail Flow is enabled in hybrid mode, the standard connector for the SMTP namespace is ignored, as all mail routes via the * connector apart from that that is already affected by mail flow rules. As journal reports cannot be routed via conditional routes due to not being processed by the mail flow rules, this means in a scenario where Centralized Mail Flow is enabled, journal reports will only follow the routing to *.

In a multi-organization hybrid deployment, this means that your journal reports from the cloud may end up in the wrong on-premises organization and you will need to route them appropriately.

The second issue I came across is more for a journal test scenario. It is against the terms of service in Exchange Online to store journal reports in a mailbox in Exchange Online, but its only in the last few days I have noticed that you now (and not sure for how long) you have been unable to enter a target mailbox that is in Exchange Online.

For example, I created a new journal rule and entered a target mailbox in a different Office 356 tenant. I was not allowed to use that mailbox. The error message was not clear though, and it took some time to work this out. The error message you get is “The JournalEmailAddress can only be a mail user, a mail contact or an external address”

image

Of course where the journal target address is external to your tenant (an external address), then this error makes no sense. Also if you create a mail user or mail contact that points towards the target it will not be accepted whilst that mailbox exists elsewhere in Office 365. You can enter an address for a domain that is hosted in Office 365, as long as that mailbox is not hosted in Office 365. It is just where the address is currently in Office 365 you cannot make a journal rule to send email to it.

You cannot also work around this limitation anymore either – if you enter a journal target address that is not in Exchange Online so that the Journal Rule setup completes, then go and add that target address to your other tenant, you will see that the journal report messages never arrive. Change it for an on-premises mailbox and it will work straight away.

Therefore it is now no longer possible to even test journaling unless you have an external mailbox. Shame the error is not clearer – would have saved a bit of time!

Duplicate Exchange Online and Exchange Server Mailboxes

Posted on 8 CommentsPosted in duplicate, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, mailbox, MX, Office 365

With a hybrid Exchange Online deployment, where you have Exchange Server on-premises and Exchange Online configured in the cloud, and utilising AADConnect to synchronize the directories, you should never find that a synced user object is configured as both a mailbox in Exchange Online and a mailbox on-premises.

When Active Directory is synced to Azure Active Directory, the ExchangeGUID attribute for the on-premises user is synced to the cloud (assuming that you have not done a limited attribute sync and excluded the Exchange attributes from syncing to AAD – as syncing the attributes is required for Exchange Online hybrid). Exchange Online though does not read attributes from Azure Active Directory. Exchange Online reads its attributes from the Exchange Online Directory Service (EXODS). The Exchange Online directory takes a sync of information relating to Exchange from Azure Active Directory (Azure AD), which is known as forward sync. This ensures that the ExchangeGUID attribute from the on-premises mailbox is synced into Exchange Online for your tenant.

When a user is given an Exchange Online licence, it becomes the job of Exchange Online to provision a mailbox for this user. When Exchange Online needs to provision a new mailbox, it will not do so where the ExchangeGUID attribute already exists. The existence of this attribute tells the provisioning process that the mailbox already exists on-premises and may be migrated here later and so not to create a conflicting mailbox. A cloud user who does not have an ExchangeGUID attribute synced from on-premises will get a mailbox created by the Exchange Online provisioning process upon a licence being assigned, and on-premises users that do not have a mailbox on-premises (who also have no ExchangeGUID attribute) will also find that granting them an Exchange Online licence will trigger the creation of a mailbox for them. Note that this last option will create a mailbox in the cloud – but all the attribute management of this mailbox must be done on-premises, as the object syncs from on-premises and so that is the source of the object. Therefore avoid licencing synced objects that do not have a mailbox or remote-mailbox on premises (see my session on this at Microsoft Ignite 2018 “THR2145 – Why do we need to keep an Exchange Server on-premises when we move to the cloud?“)

The above is what happens in most cases – the user on-premises has a ExchangeGUID value, that is synced to the cloud, and then the user is licenced and a second mailbox is not created. But there is an edge case where an on-premises user with a mailbox (and therefore has the ExchangeGUID attribute populated) will also get a mailbox in Exchange Online. This happens where the organization manually created cloud mailboxes before enabling AADConnect to sync the directories, and these cloud users match the on-premises user by UserPrincipalName or primary SMTP address.

In this above case, because they are cloud users with an Exchange Online licence they get a mailbox. Deleting the cloud user and then enabling sync will cause the original cloud mailbox to be restored to the user account as the UserPrincipalName matches.

For example, the below shows a user being created in the cloud called “twomailboxes@domain.com”:

image

The user is granted a full Office 365 E3 licence, so this means the user has an Exchange Online mailbox. There is no AADConnect sync in place, but the UPN matches a user on-premises who has a mailbox.

In Exchange Online PowerShell, once the mailbox is provisioned we can see the following:

image

PS> Get-Mailbox twomailboxes | FL name,userprincipalname,exchangeguid


Name              : twomailboxes
UserPrincipalName : twomailboxes@domain.com
ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Repeating the same on-premises will show a separate user (remember, no AD sync in place at this time) with the same UPN and of course a different ExchangeGUID.

image

[PS] > Get-Mailbox twomailboxes | FL name,userprincipalname,exchangeguid


Name              : Two Mailboxes
UserPrincipalName : twomailboxes@domain.com
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that the on-premises object ExchangeGUID is not the same as the cloud ExchangeGUID. This is because there are two seperate mailboxes.

Get-User in the cloud will also report something useful. It will show the “PreviousRecipientTypeDetails” value, which is not modifiable by the administrator, which in this case shows there was not a previous mailbox for the user but this can show that a previous mailbox did exist. For completion we also show the licence state:

image

PS > Get-User twomailboxes | FL name,recipienttype,previousrecipienttypedetails,*sku*


Name                         : twomailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : None
SKUAssigned                  : True

Now in preparation for the sync of the Active Directory to Azure Active Directory, the user accounts in the cloud are either left in place (and so sync will do a soft-match for those users) or they are deleted and the on-premises user account syncs to the cloud. In the first case, the clash on the sync will result in the cloud mailbox being merged into the settings from the on-premises mailbox (on-premises values overwrite cloud values unless on-premises value is null or does not exist). In the second case, cloud object deleted before sync, there is no user account to merge into, but there is a mailbox to restore against this user. And even though the newly synced user has an ExchangeGUID attribute on-premises that is synced to the cloud, and they have a valid licence, Exchange Online reattaches the old mailbox associated with a different GUID but same UPN/email address.

The impact of this is minor to massive. In the scenario where MX points to on-premises and you have not yet moved any mailboxes to the cloud, this cloud mailbox will only get email from other cloud mailboxes in your tenant (there are none in this scenario) or internal alerts in Office 365 (and these are reducing over time, as they start to follow correct routing). It can be a major issue though if you use MX to Exchange Online Protection. As there is now a mailbox in the cloud for a user on-premises, inbound internet sourced email for your on-premises user will get delivered to the cloud mailbox and not appear on-premises!

The other problems are that where there is a duplicate mailbox, move requests for those users for onboarding to Exchange Online will fail:

image

This reads “a subscription for the migration user <email> couldn’t be loaded”. This occurs where the user was not licenced and so there was not a duplicate mailbox in the cloud, but the user was later licenced before the migration completed.

Where the invalid duplicate mailbox exists in the cloud and is getting valid emails delivered to it, the recovery work described below additionally will involve exporting email from this invalid mailbox and then removing the mailbox as part of the fix. Extraction of email from the duplicate mailbox needs to happen before the licence is removed.

To remove the cloud mailbox and to stop it being recreated, you need to ensure that the synced user does not have an Exchange Online licence. You can grant them other licences in Office 365, but not Exchange Online. I have noticed that if you do licencing via Azure AD group based licencing rules then this will also fail (these are still in preview at time of writing) and that you need to ensure that the user is assigned the licence directly in the Office 365 portal and that they do not get the Exchange Online licence. After licence reconciliation in the cloud occurs (a few minutes typically) the duplicate mailbox is removed (though I have seen this take a few hours). The Get-User cmdlet above will show the RecipientType being a MailUser and not Mailbox.

You are now in a position where your duplicate cloud mailbox is gone (which is why if that mailbox had been a target to valid emails before now, you would need to have extracted the data via discovery and search processes first).

Running the above Get-User and Get-Mailbox (and now Get-MailUser) cmdlets in the cloud will show you that the ExchangeGUID on the cloud object now matches the on-premises object and the duplication is gone. You can now migrate that mailbox to the cloud successfully.

We can take a look at what we see in remote PowerShell here:

Recall from above that there were two different ExchangeGUIDs, one in the cloud and one on-premises. These in my example where:

Cloud duplicate ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

On-premises mailbox ExchangeGuid  : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Get-User before licences removed in the cloud, showing a mailbox and that it was previously a mailbox as well:

image

PS > Get-User twomailboxes | FL name,recipienttype,previousrecipienttypedetails,*sku*


Name                         : Two Mailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : True

Get-Mailbox in the cloud showing the GUID was different from on-premises:

image

PS > Get-Mailbox twomailboxes | FL name,userprincipalname,exchangeguid


Name              : Two Mailboxes
UserPrincipalName :
twomailboxes@domain.com

ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Once the licence is removed in Office 365 for Exchange Online and licence reconciliation completes (SKUAssigned is False) you will see that Get-User shows it is not a mailbox anymore:

image

PS > Get-User twomailboxes | FL name,recipienttype,previousrecipienttypedetails,*sku*


Name                         : Two Mailboxes
RecipientType                : MailUser
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : False

And finally Get-MailUser (not Get-Mailbox now) run in Exchange Online shows the ExchangeGUID matches the on-premises, synced, ExchangeGUID value:

image

PS > Get-MailUser twomailboxes | FL name,userprincipalname,exchangeguid


Name              : Two Mailboxes
UserPrincipalName : twomailboxes@domain.com
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that giving these users back their Exchange Online licence will revert all of the above and restore their old mailbox. As these users cannot have an Exchange Online licence assigned in the cloud before you migrate their on-premises mailbox, as that will restore the old cloud mailbox, you need to ensure that within 30 days of their on-premises mailbox being migrated to the cloud you do give then an Exchange Online licence. Giving them a licence after migration of their on-premises mailbox to the cloud will ensure their single, migrated, mailbox remains in Exchange Online. But giving their user a licence before migration will restore their old cloud mailbox.

For users that never had a matching UPN in the cloud and a cloud mailbox, you can licence them before you migrate their mailbox as they will work correctly within the provisioning system in Exchange Online.

Enable Report Message Add-In For Office 365

Posted on Leave a commentPosted in add-in, EOP, exchange online, Exchange Online Protection, Office, Office 365, Office 365 ProPlus, phish, phishing, spam

There is a new add-in available for Outlook and OWA in Office 365 that can simplify spam and phishing reporting to Microsoft for content in your mailbox. I recommend rolling this add-in out to everyone in your Office 365 tenant and for Office 365 consultants to add this as part of the default steps in deploying a new tenant.

This can be done with the following steps:

In the Exchange Control Panel at https://outlook.office365.com/ecp/ go to the Organization > Add-Ins section

image

Click the + icon and choose “Add From Office Store”.

In the new tab that appears, search for “Report Message” via the search bar top right:

I’ve noticed that a set of search results appear, then the website notices I am logged in, logs me in and presents a second smaller list of results. It is in this small list that you should see Report Message by Microsoft Corporation

image

I’ve noticed that clicking “Get it now” does not seem to work all the time (the popup has a Continue button that does nothing)! So if that happens, cancel the popup, click the card for the app and install the add from the Get it now button rather than the get it now link on the card. The Report Message app page is shown below with a “Get It Now” button to the left:

image

Either the link or the button should work, and you should get this popup:

image

Click Continue. You are taken to Office 365 to continue. This is the step I eluded to above that sometimes does not work

image

You are asked to confirm the installation of the App into Office 365

image

Click Yes and wait a while. I’ve noticed also that sometimes you need to refresh this page manually for the process to continue, though waiting (with no indication that anything is happening for one or two minutes is usually enough as well)

image

The message above says that the add-in is now visible in the gray bar above your messages. For this add-in this is not correct as this add-in extends the menu in Outlook (2013 and later, as add-ins are not supported in Outlook 2010) and also the app is disabled by default.

Close this tab in your browser and return to the add-in page in Exchange Control Panel that is open in a previous tab.

Refresh the list of apps to see the new app:

image

From here you can enable the app, select a pilot audience, though this app is quite silent in the users view of Outlook and OWA so a pilot is not needed for determining impact to users, but can be useful for putting together quick documentation or informing the help desk of changes.

Select the app and click the edit button:

image

I recommend choosing “Mandatory, always enabled. Users can’t disable this add-in” and deploying to all users. Unchecking the option to make it available for all users makes it available for none. For a pilot choose “Optional, disabled by default”.

You are now done installing the add-in.

Users will now see the add-in in Outlook near the Store icon when a message is selected open:

image

Clicking the icon allows you to mark a messages as “junk”, “phishing” or “not junk” and options and help. Options gives the following:

image

Where the default is to ask before sending info to Microsoft.

Selecting Junk or Phishing will result in the message being moved to Junk Email folder in Outlook, and if in the Junk Email folder, marking a message “Not Junk” will return it to the inbox. All options will send info on the message, headers and other criteria to Microsoft to help adjust their machine learning algoriths for spam and phishing detection. This add-in replaces the need to email the message as an attachment to Microsoft.

For a pilot, users need to add the add-in themselves to Outlook. Mandatory deployment means it is rolled out to users (usually within a few days). To enable the add-in in OWA, click the options cog to the top right of the OWA interface:

image

Then click Manage Add-Ins and scroll down until you find the Report Message add-in (or search for it)

image

And turn the add-in on to view it in OWA as shown:

image

And also it will appear automatically in Outlook for iOS and Outlook for Android and Outlook (desktop, classic).

Once the app is enabled for all users, and recall the above where it takes a while to appear for all users, then your spam and phish reporting in Office 365 is very simple and easy to do and easy to remove from a helpdesk call and on to the end user directly to report and move messages.