Сервер времени в домене с помощью групповых политик | How to setup Time server in Domain through GPO

Настройку серверов времени удобно производить с помощью групповых политик. Преимущество в том, что в случае смены PDC роли, все настройки синхронизации с внешним NTP узлом будут применены автоматически.

Для настройки необходимо:

• Проверить доступность UDP 123 от PDC до источника времени
• Создать WMI фильтр:

Select * from Win32_ComputerSystem where DomainRole = 5

Параметр Domain Role назначается всем компьютерам домена, его можно посмотреть с помощью команды:

wmic computersystem get domainrole — локально на компьютере.

wmic /node:”M1” computersystem get domainrole — удаленно на компьютере.

Value	Meaning
0	Standalone Workstation
1	Member Workstation
2	Standalone Server
3	Member Server
4	Backup Domain Controller
5	Primary Domain Controller

•  Создать GPO TimeServices

И включить следующие параметры в разделе Сomputer Configuration/Policies/Administrative Templates/System/Windows Time Service/Time Providers

1. Enable Windows NTP Client: Enabled

2. Enable Windows NTP Server: Enabled

3. Configuring Windows NTP Client: Enabled

В разделе NTP Client значение Type — NTP означает синхронизацию с внешним источником.

NtpServer — через пробел перечисляются серверы «внешние» NTP, формат в котором нужно указывать:

ntpserver1,0x01 ntpserver2,0x01 ntpserver3,0x01

SpecialPollInterval — время в секундах через которое сервер PDC будет синхронизироваться с внешним сервером. Этот параметр работает в случае указания флага 0x01. По умолчанию сервер времени синхронизруется с источником без определенного интервала.

 

• Обновить групповую политику на PDC:

gpupdate /force

• Перезапустить сервис времени на PDC.
• Проверить настройки:

w32tm /query /status — текущий статус настройки времени на узле.

w32tm /query /source — отображает источники времени узла.

w32tm /resync — ручная синхронизация времени клиента с сервером.

Если для настройки времени используется GPO — настройки хранятся в разделе реестра:

HKLM\SOFTWARE\Policies\Microsoft\W32Time\Parameters

Если для настройки времени используется ручная настройка — настройки хранятся в разделе реестра:

HKLM\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

Skype For Business 2015 интеграция с бесплатной PBX

В рамках одного проекта на тестовом стенде был сделан транк между Skype For Business 2015 (далее по тексту Skype) и бесплатной версии АТС (бесплатная лицензия на 1 год) Vodia PBX, ниже описание настроек. Задача — выполнения звонков Skype<—>Vodia, телефонные номера в Skype — 55xx, в Vodia PBX — 57xx.

Настройки Vodia PBX

Для настройки Vodia PBX необходимо:

• Скачать пакет с сервером Vodia  можно с сайта — http://vodia.com/onefree;
• Далее необходимо установить пакет Vodia PBX. Я установил на Windows 10.
• На сайте vodia.com получить тестовую лицензию на 1 год и указать ее в разделе License. Если этого не сделать сервисы Vodia корректно работать не будут.

• В разделе Security->General указать логин и пароль для администратора. При необходимости можно создать  дополнительный аккаунт.
• В разделе SIP проверить номера портов, которые используются для SIP протокола.

• В разделе Domains необходимо создать домен (я создал домен соответсвующий SIP домену в Skype).
• После создания домена, необходимо зайти в его настройки, нажав на его название.

• В настройках домена WCFC.demo в разделе Trunks создать новый транк, нажав на кнопку Add. Предполагается, что транк будет использовать транспортный протокол TCP, адрес Mediation сервера uc01.wcfc.local, порт TCP: 5068.

Настройки транка указаны ниже:

В настройках транка в разделе SIP Caller-ID Presentation (см выше) указаны следующие значения полей, по умолчанию прямые значения которых не отображаются, поэтому чтобы узнать их настоящие значения в Value нужно указать Other.

• В настройках домена WCFC.demo в разделе Feauters->Dial Plan нужно будет создать новый Dial Plan, указав его название(например uc.demo). В рамках стенда все звонки должы отправляться по одному транку, я не стал указывать конкретные диапазоны и оставил символ *, что означает направлять все исходяшие звонки в транк «SIP Gateway».

• В настройках домена WCFC.demo в разделе Extensions создать аккаунт с номером телефона из диапазона 57xx. 
• После создания аккаунта, зайти в его настройки и указать необходимый dial plan — в моем случае, это uc.demo.

• Настройки в домене WCFC.demo раздела Advanced->General Settings

В качестве клиента использовался бесплатный SIP клиент PhonerLite

Настройка Skype

Для настройки голосовой интеграции между Skype и PBX или прокси необходимо:

1. Установить Mediation Server;
2. Создать в топологии PSTN Gate и Trunks;
3. Создать Dial Plan;
4. Создать голосовую политику (Voice Policy);
5. Настроить конфигурацию транка;
6. Настроить пользователей Skype;
7. Иметь в наличие специализированные лицензии.

1 Установка Mediation Server

Mediation Server — это роль которая отвечает за трансляцию сигнала из формата RTA или SILK в формат понятный ТСОП — G711.

Для того, чтобы проверить или установить Mediation Server, необходимо открыть соответсвующий раздел в Topology Builder.

2 Создание PSTN Gate

На каритнке ниже создано два шлюза — шлюз PSTN.WCFC.LOCAL — это Vodia, порт 5060, шлюз PBX.WCFC.LOCAL это другая IP-АТС. (После создания шлюзов не забываем опубликовать обновленную топологию).

В качестве имени шлюза необходимо указывать FQDN, который корректно разрешается в DNS Mediation севером. Trunks создаются автоматически, после создания PSTN Gate.

