Exchange ews что это
Начало работы с клиентскими приложениями EWS
Создание первого приложения с помощью веб-служб Exchange (EWS) в Exchange.
EWS это комплексная служба, которую приложения могут использовать для получения доступа практически ко всем данным, хранящимся в почтовом ящике локальной версии Exchange, Exchange Online или Exchange Online в составе Office 365. Для обеспечения доступа к серверу Exchange Server служба EWS использует стандартные веб-протоколы. Такие библиотеки, как EWS Managed API, позволяют преобразовать операции EWS для предоставления объектно-ориентированного интерфейса. Ознакомившись с примерами в этой статье, вы получите некоторое понимание того, что можно делать с помощью EWS.
Вам потребуется сервер Exchange Server
Если у вас уже есть учетная запись почтового ящика Exchange, вы можете пропустить этот шаг. Если это не так, ниже приведены несколько вариантов настройки почтового ящика Exchange для вашего первого приложения EWS.
Создайте Сайт разработчика в Office 365 (рекомендуется). Так можно получить почтовый ящик Exchange быстрее всего.
Когда вы проверите, можно ли отправлять сообщения на сервер Exchange Server и получать их с него, приступайте к настройке среды разработки. Проверить отправку сообщений можно с помощью Outlook Web App.
Если вы будете тестировать приложение на сервере Exchange Server, который использует самозаверяющий сертификат по умолчанию, вам потребуется создать метод проверки сертификата в соответствии с требованиями вашей организации к обеспечению безопасности.
Настройка среды разработки
Выбор инструментов для создания вашего первого приложения EWS зависит от операционной системы и языка, которые вы используете, но в основном это дело вкуса. Если вы хотите воспользоваться примерами на языке C# из этой статьи, вам понадобится следующее:
Подключение к Интернету, необходимое для связи компьютера для разработки с сервером Exchange Server. Если вы можете использовать Outlook Web App и DNS-имя вместо IP-адреса для соединения с сервером Exchange Server, все настроено.
Создание первого приложения EWS
Созданное приложение EWS продемонстрирует два стандартных сценария использования EWS:
Получение данных из почтового ящика Exchange и предоставление их пользователю.
Выполнение какого-либо действия (например, отправки электронного сообщения) и проверка отклика для подтверждения успешного завершения.
Теперь можно приступать к работе.
Настройка решения
Сначала необходимо создать новое консольное приложение с помощью Visual Studio, а затем — новый объект под названием Tracing.cs. Этот объект используется для записи информации в файлы журнала и консоли, чтобы после запуска кода отобразились результаты. Вставьте в файл Tracing.cs указанный ниже код.
Затем откройте файл Program.cs. В него будет помещена оставшаяся часть кода, используемого в качестве примера.
Сначала необходимо настроить программную оболочку. Программа выполнит следующее:
Создаст файл журнала для записи на диск запросов и откликов, чтобы позже их можно было изучить.
Получит доступ к электронному адресу и паролю учетной записи, которые вы будете использовать.
Вызовет примеры методов.
Замените метод Main в файле Program.cs указанным ниже кодом.
Число новых сообщений в папке «Входящие»
Получение сведений об электронных сообщениях, собраниях, встречах, а также папках, в которых эти сведения хранятся, типовые операции в приложении EWS. Этот пример поможет узнать, сколько сообщений находится в папке «Входящие» учетной записи, а также общее число сообщений и число непрочитанных сообщений. Пример демонстрирует следующие типовые действия для приложений EWS:
отправка запроса EWS на сервер Exchange;
анализ возвращенного XML-отклика на наличие запрошенной информации;
обработка типовых исключений и сообщений об ошибке.
Отправка электронных сообщений
Отправка электронных сообщений или приглашений на собрания — это еще одна типовая операция приложения EWS. Данный пример позволяет создать и отправить сообщение с помощью введенных ранее учетных данных пользователя. Пример демонстрирует следующие типовые задачи приложений EWS:
создание и отправка электронных сообщений;
анализ возвращенного XML-отклика для определения того, было ли сообщение отправлено корректно;
обработка типовых исключений и сообщений об ошибке.
Добавьте указанный ниже код в метод SendTestEmail, заглушенный вслед за основным. Запустив приложение, вы можете открыть файл GetStartedWithEWS.log и просмотреть XML-запрос, отправленный на сервер Exchange Server, и возвращенный сервером отклик.
Дальнейшие действия
Теперь, когда вы написали свое первое приложение EWS, можно переходить к другим способам использования EWS. Вот несколько идей для начала работы:
Реализуйте в приложении функции автообнаружения, чтобы оно могло соединиться с нужным сервером Exchange Server, используя электронный адрес пользователя. См. также пример в статье Exchange 2013: получение параметров пользователей с помощью автообнаружения.
Ознакомьтесь со справкой по EWS для получения дополнительных сведений об EWS.
Просмотрите список операций EWS для получения сведений о доступных операциях.
Используйте редактор EWS для просмотра траффика SOAP, отправляемого на сервер и обратно.
Если с приложением возникли проблемы, попробуйте опубликовать вопрос или комментарий на форуме (и не забудьте прочитать первую запись).
Проверка подлинности и EWS в Exchange
Сведения о том, как правильно выбрать стандарт проверки подлинности приложения веб-служб Exchange, предназначенного для Exchange.
Проверка подлинности — это ключевая составляющая приложения веб-служб Exchange. Exchange Online, Exchange Online в составе Office 365, а также локальные версии Exchange, начиная с Exchange Server 2013, поддерживают стандартные протоколы проверки подлинности в Интернете для защиты обмена данными между вашим приложением и сервером Exchange Server.
В случае с Exchange Online нужно выбрать способ проверки подлинности, при котором используется протокол HTTPS для шифрования запросов и откликов, которые отправляет ваше приложение. Хотя использование протокола HTTP для локальных серверов Exchange допустимо, рекомендуем применять протокол HTTPS в отношении всех запросов, которые ваше приложение отправляет в конечную точку веб-служб Exchange. Это обеспечит защиту обмена данными между вашим приложением и сервером Exchange Server.
В Exchange можно выбрать следующие варианты проверки подлинности:
OAuth 2.0 (только для Exchange Online);
NTLM (только для локальных версий Exchange);
обычная проверка (больше не рекомендуется).
Выбор метода проверки подлинности зависит от требований вашей организации к обеспечению защиты, от того, используете ли вы Exchange Online или локальные версии Exchange, а также от того, есть ли у вас доступ к стороннему поставщику, который может выдавать маркеры OAuth. Эта статья поможет вам выбрать подходящий стандарт проверки подлинности для вашего приложения.
Проверка подлинности OAuth
Рекомендуем использовать стандарт OAuth для подключения к службам Exchange Online во всех новых приложениях. Более высокий уровень защиты по сравнению с тем, который обеспечивает обычная проверка подлинности, оправдывает дополнительные усилия по реализации стандарта OAuth в вашем приложении. Но у этого стандарта есть и некоторые недостатки, которые следует учитывать.
Таблица 1. Преимущества и недостатки использования стандарта OAuth
| Преимущества | Недостатки |
|---|---|
| OAuth — это протокол проверки подлинности, соответствующий отраслевым стандартам. Проверку подлинности выполняет сторонний поставщик. Ваше приложение не должно собирать и хранить учетные данные Exchange. Это облегчает вам задачу, так как ваше приложение получает только скрытый маркер от поставщика проверки подлинности. Это значит, что в случае бреши в системе безопасности вашего приложения откроется доступ только к данным маркера, а не учетным данным Exchange пользователя. | OAuth требует использования стороннего поставщика проверки подлинности, поэтому возможны дополнительные расходы для вашей организации или клиентов. Стандарт OAuth сложнее реализовать, чем обычную проверку подлинности. Для его реализации необходимо интегрировать приложение с поставщиком проверки подлинности и сервером Exchange Server. |
Чтобы свести к минимуму неудобства, воспользуйтесь библиотекой проверки подлинности Microsoft Azure AD (ADAL) для аутентификации пользователей в доменных службах Active Directory (AD DS) в облаке или локальной среде, а затем получите маркеры доступа для защиты вызовов сервера Exchange Server. Для Exchange Online требуются маркеры, выданные службой Azure Active Directory, которая поддерживается библиотекой ADAL. Но можно воспользоваться любой сторонней библиотекой.
Дополнительные ресурсы, касающиеся использования стандарта проверки подлинности OAuth в приложении EWS:
пробная версия Office 365, позволяющая настроить сервер Exchange Server для тестирования клиентского приложения;
сведения о настройке Azure Active Directory, позволяющей приложению использовать маркеры OAuth для проверки подлинности;
Проверка подлинности NTLM
Таблица 2. Преимущества и недостатки использования протокола NTLM
| Преимущества | Недостатки |
|---|---|
| Проверка подлинности для сервера Exchange Server выполняется сразу: дополнительные манипуляции не нужны. Доступ к службам Exchange Server можно настроить с помощью командлета командной консоли Exchange. Доступны примеры кода, обеспечивающие использование учетных данных вошедшего в систему пользователя для проверки подлинности на локальном сервере Exchange Server. | Чтобы можно было использовать проверку подлинности на основе NTLM, пользователям нужно войти в домен. Могут возникнуть трудности с получением доступа к учетным записям электронной почты, которые не связаны с учетной записью домена пользователя. Для использования протокола NTLM у приложений служб должна быть учетная запись домена. |
Обычная проверка подлинности
Такая проверка обеспечивает базовый уровень защиты для клиентского приложения. Мы рекомендуем, чтобы все новые приложения использовали протоколы NTLM или OAuth для проверки подлинности. Но в некоторых случаях для вашего приложения подойдет именно обычная проверка подлинности.
Таблица 3. Преимущества и недостатки использования обычной проверки подлинности
| Преимущества | Недостатки |
|---|---|
| Проверка подлинности для сервера Exchange Server выполняется сразу: дополнительные манипуляции не нужны. Доступ к службам Exchange Server можно настроить с помощью командлета командной консоли Exchange. Приложения для Windows могут использовать учетные данные по умолчанию вошедшего в систему пользователя. С помощью многих доступных примеров кода можно понять, как обеспечить вызовы EWS с использованием обычной проверки подлинности. | Требуется, чтобы ваше приложение собирало и хранило учетные данные пользователей. Необходимо отключить проверку подлинности на основе NTLM для всех пользователей, если вы хотите использовать обычную проверку подлинности для всех пользователей. Если возникнет брешь системы безопасности приложения, злоумышленник может получить доступ к адресу и паролю электронной почты пользователя. |
Необходимо убедиться в том, что обычная проверка подлинности соответствует требованиям вашей организации и клиентов к обеспечению защиты. Такая проверка подойдет, если вы хотите избежать выполнения многочисленных задач по настройке (например, в простых тестовых или демонстрационных приложениях).
Для подключения EWS к Exchange Online больше не поддерживается обычная проверка подлинности. Используйте проверку подлинности OAuth во всех новых или существующих приложениях EWS для подключения к Exchange Online. Проверка подлинности OAuth для EWS доступна в Exchange Online только в составе Microsoft 365. Приложения EWS, использующие OAuth, необходимо сначала зарегистрировать в Azure Active Directory.
Общие сведения о разработке клиента EWS для Exchange
Советы по разработке с использованием EWS для Exchange.
В этой статье приведены общие сведения о создании приложения веб-служб Exchange (EWS). С помощью этих сведений можно определить, подходит ли API EWS для вашего приложения и какой тип реализации клиента вам нужен. Эта статья также содержит рекомендации по созданию приложений для Office 365, Exchange Online и версий Exchange, и версий Exchange, начиная с Exchange 2007, с использованием одной базы данных кода. Кроме того, она помогает решить, для какой среды лучше разрабатывать решения — для локальных серверов Exchange Server или Exchange Online.
Подходит ли API EWS для вашего приложения?
Прежде чем приступать к созданию приложения, необходимо определить, подходит ли вам API EWS. Если вы разрабатываете решение для Exchange Server или Exchange Online, EWS предпочтительной будет технология клиентского доступа. Разработка решений клиентского доступа для версий Exchange, начиная с Exchange 2007, в основном ориентировалась на EWS. EWS используется для работы новых функций клиентского доступа, реализованных в Outlook. К последним относится отображение состояния «нет на месте» и сведений о доступности, впервые доступное в Exchange 2007, а также функции подсказок и получения помещений, представленные в Exchange 2010. И для внутренних, и для внешних партнеров, разрабатывающих клиентские приложения Exchange, это говорит в пользу обязательности вложений в EWS.
API EWS — основной API клиентского доступа для клиентских приложений Exchange. Но в некоторых случаях для разработки клиентских приложений могут пригодиться другие API Exchange. Например, Exchange ActiveSync обладает следующими преимуществами перед EWS:
Для разработки клиентов Exchange ActiveSync нужна лицензия. Дополнительные сведения о различиях между Exchange ActiveSync и EWS см. в статье Choosing between Exchange ActiveSync and Exchange Web Services (EWS).
MAPI RPC/HTTP — это еще один вариант для программирования клиентских приложений Exchange. Но тем не менее MAPI RPC/HTTP не обладает интуитивно понятным интерфейсом для связи между клиентами и сервером.
Дополнительные сведения о технологиях разработки для Exchange см. в статье Explore the EWS Managed API, EWS, and web services in Exchange.
Способы разработки клиента EWS
Существует несколько способов разработки для Exchange с использованием EWS. Выбор оптимального варианта зависит от платформы разработки, инструментов, доступных реализаций и требований к приложениям для организации. Для создания клиентских приложений EWS доступны четыре основных варианта:
Управляемый API EWS
Вот несколько преимуществ управляемого API EWS:
Обратите внимание, что управляемый API EWS — не полное решение. В управляемом API EWS не реализованы некоторые функции. Несмотря на то что управляемый API EWS не обладает всеми функциями EWS, он может оказаться лучшим вариантом для разработки клиентских приложений по следующим причинам:
API веб-службы EWS может подойти вам больше, чем управляемый API EWS, по одной из следующих причин:
Для получения дополнительной информации см. статью Get started with EWS Managed API client applications.
Управляемое API EWS теперь доступно в качестве проекта с открытым кодом на GitHub. Вы можете использовать библиотеку открытого кода, чтобы:
Мы будем рады вашему вкладу в GitHub.
Java API веб-служб EWS
Java API EWS — это проект с открытым исходным кодом на сайте GitHub, который сообщество может обновлять и расширять. Стилистически он похож на EWS Managed API и использует сетевые запросы и ответы EWS SOAP. Хотя с помощью Java API EWS невозможно получить доступ ко всем операциям EWS SOAP, но мы надеемся, что после недавнего создания проекта с открытым кодом сообщество поможет преодолеть это препятствие. Обратите внимание, что при наличии соответствующего контракта о поддержке служба поддержки Майкрософт поможет разобраться со всеми вопросами, связанными с протоколом SOAP EWS, но не с самим Java API EWS. Java API EWS доступен для скачивания на сайте GitHub, где члены сообщества могут внести свой вклад в его развитие.
Автоматически созданные прокси EWS
Клиентские API могут быть созданы автоматически с использованием определений схем XML и WSDL EWS. Генераторы клиентских объектных моделей доступны для многих языков. Как правило, автоматически созданные объектные модели управляют сериализацией и десериализацией объектов. Такие модели не включают бизнес-логику. Кроме того, автоматическое создание часто приводит к появлению артефактов, усложняющих работу с объектной моделью. Поддержка Exchange распространяется на XML-код, который клиент отправляет и получает, но не на объектную модель.
Настраиваемый клиентский API EWS
Возможности клиента EWS
Какой бы вариант разработки вы ни выбрали, следует обдумать способ реализации возможностей EWS в клиенте. Доступность возможностей зависит от версии схемы EWS, для которой будете создавать приложение. Схемы EWS обратно и прямо совместимы. Если вы создаете приложение для более ранней версии схемы (например, Exchange Server 2007 с пакетом обновления 1), оно также будет работать с более поздними версиями схемы (например, с Exchange Online и службой Exchange Server 2013 с пакетом обновления 1).
Так как функции и их обновления зависят от схемы, рекомендуем использовать наиболее раннюю базу общего кода, которая относится к тем возможностям EWS, которые нужно реализовать в клиентском приложении. Многие приложения могут работать с версией Exchange2007_SP1, потому что схема Exchange 2007 с пакетом обновления 1 содержит почти все основные возможности Exchange для работы с элементами и папками в хранилище Exchange. Рекомендуем сохранять ветви кода для каждой версии схемы EWS. Ниже приведены версии схем, доступные в настоящее время.
Версии схем хранятся в простом типе ExchangeVersionType.
Сведения о возможностях, доступных в каждой из версий схем EWS, см. в статье EWS schema versions in Exchange.
Приложения EWS и архитектура Exchange
Узнайте, как работает служба EWS в архитектуре Exchange, и Узнайте, какие протоколы EWS использует.
Веб-службы Exchange (EWS) — это межплатформенный API, позволяющий приложениям получать доступ к элементам почтовых ящиков, собраниям и контактам из Exchange Online, Exchange Online в составе Office 365 или локальной версии Exchange, начиная с Exchange Server 2007. Приложения EWS могут получать доступ к элементам почтовых ящиков локально или удаленно, отправляя запрос в XML-сообщении на основе SOAP. Сообщение SOAP внедряется в HTTP-сообщение при отправке между приложением и сервером, что означает, что если ваше приложение может отправлять XML-данные через HTTP, для доступа к Exchange можно использовать EWS.
Обзор архитектуры Exchange
На следующих схемах показаны методы проверки подлинности и пути для обмена данными, используемые приложениями EWS при взаимодействии с Exchange 2013 и Exchange Online. С точки зрения приложения EWS пути связи идентичны, и методы проверки подлинности незначительно различаются. Основное отличие заключается в том, что вы используете внутренний сервер Exchange.
Рис. 1. Приложение EWS и локальная архитектура Exchange
На рисунке 2 показаны одни и те же пути связи, показанные на рисунке 1, которые используются приложениями EWS при взаимодействии с Exchange Online.
Рис. 2. Приложение EWS и архитектура Exchange Online
Ниже приведены компоненты, показанные на схемах.
XML-сообщение SOAP — XML-сообщение в конверте SOAP, внедренное в сообщение HTTP/S, которое соответствует файлу Services. WSDL на сервере клиентского доступа. Протокол HTTPS рекомендуется для локальной организации Exchange и необходим для Exchange Online.
Методы проверки подлинности — сообщения EWS включают основную проверку подлинности Windows (встроенную проверку подлинности Windows) или сведения проверки подлинности OAuth в составе полезных данных HTTP.
Подсистема балансировки нагрузки — подсистема балансировки нагрузки распространяет сообщение на сервер клиентского доступа в массиве серверов клиентского доступа. Этот компонент виден только в локальной архитектуре Exchange.
Массив серверов клиентского доступа — серверы клиентского доступа организованы в группу с балансировкой нагрузки, называемую массивом серверов клиентского доступа. Отдельные серверы клиентского доступа обеспечивают проверку подлинности, ограниченное перенаправление и прокси-службы. Сами серверы клиентского доступа не выполняют отрисовку данных, а данные не помещаются в очередь или не хранятся на сервере клиентского доступа — он является тонким и без состояний; Он просто проверяет подлинность запроса, выполняет поиск автообнаружения, а затем передает прокси-серверу запрос на сервер почтовых ящиков. Сервер клиентского доступа поддерживает связь 1:1 с сервером почтовых ящиков, на котором размещаются данные пользователя. Протокол HTTP (защищенный через SSL с помощью самозаверяющего сертификата) используется между сервером клиентского доступа и сервером почтовых ящиков. Этот компонент виден только в локальной архитектуре Exchange.
Служба автообнаружения — служба автообнаружения выполняет обнаружение службы при доступе к доменным службам Active Directory (AD DS), чтобы получить версию почтового ящика и расположение сервера почтовых ящиков, на котором размещается активная копия данных пользователя.
Служба EWS — служба EWS описана тремя файлами: Services. WSDL, messages. xsd и Types. xsd, а также сборками управляемого API EWS. Services. WSDL описывает контракт между клиентом и сервером, messages. xsd определяет сообщения запроса и ответа SOAP, а Types. xsd определяет элементы, используемые в сообщениях SOAP. Messages. xsd и Types. xsd всегда содержат последние версии схемы, хотя существуют более ранние версии схемы. Обратите внимание, что Services. WSDL, messages. xsd и Types. xsd становятся доступными на сервере клиентского доступа, но фактически не используются для проверки схемы, они предоставляются только для справки. Сборки управляемого API EWS предоставляются для серверных клиентских приложений EWS и развертываются во всех ролях Exchange Server, а не только на серверах клиентского доступа. Этот компонент виден только в локальной архитектуре Exchange.
Доступность функций основана на версии схемы EWS, для которой предназначено приложение. Так как схемы EWS поддерживают обратную и обратную совместимость, при создании приложения, предназначенного для более ранней версии схемы, например Exchange 2007 с пакетом обновления 1 (SP1), ваше приложение также будет работать с более поздней версией схемы, такой как служба Exchange 2010 с пакетом обновления 2 (SP2), а также Exchange Online. Так как функции и их обновления зависят от схемы, рекомендуем использовать наиболее раннюю базу общего кода, которая относится к тем возможностям EWS, которые нужно реализовать в клиентском приложении. Многие приложения могут работать с версией Exchange2007_SP1, потому что схема Exchange 2007 с пакетом обновления 1 содержит почти все основные возможности Exchange для работы с элементами и папками в хранилище Exchange. Для получения дополнительных сведений обратитесь к компонентам клиента EWS.
Группа обеспечения доступности баз данных — серверы почтовых ящиков организованы в группу обеспечения доступности баз данных с высокой доступностью, которая может быть развернута в одном или нескольких центрах обработки данных. Сервер почтовых ящиков содержит базу данных почтовых ящиков и обрабатывает все действия для активных почтовых ящиков на этом сервере. Все компоненты, которые обрабатывают, отображают и хранят данные, находятся на сервере почтовых ящиков. Клиенты не подключаются непосредственно к серверу почтовых ящиков; все подключения обрабатываются сервером клиентского доступа. Этот компонент виден только в локальной архитектуре Exchange.
Exchange Online и Exchange Online в составе Office 365 — решение для обмена сообщениями, которое предоставляет функции Exchange в виде облачной службы.
Когда приложение EWS запрашивает сведения из хранилища Exchange, создается и отправляется на сервер Exchange сообщение XML-запроса, которое соответствует стандарту SOAP. Когда сервер Exchange получает запрос, он проверяет учетные данные, предоставляемые клиентом, и автоматически анализирует XML для запрошенных данных. Затем сервер создает ответ SOAP, содержащий XML-данные, которые представляют запрошенные строго типизированные объекты и их свойства. XML-данные отправляются обратно в приложение в ответе HTTP. Затем приложение десериализует XML и использует данные для выполнения более новые строго типизированные объекты.
Протоколы и стандарты, которые должны поддерживаться приложениями EWS
Для обмена данными с сервером Exchange приложения EWS должны поддерживать указанные ниже протоколы и стандарты.
Таблица 1. QP
| Protocol (Протокол) | Использование |
|---|---|
| HTTP/S | Позволяет приложениям EWS получать доступ к данным базы данных Exchange по сети независимо от того, находится ли клиент в Интернете или интрасети. |
| SOAP 1,0 | Формирует оболочку вокруг полезных данных обмена сообщениями. В веб-службах EWS протокол SOAP реализован с помощью различных частей конверта SOAP для поддержки различных функциональных возможностей. Заголовок SOAP используется для олицетворения и предоставления данных управления версиями. Основной текст SOAP предоставляет сведения о выполняемой операции и данных, которые передаются в операцию. SOAP использует WSDL для описания операций, которые необходимо вызвать. |
| WSDL 1,0 | Описывает привязки, операции и свойства, используемые для вызова операций EWS, в файле Services. WSDL. Этот файл вместе с файлами схемы, на которые имеются ссылки, включает контракт между приложением EWS и сервером Exchange Server и часто используется вместе с инструментами, зависящими от поставщика, для создания приложений для определенных платформ. Файл WSDL находится в виртуальном каталоге EWS, который находится в корневом каталоге веб-сайта. |
| Протокол TLS (Transport Layer Security)/ССЛ | Обеспечивает безопасную веб-связь в Интернете или интрасети. Протокол TLS позволяет приложениям проверять подлинность серверов или, при необходимости, серверы для проверки подлинности приложений EWS. Он также предоставляет канал безопасности, шифруя связь. Протокол TLS является более последней версией протокола SSL. |
| XML/XSD | Предоставляет универсальный формат сообщений для обмена данными между сервером Exchange Server и клиентом. XML обеспечивает сложные данные базы данных Exchange для клиентских приложений, но в определенной структуре. Красота XML заключается в том, что он обеспечивает обмен данными даже в том случае, если приложение EWS и сервер не используют общую платформу. |
Кроме того, приложения EWS должны поддерживать следующие стандарты проверки подлинности:
Обычная проверка подлинности по протоколу SSL для приложений, предназначенных для локального сервера Exchange Online или Exchange.
Проверка подлинности NTLM через SSL для приложений, поддерживающих локальную систему Exchange.
Аутентификация маркеров OAuth 2,0 для доверенных партнерских приложений и взаимодействия с Lync Server 2013 и SharePoint Server 2013.