Join me at COUCUG for a talk about the new Exchange patches

Wednesday, February 20, 2019

Join me Thursday, February 21st, as I present a session on Exchange Server patching, specifically around the new security patches just released. I'll be presenting to a live audience via Skype for Business at the Colorado Unified Communications User Group (COUCUG).

Where: 7595 Technology Way, Suite 400 Denver, CO 80237
When: February 21st, 4:00-6:00 pm
Who: Anyone interested in Microsoft Unified (Intelligent) Communications

Agenda (all times in Mountain Standard Time):

4:00-4:10 pm - Arrival and introductions
4:10-5:00 pm - Jeff Guillet and Exchange patching
5:00-5:20 pm - Dinner
5:20-6:00 pm - Jonathan and Exchange Online UM (the death of)


Thanks to our friends at Jabra for hosting dinner!
Read more ...

The Microsoft Hybrid Agent: What you need to know

Thursday, February 7, 2019
Microsoft just announced the new Hybrid Agent Public Preview. This represents an important step toward making it easier for on-prem organizations to implement a hybrid configuration with Exchange Online. Work on the new hybrid agent was announced at Microsoft Ignite 2018 in Orlando, FL to great fanfare.

I wrote an article for the ENow ESE blog where I discuss what it all means and caveats for this implementation. Read it here.

Read more ...

How to work with Inactive Mailboxes in a Hybrid Environment

Tuesday, January 29, 2019
Earlier today the Exchange team posted an article on the EHLO Blog explaining how to manage inactive mailboxes in Exchange Online. That blog post is geared mainly toward cloud-only tenants. This article gives information about the differences between inactive users and shared mailboxes and how to configure them both in a hybrid environment.

Inactive vs Shared Mailboxes

Most customers are interested in a way to remove the Office 365 license from terminated users to reduce costs, while maintaining access to their email. There are two ways to do this.

Inactive mailboxes are mailboxes that have been put on litigation hold and the Office 365 licenses have been removed from the user account in Azure AD. Normally when you remove an Exchange Online license from a user account, the mailbox becomes disconnected and will eventually be purged from EXO (30 days by default). However, if the mailbox is placed on litigation hold before the user account is deleted or unlicensed, EXO is unable to delete the mailbox until the lit hold is removed.

Shared mailboxes are mailboxes that multiple users can access to read and send e-mail messages. Shared mailboxes allow a group of users to view and send e-mail from a common mailbox. This type of mailbox also does not require an EXO license, but has some limits placed on it to prevent abuse.

I put together a table that lists some of the important differences between Inactive and Shared mailboxes that may help you chose which one to use. Neither require an EXO license.

Characteristic
Inactive Mailbox
Shared Mailbox
Requires an EXO license
No
No
Accessed by
Only by users with Discovery Management role
Any user with Full Access rights or with Discovery Management role
Can receive new emails
No
Yes
Can send new emails
No
Yes
Mailbox size limit
100 GB
50 GB
Supports online archive mailboxes
Yes
Yes, but requires a license
Messages can be changed or deleted
No
Yes

Note: There are other limits and requirements, as well. See Exchange Online Limits for the complete list.

Inactive mailboxes are just that -- inactive. The mailbox contents are in stasis and cannot be changed. No new emails can be sent or received by an inactive mailbox. The original user cannot access the mailbox because the account has been deleted or the Office 365 license(s) have been removed. Only users with the Discovery Management role can access the historical mailbox contents. If a user was granted full access to that mailbox prior to removing the license(s), the mailbox may still show in Outlook, but the contents will be inaccessible.

Some organizations chose to convert mailboxes for terminated users into shared mailboxes instead and assign full access to the user's manager or another team member or group. That way, emails sent to the shared mailbox don't bounce with an NDR and the user with full access can respond for the termed employee. Just keep in mind the size and archive limits listed above. See Correcting Shared Mailbox provisioning and sizing for more details.

How to Configure an Inactive Mailbox in a Hybrid Environment

Normally in a hybrid environment all user and mailbox management is done on-premises and the configuration changes sync to the cloud. However, configuring litigation hold for an inactive mailbox is performed directly in Exchange Online.

Follow the first two steps listed in the EHLO Blog article. These are performed in the Microsoft Exchange Online Powershell Module.

1. Put the mailbox on a hold (which will also place the Archive on the hold, if it is present). For this scenario I’ve used LitigationHold, but, any hold from Exchange Online, or Security and Compliance can be used:
Set-Mailbox David -LitigationHoldEnabled $True -LitigationHoldDuration Unlimited
Note: The hold setting may take up to 60 minutes to take effect.