3 Создание Dial Plan

Dial Plan это правила нормализации, которые преобразуют телефонные номера в единый стандарт (E. 164). Это относится как к входящим так и к исходящим номерам.

В реальной жизни форматов номеров конечно же больше, чем в приведенным ниже примере.

Предоставленное на изображении ниже правило отслеживает любые четырехзначные номера и прибавляет к ним знак «+».

4 Голосовая политика маршрутизации

Голосовая политика маршрутизации или Voice Routing — определяет для пользователей Skype кто из пользователей и куда может выполнять звонки.

На тестовом стенде все упрощается, поэтому не принципиально какая область действия будет у правила маршрутизации. Я создал для пользователей и назвал «Внутренние звонки».

Настройки политики:

• После того, как голосовая политика создана, необходимо создать PSTN Usage к которым потом привязать конкретные маршруты. Изначально я создаю пустые PSTN Usage. В этом примере создано два PSTN Usage. (На изображении PSTN Usage уже прикреплены маршруты, изначально это поле будет пустым).
• После создания PSTN Usage, необходимо создать маршрут.
• Маршрут создается исходя из того, какие номера нужно отследить и в какой шлюз PSTN направить. В моем случае необходимо отследить вызываемые абонентами Skype номера +57xx (уже нормализованные после Dial Plan) и направить их в шлюз pstn.wcfc.local. Кнопка Select позволяет прикрепить маршрут к созанному на предыдущем шаге PSTN Usage.

В результате на стенде было создано два маршрута, один отслеживал звонки +57xx и отправлял на Vodia, второй маршрут отправлял звонки +56xx на MX-One PBX.

5 Настройка транка 

Настройки транка:

В разделе Associated translation rule можно создать правила изменения исходящих и вызываемых номеров на выходе из Skype транка. Например можно указать правило по отношению к исходящим номерам, смысл которого удаление знака «+» у номеров. На самом деле в этом нет необходимости — Vodia примет звонки с номеров +55xx.

6 Настройка пользователей в Skype

Для пользователей необходимо включить функцию Enterprise Voice, назначить голосовую политику, так как она создана на пользователей и назначить номер телефона.

 

После того, как все настройки на Vodia и Skype будут выполнены, между пользователями двух систем можно выполнять аудио звонки. Единственный нюанс заключается в том, что Vodia в бесплатном режиме может осуществлять не более двух одновременных вызовов.

Exchange 2016 | Как я ставил обновления

Недавно столкнулся с проблемами обновления (СU5) сервера Exchange 2016 RTM + Windows 2016 (не R2!). Напоминаю, чтобы посмотреть текущую версию Exchange можно выполнив команду (Get-ExchangeServer | Format-List Name, Edition, AdminDisplayVersion). До того, как я начал разбираться в чем проблема обновление было запущено несколько раз, ошибки записаны не были, однако все логи в разделе «C:\ExchangeSetupLogs» были сохранены :).

Первые  два запуска закончились с ошибкой:

[ERROR] There isn’t enough disk space on the system drive to copy the Exchange Server setup files.

После того, как было добавлено доп. место на диске последовал третий запуск обновления, который так же завершился ошибкой:

[08.18.2017 13:06:05.0155] [1] [ERROR] Service ‘Microsoft Exchange Service Host (MSExchangeServiceHost)’ cannot be started due to the following error: Cannot start service MSExchangeServiceHost on computer ‘.’.
[08.18.2017 13:06:05.0155] [1] [ERROR] Cannot start service MSExchangeServiceHost on computer ‘.’.
[08.18.2017 13:06:05.0155] [1] [ERROR] The service cannot be started, either because it is disabled or because it has no enabled devices associated with it
[08.18.2017 13:06:05.0158] [1] [ERROR-REFERENCE] Id=BridgeheadRoleSetterComponent___115c1108e99e4560bd2c03c0fec99908 Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[08.18.2017 13:06:05.0191] [1] Setup is stopping now because of one or more critical errors.
[08.18.2017 13:06:05.0191] [1] Finished executing component tasks.

Далее, когда я начал изучение проблемы — следующий запуск завершился той же ошибкой, смысл которой в том, что после установки обновлений система не может запустить сервис «Microsoft Exchange Service Host (MSExchangeServiceHost)« в оснастке сервисов  -все сервисы Exchange были переведены в состояние Disabled. После перевода сервисов в автоматический запуск (Automatic) и повторного запуска обновлений стало ясно, что мастер обновления Exchange практически сразу после старта переводит все сервисы в состояние (Disabled), но в процессе обновления не может их запустить.

Из логов обновлений видно что скрипт выполняет следующие команды:

Executing:
if (get-service MSExchangeServiceHost* | where {$_.name -eq «MSExchangeServiceHost»})
{
restart-service MSExchangeServiceHost
}

Я не знаю, что это — ошибка разработчиков или другая ошибка, но команды перевода сервиса из Disabled в Automatic в скрипте нет, поэтому происходит остановка обновлений. Если посмотреть, на лог можно увидеть, что запуск некоторых сервисов осуществлялся по другому сценарию:

[08.18.2017 08:31:52.0477] [1] Executing:
if (Get-Service WinMgmt* | ?{$_.Name -eq ‘WinMgmt’})
{
Set-Service WinMgmt -StartupType Automatic
Start-SetupService -ServiceName WinMgmt
}

Чтобы решить эту проблему, я сделал задачу в Task Sheduler, которая каждую минуту запускает скрипт Poweshell:

Get-Service | where{$_.Name -Like ‘MSExchange*’} | set-Service -StartupType ‘automatic’

