top of page

С CAS 2013 можно ознакомится здесь.

CAS

Все клиентские обращения идут к CAS. Собственно поэтому и название Client Access. POP, IMAP, ActiveSync, Outlook Anywhere это всё связано с CAS. Кроме SMTP, который втыкается либо в роль Hub, либо Edge.

Раньше, в 2007, MAPI работал через Mailbox. В 2010 это было прекращено. Поэтому можно сказать:

если у вас сервер только с ролью Mailbox, он будет только хранить почту. Он не сможет передать почту из ящика А в ящик Б, даже если они лежат рядом. Для этого нужен Hub. Ни к одному из ящиков доступ вы не получите. Для этого нужен CAS.

Рассмотрим возможности подключения и службы, которые в обязательном порядке выполняет CAS-сервер.

Итак, ситуация следующая.

   Все MAPI-клиенты подключаются непосредственно к CAS.  Это новое архитектурное решение в 2010, т.к. в 2007 клиенты коннектились к Mailbox. Итак, задача CAS - обратиться к КД, выполнить аутентификацию клиента и вытащить информацию из AD о том, на каком Mailbox-сервере находится клиент. 

   CAS может обращаться только к Mailbox-серверам, находящимся с ним в одном сайте, т.к. CAS коннектиться к Mailbox по протоколу MAPI. CAS не выносится в демилитаризованную зону: во-первых он является членом домена, что требует открытия группы портов в обязательном порядке, во-вторых используется MAPI-подключение. Т.е. получается что файерволл между внутренней и DMZ сетью у вас открыт. Смысла от этого никакого.

Рассмотрим работу CAS.

   По MAPI подключаются внутренние клиенты, т.е. полнофункциональный Outlook.

   Если мы говорим о внешних полнофункциональных клиентах, здесь используется Outlook AnyWhere. Здесь те же MAPI пакеты, только они инкапсулируются в HTTP и передаются по 443 порту.

   Web App - это бывший Web Access, сейчас owa. Здесь тот же 443 порт и HTTPS.

   Exchange ActiveSync. Тот же HTTPS, только с мобильного устройства.

   Также поддерживаются POP3 и IMAP.

   Entourage 2008 - это для клиентов Mac ОС.  

   RPC CAS - это проксирование RPC.

   Autodiscover - автоматическое обнаружение. Веб-сервер IIS хранит директорию Autodiscover, в которой лежит файл xml, который запрашивает клиент для автоматического конфигурирования.

   Availability - информация о доступности. Например, когда мы создаем ресурсный почтовый ящик (к примеру ящик комнаты), у него есть информация о доступности (например занята комната или нет).

Address Book - для скачивания офлайн адресной книги.

Exchange Web Services - возможность подключаться к Exchabge через веб-сервисы.

MailTips - подсказки, которые выдаются клиенту в процессе работы. Рассмотрим в дальнейшем.

Exchange Control Panel - это фактически часть веб-доступа к Exchange серверу, но через отдельную админку (виртуальную директорию). 

1. Коннект через HTTPS, IMAP,POP. Это Outlook Anywhere, ActiveSync и прочее.На рисунке отображено, типа пользователи прокрадываются через файервол.

2. Коннект через Outlook с компьютера. Локальные пользователи используют MAPI.

3. КД связывается по LDAP.

4. Mailbox связывается с CAS через MAPI. 

Рассмотрим работу CAS с несколькими сайтами.

Есть две разных задачи по перенаправлению запросов - Proxying (проксирование) и Redirection (редирект).

Итак, у вас много сайтов. У каждого свой CAS, каждый из которых имеет свой FQDN.Смотрим на левую часть рисунка. У нас есть 2 CAS-сервера в разных сайтах, связанных друг с другом и каждый из которых смотрит в интернет. Предположим клиент набирает через IE какой-то адрес CAS-сервера (т.е. URL). CAS идёт на КД и видит, что п/я клиента находится в другом сайте. В таком случае CAS (к примеру возьмем нижний левый)  опять идёт на КД и берет оттуда External URL CAS-сервера, который является родным для клиента и возвращает этот URL клиенту. Клиент

