Turning off Basic Authentication for Autodiscover in Exchange Online

Much has been said and written about disabling Basic Authentication in Exchange Online, and for good reason. Basic Auth is insecure and makes it easy for bad guys to hack your accounts and access your organization's data.

Microsoft disabled Basic Auth for most Exchange Online protocols in October of this year. Those protocols include Outlook, EWS, RPS, POP, IMAP, and EAS. SMTP Auth was also be disabled in your tenant if it is not being used. Modern Authentication is the secure way to authenticate for these protocols. Congratulations to Microsoft for pulling off such a monumental achievement to help keep customers' data safe!

Read Deprecation of Basic authentication in Exchange Online | Microsoft Learn for more information.

Next up, Microsoft is going to disable Basic Auth for the Autodiscover protocol. I would argue this is one of the most significant changes to deprecating Basic Auth, since it is continuously used by Outlook and whenever you configure a mail profile on a mobile device that uses ActiveSync. Because of this, it's easy to ignore this traffic when monitoring for Basic Auth usage. It's also a fairly easy protocol for the bad guys to use for password guessing or dictionary attacks.

As with all the other impacted protocols, Microsoft is not turning off the protocol itself, only the ability to authenticate to the protocol using nothing more than a username and password.

Read more ...

Azure AD Connect version 2.1.20.0 released with a new ability you probably can't use yet

UPDATE: Hot on the heels of the last update, Microsoft released Azure AD Connect version 2.1.20 (6 days later) which apparently fixes a bug in the new sync feature described below. If you implemented the custom sync rule described earlier, you'll need to undo it and do it again. <facepalm>

Microsoft updated Azure AD Connect to version 2.1.19.0 today. 

According to the release notes, "We added a new attribute 'employeeLeaveDateTime' for syncing to Azure AD. To learn more about how to use this attribute to manage your users' life cycles, please refer to this article".

Let's break this down.

First, the support article the release notes refer to is for Azure AD Connect cloud sync, not Azure AD Connect. At this time, syncing the employeeLeaveDateTime is still not supported in Azure AD Connect.

Since AAD cloud sync doesn't support Exchange hybrid at this time, AAD cloud sync is of no value for hybrid customers. However, the AD Connect team is working on adding Exchange hybrid support in the future. 

The support table shows that syncing the employeeHireDate attribute is already supported in Azure AD Connect, so I expect that suspect the configuration is the same. I could not find a similar support article for Azure AD Connect.

Second, the employeeHireDate and EmployeeLeaveDateTime attributes only exist in Azure AD. The on-premises Active Directory schema is not extended to add these two attributes, so the recommendation is to use one of the existing extensionAttribute* attributes an AD to hold these values.

At this time, Microsoft recommends using the extensionAttribute1 attribute for employeeHireDate, but the documentation makes no mention of how to handle the EmployeeLeaveDateTime attribute. See How to synchronize attributes for Lifecycle workflows - Microsoft Entra | Microsoft Learn. I hope this documentation will be updated soon with the missing info and how to handle it if this attribute is already in use in your organization.

Last, if you want to update the employeeLeaveDateTime attribute directly in Azure AD using the Graph API, please see Set employeeLeaveDateTime - Microsoft Graph | Microsoft Learn.

Read more ...

Fix for "Online - Data retrieval failures occurred" on Exchange DAG members

You may find that when you add an Exchange server to a DAG that Server Manager shows multiple errors.

The Notification flag at the top indicates "Refresh failed" and Manageability for All Servers shows an error for the remote DAG member saying, "Online - Data retrieval failures occurred".

You may also see errors that say, "Configuration refresh failed with the following error: The WS-Management service cannot process the request. The computed response packet size (517916) exceeds the maximum envelope size that is allowed (512000)."

These errors occur when the Failover Clustering feature is installed on the DAG member. I've usually only seen this for Exchange 2019 installed in Windows Server 2019 or Windows Server 2022. This is a Windows Server issue, not an Exchange issue, so this fix should also apply to any Windows cluster experiencing this problem.

