none
Mapi over http password prompt RRS feed

  • Question

  • Hi all!

    I have a strange situation with MAPI over HTTP protocol.

    When user is on a corporate network all is OK and working just fine.

    Situation A:

    User goes to public network and open Outlook 2016/2019. In few seconds there will be username&password prompt. If you enter the credentials and save them everything is just fine and working OK.

    Situation B:

    I now have saved credentials from situation A. Now I login back to corpo network and change my password. Then I restart my PC and still on corpo network open Outlook. All OK.

    Then I go to public network and credential prompt is back again.

    So points are:

    Outlook is working just fine when internal

    Outlook will prompt for credentials when domain user is on external network

    If you save the creds you are good till next password change

    This is NOT OK as it should always use Windows logon session credentials

    More info:

    Mixed Outlook 2016/2019 with literally latest patches applied.

    Exchange server 2013 CU22

    Outlook anywhere set to negotiate and SSL offloading enabled

    Certs are OK

    Output of mapi virtual dir:

    IISAuthenticationMethods        : {Ntlm, OAuth, Negotiate}
    MetabasePath                    : IIS://INTERNALSERVER/W3SVC/1/ROOT/mapi
    Path                            : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\mapi
    ExtendedProtectionTokenChecking : None
    ExtendedProtectionFlags         : {}
    ExtendedProtectionSPNList       : {}
    AdminDisplayVersion             : Version 15.0 (Build 1473.3)
    Server                          : INTERNALSERVER
    InternalUrl                     : https://mail.domain.com/mapi
    InternalAuthenticationMethods   : {Ntlm, OAuth, Negotiate}
    ExternalUrl                     : https://mail.domain.com/mapi
    ExternalAuthenticationMethods   : {Ntlm, OAuth, Negotiate}
    AdminDisplayName                :
    ExchangeVersion                 : 0.10 (14.0.100.0)
    Name                            : mapi (Default Web Site)

    On AD we have set user logon name to proper UPN format: user@domain.com
    Users are logging in to their PC with DOMAIN\user   format.

    So why are only external users getting password prompts?

    Thanks for help in advance :) !

    Thursday, April 4, 2019 10:01 AM

Answers

  • Hi Grega,

    The articles you referred to are for legacy version of Exchange which use MAPI/RPC instead of MAPI/HTTP. That isn't applicable in your situation.

    Based on my deep research, this is indeed an expected behavior for security reason. Check the following quoted info for more details:

    The problem originates in the LSASS (local security authority) of the client machine.  It is asked to provide an NTLM hash for the purpose of authenticating to the MAPI HTTP end-point; however due to the state of the authentication engine (Kerberos is not available because DC is no longer available), it is considered to be a downgrade attack. That is, an attempt to force the less secure NTLM hash to be used when it shouldn’t.

    This downgrade protection was introduced a long time ago in Windows and it is unfortunate that it is causing inconvenience in a new scenario (i.e. re-enter credentials once to access email, when resuming work whilst away from the corporate network/Domain Controller).  

    All told, in a world that demands more information security, we believe it is acceptable that when moving to a new, more secure platform (MAPI over HTTP versus Outlook Anywhere), some compromises need to be made.  It has always been, and still is a bit of a dilemma with increased security and usability. Entering a password to reconnect to Email when away from the corporate network seems a small price to pay for improved security.

    To simplify it a bit, but the reason Outlook Anywhere is working is because first of all we are using a different protocol that works differently, and that the client would be able to instruct the underlaying communication layer to use NTLM, that is not feasible the same way when using MAPIHTTP.

    Hope it helps.

    Regards,
    Steve Fan


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, April 11, 2019 10:36 AM
    Moderator

