Ошибка 401 веб-служб Exchange в Debian, но не в Windows

Question

Следующий код прекрасно работает в 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("[e-mail]");
                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>

Answer 1

Этот ответ на 3 года слишком поздно, чтобы помочь OP, но он может помочь другим бедным душам, ломающим голову. У меня были те же симптомы, но на macOS с .Net Core 3.1, и исправление, которое я нашел, заключалось в использовании только схемы + имя хоста в URL-адресе службы. Нет элементов пути.

Вместо того

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

использовать

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

Я наткнулся на это решение, которое, я уверен, очевидно для более опытных разработчиков .Net, после того, как попробовал всевозможные другие потенциальные решения. Я попытался включить домен AD в имя пользователя (DOMAIN\username), используя CredentialCache с записью для NTLM, переключение PreAuthenticate, включая различные доменные имена в NetworkCredential, Basicавторизация и многое другое. Все потерпели неудачу с ужасным 401 пока я не вырезал путь из URL-адреса службы.