The fix is to increase the WSMAN maxEnvelopeSize in the registry on all DAG members.

1. On the DAG member, launch regedit.exe and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WSMAN\Client.
2. Create a new DWORD (32-bit) value named maxEnvelopeSize, or modify it if it already exists.
3. Set the value data to 2000 hexadecimal (8192 decimal).

Finally, restart the Windows Remote Management (WS-Management), aka WinRM, service on the server.

When you refresh Server Manager, the error should go away.

Read more ...

Bug when moving Public Folders to Exchange 2019

There's a bug in Exchange 2019 CU12 and earlier that causes New-MoveRequests for Public Folders to fail. 

The move request will fail with the error: StalledDueToMRS_Quarantined, which means that the Mailbox Replication Service (MRS) on the target Exchange 2019 server has crashed repeatedly due to the bug and has quarantined the move request (not the mailbox).

If you check the move request report with the Get-MoveRequestStatistics <PFMailbox> -IncludeReport | FL Report cmdlet you will see the error:

StatusDetail : StalledDueToMRS_Quarantined
Message : Request was quarantined because of following error: Object of type "Microsoft.Exchange.Data.Storage.PublicFolderSession" cannot be converted to object of type "Microsoft.Exchange.Data.Storage.MailboxSession"

or

InvalidCastExceptionException:
Unable to cast object of type 'Microsoft.Exchange.Data.Storage.PublicFolderSession' to type 'Microsoft.Exchange.Data.Storage.MailboxSession'

Microsoft is aware of the problem, which will be fixed in an upcoming Exchange 2019 Cumulative Update. It's unknown at this time if the fix will be included in Exchange Server 2019 CU13.

Read more ...

Support for Windows Active Directory 2022 Environments

As Scott Schnoll mentioned at MEC 2022, Microsoft now supports Active Directory environments running on Windows Server 2022 beginning with Exchange Server 2013 CU23 and Exchange Server 2016 CU23.

It's interesting to note that Exchange 2013 CU23 does not support Windows Server 2019 Active Directory, so if you're running Windows Server 2016 AD or earlier you should plan accordingly. There are no issues upgrading AD directly from a previous version to 2022, bypassing 2019 AD.

The highest Active Directory forest functional level supported by all supported versions of Exchange Server is still Windows Server 2016.

View the Exchange Server supportability matrix | Microsoft Learn here.

Read more ...

How to Setup Exchange Management Tools in Environments without Exchange Server

Some Exchange Online customers have an Active Directory on-premises, but never had Exchange Server on-prem. For example, customers who migrated their email from an Exchange hosted environment or from a different email system, such as Notes.

In some environments, these customers are having to manage user accounts and groups in both AD and Azure AD. This leads to confusion since accounts and passwords are not synced, so usernames and passwords can be different. Those customers may be looking for a way to master accounts, groups, and mailboxes from AD on-prem so they have a single source of authority, similar to the way that hybrid customers do.

In other environments, customers are using Azure AD Connect to sync users from AD on-premises to the cloud. Here, user accounts and groups are managed on-premises, but mailboxes are managed in Exchange Online. These customers may be looking for a way to manage mailboxes and groups from AD, so they also have a single source of authority.

The following steps will let you install the Exchange 2019 Exchange Management Tools (EMT) in an AD environment without having to install Exchange Server. 

Keep in mind that this solution is not supported by Microsoft, since manual configurations must be made in AD using ADSI Edit. The Microsoft supported way to do this is to install an Exchange Server in the org. The solution below does not require this.

Prerequisites

• Active Directory is installed and the Forest Functional Level is Windows Server 2012 R2 or higher.
• The Exchange Management Tools (EMT) must be installed on a domain-joined computer. Azure AD-joined by itself is not enough, since we need to be able to update Active Directory.
• EMT can be installed on Windows 10, Windows 11, or any Windows Server 2016+ server.
• You will need the Exchange Server 2019 CU12 or later media.
• The AD schema will be updated during EMT installation. These procedures assume the installation is being performed by a Domain Admin.

