Управление доступом на основе ролей(RBAC) в Lync 2013\S4B

Это статья о RBAC в Lync 2013\S4B. Статья применима как к Lync 2013 так и для S4B. Здесь собрана самая необходимая информация о RBAC Lync с моей точки зрения, она собрана из двух источников: technet и собственный опыт. Естественно рекомендуется сначала прочитать официальную документацию. Цель статьи – помочь администраторам\архитекторам Lync средних и крупных компаний понять тему(включая неосвещенные в документации вопросы), чтобы в итоге создать свою модель администрирования Lync\S4B.

 

Общая информация о RBAC в Lync\S4B

Lync\S4B имеют группы управления доступом на основе ролей (RBAC), которые помогают делегировать административные задачи. Эти группы создаются в процессе подготовки леса, не путайте их с другими группами которые также создаются во время подготовки леса (административные группы, группы инфраструктуры, группы служб). Используя эти группы RBAC, можно предоставить административные привилегии нужной учетной записи. При этом можно создавать свои уникальные роли которые можно ограничить рамками сайта lync(ограничение области действия на уровне серверов), OU (ограничение области действия на уровне пользователей), а также разрешенными для выполнения командлетами.

 

Предопределенные роли RBAC

Всего существует 11 предопределённых ролей RBAC:

CSAdministrator, CSVoiceAdministrator, CSUserAdministrator, CSResponseGroupAdministrator,  CSLocationAdministrator, CSArchivingAdministrator, CSViewOnlyAdministrator,  CSServerAdministrator,  CSHelpDesk, CSResponseGroupManager, CsPersistentChatAdministrator.

Увидеть их можно в AD в предопределенном контейнере Users:

Они охватывают определенный набор административных задач реализуемое через предоставление разрешений на использование определенного списка командлет. Посмотреть список командлет разрешенных для конкретной роли CSUserAdministrator можно посмотреть например так в удобном виде через Lync PS:

Get-CsAdminRole -Identity “CSUserAdministrator” | select -ExpandProperty cmdlets| select Name | sort Name

Не все командлеты доступны для предопределенных групп RBAC Lync, например Enable-CsADDomain (для запуска вы должны быть админом домена).

Также можно посмотреть остальную информацию о роли через GetCsAdminRole.

Все предопределенные роли действуют глобально(ConfigScopes и UserScopes : {Global}) поэтому чтобы реализовать необходимую административную модель в соответствии с областью действия (сайт Lync, OU) необходимо создавать новые административные роли и определять им область действия.

 

Создание новой административной роли (Custom RBAC)

Чтобы создать новую кастомную роль необходимо создать универсальную группу безопасности (Universal Security AD group), после этого можно создать кастомную роль RBAC на основе предопределенной группы, при этом можно добавить или убрать конкретные командлеты. Добавив учетную запись администратора в эту группу безопасности, мы делегируем ему соответствующие административные права.

На примерах посмотрим, как можно создать новую роль и изменить разрешенные командлеты:

  • Создание кастомной роли RegUsersAdmin. Эта роль обладает возможностями предопределенной роли CsUserAdministrator, но только для пользователей, расположенных в соответствующей OU. Этот командлет cработает только в том случае, если соответствующая OU и универсальная группа безопасности с именем RegUsersAdmin уже существуют.

New-CsAdminRole -Identity ”RegUsersAdmin” -Template CSUserAdministrator -UserScopes ”OU:OU=RegionUsers,OU=Samara,DC=domain,DC=ru”

  • Создание кастомной роли RegServersAdmin. Эта роль обладает возможностями предопределенной роли CsServerAdministrator, но только для серверов, расположенных в сайте “Site:SiteID”(список сайтов, а так же их идентификаторы можно получить через командлет Get-CsSite, в нашем случае SiteID = 1). Этот командлет работает только в том случае, если Site:SiteID уже создан и универсальная группа безопасности с именем RegServersAdmin уже существует.

New-CsAdminRole -Identity ”RegServersAdmin” -Template CSServerAdministrator -ConfigScopes ”site:1”

  • Создание кастомной роли RegAdmin. Эта роль обладает возможностями предопределенной роли CsAdministrator, но только для серверов, расположенных в сайте “Site:SiteID”(site:1) и пользователей в соответствующей OU. Соответственно сайт и OU уже должны существовать, а также универсальная группа безопасности RegAdmin.

New-CsAdminRole -Identity ”RegAdmin” -Template CSAdministrator -ConfigScopes ”site:1” -UserScopes ”OU:OU=RegionUsers,OU=Samara,DC=domain,DC=ru”

  • Убрать разрешения на использование определенных командлет у новой роли

Set-CsAdminRole -Identity “RegAdmin” -Cmdlets @{Remove=”get-CsSite”,”get-CsUser”}

  • Добавить разрешения на использование определенных командлет у новой роли

Set-CsAdminRole -Identity “RegAdmin” -Cmdlets @{Add=”get-CsSite”,”get-CsUser”}

  • Удалить роль

Remove-CsAdminRole -Identity RegionAdmin -Verbose

 

Далее добавим учетную запись администратора филиала\дочки\региона и т.п в необходимые группы безопасности(созданные для ролей RBAC), тем самым делегировав им соответствующие права.

Посмотреть какие роли RBAC сейчас присвоены УЗ можно либо в Control Panel Lync на странице приветствия (войти из-под этой УЗ) либо так:

Get-CsAdminRoleAssignment ”domain\user”

 

Параметры роли RBAC

Разберем свойства у кастомной роли созданной на основе CS Administrator действующей на определенный сайт и OU

PS C:> Get-CsAdminRole -Identity RegAdmin

 

Identity       : RegAdmin

SID           : S-1-5-21-2825852277-2804793686-1768688180-1134

IsStandardRole : False

Cmdlets       : {Name=Debug-CsInterPoolReplication,…}

ScriptModules : {}

ConfigScopes   : {Site:1}

UserScopes     : {OU:OU=RegionUsers,OU=UCLAB,DC=uclab,DC=ru}

Template       : CSAdministrator

  • Identity – имя роли
  • SID идентификатор безопасности группы AD
  • IsStandardRole признак предопределенной группы, чтобы увидеть все кастомные роли выполнить Get-CsAdminRole | ? {$_.IsStandardRole -eq $False}
  • Cmdlets перечень командлет разрешенных для этой роли
  • ScriptModules перечень сценариев и модулей которые может выполнять данная роль. Они должны храниться в следующих каталогах(для Lync2013):

