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.

8
  • 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 8: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 1:38
  • Yes, all share the same database (out of four active db)
    – fcm
    Apr 27 '20 at 7:33
  • 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(support.microsoft.com/en-us/help/3211279/…), 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 1:33
0

Did you get the following web request?

enter image description here

4
  • Yes, this is the nefarious message...
    – fcm
    May 5 '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: gothamweb.com/portal/index.php/knowledgebase/8/…
    – Ivan_Wang
    May 6 '20 at 1:38
  • good tip, but did not work on my case.... (o365)
    – fcm
    May 12 '20 at 3:54
  • Maybe some autodiscover configurations cause the issue, here is one document about it, hope it helpful to you: ajtek.ca/guides/…
    – 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.