Steps for Installing the Exchange Management Tools

• Logon to the domain-joined computer or server where you want to install the EMT as a Domain Admin. For ease of installation, it is recommended that this computer be in the same AD site as the AD Schema Master.
• Install the .NET Framework 4.8.
• Install the Visual C++ 2012 Runtime.
• Install Windows Remote Server Administration Tools (RSAT) for Windows 10 or Windows 11. On Windows Server add the AD DS Tools from Server Manager.
• Install the IIS 6 Metabase Compatibility component using the following command:
• dism /online /Enable-Feature /FeatureName:IIS-IIS6ManagementCompatibility /all
• Restart the management computer twice to ensure all files and installations are up-to-date.
• Run Setup from the Exchange 2019 CU12+ media
• Select only Management Tools in the Server Role Selection
• You will be prompted to add the Exchange Organization Name (i.e., Contoso)
• Restart the computer after EMT installation
• Run the C:\Program Files\Microsoft\Exchange Server\V15\Scripts\ExchangeAdd-PermissionForEMT.ps1 script from an elevated PowerShell prompt to create the Recipient Management EMT security group in the Users container.
• Add admin accounts to the new Recipient Management EMT group. Domain Admins already have rights to run the EMT and do not need to be added.
• Create a shortcut on the Desktop to the EMT:
• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command "Add-PSSnapin *RecipientManagement"
• Configure the shortcut to run as Administrator

Note:

All mailbox management will be done using the EMT PowerShell cmdlets. The Exchange Management Shell (EMS) will also be installed, but you will never use it because you have no Exchange Server to connect to.

There is no built-in GUI for EMT recipient management, but fellow Office Apps & Services MVP Steve Goodman wrote one on GitHub. You may want to check it out. 

Also, be aware that the EMT does not support roles based access controls (RBAC) and there is no auditing available. For complete Microsoft EMT documentation see Install the Exchange management tools | Microsoft Learn.

Microsoft Exchange System Objects (MESO) Configuration

In order for admins to create remote mailboxes, you need to add a remote domain to the Exchange configuration partition in Active Directory. This is done using ADSI Edit. The usual disclaimer applies - Don't use this tool unless you know what you're doing. I accept no responsibility. Yada yada yada.

• Begin by getting your Microsoft 365 tenant's remote routing domain.
• Open Exchange Admin Center
• Navigate to Mail Flow > Accepted Domains
• Record the accepted domain of the domain that looks like domain.mail.onmicrosoft.com

• Open ADSIEdit.msc from the management computer. This was installed when you installed the Windows Remote Server Administration Tools (RSAT).
• Connect to the Configuration Naming Context.
• Navigate to CN=Configuration > CN=Services > CN=Microsoft Exchange > CN=domain > CN=Global Settings > CN=Internet Message Formats
• Right-click CN=Internet Message Formats and select New > Object...
• Select the class msExchDomainContentConfig and click Next
• Enter Hybrid Domain - domain.mail.onmicrosoft.com for the value, using the value recorded above. Click Next and Finish.
• Edit the Hybrid Domain you just created and set the following values:
• contentType: 0
• domainName: domain.mail.onmicrosoft.com, using the value recorded above
• msExchContentByteEncoderTypeFor7BitCharsets: 15
• msExchContentPreferredInternetCodePageForShiftJis: 0
• msExchDomainContentConfigFlags: 1
• msExchMinAdminVersion: -2147453113
• msExchResolveP2: 2147483647
• msExchRoutingAcceptMessageType: 351
• msExchRoutingDisplaySenderEnabled: True
• msExchVersion: 4535486012416
• sendTNEF: True
• Close ADSI Edit.

Add the remote routing domain as an accepted domain.