Путь к модулю Lync (по умолчанию: C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync)

Путь к модулю S4B (C:\Program Files\Common Files\Microsoft Skype for Business Server 2015\Modules\Skype for Business\)

Путь к пользовательскому сценарию (по умолчанию: C:\Program Files\Common Files\Microsoft Lync Server 2013\AdminScripts)

Пример: New-CsAdminRole -Identity «RegUsersAdmin» -Templated CsUserAdministrator -ScriptModules @{Add-«MyScript.Ps1} -Verbose

  • ConfigScopes это сайт Lync (или сайты), к которому относится роль RBAC. По умолчанию установлено значение Global, что подразумевает все сайты. Если сайты были добавлены, то в параметре будет значение (например, Site: 1). УЗ ограниченные сайтом не смогут создавать глобальные уникальные объекты, например политики, правила нормализации, параметры безопасности можно создавать\изменять только на уровне сайта Lync. При этом если не изменяется UserScopes то управление пользователями разрешенными командлетами осуществляется на глобальном уровне.
  • UserScopes это область ограничения администрирования пользователей на уровне OU. Указывается в виде distinguished name OU. При этом если не изменяется ConfigScopes то управление конфигурацией разрешенными командлетами осуществляется на глобальном уровне.
  • Template предопределённая роль RBAC Lync использованная как шаблон во время создания кастомной роли.

Администрирование с помощью кастомных ролей RBAC

Для целей администрирования используются средства, устанавливаемые по умолчанию на каждый сервер Lync FE либо отдельно на компьютер администратора. При выполнении командлета через Lync PS всегда выполняется подключение к CMS (топология, конфигурация и политики), чтобы проверить ограничения RBAC. Также при запуске Lync Control Panel тоже выполняется подключение к CMS. Группа безопасности, которая создается для новой роли не имеет доступа к базе данных CMS.Поэтому при использовании Lync PS или Lync Control Panel (из Lync administrative tools) вы не сможете выполнять администрирование через новую роль, будет ошибка:

Есть два варианта выхода из ситуации:

  • Первый вариант:

Использовать Lync Remote PowerShell

Например, подключаться со своей рабочей станции:

$credential = Get-Credential uclab\regionadmin

$SessionOptions = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck

$session = New-PSSession -ConnectionUri ”https://lyncpoolfe01.uclab.ru/OcsPowershell” -Credential $credential -SessionOption $sessionoptions

Import-PSSession -Session $session –AllowClobber

При этом импортируются все командлеты которые вы можете использовать в соответствии с вашей ролью.

Также можно использовать Lync Control Panel подключаясь удаленно через браузер.

  • Второй вариант:

Дать права на доступ к CMS, сделав например членом административной группы RTCUniversalReadOnlyAdmins (группа создается во время подготовки леса и позволяет членам считывать параметры серверов, пулов и пользователей). При этом появляются права доступа к CMS и собственно проблема разрешается.

 

Чем можно облегчить жизнь при работе с RBAC

  • Скрипт просмотра ролей RBAC и кому они назначены. Очень полезен при сложной административной модели и большом количестве филиалов компании.
  • Инструмент для визуальной работы по созданию ролей(сторонняя разработка).
  • Файл Excel в котором можно посмотреть и сравнить командлеты назначенные всем предопределенным ролям RBAC
Реклама
Рубрики:Lync, SfB

Central Management Store Lync 2013\S4B

Central Management Store Lync 2013\S4B

Это статья о CMS – что это и с чем едят.

Информация будет полезна IT архитекторам для планирования архитектуры Lync\S4B в части CMS или поиске проблем репликации. Также при проектировании часто возникают какие-либо требования, сетевые или архитектурные ограничения (да — да привет СБ! :)) или необходимо описать взаимодействие компонентов CMS. Собственно об этом и поговорим.

 

Что такое CMS (Central Management Store) и ее основные нюансы

CMS — это хранилище (база данных sql: xds, экземпляр sql: rtc) для хранения топологии, конфигурации и политик в виде документов в формате XML.

  • Топология – это информация о топологии Lync\S4B создаваемая\изменяемая через Topology Builder
  • Конфигурация – все настройки Lync/S4B серверов (изменяемая через Lync Server Management Shell (PS) and Lync Server Control Panel (LSCP)).
  • Политики – всевозможные политики (например, client policies, dial plan)

Основные моменты опишем несколькими пунктами:

  1. Устанавливается на первом сервере в случае использования Standard редакции, а при использовании Enterprise редакции на первом SQL Back End Server (RTC)
  2. Изменять CMS можно с помощью инструментов: Topology Builder, Lync Server Management Shell (PS), Lync Server Control Panel (LSCP), при этом информация для подключения берется из AD (Service Connection Point).
  3. CMS включает в себя основные функции проверки достоверности любой записываемой в нее информации до того, как она будет зафиксирована в базе данных. CMS реализует и проверяет многие правила для зависимостей и взаимозависимостей между компонентами и ролями сервера. Логика валидации также доступна и используется инструментами, упомянутыми выше.
  4. Каждый последующий Lync сервер получает доступную только на чтение копию базы CMS. Любые изменения конфигурации выполняются только на мастере с копированием изменений в реплики на остальных серверах.
  5. Изменения реплицируются между серверами с использованием протокола SMB по порту 445. (в случае репликации изменений на пограничный сервер Edge используется HTTPS и порт 4443)
  6. Любой Lync сервер читает информацию только с локальной реплики cms (экземпляр sql: rtclocal). В самой простой топологии с одним сервером (cms на Standard Edition) вы должны получить на Lync сервере два экземпляра SQL c именами \rtc и \rtclocal. Экземпляр \rtclocal содержит реплики баз.
  7. Данные хранятся в виде xml документов, и могут относится к четырем уровням областей: global, site, service, tag. Для каждой области используется только один xml документ. Например global dial plan и dial plan для сайта будут два различных xml документа хранящихся в базе данных xds(таблица document).
  8. Active Directory (AD DS) по-прежнему используются для хранения основной пользовательской информации, такой как SIP URI пользователя и его номер телефона.

CMS и службы

  • Lync Server Master Replicator Agent (MASTER)
  • Lync Server File Transfer Agent (FTA)
  • Lync Server Replica Replicator Agent (REPLICA).

Все три службы запущены на мастере CMS(FE), на остальных серверах с репликами cms запущена служба Lync Server Replica Replicator Agent (REPLICA).

