Debian 上的 Exchange Web Services 401 错误，但不是 Windows答案

【问题标题】：Exchange Web Services 401 error on Debian but not windowsDebian 上的 Exchange Web Services 401 错误，但不是 Windows
【发布时间】：2018-07-20 08:26:50
【问题描述】：

以下代码在 Windows 上运行良好，但在 debian 上返回 401 - 不允许匿名请求。它使用的是 DotNet 核心 2.0.0。如果这有帮助。我认为这可能是因为 Windows 上的机器以某种方式发现了域，而 debian 机器却没有。我不知道。任何帮助表示赞赏。

using System;
using Microsoft.Exchange.WebServices.Data;

namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            ExchangeService service = new ExchangeService();
            service.EnableScpLookup = false;
            service.TraceEnabled = true;
            service.UseDefaultCredentials = false;
            service.PreAuthenticate = false;
            service.TraceFlags = TraceFlags.All;
            try
            {
                service.Url = new Uri("https:/domain/ews/Exchange.asmx");
            }
            catch (Exception ex) {
                throw new Exception(string.Format("webService Uri:" + ex));
            }
            try
            {
                service.Credentials = new WebCredentials("username", "pass","domain");
            }
            catch (Exception ex) {
                throw new Exception(string.Format("Credentials:" + ex));
            }
            try
            {
                EmailMessage email = new EmailMessage(service);
                email.ToRecipients.Add("user@domain.com");
                email.Subject = "HelloWorld";
                email.Body = new MessageBody("This is the first email I've sent by using the EWS Managed API");
                email.Save();
                email.Send();
            }
            catch (Exception ex) {
                Console.WriteLine(ex.ToString());
            }
        }
    }
}

编辑 1：如果有帮助，我可以把肥皂的痕迹和电子邮件的异常省略：

<trace Tag="EwsRequestHttpHeaders" Tid="1" Time="2018-07-20 09:31:08Z">
POST /ews/Exchange.asmx HTTP/1.1
Content-Type: text/xml; charset=utf-8
Accept: text/xml
User-Agent: ExchangeServicesClient/15.00.0913.015
Accept-Encoding: gzip,deflate


</Trace>
<Trace Tag="EwsRequest" Tid="1" Time="2018-07-20 09:31:09Z" 
Version="15.00.0913.015">
 <?xml version="1.0" encoding="utf-8"?>
 <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
   <soap:Header>
     <t:RequestServerVersion Version="Exchange2013_SP1" />
   </soap:Header>
   <soap:Body>
     <m:CreateItem MessageDisposition="SaveOnly">
       <m:Items>
         <t:Message>
           <t:Subject>HelloWorld</t:Subject>
           <t:Body BodyType="HTML">This is the first email I've sent by using the EWS Managed API</t:Body>
           <t:ToRecipients>
             <t:Mailbox>
               <t:EmailAddress>**********@******.com</t:EmailAddress>
             </t:Mailbox>
           </t:ToRecipients>
         </t:Message>
       </m:Items>
     </m:CreateItem>
   </soap:Body>
 </soap:Envelope>
</Trace>
<Trace Tag="EwsResponseHttpHeaders" Tid="1" Time="2018-07-20 09:31:12Z">
HTTP/1.1 401 Anonymous Request Disallowed
Server: Microsoft-IIS/8.5
request-id: 13c632cd-7642-4e26-ad5d-48dce4b52d35
WWW-Authenticate: Negotiate, NTLM
X-Powered-By: ASP.NET
X-FEServer: FTLPEX02CAS02
Date: Fri, 20 Jul 2018 09:31:11 GMT
Content-Length: 0


</Trace>

【问题讨论】：

这个答案有帮助吗：SOAP authentication fails when running a c# app on a linux box?
不是真的，我尝试缓存我的凭据，然后将 NTML 指定为身份验证类型，然后发送它，这在 Windows 上工作正常（就像我的原始代码一样），但在 Debian 上也有同样的错误.不过可能我理解错了。
我也尝试将 DotNet 核心版本更改为 2.1，但这给了我一些奇怪的 kerberos 错误

标签： c# .net linux asp.net-core exchangewebservices

【解决方案1】：

这个答案对于帮助 OP 来说已经晚了 3 年，但它可能会帮助其他一些令人头疼的可怜人。我遇到了同样的症状，但在 macOS 上，使用 .Net Core 3.1，我发现的修复是在服务 URL 中仅使用架构 + 主机名。没有路径元素。

代替

service.Url = new Uri("https:/domain/ews/Exchange.asmx");

使用

service.Url = new Uri("https:/domain");

我偶然发现了这个解决方案，在尝试了各种其他潜在的解决方案之后，我确信这对于更有经验的 .Net 开发人员来说是显而易见的。我尝试在用户名 (DOMAIN\username) 中包含 AD 域，使用 CredentialCache 和 NTLM 的条目，切换 PreAuthenticate，包括 NetworkCredential、Basic 授权等中的各种域名。可怕的401 都失败了，直到我切断了服务 URL 的路径。

【讨论】：