После этого шаг на котором останавливалось обновление был пройден, далее обновление остановилось со следующей ошибкой:

[08.22.2017 12:30:04.0164] [1] [ERROR] Couldn’t open package ‘F:\en\UMLanguagePack.en-US.msi’. This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package. Error code is 1619.
[08.22.2017 12:30:04.0164] [1] [ERROR] This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package
[08.22.2017 12:30:04.0165] [1] [ERROR-REFERENCE] Id=UmLanguagePackComponent___98c7f337c1334ef59c2ac59e52813c12 Component=EXCHANGE14:\Current\Release\Client Access\Unified Messaging

Я всегда запускаю обновления с локальных дисков, диска F:/ у меня не было ни локального, ни виртуального привода CD. Пришлось одному из дисков присвоить букву F:/.  Я думаю эта ошибка произошла из-за того, что мой коллега изначально запускал обновление с виртуального диска, а так как на сервере были диски C, D, E — этому диску присвоилось имя F:/. Возможно, что эту проблему решить можно было по другому..если кто-то будет читать и знает как — напишите пожалуйста в комментариях.

После этого была еще одна ошибка, которая остановила обновление:

[08.22.2017 15:52:06.0111] [1] [ERROR] Cannot find path ‘C:\Program Files\Microsoft\Exchange Server\V15\UnifiedMessaging\grammars’ because it does not exist.
[08.22.2017 15:52:06.0111] [1] [ERROR-REFERENCE] Id=UnifiedMessagingComponent___99d8be02cb8d413eafc6ff15e437e13d Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[08.22.2017 15:52:06.0111] [1] Setup is stopping now because of one or more critical errors.

Решением этой проблемы было ручное создание папки grammars в папке «C:\Program Files\Microsoft\Exchange Server\V15\UnifiedMessaging».

Так же при поиске решений проблемы было найдено несколько заметок, в котороых сообщалось о несовместимости CU 5 с NET.Framework 4.7:

• https://blogs.technet.microsoft.com/exchange/2017/06/13/net-framework-4-7-and-exchange-server/
• https://blogs.technet.microsoft.com/rmilne/2017/03/27/exchange-2013-cu16-and-exchange-2016-cu5-net-framework-requirement/

После всей этой истории я еще раз сделал выводы:

1. Все перед обновлением выполнять резервирование;
2. Потратить время на изучение проблем, которые могут воникнуть в результате обновления CU.
3. Запускать обновления с локальных дисков на сервере.
4. Создание тестового стенда макимально приближенного к промышленной среде и тестирование обновлений на нем.

Skype For Business | Call via Work

На сегодняшний день интеграция Remote Call Control, которая позволяла использовать телефоны PBX в одной связке с клиентом SFB — не поддерживается в Skype For Business 2015 (https://technet.microsoft.com/en-us/library/gg558658.aspx).

Что пришло на замену? Call via Work!.

Это функция SFB 2015 которая позволяет использовать клиент Skype For Business для управления (условно) телефонами PBX. Необходимо отметить, что функция работает только для исходящих вызовов. Чтобы задействовать стационарный телефон для входящих вызовов, необходимо в клиенте SFB указать в опции «Обработка звонков» ->»Одновременный звонок» и указать номер стационарного телефона.

Как это выглядит с точки зрения пользователя?

Пользователь в клиенте Skype For Business 2015 (далее по тексту клиент Skype) набирает номер вызываемого абонента и нажимает «Позвонить», сразу после этого звонит стационарный телефон на его рабочем месте. Пользователь снимает трубку и дозванивается до вызываемого абонента, при этом клиент Skype пользователя отображает информацию о том, что  звонок был переведен на другой телефон. Таким образом клиент Skype (как бы) управляет стационарным телефоном. В случае если вызываемый абонент так же является клиентом Skype — будет доступен чат, доски, общий экран (видео не будет доступно).

Как это выглядит с точки зрения сервера Skype For Business?

1. Клиент Skype (через Mediation сервер конечно же) выполняет звонок через SIP транк на стационарный телефон (далее по тексту Phone PBX).
2. Сотрудник поднимает трубку Phone PBX и SFB выполняет звонок конечному абоненту, объединяя Phone PBX и конечного абонента.

т.е. фактически SFB создает конференцию на несколько участников.

В этой схеме есть небольшой, но очень существенный нюанс :). Перед тем, как выполняется исходящий звонок PBX телефону, клиент Skype выполняет запрос XML к службе UCWA, работающий на сервере Skype For Business 2015 роль Front End. Поставив Fiddler можно посмотреть этот запрос и ответ от сервера:

В теле запроса передается следующая информация:

<input xmlns=»http://schemas.microsoft.com/rtc/2012/03/ucwa»&gt;

<property name=»importance»>Normal</property>

<property name=»operationId»>c243ebb6-77d1-fb44-aa6b-eac02a3567cd</property>

<property name=»phoneNumber»>tel:+5601</property> ##(номер на который необходимо переадресовать)

<property name=»subject»></property>

<property name=»threadId»>AdMJ5Av64evEZCFBQUWpJ5hJzLxhhg==</property>

<property name=»to»>+5505</property> номер конечного абонента

</input>

Для того, чтобы клиент Skype корректно выполнил запрос и получил ответ необходимо выполнить несколько условий.

1. Клиент Skype должен быть настроен на автоматический вход (проверить все необходимые записи в DNS и настройки клиента Skype в разделе «Личные»).
2. Как оказалось запросы к UCWA клиент отправляет используя внешний External Web Services.  Изначально у меня на стенде External Web Services отличался от Internal Web Services и так же не был настроен обратный проксирующий сервер. Поэтому сложилась ситуация, когда клиент Skype запрашивал External Web Services, а ответа не было. Для того, чтобы ситуацию разрешить необходимо развернуть обратный прокси и настроить DNS, так чтобы запросы клиентов  Skype к External Web Services  принимались обратным проксирующим сервером и далее проксировались на внешний  сайт IIS FE (который, напомню ожидает подключения на TCP 8080).