2. Ensure the mailbox has Litigation Hold enabled:
Get-Mailbox David | fl PrimarySMTPAddress, Identity, LitigationHoldEnabled, LitigationHoldDuration, MailboxPlan, PersistedCapabilities, SKUAssigned
User properties should now show:

PrimarySmtpAddress : David@contoso.com
Identity : David
LitigationHoldEnabled : True
LitigationHoldDuration : Unlimited
MailboxPlan : ExchangeOnlineEnterprise-0527a260-bea3-46a3-9f4f-215fdd24f4d9
PersistedCapabilities : {BPOS_S_O365PAM, BPOS_S_ThreatIntelligenceAddOn, BPOS_S_EquivioAnalytics, BPOS_S_CustomerLockbox, BPOS_S_Analytics, BPOS_S_Enterprise}
SKUAssigned : True

3. Wait for Azure AD Connect to replicate the change back to on-premises or you can force AAD replication using the following command on your AAD Connect server:
Start-ADSyncSyncCycle -PolicyType delta
4. Now you can either delete the user's AD account from on-premises, which will sync to ADD and remove the user account there. The inactive mailbox will not be deleted because it's on indefinite litigation hold. Use the procedures here to access the inactive mailbox.

How to Configure a Shared Mailbox in a Hybrid Environment

First, it's important to know that it's recommended that you do not convert a mailbox that was migrated to Exchange Online to a shared mailbox. The mailbox should be moved back to on-prem, converted to a shared mailbox, and remigrated to Office 365 again. The reason is that AAD Connect doesn't sync the correct attributes back to on-premises. See Convert a user's mailbox in a hybrid environment for more details.

That said, it is possible to convert a migrated user mailbox to a shared mailbox by updating AD on-premises manually. Fellow MVP Jetze Mellema blogged about it here. Just follow these steps:

1. Sign-in to the Exchange Online Admin Center and navigate to Recipients > Mailboxes.

2. Select the user account you wish to convert and select Convert to Shared Mailbox on the right-side pane. The mailbox will now show under Shared mailboxes in the Exchange Admin Center in Exchange Online.

3. In AD on premises, change the following two attributes for the user account. This can be done using ADSIEdit or the Advanced view of AD Users and Computers on the Attributes tab.
msExchRemoteRecipientType: 100
msExchRecipientTypeDetails: 34359738368
4. Remove the Office 365 licenses from the Shared mailbox.

5. Disable the user account in AD on-prem and Windows will manage its password. The mailbox will now show under Shared mailboxes in the Exchange Admin Center on premises.




Read more ...

Enable Outlook Automapping for Exchange mailboxes

Wednesday, January 23, 2019
When a user is delegated full access rights to another mailbox, automapping will automatically add that mailbox to that user's Outlook. Automapping does this when Outlook runs a background autodiscover process and discovers that the user has been given full access to another mailbox. The user doesn't need to add the mailbox manually to Outlook and will be unable to remove the additional mailbox.

Automapping is enabled by default, but it can be disabled by running the following cmdlet:
Add-MailboxPermission TeamMailbox -User kmeyer -AccessRights FullAccess -AutoMapping $false
The cmdlet above gives user Ken Meyer full access to the TeamMailbox mailbox and disables automapping for that mailbox.

I published the Enable-AutomappingForFullAccessMailboxes.ps1 script for Exchange in the Microsoft Script Center Gallery. The script re-enables Outlook automapping on mailboxes where users have been given full access rights. It runs on Exchange 2010-2019 and Exchange Online, and must be run from the Exchange Management Shell (EMS).


Read more ...

Introducing the OME Test Tool

Saturday, January 12, 2019
tldr; Send an email to OMETest@expta.com and the service will respond with an email encrypted by Office 365 Message Encryption. If your test email includes an attachment, that attachment will be included in the OME encrypted response as an encrypted attachment. Use this service to test how encrypted emails are handled by your email clients and mobile devices.
The well-intentioned folks over at Microsoft are doing it again, but you know what they say about the road to hell...

In late December message ID MC170958 showed up in the Office 365 Message Center entitled, "New Office 365 Message Encryption policy for sensitive information." This feature is intended to keep user emails that contain sensitive information safe by automatically encrypting them. This will be done by creating a new Exchange mail flow rule in your tenant to use Online Message Encryption (OME), which was recently renamed to Office 365 Message Encryption.

Message Center ID MC170958
The Message Center notice included a link to https://docs.microsoft.com/en-us/office365/securitycompliance/new-ome-encryption-policy, but that link no longer works for most users. Perhaps Microsoft is rethinking this, but it still shows in the Message Center for some customers.

While the idea of keeping users from doing something stupid is a noble one, to me this reeks of Skynet. I really don't like the idea of anyone or anything inserting logic and a new business process into my emails and mail flow. What if my emails to customers start being encrypted because my item numbers resemble a bank account number? What if I have a complex transport configuration?