Структура CMS в файловом хранилище

Как уже было сказано выше изменения реплицируются между серверами с использованием протокола SMB по порту 445. (в случае репликации изменений на пограничный сервер Edge используется HTTPS и порт 4443)

Мастер cms для репликации данных использует хранилище файлов, определяемом топологией при развертывании Lync. В хранилище используется папка “CentralMgmt”. (Имена папок создаются по следующей логике: <Site ID>-<Service ID>-<Pool ID>)

Структура папки “CentralMgmt” выглядит так:

В папке CentralMgmt находятся папки CMSFileStore\xds-master\replicas. В папке replicas вы можете найти папки для каждого из серверов Lync вашей топологии. В каждой из этих папок есть папки to-replica и from-replica.

На каждом из серверов топологии Lync есть локальная папка на системном диске RTCReplicaRoot, в ней находится папка xds-replica, а в ней находятся папки to-master, from-master, working.

Что изменилось в S4B

  • В S4B размещение файлов репликации CMS было изменено: они перемещены из файлового хранилища(CMSFileStore) в папку RTCReplicaRoot на Front-End.
  • В случае редакции Enterprise узнать на каком FE размещается мастер в данный момент можно с помощью командлета Get-CsManagementStoreReplicationStatus –CentralManagementStoreStatus. В параметре ActiveMasterFqdn будет указано на каком сервере расположена шара для распространения CMS.
  • Если сервер FE (в Enterprise пуле) на котором расположена шара выходит из строя, то вся структура папок и функционал автоматически переключается на другой сервер FE пула.
  • Путь размещения реплик \\ActiveMasterFqdn\RtcReplicaRoot\xds-replica\xds-master\xds-master\ , при этом структура папок реплик не поменялась.

 

Как работает репликация CMS

Суть репликации заключается в том, что существует только один мастер и множество реплик. Мастер размещается на SQL Back-End (RTC), а реплики размещаются на каждом из серверов Lync (RTCLOCAL).

При этом получается что для Enterprise пула cms размещается на отдельном SQL Back-End сервере (экземпляр RTC), а для Standard мастер и реплика размещаются на одном сервере в различных экземплярах SQL Express(RTC и RTCLOCAL).

Информация о размещении мастера CMS хранится в Active Directory в Service Connection Point (SCP). Посмотреть можно через ADSIEDIT (Configuration) CN=Topology Settings, CN=RTC Service, CN=Services, DC=<domain> атрибут msRTCSIP-BackEndServer.

Как работает репликация КРАТКО:

  1. Проверка изменений и копирование этой информации с мастера на реплику.
  2. Применение принятых изменений на реплике.
  3. Отправка отчета о статусе на мастер.

Как работает репликация ПОДРОБНО

  1. Каждые 60 секунд запускается задача проверки изменений на мастере CMS (и которые нужно реплицировать)
  2. Если изменения найдены (xml файлы), то они упаковываются в файл data.zip. Размер файла получается менее 100KB для того, чтобы побыстрее выполнить репликацию. В файле data.zip находятся два файла с общей топологией и информацией о телефонии и интеграции с Exchange.
  3. Файл data.zip копируется в файловое хранилище (для Lync2013) либо в локальную шару RTCReplicaRoot ActiveMasterFqdn Front-End (для S4B) в каждую папку “to-replica” для каждого сервера в папке xds-master\replicas (см. структуру выше)
  4. Служба Lync Server File Transfer Agent (FTA) запущенная на мастере, отслеживает все папки “to-replica”, и после того как увидит файл data.zip в папке, запускает процесс репликации (SMB:445, а в случае Edge по HTTPS:4443).
  5. На серверах с репликами запущена служба Lync Server Replica Replicator Agent (REPLICA), которая отслеживает папку “from-master”. Когда видит в ней файл data.zip, распаковывает его и применяет изменения к серверу.
  6. После применения изменений на реплике, создается файл status.zip и помещается в папку “to-master” на сервере.
  7. FTA отслеживает папки “from-master” на всех серверах и увидев файл status.zip, копирует его в папку «from-replica» на мастере.
  8. Lync Server Master Replicator Agent (MASTER) распаковывает файл и обновляет статус в CMS. Ну а визуально вы можете увидеть этот статус в виде зеленой галки в Lync Control Panel\Topology\Status\колонка Replication, либо через Get-CsManagementStoreReplicationStatus

 

Ну и для наглядности процессов схема из постера Skype for Business 2015 Protocol Workloads Poster

Официальная документация по портам и протоколам для планирования CMS (ведь не поверят же вам на слово! 🙂 )

Ну вот как то так.. далее если руки дойдут то дополню статью информацией по инструментам lync shell, topology builder, lscp.(что, куда и по каким портам).

Рубрики:Lync, SfB

Lync Autodiscover

О чем это все

В данной статье описан процесс Autodiscover Lync. Почему написал: порой приходится освежать информацию по Lync, и в частности вопрос по процессу автообнаружения, поэтому решил собрать в кучку информацию по этому вопросу из разных источников и практики. Надеюсь куча получилась понятная ))

 

Autodiscover – это служба автообнаружения, необходимая для работы мобильных клиентов, в Lync 2013\S4B также используется клиентами стационарных ПК. Она распознается по обязательным DNS-записям lyncdiscover.<домен> и lyncdiscoverinternal.<домен>. Веб-службы Lync\S4B передают ответ на запрос клиента, в котором указываются компоненты, доступные для клиента, и способы связи с этими компонентами, в формате отклика автообнаружения.

Таблица поддержки режимов автообнаружения клиентами Lync\S4B

LyncDiscover DNS SRV Lookup
Lync 2010 client +
Lync 2013 client + +
S4B client + +
Lync Windows Store App +
Lync Phone Edition +
Lync\S4B Mobile +
Lync Mac +

 

Порядок обнаружения служб клиентами Lync\S4B (пример для домена contoso.com)

Клиент пытается разрешить в DNS записи (порядок в следующей таблице) и получить ответ от служб для последующей регистрации.