Для выполнения звонков между клиентами Skype и Phone PBX необходимо, чтобы между SFB и PBX был настроен SIP-транк. У меня на стенде в качестве PBX был Vodia PBX (1 год условно-бесплатная версия).

На всякий случай оставлю настройки SIP-транка:

Просто как напоминалка, как выглядят параметры External Web Services в Topology Builder

 

Настройка Skype For Business 2015 Call via Work

1 Указать глобальный номер (это номер который будет приходить от SFB на АТС в поле Caller ID, тем самым пользователь определяет, что выполняется звонок самому себе на телефон).

Set-CsRoutingConfiguration -CallViaWorkCallerId +1234

2 Создать политику Call via Work

New-CsCallViaWorkPolicy -Identity Tag:CvW -Enabled $true

3 Назначить пользователям политику, например если политика только одна можно назначить ее всем пользователям

Get-Csuser | Grant-CsCallViaWorkPolicy -PolicyName Tag:CvW

4 После этого через некоторое время необходимо выйти и зайти повторно в клиент Skype.

5  Пользователю Skype будут доступны переадресации исходящих звонков, где он самостоятельно устанавливает номер телеона (+5706) куда скайп будет звонить в первую очередь, еще раз — обычно это стационарный телефон PBX, который установлен на рабочем месте сотрудника:

Администратор в политике Call via Work может принудительно задать пользователю номер на который будет выполняться обратный вызовов с помощью параметра — UseAdminCallbackNumber.

Например:

New-CsCallViaWorkPolicy -Identity Tag:CvW -Enabled $true -AdminCallbackNumber +5508 -UseAdminCallbackNumber $true

После этого пользователь Skype сможет только включить или выключить Call via Work, изменение номера не будет доступно.

6 Для пользователей Skype For Business должны быть отключены делегирование, групповые звонки и группы ответов.

Следует обратить внимание на официальную страницу «Deploy Call Via Work in Skype for Business Server 2015 »  (https://technet.microsoft.com/en-us/library/dn933908.aspx).

В технете указано, что у пользователя Skype и PBX должны быть одинаковые номера. В конфигурации стенда на SFB у меня были номера 55xx, а на АТС 57xx. Для того, чтобы номера были одинаковые на SFB рекомендуется настроить (ms-skip-rnl) это позволит пропускать RNL для номеров Skype, чтобы все звонки передавать в транк.

Так же волнующий вопрос — в каком формате должны быть указаны номера абонентов Skype?  У меня они были указаны в формате внутреннего номера +XXXX.

Описание ограничений Call via Work указано в разделе «Plan for Call Via Work in Skype for Business Server 2015»  (https://technet.microsoft.com/en-us/library/dn951395.aspx)

Настройка инфраструктуры открытых ключей PKI 4

Настройка выдающего УЦ

Основные параметры УЦ:

• Имя УЦ: IssuingCA
• Алгоритм хэширования: SHA 256
• Срок действия сертификата УЦ: 5 лет
• Срок действия выпускаемых сертификатов: 1-4 лет
• Длина ключа: 2048
• Время жизни списков отзывов: 5 дней
• Операционная система Windows 2012 R2

Инсталляция роли

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Add-WindowsFeature Adcs-web-enrollment
Install-adcswebenrollment

Описание файла настроек УЦ

[Version]
Signature = «$Windows NT$»
OID = 2.5.29.32.0
[certsrv_server]
RenewalKeyLength = 2048
RenewalValidityPeriodUnits = 5
RenewalValidityPeriod = years
CRLPeriodUnits = 5
CRLPeriod = days
CRLOverlapUnits = 1
CRLOverlapPeriod = days
CRLDeltaPeriodUnits = 12
CRLDeltaPeriod = hours
AlternateSignatureAlgorithm = 0
LoadDefaultTemplates=0

Я хотел бы обратить внимание на этот параметр LoadDefaultTemplates=0 (удаляет по умолчанию шаблоны сертификатов из раздела Certificate Templates), раньше я не придавал должного значения этому параметру, так как рзаворачивал УЦ там где их не было впринципе или в тестовых средах. В этом проекте я столнулся с тем, что как только я развернул выдающий УЦ (без этого параметра) УЦ в течении часа автоматически выдал 400 сертификатов рабочим станциям и серверам. Честно признаться я не смог разобраться по какой причине. Политик Autoenrollment я найти не смог, какие сервисы запросили сертификаты по стандартным логам на рабочей станции тоже не смог определить. После этого я всегда включаю данный параметр, если разворачиваю УЦ в промышленной среде.

Инсталляция выдающего УЦ

Install-AdcsCertificationAuthority -CAType EnterpriseSubordinateCA -CACommonName «IssuingCA» -KeyLength 2048 -HashAlgorithm SHA256 -CryptoProviderName «RSA#Microsoft Software Key Storage Provider»

После того, как команда отработает создается файл запроса

Копируем файл ENT-CA.viktorp.club_IssuingCA.req на корневой УЦ.

На корневом УЦ выпустить сертификат

1 В оснастке Certification Authority из папки Administrative Tools.
2 Нажмите правой клавишей на названии сервера CA, далее All Tasks –> Submit new request.
3 В диалоговом окне укажите файл запроса, который был сгенерирован на этапе установки «IssuingCA», теперь запрос находится в очереди ожидания.
4 Перейдите в раздел Pending Requests, выделите нужный запрос, нажмите правой кнопкой и нажмите Issue.
5 Перейдите в раздел Issued certificates, откройте сертификат, перейдите на вкладку Details и там нажмите кнопку Copy to File и сохраните файл в папку C:\.

* После этого шага, впринципе корневой УЦ больше не понадобиться его можно выключить до момента обновления CRL или выпуска еще одного сертификата.

6 На выдающем сервере УЦ перейдите в раздел Certification Authority.

7 Нажмите правой клавишей на названии сервера CA, далее All Tasks –> Install CA Certificate и укажите скопированный сертификат.

8 Запустите CA.

9 Проверьте параметры сертификата.

10 настройка параметров CRL и AIA и дублирование параметров в файле CAPolicy

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force};
Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
Add-CACRLDistributionPoint -Uri http://crl.viktorp.club/crld/%3%8%9.crl -AddToCertificateCDP -AddToFreshestCrl -Force
Add-CACRLDistributionPoint -Uri file://\\crl.viktorp.club\pki\CRLD\%3%8%9.crl -PublishToServer -PublishDeltaToServer -Force
Add-CACRLDistributionPoint -Uri «ldap:///CN=%7%8,CN=%2,CN=CDP,CN=Public Key Services,CN=Services,%6%10» -AddToCrlCdp -AddToCertificateCdp
$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};
Add-CAAuthorityInformationAccess -AddToCertificateAia http://crl.viktorp.club/crld/%3%4.crt –Force
Add-CAAuthorityInformationAccess –AddToCertificateAia “ldap:///CN=%7,CN=AIA,CN=Public Key Services,CN=Services,%6%11”

