03 августа 2018

Гибридный домен и Exchange на Windows Server 2016 и Office365

Вдруг кому пригодится. Нужно было развернуть домен и почтовик, привязать внешний домен к облаку и домену, авторизовывать в облаке через наш сервис, связать Exchange с облаками.
Приветствуются замечания и дополнения в коментариях =)


Внутренний домен: domain.local
Внешний домен: domain.com
DNS-имена:  adds, adfs, exchange, wap
Имя tenant: domaincomtest

1. Установить 4 ВМ с Windows Server 2016 - ADDS (контроллер домена, DNS primary, Certification authority ADCS), ADFS (ADFS, Azure Sync), Exchange (Exchange 2016 CU10), WAP (Web application proxy, DNS relay).
Для ADDS, ADFS и WAP достаточно 8GB RAM/60GB HDD. Для Exchange - 10GB RAM, 100GB HDD.
Также, для ВМ ADFS, Exchange и WAP добавить вторую сетевую карту выходящую в сеть с интернет-шлюзом и прописать статические адреса (для проброса портов).
1.1. При установке ролей на ADDS сначала добавить ADDS, настроить домен и только потом добавить ADCS, плюс добавить дополнительные службы к CA - Certificate Enrollment Policy Web Service, Certificate Enrollment Web Service, Certification Authority Web Enrollment. Они позволят выпускать сертификаты через вебстраницу.
ADCS настроить как Enterprise CA+Root CA. После установки CA нужно перезапустить остальные ВМ, т.к. там не будет корневого сертификата нашего УЦ.

2. Дать имена машинам ADDS, ADFS, Exchange и WAP соответственно. Создать внутренний домен на ADDS с любым именем, но желательно то, которое не резолвится внешними DNS. Ввести ADFS и Exchange в домен, но WAP не нужно (рекомендация MS). На шлюзе, через который выходят ADFS, Exchange и WAP нужно пробросить 443 tcp-порт до WAP, а также 25, 110, 143, 587, 993 и 995 tcp-порты до Exchange.

3. На ADDS настроить DNS чтобы он использовал Forwarder = IP WAP во внутренней сети. Соответственно, на WAP настроить DNS на использование Forwarder = IP шлюза или любой внешний DNS-сервер. Также необходимо на ADDS, ADFS и Exchange в настройках сетевой карты указать DNS = IP ADDS. Все сервера смогут резолвить как внутренний домен, так и внешние адреса.
3.1. Зарегистрировать внешний домен или иметь доступ к его DNS-зоне для изменения. Необходимо для резолва сервисов из интернета и связки с Office365.
3.2. Добавить в DNS авторитативную Primary-зону (Forward Lookup Zones) с внешним доменом, без динамического обновления (Do not allow dynamic updates). Добавить туда 4 A-записи для серверов с внутренними адресами. Это позволит настроить сервисы на внешний домен и обращаться к ним локально по тому же имени и по локальным адресам.
3.3. В консоли Active Directory Domains and Trusts выбрать в дереве слева самый верхний пункт, Properties. Добавить UPN-суффикс = внешнему домену, чтобы пользователи могли заходить не только под внутренним.
3.4. В консоли Active Directory Users and Computers добавить 2 пользователей user1 и user2, выбрав внешний домен (вместо внутреннего). Там же добавим группу безопасности office365, в которую включим этих 2 пользователей - она будет использоваться для фильтрации при синхронизации учётных записей с Office365.