автоматически редиректиться на другой, свой родной, CAS. Для клиента это выглядит следующим образом: он набирает в адресной строке какой-то URL, нажимает Enter, и тут же у него в адресной строке URL меняется и он уже подключен к другому CAS. Но это при условии, что родной CAS доступен из интернета, у него в свойствах owa прописан External URL (скриншот ниже) и этот адрес в DNS нормально разрешается в IP-адрес.

  Смотрим правую часть рисунка и рассматриваем ситуацию, когда есть 2 CAS, но только один смотрит в интернет, т.е. есть только одна точка входа. External URL прописываем только на том CAS, который доступен снаружи. Итак, клиент подключается не к тому CAS, который нужен. CAS лезет в AD, но не находит External URL, т.е. возвращать клиенту нечего. Тогда CAS начинает проксировать. Т.е. цепочка получается следующая: клиент - неродной CAS - родной CAS - Mailbox. 

   В случае проксирования между CAS-серверами будет использоваться тот же протокол, по которому подключился клиент. Далее, между CAS и Mailbox будет уже MAPI.

   Итого ситуация следующая: проксируется абсолютно всё, редиректиться только Outlook Web App. 

 

Требования к CAS-серверу.

При наличии нескольких CAS  на одной площадке встает вопрос: как они будут работать вместе.

По ссылке можно ознакомиться с настройкой NLB  

https://www.youtube.com/watch?v=aOOMBajgyAk&index=2&list=PLI8lqhYmSpWc7M0Yd-FeLELVLVUOeM_j2 (Начиная с 6:06:00)

   В рекомендации есть ограничение на 12 ядер процессора как максимум.  Подразумевается, что если у вас CAS не справляется по процессору при 12 ядрах, то вам необходим дополнительный CAS-сервер.

   По памяти вам потребуется минимум 2 Gb на одно ядро. Т.е. при 12 ядрах это будет 24 Gb.

   Интенсивность использования диска. CAS'у в принципе дисковая система особо не нужна. Данные, как Mailbox, он не хранит. Очереди, как у HUB Transport  у него тоже нет.

Autodiscover.

Эта технология появилась ещё в 2007. Логика простая:

У нас есть xml-файл, который находится в виртуальной директории IIS. Когда клиент открывает Outlook, у него запрашивается электронный адрес. Он вводит свой адрес, после чего Outlook определяет, является ли клиент внутренним (по членству в домене). Если он внутренний, то клиент обращается к виртуальной директории Autodiscover, для него генерируется xml-файл с настройками, который клиент скачивает и интерпритирует. В итоге Outlook настраивается автоматом. Т.е. за счёт технологии Autodiscover мы внутренних клиентов не настраиваем вообще.  

   Если клиент является внешним, то виртуальную директорию Autodiscover он может найти двумя способами:

1) В логике Outlook'а зашито обращение по двум ссылкам:

а) autodiscover.tvoydomain.ru/autodiscover Для того, чтобы это отработало, вам нужно чтобы хост autodiscover.tvoydomain.ru разрешался в адрес вашего CAS-сервера и, следовательно, был доступен снаружи по 443 порту;

б) Если вариант а) не прокатывает, тогда Outlook пытается обратиться по адресу tvoydomain.ru/autodiscover Т.е. если у вас имя домена разрешается в IP вашего CAS-сервера, то всё будет гуд.  

2) Это использование записи SRV для обнаружения службы Autodiscover. Т.е. можно создать SRV-запись autodiscover, которая будет доступна по https по 443 порту. Если вы добавите такую запись во внешнюю зону, Outlook'у этого будет достаточно, чтобы найти ваш почтовый домен.

   Autodiscover используется клиентами MAPI, Outlook Anyware и Active Sync.

   Помните, что шифрование настраивается на каждой виртуальной директории. Т.е., к примеру, если вам не нужно, чтобы клиенты

использовали шифрование при подключении через owa или вы хотите поменять настройки этого шифрования, то в IIS, в настройках каждой виртуальной директории это можно изменить.

На заметку. Как работает SSL.

Есть сертификат на сервере. У сервера есть закрытый ключ  и открытый, которым он со всеми может поделиться. Клиент подключается к серверу. Клиент на своей стороне генерирует симметричный ключ (т.е. тот, которым и шифруется и дешифруется). Симметричный используется потому, что с ним просто быстрее работать. Итак, клиент сгенерировал ключ. Потом он берёт открытый ключ с сервера и шифрует симметричный ключ открытым и передает серверу. Т.е. гарантировано, что этот пакет может открыть только владелец закрытого ключа.

Настройка CAS.

В EMC  переходим в Server Configuration - Client Access. Если у вас несколько CAS серверов, выберите необходимый и переходите на вкладки ниже.

Рассмотрим первую вкладку Outlook Web App и свойства owa.