certutil -setreg CA\ValidityPeriodUnits 4
certutil -setreg CA\ValidityPeriod «Years»

Параметр ValidityPeriodUnits 4 указывает, что максимальное время на которое могут быть выписаны сертификаты, насколько я помню по умолчанию 3 года.

Дублируем, то что было указано в файле CAPolicy

certutil -setreg CA\CRLPeriodUnits 5
certutil -setreg CA\CRLPeriod «Days»
certutil -setreg CA\CRLDeltaPeriodUnits 12
certutil -setreg CA\CRLDeltaPeriod «Hours»
certutil -setreg CA\CRLOverlapPeriod «Days»
certutil -setreg CA\CRLOverlapUnits 1

 Выполнить публикацию CRL в точки публикации, используя команду

certutil -crl

Осталось опубликовать сертификат, для этого необходимо:

1. Указать контекст конфигураци для сервера IssuingCA (корневой домен)

certutil -setreg CA\DSConfig «CN=Configuration,DC=viktorp,DC=club»

2. Опубликовать сертификат IssuingCA в AD

certutil -dspublish -f C:\{название_сертификата}.crt Subca
certutil -dspublish -f C:\{название_сертификата}.crt NTAuthCA

net stop certsvc && net start certsvc

 

Настройка инфраструктуры открытых ключей PKI 3

Настройка точек публикации CRL и цепочки сертификатов AIA

Идентичные настройки необходимо выполнить для двух серверах WEB1 и WEB2:

1. Установить IIS в стандартной комплектации

2. Установить DFS и NLB роли на серверы:

Install-WindowsFeature -Name FS-DFS-Namespace, FS-DFS-Replication, NLB -IncludeManagementTools

3. Настроить NLB

Настройку NLB описывать не буду, она очень простая. Есть нюансы при выборе Unicast и Multicast режимов работы кластера. Некоторые ссылки указаны ниже:

https://technet.microsoft.com/en-us/library/cc782694(v=ws.10).aspx

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006558

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1556

У меня был настроен Unicast с одним адаптером. Правило балансировки только для одного порта TCP 80.

В DNS вручную создана запись A (crl.viktorp.club= VIP NLB), которая указывает на общий виртуальный IP-адрес кластера NLB.

4 Настройка DFS на двух серверах:

На серверах WEB1 и WEB2 создать папку C:\CRLD, сделать ее общедоступной (Shared) и назначить локальным администратором полные права NTFS на папку.

В оснастке DFS Management создать Namespace с названием PKI и добавить два Namespace сервера.

Добавить новую папку с названием «CRLD» в которой добавляются два сервера WEB1 и WEB2 с локально, расположенными папками CRLD.

После создания папки CRLD автоматически запускается помощник настройки репликации в ходе которого необходимо указать два сервера репликации WEB1 и WEB2.

После этого можно создать тестовый файл в \\viktorp.club/pki/crld который будет доступен в папках CRLD на серверах WEB1 и WEB2.

6. Выполнить WEB публикацию содержимого папки CRLD с помощью IIS

Для настройки IIS необходимо создать сервисную учетную запись Domain User — svc-iisuser (не забываем отключать устаревание паролей для сервисных учетных записей).

На каждом из серверов WEB1 или WEB2 создать виртуальную дирректорию CRLD

В разделе Connect as.. указать, созданную учетную запись.

Включить на двух серверах Directory Browsing для CRLD и Double Escaping

На этом настройка web-серверов завершена, протестируйте доступность общей папки, репликацию файлов между серверами, их доступность через браузер. Не забывайте выполнить настройки проксирующих серверов для того, чтобы не было проблем с доступом до файлов ИОК.

Настройка инфраструктуры открытых ключей PKI 2

Настройка автономного корневого УЦ

 

Основные параметры УЦ:

• Имя УЦ: RootCA
• Алгоритм хэширования: SHA 256
• Срок действия сертификата УЦ: 10 лет
• Срок действия выпускаемых сертификатов: 5 лет
• Длина ключа: 2048
• Время жизни списков отзывов: 1 год
• Операционная система Windows 2012 R2