It's easy enough to opt-out of this change by running Set-IRMConfiguration -AutomaticServiceUpdateEnabled $false, but shouldn't I really have to opt-in instead of opt-out?

January 25 UPDATE: Microsoft has indeed rethought this a bit. They will still be creating the OME transport rule, but it will not be enabled by default:

Updated Message Center Notification

I'm sure automation like this might help small customers who don't have the time or skills to properly manage and secure their infrastructure, but for enterprise customers this could be a real disaster. OME encrypted emails require the recipient to authenticate with a Microsoft account to read them. Despite what Microsoft thinks, not everyone has (or wants) an account with them or uses Microsoft Office. This causes a barrier that a lot of email recipients will find difficult. It should be noted that one-time passwords are also supported. Read Microsoft Plans to Launch Automatic Email Encryption for Office 365 Tenants for Tony Redmond's take on this.

I created an OME test service in Office 365 that you can use to test the end-user experience of receiving an OME encrypted email. Simply send an email to ometest@expta.com. In a short while the service will automatically respond with an encrypted message. If you include an attachment with your email, that attachment will also be returned in the OME message as an encrypted attachment.

Note: The OME test service will not respond to messages that contain ": " in the subject. This prevents mail loops caused by rules that automatically reply or forward messages.

You should test access to this encrypted email from Outlook or any desktop email app, your mobile device, and your web browser to see how each client handles OME encrypted emails. You may be required to create a free Microsoft ID to view it.

You'll notice that you cannot preview OME encrypted emails in the Outlook preview pane. They must be opened to view them.

OME encrypted emails cannot be viewed in the preview pane
Outlook will attempt to download a rights management service user license to make the reading experience fairly straightforward, assuming you're signed into Office 365. Other email clients will be more cumbersome and recipients without a Microsoft account will need to sign up for one to read the email. Honestly, I can't imagine my parents having to deal with this from their mobile phones.

This is what an OME protected email looks like on an iPhone

I use the native Apple mail client, not the Outlook app. If you're like me, you have more than one email account on your mobile device. When you click "Read the message" you'll need to authenticate with the same email address it was sent to - something that may not be readily apparent from an "All Inboxes" view, like on the iPhone. If you use the wrong account you get an unhelpful "The item was not found" error.

Once you successfully sign-in to Office 365 you can view, reply, or forward the email via OWA. If you use the Outlook app for iOS or Android, your experience will be better.

This is the OME encrypted email
I hope you find that the OME tester utility is useful. Please let me know if you have any issues.

Reference:


Read more ...

Azure AD Connect version 1.2.70.0 released

Monday, December 31, 2018
This build updates the non-standard connectors (for example, Generic LDAP Connector and Generic SQL Connector) shipped with Azure AD Connect. If you use AAD Connect with directories other than Active Directory, this update is for you.

For more information on applicable connectors, see version 1.1.911.0 in Connector Version Release History.

Download Azure AD Connect here.
Read more ...

How to Create and Manage an Office 365 Breakglass Account

Monday, December 24, 2018
Despite the huge investments Microsoft has made to make Office 365 both secure and highly available, there have been three major outages this year that prevented customers from accessing their cloud resources. Administrators discovered that they couldn't connect to the Office 365 administrative portals to make the changes needed to allow their users to sign in.

Just like having a house key hidden somewhere in case you get locked out, it's important to have a breakglass account that you can use to sign in to Office 365 in case DirSync, MFA, or AD FS authentication fails. In this article, I'll provide step-by-step instructions on how to properly create an O365 break glass account and how to manage it.

Before we get started it's important to understand what this account is for and how to secure it. The purpose of the break-glass account is to allow the administrator sign in to Office 365 with the highest level of privileges (i.e., Global Administrator) with the minimal number of security controls, since these security controls are most likely the reason that admins or users cannot sign-in in the first place. That means the only security controls you have for this highly privileged account are a strong password and physical security. We'll talk more about guarding this account later in this article.

Create the breakglass account

First, let's create the breakglass account in Office 365. The breakglass account should always be a tenant account - one that only exists in Azure Active Directory and is not synced from your on-premises AD. Typically, it would look like breakglass@domain.onmicrosoft.com. By using an Azure Active Directory account, you remove the reliance on ADFS, pass-though authentication, or any other third-party authentication mechanism (Okta, Onelogin, etc.) to sign in. The breakglass account also shouldn't require a hard or soft token, such as YubiKey, Duo, or RSA.

Go to the Azure AD portal at https://aad.portal.azure.com and sign-in with a Global Administrator account. Create a new breakglass account in Azure AD, making sure that the account's UPN uses the tenant domain (domain.onmicrosoft.com) to bypass any on-premises authentication. Add the new account to the Global Administrator group.