DNS запись Примечание
1 lyncdiscoverinternal.contoso.com Запись А для службы автообнаружения, для внутренних подключений, направленных к внутренним веб-службам
2 lyncdiscover.contoso.com запись A для службы автообнаружения, для внешних веб-служб
3 _sipinternaltls._tcp.contoso.com SRV-запись для внутренних подключений TLS
4 _sipinternal._tcp.contoso.com SRV-запись для внутренних подключений TCP
5 _sip._tls.contoso.com SRV-запись для внешних подключений TCP
6 sipinternal.contoso.com запись A, для пула переднего плана
7 sip.contoso.com запись A для пула переднего плана, если клиент во внутренней сети; запись A для пограничного сервера доступа (если клиент внешний и без доступа по VPN)
8 sipexternal.contoso.com запись A для пограничного сервера доступа, если клиент внешний без доступа по VPN

 

Кратко о процессе получения ответа клиенту Lync от Autodiscover (LyncDiscover) на примере подключения мобильного клиента Lync 2013 (sip: user@contoso.com)

  • Разрешить в DNS А-запись lyncdiscoverinternal.contoso.com если невозможно разрешить или подключиться, то lyncdiscover.contoso.com
  • Разрешив запись, клиент пытается туда отправить HTTP (port 80) и HTTPS (port 443) запрос: GET http://lyncdiscover.contoso.com/?sipuri=user@contoso.com
  • Клиент получает файл формата JSON или XML, где указаны url веб-служб Lync\S4B (для подключения и проверки подлинности)
  • Проходит проверку подлинности и получает тикет от службы WebTicket
  • Клиент заново отправляет запрос на получение информации о домашнем пуле предоставив свой веб-тикет.
  • Если для пользователя это не домашний пул, то мы получим ответ перенаправления, где проводятся те же самые шаги для аутентификации на другом сервере.
  • Получить XML от службы Autodiscover где будут указаны url домашнего пула FE, пула Edge связанного с этим пулом FE, и других служб.

 

Далее подробнее о процессе LyncDiscover (Lync 2013 / S4B). Этот раздел – это вольный пересказ части этой статьи

Итак, рассмотрим подробнее процесс lyncdiscover (SRV записи тут рассматривать не будем). Из предыдущей таблицы видим, что клиент должен разрешить по порядку следующие А записи:

  • lyncdiscoverinternal.contoso.com
  • lyncdiscover.contoso.com

Разрешив запись, клиент пытается отправить HTTP (port 80) и HTTPS (port 443) запрос (HTTP GET) в следующем виде:

GET http://lyncdiscover.contoso.com/?sipuri=user@contoso.com

 Далее клиент должен получить ответ в одном из двух поддерживаемых форматах: JSON или XML. Формат по умолчанию — нотация объектов JavaScript (JSON). Второй формат — документ XML. Запрос и ответ предсказуемы, так как документ имеет заданную схему, определяющую формат. Строка, которая указывает используемую схему в документе, — это первая строка в запросе или ответе.

 

JSON

Клиент отправляет в заголовке HTTP запроса:

Accept: application/json

Ответ сервера выглядит так:

{

  «_links»:{

    «self»:{

      «href»:»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=contoso.com&#187;

    },

    «user»:{

      «href»:»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com&#187;

    },

    «xframe»:{

      «href»:»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187;

    }

  }

}

 

Так как используется формат JSON то служба lyncdiscover предполагает, что клиент будет использовать службу UCWA, поэтому предлагает метод OAUTH для получения домашнего пула пользователя. Как можно видеть, формат json возвращает мало информации (меньше чем xml):

  • “self” – это ссылка на веб-службы, сгенерировавшие этот ответ
  • “user” – это URL-адрес службы автообнаружения, использующая аутентификацию OAUTH
  • “xframe” – предназначен для использования веб-приложениями для обхода ограничений AJAX при междоменных запросах.

 

XML

Клиент отправляет в заголовке HTTP запроса:

Accept: application/vnd.microsoft.rtc.autodiscover+xml;v=1

 

Ответ от сервера Lync 2013/S4B

<AutodiscoverResponse xmlns:xsd=»http://www.w3.org/2001/XMLSchema&#187; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance&#187; AccessLocation=»External»>

  <Root>

    <Link token=»Domain» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/domain?originalDomain=contoso.com&#187; />

    <Link token=»User» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=contoso.com&#187; />

    <Link token=»Self» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=contoso.com&#187; />

    <Link token=»OAuth» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com&#187; />

    <Link token=»External/XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

    <Link token=»Internal/XFrame» href=»https://lyncpool.domain.local/Autodiscover/XFrame/XFrame.html&#187; />

    <Link token=»XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

  </Root>

</AutodiscoverResponse>

 

Разберем что мы получили в ответе:

  • AccessLocationExternal» в корне AutodiscoverResponse – это место подключения , либо внешнее(external) либо внутреннее (internal), и определяется по порту подключения (4443 или 443 соответственно)
  • «Domain» – для обнаружения FQDN текущего пула. Не требует аутентификации.
  • «User» – для обнаружения домашнего пула пользователя, требует аутентификации.
  • «OAuth» – аналогично “user” при этом для NTLM\Kerberos требуется аутентификация OAuth

Есть два отдельных способа получения информации о домашнем пуле конкретного пользователя и связанных с ним веб-сервисов.

  • WebTicketService доступен на Lync Server 2010 и 2013 и требует поддержки NTLM или Kerberos для получения начального билета, который затем может быть использован для подтверждения личности пользователя с этого момента.
  • OAuth доступен только на Lync Server 2013 и предоставляет простой (и более удобный в Интернете) способ получения токена, который также может использоваться для подтверждения подлинности, на любом Front End Server в топологии, поскольку все они имеют один и тот же сертификат X509(реплицируется через CMS).

 

Autodiscover через WebTicketService

Итак, рассмотрим обнаружение домашнего пула пользователя по методу “user”. Отправляем HTTP GET на “user” URL

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=contoso.com?sipuri=user@contoso.com

И мы получаем ответ HTTP 401 Unauthorized, сообщающий нам, что требуется аутентификация. Но он не принимает какие-либо традиционные методы аутентификации, вы не можете использовать NTLM или Kerberos, так как оба требуют соединения с AD для проверки учетных данных (это увеличило бы зависимость от AD и дало бы дополнительную нагрузку для каждой попытки соединения). Также NTLM через HTTP раздувается, требуя, чтобы каждое соединение полностью аутентифицировалось.

Тогда как в методе получения билета(ticket, «тикет») – нужно один раз подтвердить вашу личность и получить уникальный «тикет», действительный в течении определенного периода. Что позволяет вам просто передавать свой тикет в последующих запросах, делая сам запрос более быстрым и легким и избавляет от необходимости проходить весь повторный процесс аутентификации каждый раз (в отличии от NTLM).