Инсталляция роли

Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools

Описание файла настроек УЦ

Файл CApolicy.inf следует поместить в C:\Windows до начала настройки роли Active Directory Certificate Services.

Содержание файла CApolicy.inf

[Version]
Signature=”$Windows NT$”
[Certsrv_Server]
RenewalKeyLength=2048
RenewalValidityPeriod=Years
RenewalValidityPeriodUnits=10
CRLPeriod=Years

CRLPeriodUnits=1
CRLDeltaPeriod=Days
CRLDeltaPeriodUnits=0
LoadDefaultTemplates=0
AlternateSignatureAlgorithm=0

Где:

CRLPeriodUnits — Время жизни CRL (период обновления CRL)

CRLDeltaPeriodUnits — Дельты CRL. в корневых УЦ не публикуются.

RenewalValidityPeriodUnits — Время жизни сертификата УЦ

Хочу отдельно выделить параметр «AlternateSignatureAlgorithm=0» в случае если его значение «1» тогда в качестве алгоритма цифровой подписи используется RSASSA-PSS. Проблема заключается в том, что данный алгоритм не поддерживается некоторыми аппаратными устройствами. В случае, если вы уже установили УЦ с использованием RSASSA-PSS, для того, чтобы переделать в SHA1 или SHA256 необходимо:

1 На корневом сервере выполнить команду:

certutil -setreg csp\alternatesignaturealgorithm 0
net stop certsvc && net start certsvc

2 Перевыписать сертификат корневого УЦ;

3 Повторить последовательность действий на всех подчиненных УЦ

Инсталляция УЦ

Install-AdcsCertificationAuthority -CAType StandaloneRootCA -KeyLength 2048 -HashAlgorithmName SHA256 -CACommonName «RootCA» -CryptoProviderName «RSA#Microsoft Software Key Storage Provider» -ValidityPeriod Years -ValidityPeriodUnits 10

Настройка параметров УЦ

#Период перекрытия списка отзывов. Время в течении которого новый CRL опубликован но старый еще валидный.

Certutil -setreg CA\CRLOverlapPeriodUnits 12

Certutil -setreg CA\CRLOverlapPeriod «Hours»

#Время в годах валидности выпускаемых сертификатов корневым УЦ

Certutil -setreg CA\ValidityPeriodUnits 5

Certutil -setreg CA\ValidityPeriod «Years»

#Настройка CRL публикаций

$crllist = Get-CACrlDistributionPoint; foreach ($crl in $crllist) {Remove-CACrlDistributionPoint $crl.uri -Force}; Add-CACRLDistributionPoint -Uri C:\Windows\System32\CertSrv\CertEnroll\VIKTORP-ROOTCA%8.crl -PublishToServer -Force

Add-CACRLDistributionPoint -Uri http://crl.viktorp.club/crld/VIKTORP-ROOTCA%8.crl -AddToCertificateCDP -Force

#Настройка AIA публикаций

$aialist = Get-CAAuthorityInformationAccess; foreach ($aia in $aialist) {Remove-CAAuthorityInformationAccess $aia.uri -Force};

Add-CAAuthorityInformationAccess -Uri http://crl.viktorp.club/crld/VIKTORP-ROOTCA%4.crt -AddToCertificateAia -Force

#Включение аудита событий УЦ

Certutil -setreg CA\AuditFilter 127

restart-service certsvc

#Публикация новых CRL

certutil -crl

#Переименование файлов CRL и CRT и публикация в Active Directory

Необходимо вручную переименовать файлы CRT и CRL и скопировать их на выдающий УЦ.

 

Процедуру публикации в Active Directory необходимо выполнять с правами Domain Admins и Enterprise Admins на сервере входящим в состав домена, например ENT-CA.

certutil –dspublish –f VIKTORP-ROOTCA.crt RootCA #Публикация к AIA контейнере

certutil –addstore –f root VIKTORP-ROOTCA.crt #Публикация в Certification Authorities Container контейнере

certutil –addstore –f root VIKTORP-ROOTCA.crl

 Справочник переменных

Variable	Extensions tab name	Description
%1	<ServerDNSName>	The DNS name for the CA computer. If connected to a DNS domain, it is the fully qualified domain name; otherwise, it is the hostname of the computer.
%2	<ServerShortName>	The NetBIOS name of the CA server
%3	<CaName>	The name of the CA
%4	<CertificateName>	This allows each additional revision of the certificate to have a unique suffix.
%4	None	Not used
%6	<ConfigurationContainer>	The location of the configuration container in Active Directory Domain Services (AD DS)
%7	<CATruncatedName>	The name of the CA truncated to 32 characters with a hash at the end
%8	<CRLNameSuffix>	This inserts a suffix on the file name when publishing a CRL to a file or URL location.
%9	<DeltaCRLAllowed>	When a delta CRL is published, this replaces the CRLNameSuffix variable with a separate suffix to distinguish the delta CRL from the CRL.
%10	<CDPObjectClass>	The object class identifier for CRL distribution points, which is used when publishing to an LDAP URL.
%11	<CAObjectClass>	The object class identifier for a CA, which is used when publishing to an LDAP URL.

Настройка инфраструктуры открытых ключей PKI 1

Краткое описание инфраструктуры открытых ключей

Настройка инфраструктуры открытых ключей 1 | Введение

Настройка инфраструктуры открытых ключей 2 | Корневой УЦ

Настройка инфраструктуры открытых ключей 3 | Точки публикации CRL и AIA

