What configuration or authentication behavior in Exchange/Outlook could be causing credentials to be misrouted

Question

In a hybrid environment with on-premises Active Directory and externally hosted Exchange Server, users are experiencing repeated AD account lockouts when launching Outlook; the client appears to send the mailbox credentials against local domain controllers using only the pre-@ portion of the UPN, which fails if AD and mailbox passwords differ. Reviewing AD security logs confirms the repeated failed logons from Outlook clients, for example:

Get-WinEvent -LogName Security |
  Where-Object { $_.Id -eq 4625 -and $_.Properties[5].Value -like "<username>" } |
  Select-Object TimeCreated, @{Name="Workstation";Expression={$_.Properties[18].Value}}, @{Name="FailureReason";Expression={$_.Properties[11].Value}} |
  Sort-Object TimeCreated -Descending | Select-Object -First 5

What configuration or authentication behavior in Exchange/Outlook could be causing credentials to be misrouted to AD in this way

Answer 1

Hi @Palmira Paerce

Thank you for posting your question in Microsoft Q&A. 

As my research, this issue might be caused by incorrectly configured Autodiscover Service Connection Point (SCP) record in your on-premises Active Directory. When a domain-joined Outlook client launches, its first step in the Autodiscover process is to query Active Directory for this SCP record. If the SCP record still points to an on-premises Exchange server (or a decommissioned one), Outlook will attempt to authenticate against that internal endpoint. This internal authentication attempt uses legacy protocols (like NTLM) which send the username in the Domain\SAMAccountName format, matching the pre-@ behavior you're seeing and causing the lockout when the password differs from the cloud mailbox. 

Could you try to check SCP Configuration:  

Use PowerShell to inspect the SCP on the on-premises Exchange server:  

Get-ClientAccessServer | Get-AutodiscoverVirtualDirectory | fl Name,InternalUrl,ExternalUrl 

Ensure the InternalUrl and ExternalUrl point to the correct hosted Exchange Autodiscover endpoint. 

If the AutoDiscoverServiceInternalUri value is populated, run the following command to nullify it. Repeat for all servers listed. 

Set-ClientAccessService -Identity "YourOnPremServerName" -AutoDiscoverServiceInternalUri $null 

Then, try launching Outlook again. 

Please understand that our initial reply may not always immediately resolve the issue. However, with your help and more detailed information, we can work together to find a solution.

---

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".      

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.