4. Генерируем сертификаты и закрытые ключи для ADDS, ADFS и Exchange. Т.к. мы установили CA на ADDS, то алгоритм для всех следующий:
 - открываем Microsoft Management Console (mmc), добавляем оснастку (File, Add/Remove Snap-in) Certificates (тип Computer account). Сохраним на рабочий стол на будущее.
 - открываем раздел Personal, правой кнопкой выбираем All tasks, Advanced operations, Create custom request
 - доходим до раздела где выбирается шаблон запроса (Template) и выбираем Web Server, далее на странице Certificate Information клацаем по Details, далее Properties.
 - Вкладка Subject, Subject name, Type выбираем Common name и вбиваем FQDN внешнего адреса сервера (например adds.domain.com), жмём справа Add >, ниже в Alternative name выбираем тип DNS и делаем тоже самое.
 - Вкладка General вбиваем Friendly name и Description - описательные характеристики. Можно вбить в первый полный FQDN, во второй описание. Текст может быть любой.
 - Вкладка Private Key, выбрать раздел Cryptographic Service Provider и оставляем только Microsoft RSA SChannel Cryptographic Provider (Encryption). Ниже выбрать раздел Key options и выбрать длину ключа, а также признак экспортируемости приватного ключа (нужно для ADFS и Exchange).
 - Жмём OK, Next. Выбираем в какой файл сохранить запрос.
 - Открываем этот файл блокнотом и копируем в буфер обмена.
 - Открываем веб-страницу выпуска сертификатов http://<ip adds>/certsrv
Браузер будет ругаться на неверный сертификат, это норм, т.к. CA поставил свой сертификат на весь IIS, частью которого является /certsrv. Вбиваем креды доменного админа, выбираем Request a certificate, далее advanced certificate request. В первое поле вставляем содержимое буфера, ниже выбираем Web server и жмём Submit. Выбираем "Base 64 encoded" и жмём Download certificate. Мы получили файл сертификата от удостоверяющего центра. Далее импортируем его в оснастку MMC в раздел Computer account/Personal (All tasks, Import...), next next finish =)
 - Для серверов ADFS и Exchange теперь ещё необходимо экспортировать комбинированный ключ (сертификат + закрытый ключ) который появился в списке. All tasks, Export, Next. Укажем что нужно экспортировать с закрытым ключом, Next. Зададим пароль на комбинированный ключ (ибо если его взломают, то компрометируются все службы завязанные на нём), сохраняем ключ.

4.1. Обновим сертификат на IIS на сервере ADDS чтобы не ругались браузеры при открытии /certsrv. Открываем Internet Information Services (IIS) Manager. Слева в дереве выбираем ADDS, Sites, Default Web Site. В правой колонке клацаем Bindings..., выбираем строку с https, Edit и выставляем вновь сгенерированный сертификат для этого сервера.

5. Установка и настройка Exchange 2016 CU10. Потребуется .NET 4.7, MS UCM API 4.0 и VC 2013 (предупредит сам при начале установки). Установить Mailbox-роль.
Откроем панель управления https://localhost/ecp. Игнорируем ругань на сертификат.
Servers, servers, выбрать Exchange, редактировать, Outlook Anywhere. Вбить внешнее FQDN-имя Exchange (например exchange.domain.com). Save.
Далее откроем вкладку Virtual directories. Нажать значок гаечного ключа (Configure external access domain), выбрать сервер EXCHANGE и вбить exchange.domain.com. Тем самым мы пропишем для всех директорий этот внешний адрес.
Откроем вкладку Certificates. Если правильно сделали и установили сертификат для Exchange, то он отобразится в списке. Выбираем его и жмём значок карандаша (Edit), выбираем слева Services и отмечаем SMTP, IMAP, POP и IIS. Страница зависнет и перестанет отвечать, это норма т.к. мы сменили сертификат и внешнее имя =) Открываем теперь уже адрес https://exchange.domain.com/ecp. Заходим снова в Certificates и убеждаемся что наш сертификат теперь завязан на IMAP, POP, IIS и SMTP.
Настроим хождение почты. Слева выбираем Mail flow, справа Accepted domains. Жмём значок плюс и добавляем наш внешний домен (domain.com). Домен типа Authoritative. Save. Откроем его на редактирование (значок карандаша Edit) и поставим галку в самом низу Make this the default domain. Save. Открываем вкладку Email address policies, там будет одна строчка, жмём редактировать. Слева выбираем Email address format, значок плюс. В самом верху в комбобоксе будет уже по-умолчанию наш внешний домен, в самом низу отметить галку Make this format the reply email address. Save. Справа нажать Apply.
Добавим ящики нашим пользователям. Вверху вкладка Entriprise, слева Recipients, Mailboxes.