Наряду с ответом «401», сервер возвращает ответ с следующими заголовками:

X-MS-WebTicketURL: https://lyncweb.contoso.com/WebTicket/WebTicketService.svc

X-MS-WebTicketSupported: cwt,saml

X-MS-Server-Fqdn: lync-fe01.contoso.local

X-Content-Type-Options: nosniff

Content-Length: 1293

Cache-Control: no-cache

Content-Type: text/html

Server: Microsoft-IIS/8.0

X-Powered-By: ASP.NET,ARR/2.5

Date: Sat, 09 Jan 2017 21:00:00 GMT

 

Здесь мы видим важную информацию:

  • XMSServerFqdn: Fqdn пула который отвечает на этот запрос

 

  • X-MS-WebTicketURL: url службы WebTicketService. Эта веб-служба SOAP, которая аутентифицирует пользователя через протоколы NTLM или Kerberos(напомню что керберос нужно дополнительно настраивать) и возвращает тикет (часть ответа SOAP-сообщения)

 

Далее мы отправляем по полученному URL новый запрос и получаем опять HTTP 401 Unauthorized, но в этот раз мы видим метод аутентификации в ответе: WWW-Authenticate: NTLM. И в следующем заголовке добавим:

SOAPAction: http://docs.oasisopen.org/wssx/wstrust/200512/RST/Issue

 И присоединим SOAP – сообщение используя метод «Issue» WebTicketService

<s:Envelope xmlns:s=»http://schemas.xmlsoap.org/soap/envelope/»&gt;

   <s:Body>

       <RequestSecurityToken Context=»9deba099-5746-4d41-8e36-6f1977e69d8f» xmlns=»http://docs.oasis-open.org/ws-sx/ws-trust/200512″&gt;

           <TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</TokenType&gt;

           <RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/Issue</RequestType&gt;

           <AppliesTo xmlns=»http://schemas.xmlsoap.org/ws/2004/09/policy»&gt;

               <EndpointReference xmlns=»http://www.w3.org/2005/08/addressing»&gt;

                   <Address>https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?sipuri=user@contoso.com</Address&gt;

               </EndpointReference>

           </AppliesTo>

           <Claims Dialect=»urn:component:Microsoft.Rtc.WebAuthentication.2010:authclaims»>

               <auth:ClaimType Uri=»http://schemas.xmlsoap.org/ws/2005/05/identity/claims/uri&#187; Optional=»false» xmlns:auth=»http://schemas.xmlsoap.org/ws/2006/12/authorization»&gt;

                   <auth:Value>sip:user@contoso.com</auth:Value>

               </auth:ClaimType>

           </Claims>

           <Entropy>

               <BinarySecret Type=»http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce»>OTJhYzRlZjMtYTY1OC00MGQ1LWI2YjQtNzczOGFlZDFmZjVl</BinarySecret&gt;

           </Entropy>

           <KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/SymmetricKey</KeyType&gt;

       </RequestSecurityToken>

   </s:Body>

</s:Envelope>

 

Этот обмен SOAP-сообщениями использует WS-Trust (расширение WS-Security) и обеспечивает платформу для обмена токенами безопасности и установления доверительных отношений.

Важные моменты в этом сообщении:

  • “EndpointReference” (<Address>) – содержит адрес веб-сервиса, к которому мы хотели бы получить доступ, используя ранее полученный тикет.
  • “Claims” (<auth:value>) – sip адрес пользователя
  • “Entropy”( BinarySecret) – уникальный ключ Base64, используется как «доказательство владения» для предотвращения атак повтора.

Затем мы получаем утверждение SAML, завернутое в сообщение SOAP. В сообщении все содержимое RequestedSecurityToken и есть наш тикет. Теперь у нас есть все чтобы подтвердить идентичность.

Теперь возвращаемся к исходному запросу HTTP GET на “user” URL

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=contoso.com?sipuri=user@contoso.com

 

Но сейчас мы можем аутентифицироваться, добавив в HTTP заголовок наш веб-тикет и получить наш XML от службы Autodiscover.

 

 

Autodiscover через OAuth

OAuth – более легкий способ получения токена, который необходим чтобы доказать нашу идентичность и получить свой XML от службы autodiscover. OAuth — это открытый стандарт, написанный Microsoft и опубликованный IETF как RFC6749. На высоком уровне он обеспечивает те же функциональные возможности, что и WebTicketService, но самое важное отличие заключается в том, что полученный маркер создается с использованием сертификата X509, назначенного на сервере, поэтому разрешает любому серверу с этим сертификатом декодировать и доверять токену без необходимости повторной аутентификации клиента на другом сервере. (Lync 2013\S4B автоматически копирует этот сертификат OAuth на все другие серверы Front End через CMS).

Сначала идет запрос GET на URL-адрес «OAuth», полученный из ответа LyncDiscover в формате XML (или «User» URL из ответа JSON).

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com?sipuri=user@contoso.com

Мы опять получаем HTTP 401 Unauthorized, но в этот раз со следующим заголовком:

Content-Length: 1293

Cache-Control: no-cache

Content-Type: text/html

Server: Microsoft-IIS/8.0

WWW-Authenticate: Bearer trusted_issuers=»», client_id=»00000004-0000-0ff1-ce00-000000000000″,MsRtcOAuth href=»https://lyncweb.contoso.com/WebTicket/oauthtoken&#187;,grant_type=»urn:microsoft.rtc:windows,urn:microsoft.rtc:anonmeeting,password»

X-MS-Server-Fqdn: lync-fe01.contoso.local

X-Powered-By: ASP.NET,ARR/2.5

X-Content-Type-Options: nosniff

Date: Sun, 9 Jan 2017 20:00:00 GMT

 

На этот раз заголовок WWW-Authenticate дает нам URL-адрес MsRtcOAuth для https://lyncweb.contoso.com/WebTicket/oauthtoken, который принимает несколько разных типов проверки подлинности “grant_type”. Мы можем видеть, что он принимает аутентификацию Windows, проверку подлинности с помощью пароля и тип разрешения, позволяющий анонимно присоединяться к конференциям.

Теперь все, что нам надо, это собрать данные для аутентификации(логин и пароль) и отправим это на URL “OAuth”

grant_type=password&username=user@contoso.com&password=MyPassword!

 

Ответ JSON:

{«access_token»:»cwt=AAEBHAEFAAAAFFAF…Xyrbdfs»,

    «expires_in»:28402,

    «ms_rtc_identityscope»:»local»,

    «token_type«:»Bearer«

}

 