All replies

  • Just to add, this NEVER happened with Outlook anywhere (RPC).

    We only have problems with mapi over http.

    Thursday, April 4, 2019 10:07 AM
  • Heh.

    Set mapi virtual dir IIS auth mode to NTLM only

    Remove negotiate auth method from IIS directly from sites: EWS, MAPI, AUTODISCOVER

    Restart Exchange for good measure = working now, but NTLM

    As many people figured it out Negotiate is the problem here.

    Question:
    Is this (password prompt for external users) considered to be:
    a) error with configuration on my side
    b) outlook bug (2003 to 2019)
    c) Exchange bug (Tried with 2013 CU22 and latest 2019)
    d) working as intended so NO bug and NO config error?

    Thanks!

    Thursday, April 4, 2019 5:37 PM
  • Hi,

    I haven't found any documentation that stating this is a limitation on the server side or the client side, but I did come across several threads reporting the same issue, and using NTLM is always the workaround in the situation. I'll keep researching on the issue from our internal database and will keep you posted when I have any finding.

    Thanks,
    Steve Fan


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, April 5, 2019 7:32 AM
    Moderator
  • Thanks.

    I also tried logging into PC with UPN, so with mail address and same situation occured.

    UPN matches email address and all connectivity tests are successful.

    But same result, credential prompt.

    Outlook *should* fall back to NTLM IMHO.

    Friday, April 5, 2019 8:30 AM
  • Thank you for the update. 

    Are you using Kerberos authentication internally? If so, I'm afraid this is the expected behavior and you have to type in password if prompted. 

    Regards,
    Steve Fan


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, April 9, 2019 8:54 AM
    Moderator
  • Hi!
    We use Negotiate.

    And I found this:

    Negotiate authentication automatically selects between the Kerberos protocol and NTLM authentication, depending on availability. The Kerberos protocol is used if it is available; otherwise, NTLM is tried. Kerberos authentication significantly improves upon NTLM. Kerberos authentication is both faster than NTLM and allows the use of mutual authentication and delegation of credentials to remote machines.

    So well I still think it`s a bug. Outlook should try Kerberos, fail it (for external users) and then try NTLM which should be OK.

    So you are telling me:

    If we have set NTLM and Negotiate on MAPI virtual dir internal clients are OK, but external SHOULD and MUST prompt for password?

    Tuesday, April 9, 2019 9:14 AM
  • Hmmm also here:

    https://blogs.technet.microsoft.com/exchange/2011/04/15/recommendation-enabling-kerberos-authentication-for-mapi-clients/

    and here:

    https://support.microsoft.com/ru-ru/help/2688772/kerberos-authentication-for-mapi-client-connection-to-a-client-access

    it is mentioned:

    "Note: External or Internet-based clients that use Outlook Anywhere won’t use Kerberos authentication. Therefore, you don't have to add the FQDNs that these clients use as SPNs to the ASA credential. "

    And comment from <cite class="fn">Ross Smith IV:</cite>

    "@CY – When you use external trust, only NTLM authentication is available."<cite class="fn"></cite>

    So this actually confirms even more that this is Outlook issue that it`s not switching to NTLM when KDC not available but instead it switches to basic auth which prompts user for credentials.

    Can somebody please escalate this to Outlook team?

    Thanks!

    Wednesday, April 10, 2019 5:41 PM
  • Hi Grega,

    The articles you referred to are for legacy version of Exchange which use MAPI/RPC instead of MAPI/HTTP. That isn't applicable in your situation.

    Based on my deep research, this is indeed an expected behavior for security reason. Check the following quoted info for more details:

    The problem originates in the LSASS (local security authority) of the client machine.  It is asked to provide an NTLM hash for the purpose of authenticating to the MAPI HTTP end-point; however due to the state of the authentication engine (Kerberos is not available because DC is no longer available), it is considered to be a downgrade attack. That is, an attempt to force the less secure NTLM hash to be used when it shouldn’t.

    This downgrade protection was introduced a long time ago in Windows and it is unfortunate that it is causing inconvenience in a new scenario (i.e. re-enter credentials once to access email, when resuming work whilst away from the corporate network/Domain Controller).  

    All told, in a world that demands more information security, we believe it is acceptable that when moving to a new, more secure platform (MAPI over HTTP versus Outlook Anywhere), some compromises need to be made.  It has always been, and still is a bit of a dilemma with increased security and usability. Entering a password to reconnect to Email when away from the corporate network seems a small price to pay for improved security.

    To simplify it a bit, but the reason Outlook Anywhere is working is because first of all we are using a different protocol that works differently, and that the client would be able to instruct the underlaying communication layer to use NTLM, that is not feasible the same way when using MAPIHTTP.

    Hope it helps.

    Regards,
    Steve Fan


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, April 11, 2019 10:36 AM
    Moderator
  • I know that was for RPC, but it applies to MAPI over HTTP as well.

    So that is a step back and will have to remove Negotiate header from external users connections so that they can use NTLM and have no pass prompts.

    But thanks, that cleared things up.

    Thursday, April 11, 2019 12:25 PM