6. Настройка ADFS. После установки роли ADFS, откроем её пост-установочную настройку.
Прежде всего, выполним в консоли Powershell команду:

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Это позволит нам создать GMSA-учётную запись далее.
Выбираем Create the first federation server in a federation server farm, Next, Next. В комбобоксе SSL Certificate выбираем ранее сгенерированный сертификат, в поле Federation Service Name автоматически вставится Common Name из этого сертификата. Ниже нужно ввести отображаемое имя ADFS (любой текст), которое будет выводится на странице с авторизацией. Next. Теперь нужно создать учётную запись для GMSA - выбираем пункт Create a Group Managed Service Account и вводим любое имя (например GMSA). Next. Выбираем тип базы данных для ADFS как простой (Create a database on this server using Windows Internal Database), т.к. у нас всего 1 сервер для ADFS (простая база поддерживает до 10 серверов, если больше требуется внешняя MSSQL-база). После завершения пост-настройки нужно перезагрузить ВМ ADFS.

6.1. Открываем консоль ADFS, слева в дереве выбираем AD FS, Service, Certificates. В появившемся списке справа выбираем сертификат отвечающий за подписывание токенов безопасности (Token-signing) и кликаем 2 раза. Откроется сертификат, вкладка Details, кнопка Copy to File... и сохраняем его в файл (формат Base-64 encoded X.509). Он нам понадобится на этапе настройки Exchange.

6.2. Создадим 3 отношения доверия для делегирования авторизации сервисов от Exchange к ADFS для OWA, ECP и ActiveSync. Слева в дереве выбираем Relying Party Trusts, справа Add Relying Party Trust...
Выбираем Claims aware, Start, Enter data about the relying party manually, Next.
Вводим название отношения OWA. Next, Next. Выбираем Enable support for ther WS-Federation Passive protocol и ниже вбиваем полный https-путь до сервиса OWA, например: https://exchange.domain.com/owa/
Next. На странице с идентификацией в списке с идентификаторами должна быть только что введённая строка ранее, если нет добавляем. Next. Выбираем политику доступа (Choose an access control policy), для начала хватит пока Permit everyone. Next. Тут будет выведен суммарный итог создаваемого правила, Next. Оставим галку у пункта "Configure claims issuance policy for this application". Close.
Появится новое окно "Edit Claim Issuance Policy for OWA", в котором надо добавить 3 правила (авторизация по SID пользователя, по SID группы пользователя и по UPN). Жмём Add Rule..., выбираем в комбобоксе "Send Claims Using a Custom Rule", Next. В поле имени правила вбиваем "ActiveDirectoryUserSID", в поле самого правила следующий текст:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
    => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = ";objectSID;{0}", param = c.Value);

OK. Повторяем для групового SID: имя правила "ActiveDirectoryGroupSID", само правило:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
    => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid"), query = ";tokenGroups(SID);{0}", param = c.Value);

OK. Повторим для UPN: имя правила "ActiveDirectoryUPN", само правило:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
    => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);

ОК. Повторим аналогично для ECP, идентификатор будет https://exchange.domain.com/ecp/
Для правила ActiveSync нужно выбрать "Non claims aware", добавить идентификатор "https://exchange.domain.com/Microsoft-Server-ActiveSync/", политика доступа "Permit everyone".

