Exchange 2013 / Outlook 2010 - Prompts for Credentials that are not Accepted


  • Hi,

    Having attempted to resolve this issue in the Office 365 Forums (, as it was after partially setting up an ADFS server (configured the Wizard to create the ADFS entry in AD, using my Exchange OWA Certificate - eg, rather than the desired and then attempting to activate AD Synchronisation in the Office365 Portal, I noticed that my Outlook clients were prompting for AD credentials (which are no longer recognised). Also. I applied SP1 to my windows 2008 R2 DC's at the same time but I'm pretty sure this not related.

    Anyway, the intersting thing is Outlook Anywhere works externally (if I connect a laptop via a 3G dongle) but not the LAN, although I did notice that Outllok 2013 did intermittently work on an internally connected laptop.

    I have tried to retrace my steps (remove ADFS and then re-install with correct SSL cert - and removed the old ADFS entries using ADSIEDIT (CN=<GUID>,CN=ADFS,CN=Microsoft,CN=Program Data,DC=<Domain>,DC=<COM>) but the Office 365team have suggested that I raise this with the Exchange experts.

    Note, I did start to configure SSO 

    • Connect to Microsoft Online Services with the credential variable set previously
      • Connect-MsolService –Credential $cred

     Set the MSOL ADFS Context server, to the ADFS server

      • Set-MsolADFSContext –Computer


    • Convert the domain to a federated domain
      • Convert-MsolDomainToFederated –DomainName domain_name.comand even tried to disbale ADS

    And even tried to disable the Federation

    Set-MSOLDomainAuthentication-Authentication Managed -DomainName

    John Philipson

    Possibly made a bit of progress, regarding Outlook Anywhere Security Settings. Not sure whether this was thing that changed but all settings are now for "Anonymous Logon", rather than say "Negotiate Authentication". 

    I have tried to change the Internal Settings with the following Powershell Command

    Get-OutlookAnywhere -Server Exchange_CAS_Server| Set-OutlookAnywhere -InternalClientAuthenticationMethod NTLM

    and when I checked,  with the following command, 

    Get-OutlookAnyWhere – Server Exchange_CAS_Server | fl *internal*

    the settings has changed to NTLM

    but when I check Outlook clients, Autodiscover is still keeping the settings for  "Anonymous Logon"

    I think there us a way of changing this in the registry but looks very involved

    Am I right in saying that Office365 actually needs "Anonymous Logon"

    • Edited by Baseliner Friday, September 11, 2015 8:07 PM
    Friday, September 11, 2015 10:52 AM


All replies

  • Have you tried installing the MSOL PowerShell on the ADFS server and running the commands there?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Saturday, September 12, 2015 8:01 PM
  • Thanks Ed,

    I was reluctant to run those commands and set up SSO, until I'd figured out the problem with Outlook prompting for credentials ?

    Are you suggesting that I run the commands that I listed above and complete the SSO config command (see below) that this might address the credentials issue ?

    Convert-MsolDomainToFederated –DomainName

    Also, I was actually wondering whether a "failed" but nevertheless attempted install of Dirsync could be causing problems. This was pretty much the last thing I did on a Windows 2008 R2 DC before the credentials issue surfaced but as the install failed (although it had nothing). Anyway, I have since installed dirsysnc successfully and still problems exist.

    John Philipson

    Sunday, September 13, 2015 1:43 PM
  • It is my understanding that you need DirSync for Office 365 to work with AD FS.  You must federate all domains for which you want AD FS to authenticate.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Monday, September 14, 2015 12:02 AM
  • OK Ed, I'll give that a go - just didn't want to make too many changes to a trial (that I may need to back out of).

    Just to recap though, is the default on Exchange 2013 Outlook Anywhere Settings, to configure Outlook to use security setting of "Anonymous Logon" or is something that must have changed since Office 365 ?

    I'm surprised that despite running commands like the one below, that the settings refuse to change to use "Negotiate Authentication" ? (

    Get-OutlookAnywhere -Server Exchange_CAS_Server| Set-OutlookAnywhere -InternalClientAuthenticationMethod NTLM

    John Philipson

    Monday, September 14, 2015 9:49 AM
  • I don't understand your question.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Monday, September 14, 2015 2:20 PM
  • Hi Ed,

    My understanding is that I keep getting the credentials required pop up because Outlook is trying to use "Anonymous Logon" (although not sure what has actually caused that change) and that I need to change both my external & Internal Outlook Anywhere (and possibly IIS) Authentication methods from negotiate to NTLM ?

    John Philipson

    Tuesday, September 15, 2015 11:36 AM
  • Upon what is that understanding based?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Tuesday, September 15, 2015 3:22 PM
  • Hi,

    There a few articles that suggest the Outlook Anywhere settings are the issue with repeated pops up (see example URL below)

    If that's not the case, then I can only assume that ADFS may be causing the problems (although I still haven't configured the SSO setting) so not clear what mechanism is causing the credentials to be requested and then not accepted. 

    John Philipson

    Wednesday, September 16, 2015 9:33 AM
  • I don't believe that article applies to you since you are using Office 365 and the conditions it describes aren't present there. For Office 365, just let Outlook configure itself with Autodiscover.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Wednesday, September 16, 2015 10:18 AM
  • Thanks Ed,

    What I'm not clear about is what Office 365 process / mechanism is possibly causing Outlook to prompt for credentials internally (bot not externally) and then NOT accept them ?

    As far as I can tell, if I try to set up a new profile, Autodiscovery detects the User mailbox and puts in the GUID (GUID@DOMAIN.local) but cannot progress any further (error is "Action cannot be completed. The Connection to Microsoft Exchange is unavailable ..etc)

    The article below talks about DNS resolution issues (and I did switch on DNS scavenging a few days earlier) but my DNS looks fine and I'm at a loss with my troubleshooting steps ?

    Is it possible that my On Prem Exchange isn't recognizing properly my external domain name ( anymore as it doesn't appear in my accepted domains list but it won't let me add it either (says it already exists)

    Thursday, September 17, 2015 8:38 AM
  • PS. Also I was unable to complete the Hybrid Wizard due to the following error, which I believe points to a need to upgrade to CU6

    he wizard did not complete successfully. Please see the list below for error details.

    Updating hybrid configuration failed with error ‎'Subtask CheckPrereqs execution failed: Check Tenant Prerequisites Could not load type ‎'Microsoft.Exchange.Data.Directory.DirectoryBackendType‎' from assembly ‎'Microsoft.Exchange.Data.Directory, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35‎'. at System.Reflection.RuntimeAssembly.GetType‎(RuntimeAssembly assembly, String name, Boolean throwOnError, Boolean ignoreCase, ObjectHandleOnStack type)‎ at System.Reflection.RuntimeAssembly.GetType‎(String name, Boolean throwOnError, Boolean ignoreCase)‎ at System.UnitySerializationHolder.GetRealObject‎(StreamingContext context)‎ at System.Runtime.Serialization.ObjectManager.ResolveObjectReference‎(ObjectHolder holder)‎ at System.Runtime.Serialization.ObjectManager.DoFixups‎()‎ at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize‎(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)‎ at etc...

    Thursday, September 17, 2015 8:47 AM
  • Have just done some more testing and when I set up a profile manually and type in the CAS server name, it resolves to Mailbox Server Node B of my DAG, which is currently the hosting the Passive copy of the Storage group DB so is it possible that Internally the CAS is trying to point Outlook to a read only copy of the users mailbox, whereas externally it is routing that information correctly ?
    Thursday, September 17, 2015 10:27 AM
  • If you still have an internal Exchange server and if you no longer have mailboxes on it (or at least mailboxes you need to use Autodiscover with), then consider setting Set-ClientAccessServer -AutodiscoverServiceInternalUri to the URL for Exchange Online Autodiscover.  That'll take the internal server out of the loop entirely.

    If you're still getting authentication prompts, run Outlook's Test E-mail Autoconfiguration feature and make sure everything points to Exchange Online.  If that looks good, then you could have a firewall problem.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Thursday, September 17, 2015 1:13 PM
  • Hi Ed,

    Just to clarify, I have NOT begun any Office 365 Migrations.

    As far as I'm concerned, everything should be still as it was, with my on-prem Exchange 2013 still acting as the Primary Exchange solution for ALL mailboxes.

    The only vaguely related article, I could find, is this one in that the person is having the same problems with Internal V external access but I'm really not sure what has changed on my environment. 

    Thursday, September 17, 2015 1:45 PM
  • Can your internal users get to your AD FS server without traversing the firewall?  That is, do you have split-brain DNS and an internal DNS entry for your AD FS server?  Have you tested that you can get AD FS by entering one of the test URLs in a browser?

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Thursday, September 17, 2015 2:08 PM
  • Hi Ed,

    Yes Internal uses can get to the ADFS Server (using split DNS)  URL ( but interestingly no valid credentials are not recognised.

    I'm still not clear why this should be affecting Outlook users connecting to On-Prem mailboxes ?

    Thursday, September 17, 2015 5:42 PM
  • It wasn't clear to me that you were having problems with on-premises mailboxes.

    Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

    Friday, September 18, 2015 4:15 AM