AAD will automatically create a temporary password for this account, as shown above. Copy this password and create the account. Now sign out of the AAD Portal and sign back in with the new breakglass account using the temporary password. If you've configured multi factor authentication (MFA) or self-service password reset (SSPR) for all users, or you've configured the "Require MFA for admins" conditional access baseline policy, you'll be prompted for additional information to sign-in for the first time.



Click Next and complete the MFA enrollment. It doesn't really matter if you use the Authenticator app, phone call, or text to enroll because we'll turn MFA off for this account shortly.

Next you'll be prompted to enter the temporary password and create a new password. Make the new password a complex password. Passwords for cloud accounts can't contain the user ID, and need to be 8-16 characters long, with at least 3 of the following: uppercase letters, lowercase letters, numbers, and symbols. Record this new password to store in a secure place. 

TIP: Avoid characters that can be confusing when written down (o, O, 0, 1, l, etc.) - you may not be the one who has to read the password for the breakglass account. Use Notepad or Word to print the password using the Courier New font to print it out, since this font makes it easier to discern characters and numbers.


TIP: Record the username and password on a piece of paper and store it in a sealed business envelope. Make sure the password cannot be read through the envelope when held up to the light. Write "OFFICE 365 BREAKGLASS ACCOUNT" across the front of the envelope and sign the envelope across the flap on the back so you'll know if it is ever opened. Then store this envelope in a secure location that you and other trusted individuals can access, such as a safe or locked drawer. Don't make it so difficult to access that it can't be found and accessed when needed.

Now that we've created the cloud-only breakglass account with a complex secure password, we need to remove any security controls from the account that might prevent the breakglass account from signing in.

Remove Multi-Factor Authentication

Office 365 provides MFA for all tenant admin accounts. It's not enabled by default, but you should ensure it's not configured for the breakglass account. The idea behind removing any MFA policies is to prevent any obstruction from logging into this account to manage the domain.

In the AAD Portal go to Azure Active Directory > Users > Multi-Factor Authentication and locate the breakglass account. Ensure that Multi-Factor Auth Status shows as Disabled.


There are also some conditional access policies that can enable MFA. These are managed from Azure Active Directory > Conditional Access > Policies.


The "Baseline policy: Require MFA for admins" conditional access policy, which is currently in preview, automatically enables MFA for accounts that are members of any Office 365 admin groups. Azure AD Premium customers may also have other custom conditional access policies, like "Require MFA from external networks". Azure AD Premium P2 licenses include the "Require MFA for risky actions" conditional access policy. You should exclude the breakglass account from all of these conditional access policies.

Edit each of these policies to exclude the breakglass account, as shown in the example below. Click Exclude users, add the breakglass account, then click Done and Save. Repeat for each conditional access policy.


Azure AD Premium P2 users also have Azure AD Identity Protection, which provides other ways to configure MFA. You should exclude the breakglass account here, too. Go to the Azure AD Identity Protection portal at https://portal.azure.com/#blade/Microsoft_AAD_ProtectionCenter/IdentitySecurityDashboardMenuBlade/Mfa. Here, you will see the MFA registration, user risk, and sign-in risk policies.



By default, these policies are not enabled, but you should make sure that the breakglass account is excluded if and when they are enabled. For each policy click Users under Assignments and exclude the breakglass account.


If the Azure AD Identity Protection policies have not been configured yet, you'll need to fully configure them to save the exclusion, even if they're not enforced yet.



Other Tips and Important Considerations

Set the password to never expire for the breakglass account after creating the account. Connect to AAD using the Microsoft Azure Active Directory Module for Windows PowerShell using a Global Administrator account and run the following cmdlet:
Set-MsolUser -UserPrincipalName breakglass@domain.onmicrosoft.com -PasswordNeverExpires $true
If you have Azure AD Premium, do not use Azure AD Privileged Identity Management (PIM) for the breakglass account. You want to be sure that the breakglass account can sign-in using only the complex password which is stored with physical security.

Routinely check the sign-ins and admin audit logs for the breakglass account to confirm it's not being used inappropriately. From the AAD portal go to Users > Breakglass > Sign-ins and Audit logs.

Reset the password on the breakglass account every 6 months or so. Not only does this increase the security of the account, it reinforces your procedures for locating the sign-in information and accessing the account. You don't want to find out that no one remembers the combination to the safe where the breakglass account information is kept when you need it.

If you ever have to use the breakglass account be sure to reset the password when you no longer need to use it and store it away again.

Conclusion

Like other types of insurance, a breakglass account is something you never hope you need to use, but having one can be invaluable when the next outage occurs. And it will.

Read more ...