• Run the following from an elevated EMT prompt, using the value you recorded above:
• New-AcceptedDomain domain.mail.onmicrosoft.com -DomainName domain.mail.onmicrosoft.com

Update the email address policy that was created when the EMT was installed.

• Run the following from an elevated EMT prompt:
• Get-EmailAddressPolicy | Set-EmailAddressPolicy -EnabledEmailAddressTemplates "SMTP:@domain.com","smtp:@domain.mail.onmicrosoft.com"
• Replace the domains with the correct values.
• SMTP:@domain.com (SMTP in all caps) is the primary SMTP address for your organization.
• smtp:@domain.mail.onmicrosoft.com is the remote routing domain that you recorded above.

Now you can run all the EMT cmdlets to update your on-prem user accounts, mailboxes, and groups.

Configure AD Synchronization with Azure AD

Now that you have a way to update Exchange attributes in AD, the final step is to configure Azure AD Connect to sync the AD objects with Azure AD. 

If your environment already has AAD Connect installed and configured, you only need to update the AAD Connect configuration to use Exchange Hybrid Deployment in Optional Features.

If your environment doesn't already have Azure AD Connect installed and configured, you will need to do so and perform a soft match of the AD accounts to Azure AD. That's beyond the scope of this article. 

If you need help please reach out to me at EXPTA Consulting.

Read more ...

New Version of AAD Connect Fixes Vulnerability

Microsoft released Azure AD Connect version 2.1.15.0 today. This version fixes a vulnerability that was discovered in the Azure AD Connect Admin Agent. If you have installed the Admin Agent previously it is important that you update your Azure AD Connect server(s) to this version to mitigate the vulnerability.

The Azure AD Connect Admin Agent collects specific data from your Active Directory environment that helps a Microsoft support engineer to troubleshoot issues when you open a support case. See What is the Azure AD Connect Admin Agent - Azure AD Connect - Microsoft Entra | Microsoft Docs for more information.

Be aware that installing this version will cause AAD Connect to perform an Initial (Full) sync.

This update will roll out soon automatically if your configuration is enabled for auto-upgrade.

In addition to fixing the vulnerability, there are some functional changes and bug fixes. See Azure AD Connect: Version release history - Microsoft Entra | Microsoft Docs for full details.

Functional changes

• We have removed the public preview functionality for the Admin Agent from Azure AD Connect. We will not provide this functionality going forward.
• We added support for two new attributes: employeeOrgDataCostCenter and employeeOrgDataDivision.
• We added CerificateUserIds attribute to AAD Connector static schema.
• The AAD Connect wizard will now abort if write event logs permission is missing.
• We updated the AADConnect health endpoints to support the US government clouds.
• We added new cmdlets “Get-ADSyncToolsDuplicateUsersSourceAnchor and Set-ADSyncToolsDuplicateUsersSourceAnchor“ to fix bulk "source anchor has changed" errors. When a new forest is added to AADConnect with duplicate user objects, the objects are running into bulk "source anchor has changed" errors. This is happening due to the mismatch between msDsConsistencyGuid & ImmutableId. More information about this module and the new cmdlets can be found in this article.

Bug fixes

• We fixed a bug that prevented localDB upgrades in some Locales.
• We fixed a bug to prevent database corruption when using localDB.
• We added timeout and size limit errors to the connection log.
• We fixed a bug where, if child domain has a user with same name as parent domain user that happens to be an enterprise admin, the group membership failed.
• We updated the expressions used in the "In from AAD - Group SOAInAAD" rule to limit the description attribute to 448 characters.
• We made a change to set extended rights for "Unexpire Password" for Password Reset.
• We modified the AD connector upgrade to refresh the schema – we no longer show constructed and non-replicated attributes in the Wizard during upgrade.
• We fixed a bug in ADSyncConfig functions ConvertFQDNtoDN and ConvertDNtoFQDN - If a user decides to set variables called '$dn' or '$fqdn', these variables will no longer be used inside the script scope.
• Multiple accessibility fixes (see article for details).

Read more ...