7. Настройка WAP.
Импортируем 2 сертификата с закрытыми ключами (ADFS и Exchange) в Personal хранилище. При этом будет импортирован корневой сертификат с УЦ ADDS, который надо перенести в Trusted Root Certification Authorities.
Откроем на ВМ WAP постустановочный визард настройки роли Web Application Proxy.
Вбиваем в поле "Federation service name" FQDN нашего ADFS - adfs.domain.com, ниже вбиваем креды учётной записи локального администратора на ВМ ADFS. Next.
В комбобоксе выберем сертификат ADFS. Next. Configure.
Откроется консоль Remote Access Management Console. Опубликуем 4 сервиса (ADFS, OWA, ECP и ActiveSync) для доступа извне к ним.
Справа выберем Publish. Сделаем правило публикации для ADFS, к которому будут перенаправляться запросы на авторизацию. Выберем метод предавторизации "Pass-through", т.к. ADFS сам авторизатор. В поле Name вбить название правила (например ADFS, нельзя использовать символ "/" в этом поле). В поле "External URL" ввести внешний адрес сервиса (например https://adfs.domain.com/". Выбрать внешний сертификат от ADFS (в нашем случае внешний сертификат будет совпадать со внутренним). Поле "Backend server URL" будет заполнено автоматически на основании поля "External URL". Next, Publish.
Добавим правила для OWA: Publish, тип предавторизации Active Directory Federation Services (AD FS). В появившемся списке "Select the AD FS relying party for this application" выберем ранее созданное правило для OWA. Next. Аналогично, вбиваем название правила (например OWA), внешний адрес (например https://exchange.domain.com/owa/) и сертификат от Exchange.
Аналогично для ECP. Для ActiveSync тип предавторизации будет HTTP Basic.
Также желательно добавить публикации для других сервисов Exchange: OAB, Autodiscover, MAPI, EWS, RPC - у них будет предавторизация типа "Pass-through".

7.1. Настройка Exchange для делегирования авторизации ADFS
Откроем консоль сертификатов и добавим в Trusted Root Certification Authorities signing-сертификат с ADFS взятый ранее.
Открываем Exchange Management Shell на ВМ Exchange.
Выполняем следующие команды:

$cert = (Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object {$_.Subject -match "ADFS Signing"}).Thumbprint;
$uris = @(" https://exchange.domain.com/owa/","https://exchange.domain.com/ecp/")
$adfs= "https://adfs.domain.com/adfs/ls/"
Set-OrganizationConfig -AdfsIssuer $adfs -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint $cert
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
Restart-Service W3SVC,WAS -Force

Проверим: https://exchange.domain.com/ecp должен перекинуть на страницу авторизации ADFS, либо предложить Windows-авторизацию если открывать в Internet Explorer.

8. Регистрируем новый домен с именем которое будем использовать при настройке всех продуктов. В данном случае подразумевается что имя домена "domain.com". Можно использовать Freenom для бесплатной регистрации. Обязательно прописать 2 A-записи: adfs и exchange с привязкой к внешнему адресу (там будет отвечать WAP и перенаправлять к соответствующим сервисам).

9. Регистрируемся на пробный период продукт Office365 корпоративный E3 (или любой другой где есть Exchange Online). На домашней странице выбираем Администрирование. В новом окне слева выберем Установка, Домены, Добавить домен. Ввести имя домена (в нашем случае domain.com).
Потребуется подтвердить управляемость доменом добавлением TXT-записи (или MX) в DNS-зону домена. Далее надо добавить ещё несколько записей в DNS-зону для служб, выбрать "Я буду самостоятельно управлять своими записями DNS", выбрать только Exchange. Добавить MX, CNAME autodiscover, TXT SPF.
Сохраним имя и пароль основной учётной записи, она пригодится далее.

10. Установка и настройка Azure AD Connect на ВМ ADFS. После установки, выбираем Customize вместо Use express settings и клацаем Install. После установки (часть 2), появится собственно окно с настройками (раздел User Sign-in). Выбираем тип входа "Federation with AD FS", Next. Вводим учётные данные Azure AD (из предыдущего пункта - основная учётка Office365), Next. Присоединяем дерево AD - нажать кнопку Add Directory. Нам предложат создать учётную запись для синхронизации учёток с Office365, выберем Create new AD account и введём реквизиты доменного администратора. Next. Нам выведут список всех локальных доменов. Т.к. мы уже добавили UPN-суффикс для domain.com, а также добавили его в Office365, то он будет со статусом Verified. Домен domain.local будет со статусом Not Added. Клацаем по чекбоксу "Continue without any verified domains", Next.
Здесь нужно выбрать часть дерева из домена, записи из которого будут синхронизированы. Выбираем "Sync selected domains and OUs" и ниже в дереве домена оставляем только Users. Next, Next.
Здесь нужно выбрать группу пользователей для синхронизации. Выбираем "Synchronize selected", в поле GROUP ввести office365 (группа безопасности, которую создали в п. 3.4), жмём Resolve и получаем DN этой группы. Next.
Зададим дополнительные опции - "Exchange hybrid deployment", "Password hash synchronization". Next.
Вводим ещё раз реквизиты доменного администратора, Next.
На этом этапе обнаружится наш настроенный ADFS, просто жмём Next.
В комбобоксе выбираем домен для федерации, т.е. domain.com. Next. Install. Next.
В конце будет тестирование доступности ADFS изнутри и снаружи по доменному имени, нужно чтобы работало =)

11. Гибридизируем Exchange. Открываем Администрирование в профиле на Office365. Установка, Миграция данных, Exchange. Будет предложено скачать и запустить Microsoft Office 365 Hybrid Configuration Wizard.
Далее в нём, Next. Будет обнаружен наш Exchange сервер, Next. Нажать Sign-in и войти в Office365, Next, Next. Выбираем Full Hybrid Configuration, Next. Будет предложено создать федеративное доверие, соглашаемся.
Далее нужно будет добавить в DNS-зону ещё одну TXT-запись подтверждающее владение доменом. Подтверждаем.
Далее уточняется нужно ли добавлять Edge-роль в конфигурацию, у нас её нет, поэтому оставляем как есть (Configure my Client Access and Mailbox servers for secure mail transport (typical)). Next.
Далее будет настройка приёмных конекторов (Receive Connector Configuration) - просто выбрать наш Exchange сервер для установки. Next. Аналогично для конекторов отправки (Send connector). Next.
Выберем транспортный сертификат при коммуникации Exchange<->Office365. В идеале нужен сертификат подписанный доверенными издателями, т.к. Microsoft будет его проверять в созданных коннекторах. Но можно обойтись и тем что выпустил наш издатель (УЦ) на ADDS, только необходимо будет поправить далее одну вещь. Next. Вводим FQDN внешнего адреса exchange - exchange.domain.com. Next. И финальный Update.
Откроем ECP и настроим созданные конекторы. Вверху выбрать Enterprise, слева Mail flow, Send Connectors. Визард создал конектор для отсылки почты через Exchange Online Protection (EOP), но только для основного домена <имя tenant>.mail.onmicrosoft.com. Необходимо создать конектор для всех остальных доменов, на которые будет слаться почта, чтобы отправлялась тоже через EOP.
Жмём значок плюс, вводим название для конектора (любое, например "Send all via Office365 relay"), тип Custom. Next. Выбираем Route mail through smart hosts и добавляем (значок плюс) хост <имя tenant>.mail.onmicrosoft.com. Next. Тип авторизации None. Next. Добавляем адресное пространство: тип SMTP, FQDN *, вес 1. Save, Next. Выбираем наш Exchange-сервер, Finish.

Теперь нужно поправить конекторы созданные в Office365. Вверху выбираем вкладку Office 365, слева Mail flow, Connectors. Выбираем правило "Inbound from ..." и редактируем, Next. Меняем тип идентификации с сертификата на проверку по IP. Добавляем внешний IP-адрес с которого выходит Exchange. Next, Save. Выбираем правило "Outbound to ...", редактирование. Next, Next, Next. На вопрос как соединяться между Office365 и нашим Exchange выбираем "Any digital certificate, including self-signed certificates". Next. Нужно добавить почтовый адрес в нашем домене, на который будет отослано тестовое письмо. Этот адрес должен быть уже синхронизирован с Office365 и на пользователя должна быть назначена лицензия. Возьмём адрес user1@domain.com. После успешной проверки - Save.

Комментариев нет:

Отправить комментарий