Как работает авторизация и разделение данных в MS Exchange при использовании EWS в 1С

← На главную

Интеграция 1С с Microsoft Exchange через Exchange Web Services (EWS) — это мощный инструмент для автоматизации работы с почтой, календарями и задачами. Однако разработчики часто сталкиваются с ситуацией, когда авторизация ведет себя непредсказуемо. Например, запрос к серверу может успешно выполняться даже при указании заведомо неверного пароля в коде. Разберем подробно, почему так происходит, как на самом деле работает проверка подлинности и как правильно организовать доступ к данным разных пользователей.

Почему EWS «проглатывает» неверный пароль: магия NTLM

При использовании COM-объекта MSXML2.XMLHTTP или WinHttp.WinHttpRequest.5.1 для отправки SOAP-запросов к Exchange, многие сталкиваются с тем, что параметры логина и пароля в методе open() игнорируются. Проанализируем причину этого поведения.

Большинство корпоративных серверов Exchange настроены на использование Windows Integrated Authentication (NTLM или Kerberos). Если компьютер, на котором запущена 1С, находится в том же домене, что и сервер Exchange, библиотека MSXML2.XMLHTTP может автоматически использовать учетные данные текущего сеанса Windows. Рассмотрим пошагово, что происходит:

Объект 1С инициирует запрос к /EWS/Exchange.asmx.
Сервер IIS (на котором работает Exchange) отвечает кодом 401 (Unauthorized) и сообщает, что поддерживает NTLM.
Библиотека Windows, не спрашивая код 1С, автоматически подставляет токен текущего пользователя Windows.
Сервер принимает этот токен, авторизует запрос и возвращает 200 OK.

В результате, какие бы учетные данные вы ни писали в методе open(), запрос выполняется от имени того, под кем запущен сеанс 1С или служба сервера 1С. Это объясняет, почему для «новых» доменных учеток всё работает «само», а для внешних или старых учеток авторизация может требовать явного указания пароля.

Пример базового запроса к EWS

Посмотрим на пример функции, которая создает объект для отправки запроса. Важно понимать, что метод open подготавливает соединение, но не гарантирует, что будут использованы именно эти Логин и Пароль, если включена сквозная авторизация.


Функция СоздатьXMLHTTP(ИмяСервера, Логин, Пароль)
    стрURL = "https://" + ИмяСервера + "/EWS/Exchange.asmx";
    oXMLHTTP = Новый COMОбъект("MSXML2.XMLHTTP");
    
    // Третий параметр "Ложь" означает синхронный запрос
    oXMLHTTP.open("POST", стрURL, Ложь, Логин, Пароль); 
    oXMLHTTP.setRequestHeader("Content-Type", "text/xml;charset=UTF-8");    
    
    Возврат oXMLHTTP;
КонецФункции

Разделение данных: как получить доступ к конкретному ящику

Выясним, как Exchange понимает, чьи именно папки нужно вернуть. В EWS за это отвечает структура XML-запроса в теле SOAP-сообщения. Если мы используем стандартные константы, такие как msgfolderroot (корень почтового ящика) или inbox (входящие), сервер всегда возвращает данные того пользователя, под которым прошла авторизация.

Проанализируем пример SOAP-пакета для поиска папок:


| <m:ParentFolderIds>
|    <t:DistinguishedFolderId Id="msgfolderroot"/>
| </m:ParentFolderIds>

Если вы авторизованы как Иванов, вы увидите папки Иванова. Если как Петров — папки Петрова. Но как быть, если нам нужно одной сервисной учетной записью собирать почту со всех ящиков компании? Здесь на сцену выходит механизм Application Impersonation (Олицетворение).

Работа под «супер-учеткой»: Application Impersonation

Для массовой обработки писем без знания паролей каждого пользователя используется механизм «самозванства». Рассмотрим, как это реализовать:

Настройка на стороне Exchange: Администратор должен назначить вашей сервисной учетной записи роль ApplicationImpersonation. Это делается через Exchange Management Shell командой New-ManagementRoleAssignment.
Изменение XML-запроса: В заголовок SOAP-запроса (секция Header) необходимо добавить блок ExchangeImpersonation.

Разберем, как должен выглядеть заголовок в коде 1С, чтобы сервер понял, что мы хотим «прикинуться» другим пользователем:


Функция СформироватьЗаголовокИмперсонации(EmailЦелевогоПользователя)
    ТекстЗаголовка = 
    "<soap:Header>
    |  <t:ExchangeImpersonation>
    |    <t:ConnectingSID>
    |      <t:PrimarySmtpAddress>" + EmailЦелевогоПользователя + "</t:PrimarySmtpAddress>
    |    </t:ConnectingSID>
    |  </t:ExchangeImpersonation>
    |</soap:Header>";
    Возврат ТекстЗаголовка;
КонецФункции

Теперь, даже если ваша сессия авторизована под пользователем ServiceAccount, наличие этого заголовка заставит Exchange выполнять операции в контексте ящика EmailЦелевогоПользователя.

Особенности работы с Exchange 2013 и выше

При работе с Exchange 2013 стоит помнить о нескольких важных моментах:

Basic Authentication: На локальных серверах она часто включена, но в целях безопасности ее стараются отключать. Если вы используете 1С на сервере вне домена, вам придется явно передавать заголовок Authorization: Basic [Base64(login:pass)].
OAuth 2.0: Хотя для Exchange 2013 это настроить сложно, для более новых версий (2016/2019) и Office 365 это становится стандартом. В этом случае вместо логина и пароля в MSXML2.XMLHTTP нужно передавать Bearer-токен в заголовках.
Кеширование соединений: Помните, что HTTP-соединения могут оставаться открытыми (Keep-Alive). Если вы в рамках одного процесса 1С сначала авторизовались правильно, а потом пробуете с неверным паролем — запрос может пройти просто потому, что сессия еще жива на уровне TCP/IP.