Мы просто используем значение «access_token» таким же образом, как мы использовали тикет от WebTicketService, отправив HTTP GET снова на URL автообнаружения OAuth, как показано ниже:

GET https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=contoso.com?sipuri=user@contoso.com

Authorization: Bearer cwt= AAEBHAEFAAAAFFAF…Xyrbdfs

 

При этом мы получим тот же XML от Autodiscover который мы получили ранее, используя WebTicketService

 

 

Кратко о предыдущих процессах

 Итак, какие этапы у нас пройдены:

  1. Разрешить в DNS А-записи lyncdiscoverinternal.contoso.com или lyncdiscover.contoso.com
  2. Получить файл формата JSON или XML и узнать в них url веб-служб Lync\S4B
  3. Получить тикет от WebTicketService или OAuth токен.
  4. Аутентифицироваться по url autodiscover/“user” или по url autodiscover/oauth

 

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

Редирект в формате JSON выгляди так:

{

  «_links»:{

    «redirect»:{

      «href»:»https://lyncweb2.contoso.com/Autodiscover/AutodiscoverService.svc/root&#187;

    }

  }

}

 

Редирект в формате XML выглядит так:

 

<AutodiscoverResponse xmlns:xsd=»http://www.w3.org/2001/XMLSchema&#187; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance&#187; AccessLocation=»External»>

<User>

   <Link href=»https://lyncweb2.contoso.com/Autodiscover/AutodiscoverService.svc/root&#187; token=»Redirect»/>

</User>

</AutodiscoverResponse>

 Итогом всех этих мучений должен быть ответ от службы autodiscover в формате xml файла

 

Autodiscover XML

XML будет выглядеть примерно так:

 

<AutodiscoverResponse xmlns:xsd=»http://www.w3.org/2001/XMLSchema&#187; xmlns:xsi=»http://www.w3.org/2001/XMLSchema-instance&#187; AccessLocation=»External»>

<User>

<SipServerInternalAccess fqdn=»lyncpool01. contoso.local» port=»5061″ />

<SipClientInternalAccess fqdn=»lyncpool01. contoso.local» port=»5061″ />

<SipServerExternalAccess fqdn=»access01.contoso.com» port=»5061″ />

<SipClientExternalAccess fqdn=»access01.contoso.com» port=»443″ />

<Link token=»Internal/Autodiscover» href=»https://lyncpool01.contoso.local/Autodiscover/AutodiscoverService.svc/root&#187; />

<Link token=»Internal/AuthBroker» href=»https://lyncpool01.contoso.local/Reach/sip.svc&#187; />

<Link token=»Internal/WebScheduler» href=»https://lyncpool01.contoso.local/Scheduler&#187; />

<Link token=»Internal/CertProvisioning» href=»https://lyncpool01.contoso.local/CertProv/CertProvisioningService.svc&#187; />

<Link token=»External/Autodiscover» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root&#187; />

<Link token=»External/AuthBroker» href=»https://lyncweb.contoso.com/Reach/sip.svc&#187; />

<Link token=»External/WebScheduler» href=»https://lyncweb.contoso.com/Scheduler&#187; />

<Link token=»External/CertProvisioning» href=»https://lyncweb.contoso.com/CertProv/CertProvisioningService.svc&#187; />

<Link token=»Internal/Mcx» href=»https://lyncweb.contoso.com/Mcx/McxService.svc&#187; />

<Link token=»External/Mcx» href=»https://lyncweb.contoso.com/Mcx/McxService.svc&#187; />

<Link token=»Ucwa» href=»https://lyncweb.contoso.com/ucwa/oauth/v1/applications&#187; />

<Link token=»Internal/Ucwa» href=»https://lyncpool01.contoso.local/ucwa/oauth/v1/applications&#187; />

<Link token=»External/Ucwa» href=»https://lyncweb.contoso.com/ucwa/oauth/v1/applications&#187; />

<Link token=»External/XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

<Link token=»Internal/XFrame» href=»https://lyncpool01.contoso.local/Autodiscover/XFrame/XFrame.html&#187; />

<Link token=»XFrame» href=»https://lyncweb.contoso.com/Autodiscover/XFrame/XFrame.html&#187; />

<Link token=»Self» href=»https://lyncweb.contoso.com/Autodiscover/AutodiscoverService.svc/root/user&#187; />

</User>

</AutodiscoverResponse>

 

Что же мы видим в данном ответе для нашего пользователя:

  • SipServerInternalAccess fqdn – внутреннее имя (fqdn) и порт домашнего пула Front End.
  • SipClientInternalAccess fqdn – внешнее имя (fqdn) и порт домашнего пула Front End.
  • SipServerExternalAccess fqdn – внешнее имя (fqdn) и порт Edge пула связанного с домашним пулом для федеративного подключения и подключения к общедоступным службам обмена мгновенными сообщениями с помощью SIP.
  • SipClientExternalAccess fqdn — внешнее имя (fqdn) и порт Edge пула связанного с домашним пулом для клиентских подключений.
  • AutodiscoverURL службы autodiscover
  • AuthBroker – URL службы Authentication Broker (проверки подлинности (доступа))
  • WebScheduler – URL службы Web Scheduler (планировщик собраний)
  • CertProvisioning — URL службы для получения клиентских сертификатов
  • MCX – URL веб службы для обеспечения совместимости с моб. клиентами Lync 2010
  • UCWA – URL веб службы для подключения моб.клиентов и сторонних приложений
  • XFrame — предназначен для использования веб-приложениями для обхода ограничений AJAX при междоменных запросах
  • Self – URL веб службы вернувшей этот ответ

Вот собственно и все! Информация, полученная от Autodiscover, позволит подключится клиенту и начать работать.

Рубрики:Lync, SfB

Публикация ресурсного календаря Exchange 2013

ICal_IconМаленькая заметка как опубликовать календарь ресурсного ящика в формате iCalendar или HTML. Чтобы публиковать в таком виде календари пользователей необходимо предварительно настроить данную возможность, например здесь отлично описан этот процесс: http://www.stevieg.org/2010/06/calendar-sharing-improvements-coming-in-exchange-2010-sp1/

Но что если нам нужно опубликовать календарь ресурсного ящика в интернет? для этого нам необходимо сделать следующее:

