Office 365 и RMS: настройка. Часть 1.

В этом посте, разделённом для удобства чтения на две части, мы рассмотрим настройку взаимодействия RMS on-premise и Office 365. Сосредоточимся только на текущей версии Office 365 на момент написания статьи, т.е. Wave 14 (Exchange 2010). Будем полагать, что теорию о том, что такое RMS и с чем его едят, мы знаем. Кто хочет освежить знания в памяти – отправим на хороший ресурс по этой теме.

Итак, засучим рукава. Настроим RMS on-premise и прикрутим к нему Exchange Online.

Настройка RMS on-premise

Предварительная подготовка

Что потребуется подготовить перед инсталляцией:

• создать RMS Service account (обычно это простая Domain-User-учётка (в домене установки RMS) с админными правами на сервер с RMS; установка RMS не должна проводиться под этой учётной записью);
• RMS работает только для пользователей с заполненным атрибутом email address, соответственно нужно убедиться что этот атрибут у всех заполнен;
• не рекомендуется устанавливать RMS на контроллере – думаю это даже обсуждать не требуется;
• проверить, что сервер RMS достижим по FQDN (т.е. прописан в DNS);
• убедиться, что сервер RMS (вернее, URL к нему) включён в Trusted Sites браузера IE для всех пользователей-клиентов RMS;
• понимать, что не все версии Office позволяют создавать RMS-документы: см. тут

ВАЖНО: если на сервере установки уже проинсталлирован и настроен IIS и SSL, потребуется до начала установки RMS удалить соответствующую привязку ssl (она восстановится после инсталляции с этим же сертификатом, если мы его выберем далее в диалоге установки RMS). Если этого не сделать, установка завершится с ошибкой!

Инсталляция on-prem RMS

RMS на сервере в поддомене лучше всего инсталлировать под правами Enterprise Admin-a, чтобы сразу активировать SCP (клиенты находят RMS-сервер внутри локальной сети именно по этой SCP). RMS устанавливается как роль.

В моём примере в качестве базы данных для RMS используется Windows Internal Database, но в продуктиве скорее всего администратор выберет существующий уже у него SQL-сервер.

Указывая внутренний URL для RMS-сервера (кластера), следует убедиться что он достижим и что есть соответствующий сертификат PKI (шаблон web server).

Если инсталляция проходит под правами Enterprise Admin, оставить Register (чтобы сразу активировался SCP).

Перед использованием RMS после установки нужно будет сделать logoff/logon, учётная запись под которой проходила установка будет включена в группу AD RMS Enterprise Administrators (она будет локальная на сервере если RMS ставился на выделенный сервер, и доменная если на контроллер).

Проверка работы on-prem RMS

После установки проверьте:

1) стартована ли служба;

2) что пишут в Event Logs;

3) открыть консоль AD RMS, убедиться что SCP активирован (проверить это через dssite.msc:  Services – RightManagementServices – SCP – Properties - Attribute Editor tab - Distinguished Name - View - On String Attribute Editor view, verify the following value: CN=SCP, CN=RightsManagementServices,CN=Services, CN=Configuration, DC=xxxxx,DC=com);

4) Ещё без всяких дополнительных запросов пароля по указанному во время установки URL должен открываться сайт (и он д.б. в Trusted):

5) не должно быть никаких открытий окошек с предупреждениями о несовпадении имён в сертификатах.

Настройка сервиса on-prem RMS

Выполняется через AD RMS Console. Сперва настраиваем точку распространения RMS-шаблонов.

Предоставляем в общее пользование папку на сервере RMS с правами Everyone=Read, RMS Service Account=Read,Change, и добавив в права NTFS: RMS Service Account=Modify (убедиться что Domain Users могут List, Read & Execute). RMS Service Account в данном случае – учётная запись, под которой работает сервис RMS.

Далее в консоли RMS: right-click «Rights Policy Templates» и задаём эту папку:

Далее нужно настроить возможность доступа к RMS-серверу внешних пользователей ( Extranet access) . В консоли AD RMS, развернуть Active Directory Rights Management Services, right-click по имени кластера RMS, затем Properties. Кликнуть по вкладке Cluster URLs, настроить Extranet URLs.

Эта информация прошивается в выдаваемые сертификаты, так что эту настройку необходимо сделать в первую очередь.

В текущем примере видно, что сервер RMS внутри ЛВС имеет совершенно другое имя FQDN, нежели чем используемое в Extranet URL. Тем не менее это не мешает работе. Хотя конечно, красиво было бы, если бы внутренний и внешний URL-ы совпадали. Но это не всегда возможно в действительности.

Кстати, Extranet URLs можно определить не по https, а по http, таким образом вообще уйдя от необходимости возиться с сертификатами.

Публикация сервисов RMS через TMG описана тут. Публикуются RMS Certification URL и RMS Licensing URL, которые мы настраивали шагом раньше. В слушателе TMG лучше всего использовать  публичный сертификат (в моём примере это сертификат для узла fs.apestr.com) и проверкой подлинности на основе HTML-форм. В правиле публикации делегирование проверки подлинности настроить на “Без делегирования, но клиент может выполнить проверку подлинности”.

Клиентский доступ извне: настройка и проверка.   Для беспроблемного клиентского доступа извне на компьютере внутренние и внешние имена узлов должны быть занесены в Trusted sites в браузере.

 

Ещё в статье говорится, что можно вшить в реестр URLы для доступа к точкам активации сертификата и запроса лицензии. Это подойдёт если ПК всегда работает извне, или если внутреннее и внешнее FQDN-имена для сервера RMS совпадают.

Как происходит работа с RMS с не доменного компьютера, находящегося извне корпоративной сети?

При доступе к RMS-защищённому документу: система из сертификата RMS определит, на какой URL обращаться, возникнет окно с запросом имени и пароля, пользователь авторизуется и получает доступ к документу.

При попытке задать RMS-разрешения на документ возможны два варианта развития событий в зависимости от двух начальных условий:

• либо RMS-пользователь уже открывал какой-либо RMS-документ (т.е. вводил имя и пароль);
• либо ПК девственно чист, пользователь никакие RMS-документы на нём ещё не открывал.

Вариант 1. Пользователь уже открывал RMS-документ. Система предложит выбрать этого пользователя и защитить документ от его имени.

Вариант 2. «Чистый» ПК. В этом случае система только предложит использовать учётные данные Windows Live ID, и больше вообще никак.

Это потому что она не знает, на какой сервер обращаться.  Чтобы этого не было, задаются ключи в реестр (см. в статье) и соответствующие узлы заносятся в Trusted sites.

Соответствующие ключи реестра для 64-разрядных клиентских ОС находятся тут: HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\MSDRM\ServiceLocation

Тогда при нажатии кнопки «Protect document» появится возможность выбора пользователя Microsoft Windows Account:

Если есть URL в реестре, можно сразу несколько аккаунтов «активировать» и работать с ними, просто выбирая (Manage credentials – Add – Use a Microsoft Windows account):

Продолжение читайте по этой ссылке.