Настройка инфраструктуры открытых ключей 4 | Выдающий УЦ

  Ниже описан вариант настройки инфраструктуры открытых ключей (далее ИОК), который я использовал в промышленной среде в одной организации. В данных заметках отсутсвует описание процесса выбора архитектуры, только последовательность действий внедрения ИОК.

Задачей было внедрение ИОК на базе Windows 2012 R2 для возможностей аутентификации пользователей на веб-ресурсах и настройки SSL  для веб-сервисов.  Пользовательские сертификаты должны были назначаться пользователям в автоматическом режиме или от имени администратора ИОК. Для точек распространения CRL и AIA должна быть обеспечена отказоустойчивость. Отказоустойчивость серверов УЦ не обеспечивалась.

ИОК состоит из:

1. ROOT — Автономный корневой Удостоверяющий Центр (далее УЦ). Предназначен для выдачи сертификатов дочерним серверам УЦ.
2. ENT-PKI — выдающий УЦ. Используется для выдачи сертификатов конечным потребителям ИОК.
3. WEB1 — Веб-сервер. Предназначен для публикации списков отзывов и сертификатов УЦ (CRL и AIA точки распространения)
4. WEB2 — Веб-сервер. Выполняет те же функции, что и предыдщий сервер.

Безопасность хранения файлов сертификатов обеспечивалась за счет создания регулярных резервных копий и использования DFS. Безопасность веб-публикации обеспечивалась за счет создания двух узлового кластера NLB.

 

Exchange 2013 | Лицензирование

Серверные лицензии

Существует две редакции сервера Exchange:

Standard

Поддерживает от 1 до 5 баз данных неограниченного объема. Больше подходит для небольших организаций.

Enterprise

Поддерживает до 100 баз данных неограниченного объема.

После установки Exchange 2013 работает 180 дней с возможностями версии Standard, после 180 дней в EAC появляется предупреждение о необходимости лицензирования, при этом сам сервер Exchange функционирует.

Смена редакций

В случае смены версии Exchange с Standard на Enterprise необходимо ввести ключ от редакции Enterprise, переустановки сервера не требуется. Для смены версии с Enterprise на Standard необходимо переустановить сервер Exchange.

Ввод ключа

Set-ExchangeServer ExServer01 -ProductKey aaaaa-aaaaa-aaaaa-aaaaa-aaaaa

Проверка состояния лицензии

Get-ExchangeServer ExServer01 | Format-Table Edition,*Trial*

Клиентские лицензии

Клиентские лицензии приобретаются для каждого пользователя или устройства с которого будет производится подключение к Exchange. Клиентские лицензии бывают двух типов — Standard и Standard + Enterprise. Лицензия Enterprise приобретается в дополнении к лицензии Standard.

Возможности лицензий представлены в Таблице ниже.

Feature	Standard CAL	Standard plus Enterprise CAL*
Email, calendar, contacts, and tasks	Yes	Yes
Outlook Web App (Internet Explorer, Firefox, Chrome, and Safari support)	Yes	Yes
Rich Outlook inbox experience, including enhanced conversation view and MailTips	Yes	Yes
Apps for Outlook and Outlook Web App	Yes	Yes
Site mailboxes**	Yes	Yes
Role-based access control (RBAC) capabilities	Yes	Yes
Federated calendar sharing	Yes	Yes
Exchange ActiveSync mobile management policies	Standard	Advanced
Journaling	Per database	Per user/distribution list
Journal decryption	No	Yes
Unified Messaging	No	Yes
Retention policies	Default	Custom
In-Place Archive**	No	Yes
Multi-mailbox search	Yes	Yes
In-Place Hold	No	Yes
Data Loss Prevention (DLP)**	No	Yes
Information protection and control (IPC): transport protection rules, Outlook protection rules, Information Rights Management (IRM) search	No	Yes

 

Exchange 2013 | Требования

Требования для инфраструктуры

Active Directory

Schema Master

• Windows Server 2012 R2 Standard или Datacenter1

• Windows Server 2012 Standard или Datacenter
• Windows Server 2008 R2 Standard или Enterprise
• Windows Server 2008 R2 Datacenter RTM или более поздняя версия
• Windows Server 2008 Standard или Enterprise (32- или 64-разрядная)
• Окончательная первоначальная версия (RTM) Windows Server 2008 Datacenter или более поздняя версия
• Windows Server 2003 Standard Edition с пакетом обновления 2 (SP2) или более поздняя версия (32- или 64-разрядная)