Если в свойствах не указан внешний URL, значит вы не указывали внешнее имя сервера при установке. 

   По умолчанию, вариантом аутентификации в Exchange является Basic с использованием настройки forms-based. При Basic Authentication самоподписанный сертификат и SSL генерируются по умолчанию и включается шифрование, т.к. при Basic все передается открытым текстом, а это плохо.

   Надстройка forms-based не является обязательной. Можно просто использовать голый Basic и подключаться SSL'лем. Но наличие forms-based аутентификации даст возможность (например в том же Web Access) использовать варианты подключения изнутри и снаружи, использовать выброс клиента по таймауту и прочее.

   Вариант аутентификации Integrated вполне хорош и безопасен, ничего открытым текстом не передается. Но Basic всё же универсален.

На вкладке Segmentation можно включить или выключить фичи owa. 

На вкладках Private Computer File Access и Public Computer File Access конфигурируются одни и те же параметры (Private для внутренних подключений, Public для внешних), а именно, какие расширения файлов разрешено просматривать или открывать из почты. 

На заметку. Мы рассматриваем настройку политик CAS через конкретную owa. Эти настройки будут выполняться в виртуальной директории.

Произвести настройку политик CAS можно также на уровне всей организации Exchange, перейдя в Organization Configuration - Client Access. 

Обратите внимание на возможность Reset Virtual Directory.

Если вы настраивали owa и что-то пошло не так (вы всё сломали), то с помощью Reset Virtual Directory вы можете перезаписать виртуальную директорию и перезапустить IIS. Штука полезная, т.к. раньше вам бы пришлось переустанавливать CAS заново.

Двигаемся дальше и переходим на вкладку Exchange Control Panel. Заходим в свойства ecp (что такое ecp читайте здесь http://itband.ru/2010/05/ecp/). На вкладке Authentication будет использоваться та же настройка, что и в owa.

Переходим на вкладку Exchange ActiveSync. Заходим в свойства. Посмотрите на внутренний и внешний URL. Помните, когда вы публикуете Exchange 2010 в TMG 2010, ActiveSync по умолчанию не публикуется.  Вам надо делать несколько раздельных  публикаций. Т.е. отдельно owa, отдельно ActiveSync. Если owa работает, это не значит что и  ActiveSync должен работать. У него свой каталог, отдельный.

На вкладке Authentication можно выбрать только Basic authentication и что делать с сертификатами. Можно выбрать "Требовать 

сертификаты", если устройства поддерживают клиентские сертификаты со своей стороны. Тогда вам нужно будет выдать каждому клиенту сертификат, которому доверяет ваш CAS. Если человек уволился, вы отзываете сертификат и клиент отваливается.

На вкладке Remote File Servers можно указать  серверы. Например, в Block листе можно указать сервера, с которых через веб-морду не получится открывать файлы в клиенте. Т.е. вы можете сказать, что когда в письме пришла ссылка на какой-то объект, надо ее заблокировать. Или наоборот. В Allow листе можно добавить разрешенные сервера.

На вкладке POP3 и IMAP4 в свойствах каждого протокола на вкладке Authentication нужно указать Secure logon и прописать полное  имя вашего сервера (например, mail.tvoydomain.ru).

Вообще CAS это своеобразная надстройка над IIS. Поэтому посмотрите, что есть в IIS. Найдёте много интересного. 

 

Рассмотрим, к примеру, настройки SSL.

В IIS перейдите в Default Web Site в Bindings. Здесь, на каждый способ доступа по https может выбираться свой сертификат. И он обязательно должен быть, иначе работать вообще ничего не будет.

   Выше мы описали глобальную настройку. Но можно задать её на каждом отдельном уровне. Т.е. в центральном окне Default Web Site выберите SSL Settings и снимите галку Require SSL. А затем зайдите в директорию owa и там уже включите SSL.

   Зачем это нужно? Например, когда вы Exchange совмещаете с чем то другим. Необязательно что у вас на Default Web Site есть только Exchange. Может быть есть что-то другое и SSL этому не нужен. Тогда на корне требование SLL мы выключаем и даем точечно. Также это полезная штука при редиректе Exchange, который мы рассматривали выше. При включенном в корне SLL у вас после редиректа будет снова запрос аутентификации, т.к. будет новая SSL-сессия. Без SSL всё пройдёт прозрачно для пользователя и повторно вводить учетные данные не потребуется.

Переходите к следующей странице: Hub Transport Server.

bottom of page