0

Working in a 2019 Domain Active Directory, running 2019 Exchange Server, using Office Professional Plus 2016.

Adding a new account to Outlook, connect to exchange using autodiscover, the process goes smooth open the mailbox, populate folders and show the content. After a few minutes, 'need password' and a (looks like a web request) for a password. Just clicking 'Type Exchange Password and Continue' on the 'send/receive' bar, reconnect and... smooth sailing again.

Assuming domain is VALID and user is USER. Checking the security log on Exchange Server, I can see the initial connections is for VALID\USER but, the next one, that fails, is for EXCHANGE\USER. Our server name is EXCHANGE. Why trying to use the wrong domain? It also try USER@VALID... without sending the domain, that also fail.

Tests:

In Outlook-2016, create a new profile, add the domain account: same result. I should note that Outlook did not ask for username\password. The computer I'm using is not join to DOMAIN.

Hints:
I test the connection using the TestConnectivity tool results show ok, with no mention to DOMAIN as domain.

fcm
  • 398
  • 1
  • 2
  • 12
  • Exchange is domain oriented software. meaning, the exchange server, the client machine, and all users should be members of the same domain if everything is to flow smoothly. Note also that the word "exchange" appears absolutely everywhere. In the registry, in AD, in the file system, etc... everywhere. So give the mail server a different name so that you can tell the two apart(software name vs machine name). – Larryc Apr 24 '20 at 08:28
  • I partially disagree. Client machine: **NO** (you can't join a phone to a domain or your home computer). Server named Exchange: **NO** I have this name for many server version/generations with no issues. Finally, this only happen to a few users out of hundreds. – fcm Apr 25 '20 at 10:30
  • Are these users' mailboxes locating on the same database which is different from other mailboxes' ? – Ivan_Wang Apr 27 '20 at 01:38
  • Yes, all share the same database (out of four active db) – fcm Apr 27 '20 at 07:33
  • Did the "Test E-mail AutoConfiguration"(Press "Ctrl" + Right-Click the Outlook icon) return the wrong domain(Just like Internal/External OWA URLs) in the test result? – Ivan_Wang Apr 27 '20 at 09:16
  • Test run with no issues at all 100% clean. By design Internal and External URLs are the same, DNS gives inhouse users a different IP. I just move account to another database, same results. – fcm Apr 27 '20 at 18:46
  • 1
    >>"'need password' and a (looks like a web request) for a password." It looks like an office365 account, here is one document about Outlook 2016 implementation of Autodiscover(https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover), you could refer to Step4(Before changing these settings in the link, you need backup them to revert the changes easily). – Ivan_Wang Apr 29 '20 at 01:33
  • For some, use control panel ->credential manager and fix old passwords. – fcm Apr 30 '20 at 02:18

2 Answers2

0

Did you get the following web request?

enter image description here

Ivan_Wang
  • 1,323
  • 1
  • 3
  • 4
  • Yes, this is the nefarious message... – fcm May 05 '20 at 10:08
  • 1
    Try to block Outlook from connecting to O365 by setting a registry key: ExcludeExplicitO365Endpoint(DWORD, value=1) , then reboot your client and login this account again to check the result, more details about it: https://www.gothamweb.com/portal/index.php/knowledgebase/8/Outlook-bypasses-AutoDiscover-and-connects-directly-to-Office-365-mailbox.html – Ivan_Wang May 06 '20 at 01:38
  • good tip, but did not work on my case.... (o365) – fcm May 12 '20 at 03:54
  • Maybe some autodiscover configurations cause the issue, here is one document about it, hope it helpful to you: https://www.ajtek.ca/guides/exchange-autodiscover-a-guide-to-making-exchange-work-properly/ – Ivan_Wang May 15 '20 at 10:14
0

Sorry to answer my own question, however, I hope that will help others.

I'm a manager on my organization, at one point, I had 'FullAccess' to helpdesk and clerks users mailboxes; their entry turn corrupted (moved, deleted, disabled etc.) and, for whatever reason, I was unable to access them, so Outlook start asking for a password.

This Powershell script will visit every user, showing the third party mailbox permission for that user, removing 'me' (as $myself) if found there.

$myself=get-mailbox -id <MY_ID_HERE>
# search all the users, looking for me
# I'm interested only in 'real' users (with Mailbox)
# Ignoring display of one user redacted as 'xxx'
foreach ($mbx in ( Get-Mailbox )){        
    $user = $mbx | get-MailboxPermission  | `
        % { Get-Mailbox -Identity $_.user.rawIdentity -errorAction SilentlyContinue } | `
        ? { $_.Alias -ne 'xxx' }
    if ($user){
        Write-Output "------ $($mbx.DisplayName) $($mbx.alias) ------"
        foreach($fc in ($user | ? { $_.alias -eq $myself.alias } ) ){
            Remove-MailboxPermission -Identity $mbx.alias -AccessRights ('FullAccess') -User $fc.Alias -Confirm:$False
        }
        $user
        }
}

Well, no more passwords request after running it. Of course if you really need access.... you need to set them back again.

Use the -whatif parameter on the Remove-MailboxPermission to test the script.

fcm
  • 398
  • 1
  • 2
  • 12