1. Set-Mailbox -Identity ResourceMailbox -SharingPolicy SharingPolicyForInternet (назначим созданную ранее политику либо предварительно создадим новую например так New-SharingPolicy -Name SharingPolicyForInternet -Domains ‘Anonymous: CalendarSharingFreeBusySimple’ -Enabled $true)

2. Set-MailboxCalendarFolder -Identity ResourceMailbox:\Calendar -PublishEnabled $true

3. Get-MailboxCalendarFolder -Identity ResourceMailbox:\Calendar

из последней команды найдем ссылку для подключения календаря (ical или html) — теперь можно выслать данные ссылки для подключения ical либо просмотра через браузер.

P.S. Если у вас папка календаря на русском то замените в командах Calendar на Календарь (получится так ResourceMailbox:\календарь ).

Рубрики:Exchange 2010, Exchange 2013

Client Skype for Business. Включаем SkypeUI через реестр.

Недавно вышло обновление интерфейса клиента Lync 2013: Skype for Business. Подробнее можно почитать здесь.
Если лень читать то чтобы глобально включить использование Skype for Business UI на уровне глобальной клиентской политики выполните команду на сервере Lync:
Set-CsClientPolicy -EnableSkypeUI $True
Но, что, если администратор Lync решил не включать возможность использования Skype for Business UI. То после установки обновления, запустив клиент первый раз вы увидите сообщение что администратор Lync ну очень хочет, чтобы вы использовали LyncUI и предлагает перезагрузиться.

Перезагрузившись вы увидите старый добрый клиент Lync 2013 (но со значком Skype в панели задач 🙂 )

Немного теории: во время логона в Lync, применяется клиентская политика в которой в нашем случае не указано что мы можем использовать SkypeUI. При этом меняется всего лишь один ключ в реестре машины: HKEY_CURRENT_USER\Software\Microsoft\Office\Lync «EnableSkypeUI» (для отключения SkypeUI значение меняется на 00,00,00,00 )

Изменим перед запуском клиента значение данного ключа на значение 01,00,00,00 следующей командой:

Reg add HKEY_CURRENT_USER\Software\Microsoft\Office\Lync /V EnableSkypeUI /T REG_BINARY /D 01000000 /F

Перезапустим клиент и вуаля мы снова в SkypeUI, но опять получим предупреждение 🙂 — нужно будет автоматизировать процесс чтобы каждый раз не выполнять команду перед запуском клиента .

Еще полезную информацию о переключении между LyncUI и SkypeUI можно почитать здесь https://support.office.com/en-us/article/Switching-between-the-Skype-for-Business-and-the-Lync-client-user-interfaces-a2394a4c-7522-484c-a047-7b3289742be0

Рубрики:SfB

Синхронизация адресной книги CommuniGate Pro и Exchange 2013

 

ex2013

Решение задачки по синхронизации адресной книги CGP и Exchange(в одну сторону CGP to Exchange). Скрипт публикую как есть, описывать подробно лень, а кому очень нужно разберется :).

Описание ситуации: Сосуществование CGP и Exchange 2013, при этом необходимо в адресной книге Exchange иметь контакты пользователей, находящихся на CGP.

Решение задачи: Скрипт + Scheduler

 

#Выгрузка объектов(пользователей) с помощью ldap запроса из CGP

Param($user = “CGPuser”,
      $password = “CGPuserpassword”,
      $filter = “(objectclass=*)”,
      $server = “server.cgp.local:489”,
      $path = “cn=cgp.local,o=mxs”,
      [switch]$all,
      [switch]$verbose)
   

if($verbose){$verbosepreference = “Continue”}

$DN = “LDAP://$server/$path”
Write-Verbose “DN = $DN”
$auth = [System.DirectoryServices.AuthenticationTypes]::FastBind
Write-Verbose “Auth = FastBind”
$de = New-Object System.DirectoryServices.DirectoryEntry($DN,$user,$Password,$auth)
Write-Verbose $de
Write-Verbose “Filter: $filter”
$ds = New-Object system.DirectoryServices.DirectorySearcher($de,$filter)
$ds.SearchScope = “Subtree”
Write-Verbose $ds
$users = $ds.FindAll()
$Encode =  new-object system.text.UTF8encoding
Set-Content -Path C:\UAB\UsersContacts.csv -Value “displayname, alias, WindowsEmailAddress” -Encoding unicode
$i = 0
foreach ($user in $users)
{
    $i++; Write-Host $i
    $Row = “{0}, {1}, {2}” -f $Encode.GetString($user.properties[“cn”][0]), $Encode.GetString($user.properties[“uid”][0]), $Encode.GetString($user.properties[“mail”][0])
    Add-Content -Path C:\UAB\usersContacts.csv -Value $Row -Encoding unicode
}
#Создание контактов из объектов присутствующих в LDAP запросе (производится добавление только отсутствующих контактов, реализованное через сравнение Compare-Object). При этом используется отдельная OU.

$ContactOU = “OU=Update Address Book,OU=All Users,DC=cgp,DC=local“
$ContactsCGP = import-Csv ‘C:\UAB\UsersContacts.csv’ -Encoding Unicode
$ContactsExch = get-mailcontact -OrganizationalUnit $ContactOU -resultsize unlimited | select-object displayname,alias,windowsemailaddress
Compare-Object $ContactsCGP $ContactsExch -Property displayname, alias, windowsemailaddress | Where-Object {$_.SideIndicator -eq “<=“} | Export-Csv -Encoding Unicode C:\UAB\AddContacts.csv
$Users = import-Csv ‘C:\UAB\AddContacts.csv’ -Encoding Unicode
$users | ForEach-Object {Remove-MailContact -identity $_.Alias -Confirm:$y}
$users | ForEach {New-MailContact -Name $_.alias -displayname $_.displayname -alias $_.alias -ExternalEmailAddress $_.WindowsEmailAddress -OrganizationalUnit $ContactOU}

 

#Удаление контактов объектов отсутствующих в LDAP запросе(т.е пользователи уже отсутствуют в CGP)

$ContactsExch = Get-MailContact -OrganizationalUnit $ContactOU -ResultSize Unlimited |select -exp alias
$ContactsCGP = import-Csv ‘C:\UAB\UsersContacts.csv’ -Encoding Unicode|select -exp alias
$Diff  = $ContactsExch | ? {$ContactsCGP -notcontains $_}
$Diff | ForEach-Object {remove-mailcontact -identity $_ -Confirm:$Y}