• Windows Server 2003 Enterprise Edition с пакетом обновления 2 (SP2) или более поздняя версия (32- или 64-разрядная

Global Catalog

• Windows Server 2012 R2 Standard или Datacenter1
• Windows Server 2012 Standard или Datacenter
• Windows Server 2008 R2 Standard или Enterprise
• Windows Server 2008 R2 Datacenter RTM или более поздняя версия
• Windows Server 2008 Standard или Enterprise (32- или 64-разрядная)
• Окончательная первоначальная версия (RTM) Windows Server 2008 Datacenter или более поздняя версия
• Windows Server 2003 Standard Edition с пакетом обновления 2 (SP2) или более поздняя версия (32- или 64-разрядная)
• Windows Server 2003 Enterprise Edition с пакетом обновления 2 (SP2) или более поздняя версия (32- или 64-разрядная

Контроллер домена

Один контроллер домена в сайте, где размещен Exchange 2013:

• Windows Server 2012 R2 Standard или Datacenter1
• Windows Server 2012 Standard или Datacenter
• Windows Server 2008 R2 Standard или Enterprise с пакетом обновления 1 (SP1) или более поздняя версия
• Windows Server 2008 R2 Datacenter RTM или более поздняя версия
• Windows Server 2008 Standard или Enterprise с пакетом обновления 1 (SP1) или более поздняя версия (32- или 64-разрядная)
• Окончательная первоначальная версия (RTM) Windows Server 2008 Datacenter или более поздняя версия
• Windows Server 2003 Standard Edition с пакетом обновления 2 (SP2) или более поздняя версия (32- или 64-разрядная)
• Windows Server 2003 Enterprise Edition с пакетом обновления 2 (SP2) или более поздняя версия (32- или 64-разрядная)

Матрица совместимости Exchange с AD DS

Domain and forest functional level	Exchange 2013 SP1 and later	Exchange 2013 CU3	Exchange 2010 SP3 RU5 or later	Exchange 2010 SP2	Exchange 2007 SP3 RU13 or later
Windows Server 2003 domain functional level	X	X	X	X	X
Windows Server 2008 R2 SP1 domain functional level	X	X	X	X	X
Windows Server 2012 domain functional level	X	X	X	X	X
Windows Server 2012 R2 domain functional level	X		X
Windows Server 2003 forest functional level	X	X	X	X	X
Windows Server 2008 R2 SP1 forest functional level	X	X	X	X	X
Windows Server 2012 forest functional level	X	X	X	X	X
Windows Server 2012 R2 forest functional level	X		X

 

Operating system environment	Exchange 2013 SP1 and later	Exchange 2013 CU3	Exchange 2010 SP3 RU5 or later	Exchange 2010 SP2	Exchange 2007 SP3 RU13 or later
Windows Server 2003 SP1 Active Directory servers					X
Windows Server 2003 SP2 Active Directory servers	X	X	X	X	X
Windows Server 2008 SP2 Active Directory servers	X	X	X	X	X
Windows Server 2008 R2 SP1 Active Directory servers	X	X	X	X	X
Windows Server 2012 Active Directory servers	X	X	X	X	X
Windows Server 2012 R2 Active Directory servers	X	X	X		X

Совместимость с ролью AD DS

Exchange 2013 может быть установлен на контроллер домена (конфигурация не рекомендована по соображениям безопасности).

В случае если Exchange 2013 установлен на сервере, роль AD DS на этом сервере не возможно установить.

Поддерживаемые конфигурации DNS

Поддерживает следующие конфигурации DNS:

• Contiguous (Лес состоит из представлен деревом имен DNS, в котором соблюдена иерархия, например domain1.com и domain2.domain1.com).
• Noncontiguous (Лес состоит из нескольких деревьев DNS, например domain1.com и domain2.com в этом случае каждый домен должен использовать уникальное имя NETBIOS).
• Single label domains (Использование  DNS имени, где не соблюдается иерархия DNS, например domain1 или domain2).
• Disjoint (Когда на хостах основной DNS суффикс не совпадает с названием домена Active Directory к которому принадлежит хост, например основной суффикс хоста domain1.com а название домена, членом которого является хост — domain2.com).

Требования Exchange 2013 к серверам и операционным системам

Процессор

• x64 architecture-based computer with Intel processor that supports Intel 64 architecture (formerly known as Intel EM64T)
• AMD processor that supports the AMD64 platform
• Intel Itanium IA64 processors not supported

ОЗУ

• Mailbox   8GB minimum
• Client Access   4GB minimum
• Mailbox and Client Access combined   8GB minimum
• Edge Transport   4GB minimum

Файл-подкачки (для физических серверов)

Файл подкачки равен объему ОЗУ+10 Мб

Диск

Минимум 30 Гб для диска, куда будет установлен Exchange 2013

Операционная система

Инсталляция на версию «Core» не поддерживается.

Операционные системы для ролей Exchange:

• Windows Server 2012 R2 Standard or Datacenter1
• Windows Server 2012 Standard or Datacenter
• Windows Server 2008 R2 Standard with Service Pack 1 (SP1)
• Windows Server 2008 R2 Enterprise with Service Pack 1 (SP1)
• Windows Server 2008 R2 Datacenter RTM or later

Операционные системы для инструментов управления:

• Windows Server 2012 R2 Standard or Datacenter1
• Windows Server 2012 Standard or Datacenter
• Windows Server 2008 R2 Standard with SP1
• Windows Server 2008 R2 Enterprise with SP1
• Windows Server 2008 R2 Datacenter RTM or later
• 64-bit edition of Windows 8.12
• 64-bit edition of Windows 8
• 64-bit edition of Windows 7 with Service Pack 1

Operating system platform	Exchange 2013 SP1 and later	Exchange 2013 CU3	Exchange 2010 SP3	Exchange 2010 SP2	Exchange 2007 SP3
Windows Vista SP2			X1	X1	X1
Windows Server 2003 SP2					X
Windows Server 2003 R2 SP2					X
Windows Server 2008 SP2			X	X	X
Windows Server 2008 R2 SP1	X	X	X	X	X
Windows 7 SP1	X1	X1	X1	X1	X1
Windows 8	X1	X1	X1
Windows 8.1	X1
Windows Server 2012	X	X	X
Windows Server 2012 R2	X

X1- Только для средств управления.

Клиенты

• Outlook 2013 (15.0.4420.1017)
• Outlook 2010 Service Pack 1 with the Outlook 2010 November 2012 update (14.0.6126.5000). For more information, see Description of the Outlook 2010 update: November 13, 2012.
• Outlook 2007 Service Pack 3 with the Outlook 2007 November 2012 update (12.0.6665.5000). For more information, see Description of the Outlook 2007 update: November 13, 2012.
• Entourage 2008 for Mac, Web Services Edition
• Outlook for Mac 2011

Клиенты версии меньше чем Outlook 2007, Entourage 2008 для Mac RTM и Entourage 2004 не поддерживаются.