#P.S. Можно и не пользоваться выгрузкой в файлы, сделано для наглядности процесса синхронизации. Также можно через set-contact добавить дополнительные сведения в контакты.

Рубрики:Exchange 2013

Публикация CRL (certificate revocation list)

PKIProcessДанная статья описывает пример публикации CRL (certificate revocation list), в целях доступности их внешним клиентам, например мобильным клиентам lync, в случае когда для публикации вебслужб Lync используются сертификаты внутреннего CA. Данная статья предназначена для тех кому надо решить данную задачу, но не хочет лезть в дебри PKI 🙂

 

Что мы имеем:

  • Внутренний CA развернут и работает корректно
  • Запись во внешнем DNS(для публикации crl по этому имени), например ca.company.ru
  • Возможность обеспечить доступ к серверу CA (или другой публикующий web server) из Интернета по порту 80/TCP (HTTP). Например можно использовать IIS ARR который мы развернули в прошлых статьях для публикации вебслужб Lync. Просто добавим новую ферму (Server Farm) участником которой будет сервер CA и добавим новое правило(URL Rewrite) для запросов типа ca.* (для нашего примера).

Итак, приступим:

  1. На веб сервере (у нас CA) создадим папку, например c:\CRLDistribution . Дать на нее серверу CA NTFS права на модификацию. Расшарить директорию и дать серверу CA или группе Everyone права на модификацию. crl1crl2
  2. Откройте Internet Information Services (IIS) Manager (на сервере CA). Далее правой кнопкой по Default Web Site и выберете Add Virtual Directory. Заполните поле ALIAS например – CRLD, и выберете директорию из пункта 1. crl3
  3. Выберете созданную виртуальную директорию. Справа выберете и зайдите в Directory Browsing, и включите его (Enable справа в поле action)
  4. Выберете созданную виртуальную директорию. Справа выберете и зайдите в Configuration Editor, выберете в поле section значение system.webServer/security/requestFiltering. Ниже в поле allowDoubleEscaping выберете для него true. crl4         Это необходимо для доступа к файлам, содержащим в имени знак ‘+’. Такой знак генерируется в имени файла, содержащего Delta CRL. Без этого при попытке доступа к файлу Delta CRL сервер будет в любом случае возвращать Error 404 (даже при наличии файла). В нашем случае необходимо также выставить данный флаг и на IIS ARR: Default Web Site\Request Filtering\Edit Feature Settings\Allow double escaping
  5. Перейти на СА и открыть оснастку управления СА (Administrative Tools > Certificate Authority). Войти в свойства CA и перейти на вкладку Extensions. Нажать кнопку Add. В поле Location ввести следующее:
  6. file://\\CA01\CRLDistribution\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
    Необходимо для автоматической публикации crl в нужной папке. Где \\CA01\CRLDistribution — UNC-путь к директории, а CA01 — имя, по которому веб-сервер доступен внутри сети(в нашем случае это корпоративный CA).
    Нажать ОК, выделить в списке эту строку и установить:
    Publish CRLs to this location
    Publish Delta CRLs to this location
  7. Добавить еще одну строку(по этому пути внешние клиенты будут искать наши crl). При этом CA.company.ru – fqdn имя по которому сервер доступен из сети интернет. CRLD – это ALIAS виртуальной директории.
    http://CA.company.ru/CRLD/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
    Нажать ОК, выделить в списке эту строку и установить:
    Include in CRLs. Clients use this to find Delta CRL locations.
    Include in the CDP extension of issued certificates
  8. crl5
  9. Сохранить изменения. Согласиться с перезапуском службы СА
  10. В оснастке управления СА щелкнуть правой кнопкой на Revoked Certificates и выбрать All tasks -> Publish. В директории на веб-сервере появились два файла — CLR и Delta CLR. Если по этому действию возникают ошибки то они зачастую связаны с отсутствием прав на директорию размещения файлов crl. Еще раз перепроверьте правильно ли вы дали доступ к папке. Возможно помогут статьи с technet http://social.technet.microsoft.com/wiki/contents/articles/3081.ad-cs-error-the-directory-name-is-invalid-0x8007010b-win32http-267.aspx и http://technet.microsoft.com/en-us/library/cc726342(v=WS.10).aspx
  11. Теперь нужно перевыпустить сертификаты для наших публикуемых сервисов. Например для Lync: необходимо перевыпустить сертификаты для ReverseProxy и Edge. Открыть свойства новых сертификатов и на вкладке Details проверить содержимое поля CLR Distribution Points. Там должен фигурировать соответствующий URL, ссылающийся на публичный FQDN веб-сервера.
  12. Проверить доступность CRL из интернет. Например пройдя в нашем случае по ссылке http://ca.company.ru/crld/ вы должны увидеть все файлы в этой директории, попробуйте скачать их. Если скачивается значит все работает как надо. crl6
  13. Примечание: Для использования сертификатов, выданных внутренним CA, с сервисами, доступными из интернет (различные веб службы, например веб службы Lync), необходимо, чтобы публичные сертификаты корневого центра сертификации и всех подчиненных CA были помещены в хранилище Доверенные корневые центры сертификации / Trusted root certification authorities и клиентам были доступны CRL(списки отзыва сертификатов), публикуемые этими центрами сертификации. На мобильных клиентах Lync также необходимо устанавливать корневой сертификат.
  14. Пример из практики для чего нужна данная публикация CRL.

Исходные данные: В организации развернут Lync, используются сертификаты внутреннего CA. Администратор решил организовать доступ мобильных клиентов Lync из сети интернет. Опубликовал веб службы в интернет с помощью IIS ARR, использовал для публикации сертификаты выпущенные внутренним CA. Установил Lync client 2013 на свой смартфон с ОС WP8, установил корневой сертификат своего CA и успешно подключился, после этого свернул приложение. На следующее утро администратор вызвал из фона приложение Lync но приложение не могло подключиться, помогал только выход из клиента путем разлогирования, при этом появлялось сообщение что связь с сервером разорвана. Данная проблема повторялась каждый раз после длительного периода нахождения в фоне(около 4-6 часов).

Причины: поиск мобильным клиентом списков отзыва сертификатов (CRL)

Решение проблемы: публикация CRL, заново опубликовать веб службы Lync с новыми сертификатами (где есть новая точка распространения CRL)

Profit!

Заметки ИТ инженера

Мои заметки, связанные с профессиональной деятельностью в сфере Информационных Технологий

IT in realworld

о технологиях Microsoft, или кратко обо всем. Active Directory and other stuff.