Настройка kerberos windows 2019

Featured

Картинка с сайта: alexitblog.ru

В этой статье рассмотрим настройку Kerberos в SharePoint Server 2019.

Стенд
Для наглядности создадим новое Web – приложение https://krbtst.alexitsolutions.com и сервисную учетную запись, под которой наше Web – приложение будет открываться – sp_web. В данной статье мы не рассматриваем настройку SPN — записей для MSSQL Server, поскольку предполагаем, что они уже настроены.

Создание SPN
На данном этапе создадим SPN для нашей сервисной учетной записи:
1.    Открываем PowerShell или CMD с правами администратора;
2.    Регистрируем SPN типа HTTP/krbtst alexitsolutions\sp_web и HTTP/krbtst.alexitsolutions.com alexitsolutions\sp_web:

Картинка с сайта: alexitblog.ru

Для этого можно воспользоваться следующими командами:

setspn -s HTTP/krbtst alexitsolutions\sp_web
setspn -s HTTP/krbtst.alexitsolutions.com alexitsolutions\sp_web

Настройка делегирования
Теперь настроим делегирование в Active Directory:
1.    Идем Active Directory Users and Computers и находим нашу сервисную учетную запись;
2.    Далее, переходим в свойства:

3.    Идем на вкладку Delegation:

Картинка с сайта: alexitblog.ru

Здесь выбираем Trust this user for delegation to specified services only и выбираем Use any authentication protocol. Затем нажимаем Add;
4.    В открывшемся окне Add Services нажимаем Users or Computers и в стандартном окне поиска вводим нашу сервисную учетку:

После чего у нас в Available services должна появиться соответствующая информация. Выделяем ее и нажимаем OK;
5.    Мы снова возвращаемся на вкладку Delegations:

Картинка с сайта: alexitblog.ru

Здесь ставим галочку Expanded, обращаем внимание, что у нас уже появились сервисы и нажимаем OK.

Настройка Web – приложения SharePoint Server 2019
Теперь осталось только внести настройки в само приложение:
1.    Открываем CA и дальше идем по пути Application Management – Manage web applications – выбираем наше Web – приложение и нажимаем на Authentication Providers:

Картинка с сайта: alexitblog.ru

2.    Выбираем зону (в нашем случае это Default):

И в разделе Claims Authentication Types выбираем Negotiate (Kerberos):

Картинка с сайта: alexitblog.ru

И нажимаем Save.

Проверка
Теперь зайдем с клиентской станции и выполним проверку. Но, для начала, нужно добавить сайт в Local Intranet. После добавления сайта – открываем браузер и переходим по нашей ссылке:

Картинка с сайта: alexitblog.ru

Если у нас все настроено правильно, то не потребуется ввод логина/пароля. Для проверки, что мы получили билет – идем в командную строку и вводим команду klist:

Картинка с сайта: alexitblog.ru

На данном этапе можно считать, что Kerberos у нас настроен.

Картинка с сайта: habr.com

Конечная цель проектов импортозамещения в ИТ — полный отказ от операционной системы Windows. Но, как говорится, гладко было на бумаге, да забыли про овраги. Может так оказаться, что быстро заменить какие-то клиентские корпоративные приложения, написанные под эту операционную систему, не получится. В этом случае вам может пригодиться возможность присоединения Windows-компьютеров к домену ALD Pro.

В этой статье я расскажу, как добиться максимальной функциональности от такого сценария развертывания, и презентую утилиту нашей собственной разработки aldpro-join. С ее помощью можно решить проблему настройки рабочих станций всего за пару кликов. Если это именно то, о чем вы хотели узнать, но не знали, кого спросить, — вы на правильном пути. Поехали!

Материал будет полезен даже в том случае, если в вашей инфраструктуре пока еще используется «ванильная» система FreeIPA.

Присоединение Windows клиентов к домену FreeIPA не находится в фокусе внимания команды разработчиков этой службы каталога, так как проект ставит своей целью не заменить Active Directory для Windows-компьютеров, а создать аналогичное решение для компьютеров под управлением операционной системы Linux. Однако компания Microsoft еще с версии Windows 2000 поддерживает возможность интеграции своих ОС с областями Kerberos, которые совместимы с RFC 2136, а центр распределения ключей FreeIPA работает как раз на базе эталонной реализации MIT KDC. То есть ничто не препятствует тому, чтобы вводить Windows-компьютеры напрямую в домен FreeIPA.

Более того, разработчики FreeIPA реализовали возможность интеграции своего домена с Active Directory на уровне доверительных отношений за счет компонента Samba AD, поэтому контроллеры домена, помимо Kerberos, поддерживают такие протоколы, как NetBIOS, SMB, Netlogon (MS-NRPC) и NTLM. В базе данных DNS есть SRV записи по стандартам Microsoft, а Kerberos-билеты содержат не только аутентификационные данные, но и сертификат PAC, включающий SID’ы пользователя и всех его групп.

Все эти особенности открывают дополнительные возможности по работе Windows-компьютеров в составе домена FreeIPA. Ниже я расскажу, как правильно задействовать эти отличительные черты, чтобы получить доступ к следующим функциям:

• вход в ОС Windows с помощью учетных записей из домена ALD Pro;

• прозрачная аутентификация при обращении пользователя к керберизированным ресурсам, например файловым серверам;

• получение уведомлений об истечении срока действия пароля и возможность сменить пароль штатными функциями ОС Windows;

• предоставление доменным пользователям прав доступа к локальным ресурсам Windows-компьютера с учетом их участия в доменных группах;

• синхронизация времени рабочей станции с временем на контроллерах домена;

• динамическое изменение DNS-записей в домене при изменении IP-адреса на сетевом интерфейсе Windows-компьютера.

1. Настройка Kerberos-аутентификации

Компьютеру для работы в составе домена требуется учетная запись, с помощью которой он будет выполнять авторизованные LDAP-запросы к каталогу и проверять аутентичность пользователей по протоколу Kerberos V5.

Создать эту учетную запись можно на контроллере с помощью команды host-add утилиты ipa, в параметрах которой нужно указать полное доменное имя компьютера и его IP-адрес. Перед выполнением команды нужно произвести Kerberos-аутентификацию привилегированной учетной записью администратора.

Обратите внимание, что служба каталога FreeIPA автоматически приведет доменное имя компьютера к нижнему регистру.

admin@dc-1:~$ kinit admin
admin@dc-1:~$ ipa host-add DESKTOP-7VKREUO.ald.company.lan --ip-address=10.0.1.151
-----------------------------------------------
Добавлен узел "desktop-7vkreuo.ald.company.lan"
-----------------------------------------------
  Имя узла: desktop-7vkreuo.ald.company.lan
  Имя учётной записи: host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN
  Псевдоним учётной записи: host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN
  Link to department: ou=ald.company.lan,cn=orgunits,cn=accounts,dc=ald,dc=company,dc=lan
  Link to head department: ald.company.lan
  Пароль: False
  Таблица ключей: False
  Managed by: desktop-7vkreuo.ald.company.lan

Чтобы использовать новую учетную запись, ей нужно назначить пароль. Сделать это можно с помощью утилиты ipa-getkeytab, которая создаст необходимые Kerberos-ключи, запишет их в атрибут krbPrincipalKey учетной записи и сохранит в указанный keytab-файл.

admin@dc-1:~$ sudo ipa-getkeytab -p host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN \
-P -k /tmp/client.keytab << EOF
Windows10ComputerPassword
Windows10ComputerPassword
EOF

Новый пароль учётной записи: 
Проверка пароля учётной записи: 
Таблица ключей успешно получена и сохранена в: /tmp/client.keytab

где:

• p — указывает имя Kerberos-принципала, для которого будет сгенерирована связка ключей. Его можно взять из предыдущего шага в текстовом выводе команды host-add.

• P — указывает, что пароль учетной записи должен быть задан вручную с помощью интерактивного ввода. Если этот параметр не будет задан, то система сгенерирует пароль автоматически, но не отобразит его на экране. Поэтому такой способ подходит только в случае, если мы планируем использовать keytab-файл.

• k — указывает путь к keytab-файлу, в который нужно сохранить Kerberos-ключи. Параметр является обязательным — невозможно назначить пароль без создания keytab-файла.

• << EOF … EOF — позволяет перенаправить следующие две строки в качестве пароля и подтверждения. Не забудьте отключить занесение команды в history, например добавив символ пробела перед командой sudo.

Дополнительно можно воспользоваться следующими параметрами:

• s — задает fqdn имя контроллера домена, через который следует выполнить установку пароля. По умолчанию используются настройки из /etc/ipa/default.conf.

• e — задает через запятую способы хеширования паролей. В крайних версиях FreeIPA утилита ipa-getkeytab использует ключи AES256-CTS-HMAC-SHA1-96 и AES128-CTS-HMAC-SHA1-96, совместимые с современными дистрибутивами ОС Microsoft, включая Windows 10. Поэтому задавать параметр не требуется. Полный перечень хешей, поддерживаемых FreeIPA, можно посмотреть командой «ipa-getkeytab —permitted-enctypes». Для Windows это можно узнать в справке к утилите ksetup командой «ksetup.exe /?».

При желании вы можете проверить содержимое keytab-файла с помощью утилиты klist:

admin@dc-1:~$ sudo klist -ket /tmp/client.keytab 
Keytab name: FILE:/tmp/client.keytab
KVNO Timestamp           Principal
---- ------------------- ------------------------------------------------------
   1 19.11.2023 16:05:15 host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN (aes256-cts-hmac-sha1-96) 
   1 19.11.2023 16:05:15 host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN (aes128-cts-hmac-sha1-96)

Но сам keytab-файл нам не потребуется, потому что утилите ksetup.exe пароль нужно будет передать открытым текстом. Используя это значение, утилита сгенерирует несколько хешей, не совместимых с Kerberos, таких как NTLM и SHA1, и сохранит пароль «как есть» в менеджере учетных записей безопасности (Security Accounts Manager, SAM). С помощью утилиты Mimikatz можно убедиться, что Windows хранит пароль компьютера в том числе и открытым текстом.

mimikatz # sekurlsa::logonpasswords
...
Authentication Id : 0 ; 2053055 (00000000:001f53bf)
Session           : Interactive from 2
User Name         : DWM-2
Domain            : Window Manager
Logon Server      : (null)
Logon Time        : 1/11/2024 10:39:38 AM
SID               : S-1-5-90-0-2
        msv :
         [00000003] Primary
         * Username : DESKTOP-7VKREUO$
         * Domain   : ALD
         * NTLM     : cb4cacacf93394406beb092f12ac797c
         * SHA1     : 4fe309666be5630192c09851b20be577a914fee8
        tspkg :
        wdigest :
         * Username : DESKTOP-7VKREUO$
         * Domain   : ALD
         * Password : (null)
        kerberos :
         * Username : DESKTOP-7VKREUO$
         * Domain   : ALD.COMPANY.LAN
         * Password : Windows10ComputerPassword
        ssp :   KO
        credman :
...

Чтобы Windows-компьютер работал в составе домена, в качестве DNS-сервера у него должен быть указан IP-адрес контроллера домена ALD Pro. Дополнительно рекомендуется отключить протокол NetBIOS, иначе вход в систему будет выполняться с большой задержкой. А вот задавать DNS-суффикс необязательно, так как утилита ksetup установит глобальный DNS-суффикс для компьютера и короткие имена будут автоматически дополняться до FQDN-имен.

Продемонстрирую внесение указанных настроек

1. Откройте оснастку «Network Connections» (ncpa.cpl), затем свойства сетевого интерфейса, далее выберите протокол «Internet Protocol Version 4 (TCP/IPv4)» и нажмите кнопку «Properties», см. рисунок 1.

Картинка с сайта: habr.com

Внесите требуемые значения, см. рисунок 2.

IP address: 10.0.1.151

Subnet mask: 255.255.255.0

Default gateway: 10.0.1.1

Preferred DNS server: 10.0.1.11

Картинка с сайта: habr.com

Windows-компьютер может совершать ненужные запросы SAM LOGON к контроллеру домена — это сильно замедляет процедуру входа. Чтобы этого не происходило, нажмите кнопку «Advanced» — так вы перейдете к расширенным настройкам. На вкладке «WINS» отключите NetBIOS для сетевого подключения, см. рисунок 3.

Картинка с сайта: habr.com

Чтобы Windows-компьютер работал в составе домена, ему нужно предоставить логин и пароль от доменной учетной записи, которую мы создали ранее. Логин учетной записи соответствует имени компьютера. Посмотреть текущее значение и изменить его можно с помощью стандартной оснастки sysdm.cpl (System Device Manager), см. рисунок 4.

Картинка с сайта: habr.com

Пароль учетной записи компьютера можно задать с помощью команды SetComputerPassword утилиты ksetup на Windows-компьютере.

> ksetup.exe /SetComputerPassword Windows10ComputerPassword

где:

• /SetComputerPassword — команда утилиты ksetup, с помощью которой можно установить пароль для доменной учетной записи компьютера. Она сохраняет исходный текст пароля и несколько хешей в диспетчере учётных записей безопасности (Security Account Manager, SAM), то есть в защищенной части реестра.

• Windows10ComputerPassword — пароль, который мы использовали ранее при создании учетной записи компьютера в домене. Напоминаю, что нужно использовать длинные пароли, сгенерированные случайным образом.

Теперь все готово для того, чтобы переключить компьютер на работу в Kerberos-области, совместимой с RFC1510. Для этого нужно выполнить команду SetRealm утилиты ksetup.

> ksetup.exe /SetRealm ALD.COMPANY.LAN

где:

• /SetRealm — команда задает Kerberos-область, создавая ключ в разделе реестра «HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Domains».

• ALD.COMPANY.LAN — область Kerberos нашего домена ALD Pro.

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

Текущие настройки можно посмотреть с помощью команды DumpState:

> ksetup.exe /DumpState
default realm = ALD.COMPANY.LAN (external)
ALD.COMPANY.LAN:
        (no kdc entries for this realm)
        Realm Flags = 0x0No Realm Flags
No user mappings defined.

Отмечу еще несколько моментов, которые можно встретить в Интернете. Ниже объясню, почему они не требуются или могут быть даже вредны:

• Команда SetRealm первоначально называлась SetDomain, и этот алиас продолжает работать до сих пор. Поэтому во многих инструкциях остается такой вариант написания, но команда «установить область» лучше отражает тот факт, что Kerberos-аутентификация Windows-компьютеров возможна не только в домене Active Directory, но и других реализациях, совместимых с RFC1510. Например, в MIT Kerberos.

• Довольно часто предлагают с помощью команд /addkdc и /addkpasswd задать адреса серверов, через которые можно выполнять аутентификацию и менять пароль. Указанные рекомендации актуальны при интеграции Windows-машины с простой Kerberos-областью, но в домене ALD Pro (FreeIPA) есть все необходимые SRV-записи, и отказываться от функции автоматического обнаружения этих сервисов не имеет смысла.

• Иногда можно встретить рекомендации по настройке разрешенных типов шифрования Kerberos через локальную групповую политику «Security Options > Network Security: Configure encryption types allowed for Kerberos». Это может потребоваться только для учетных записей хостов, которые находятся под управлением устаревших Windows 2000, Windows Server 2003 и Windows XP. Современные релизы поддерживают необходимые типы шифрования по умолчанию (AES128_HMAC_SHA1 и AES256_HMAC_SHA1).

• В большинстве инструкций предлагают настроить сопоставление доменных пользователей на локальные учетные записи с помощью команды «ksetup.exe /mapuser * *», что правильно при интеграции Windows с базовой реализацией MIT Kerberos, в которой нет никаких идентификаторов безопасности Windows. При таком способе настройки вход Kerberos-пользователя аналогичен входу локального пользователя. Разница только в том, что первичная проверка аутентичности выполняется через KDC, а все остальные механизмы работают так же, как если бы вход в систему был выполнен локальной учетной записью.

  Однако в службе каталога FreeIPA центр распределения ключей MIT KDC интегрирован с Samba AD, поэтому Kerberos-билеты содержат сертификат PAC со всей необходимой авторизационной информацией, включая идентификатор безопасности пользователя и всех его групп. В силу указанного обстоятельства маппинг учетных записей для FreeIPA делать не нужно. При таком способе настройки будет обеспечиваться полноценная работа под доменной учетной записью: при входе пользователя будет сохраняться его доменный SID, у него будет TGT-билет с полным перечнем групп из PAC-сертификата, он сможет выполнять прозрачную Kerberos-аутентификацию при обращении к файловым серверам и другим керберизированным ресурсам в домене.

Для входа в компьютер с помощью доменной учетной записи в качестве имени пользователя нужно вводить полное имя Kerberos-принципала в формате login@REALM.FQDN. Причем логин может быть задан в любом регистре, а реалм — обязательно прописными буквами.

Операционная система Windows позволяет задать домен для входа по умолчанию, для этого нужно изменить в реестре значение DefaultLogonDomain. Из командной строки это можно сделать с помощью командлета Set-ItemProperty:

Set-ItemProperty -Path 'Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System' -Name 'DefaultLogonDomain' -Value 'ALD.COMPANY.LAN'

Однако при использовании домена по умолчанию ОС будет дополнять имена пользователей до формата DefaultLogonDomain\login, который будет усечен до NETBIOS\login — например, ALD\admin. Из-за этого перестанут работать такие важные функции, как вход с экрана блокировки, вход последним пользователем и смена пароля через <ctrl> + <alt> + <del>.

Для устранения указанных проблем, после входа необходимо исправить значения LoggedOnUser и LastLoggedOnUser в реестре, что можно сделать PowerShell-скриптом:

> cat FixPreWindowsNames.ps1

function Fix-PreWindowsName ([string]$Domain, [string]$NetBIOS, [string]$Path, [string]$Parameter){
    $Path = 'Registry::' + $Path;
    $UsernameComponents = (Get-ItemPropertyValue -Path $Path -Name $Parameter) -split '\\';
    if ($UsernameComponents.length -eq 2 -AND $UsernameComponents[0].ToUpper() -eq $NetBIOS){
        $UPN = $UsernameComponents[1] + '@' + $Domain;
        Set-ItemProperty -Path $Path -Name $Parameter -Value $UPN;
    }
}

$Domain = (Get-ItemPropertyValue -Path 'Registry::HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters' -Name 'Domain').ToUpper();
$NetBIOS = ($Domain -split '\.')[0];

Fix-PreWindowsName $Domain $NetBIOS 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\' 'LastLoggedOnUser';

foreach($SessionData in Get-ChildItem -Path 'Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\SessionData'){
    Fix-PreWindowsName $Domain $NetBIOS $SessionData.Name 'LoggedOnUser';
}

Для автоматического выполнения скрипта после входа в систему можно зарегистрировать следующее задание в планировщике. Скрипт небольшой, поэтому его текст можно передать напрямую в параметре EncodedCommand в формате base64, чтобы не хранить файл где-то на диске:

Register-ScheduledTask 
-TaskName 'FixPreWindowsNames' 
-Description 'Задача исправляет значения LoggedOnUser и LastLoggedOnUser' 
-Trigger (New-ScheduledTaskTrigger -AtLogOn) 
-Principal (New-ScheduledTaskPrincipal -UserId 'SYSTEM' -LogonType ServiceAccount) 
-Settings (New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries) 
-Action (New-ScheduledTaskAction -Execute 'cmd' -Argument $('/c start /min powershell -WindowStyle hidden -EncodedCommand ' + [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes((Get-Content FixPreWindowsNames.ps1))) ) )

В качестве промежуточного итога добавлю, что для вывода машины из домена FreeIPA достаточно выполнить команду RemoveRealm и ввести компьютер в рабочую группу:

> ksetup.exe /RemoveRealm 'ALD.COMPANY.LAN'
NOTE: /RemoveRealm requires a reboot to take effect on pre-SP1 Win2000 computers

> Add-Computer -WorkGroupName 'WORKGROUP'
WARNING: The changes will take effect after you restart the computer DESKTOP-7VKREUO.

2. Балансировка Kerberos аутентификации с использованием сайтов

Функция «локаций» в домене FreeIPA решает ту же задачу, что и «сайты» Active Directory, но несколько иным образом. Если в AD к сайтам привязываются компьютерные сети, и принадлежность компьютера к сайту определяется его текущим IP-адресом, то в FreeIPA привязка выполняется косвенно через DNS-сервер, который обслуживает запросы компьютера.

Например, если запросить SRV-записи «_kerberos._udp.ald.company.lan» у контроллеров из разных локаций, то dc-1 сделает перенаправление на адрес «hq», а dc-4 на адрес «spb» соответственно. В обоих случаях будет выдан полный перечень всех контроллеров домена с приоритизацией по принадлежности серверов к локациям. Проверку доступности серверов клиент SSSD выполняет в порядке заданных приоритетов.

$ nslookup -type=SRV _kerberos._udp.ald.company.lan dc-1.ald.company.lan
Server:         dc-1.ald.company.lan
Address:        10.0.1.11#53

_kerberos._udp.ald.company.lan  canonical name = _kerberos._udp.hq._locations.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 0 100 88 dc-2.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 0 100 88 dc-3.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 0 100 88 dc-1.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 50 100 88 dc-4.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 50 100 88 dc-5.ald.company.lan.

$ nslookup -type=SRV _kerberos._udp.ald.company.lan dc-4.ald.company.lan
Server:         dc-4.ald.company.lan
Address:        10.0.1.14#53

_kerberos._udp.ald.company.lan  canonical name = _kerberos._udp.spb._locations.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 50 100 88 dc-1.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 0 100 88 dc-5.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 50 100 88 dc-3.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 0 100 88 dc-4.ald.company.lan.
_kerberos._udp.hq._locations.ald.company.lan  service = 50 100 88 dc-2.ald.company.lan.

Windows-клиент тоже учитывает приоритеты SRV-записей, но запрашивает их по адресам вида «_kerberos._udp.dc._msdcs.ald.company.lan» в соответствии со спецификацией Active Directory (Active Directory Technical Specification, MS-ADTS). Такие записи в домене FreeIPA тоже есть, они добавляются автоматически для поддержки интеграции с Active Directory. Таким образом, для использования географической балансировки достаточно в качестве DNS-сервера указать один из контроллеров FreeIPA.

3. Настройка синхронизации времени

Для корректной работы протокола аутентификации Kerberos V5 необходимо, чтобы разница во времени между клиентом и сервером была не более 5 минут. За синхронизацию времени в операционной системе Windows отвечает служба W32Time (Windows Time Service), которая работает по протоколу NTP (Network Time Protocol). Прочитать и изменить параметры службы можно из командной строки с помощью утилиты w32tm. Параметры хранятся в реестре «Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters»:

> w32tm.exe /query /configuration
...
Type: NTP (Local)
NtpServer: time.windows.com,0x9 (Local)
...

В домене Active Directory источниками точного времени для рабочих станций выступают контроллеры домена, выбор которых осуществляется с учетом иерархии домена. Имитировать режим DOMHIER не имеет смысла, т. к. в этом случае служба W32Time будет следовать протоколу MS-SNTP и проверять цифровые подписи пакетов, которых нет в Chrony.

Учитывая сказанное, правильно будет использовать режим manual и указать DNS-имена или IP-адреса конкретных контроллеров домена. Например, если у вас в домене только два контроллера, настроить службу W32Time можно с помощью следующей команды:

> w32tm.exe /config /syncfromflags:manual /manualpeerlist:"dc-1.ald.company.lan,0x9 dc-2.ald.company.lan,0x9" /update 

где:

• /config — основная команда, используемая для конфигурирования службы W32Time. С ее помощью можно изменить текущие настройки, задать список используемых серверов времени, тип синхронизации и многое другое.

• /syncfromflags — устанавливает тип источника для синхронизации времени. Допустимы значения:

  • MANUAL — синхронизация времени с серверами из списка, заданного вручную (Type: NTP).

  • DOMHIER — синхронизация времени с контроллерами в соответствии с иерархией домена (Type: NT5DS).

  • ALL — разрешает использовать любой источник, как внешний сервер, так и контроллеры домена в соответствии с установленной иерархией (Type: AllSync).

  • NO — отключает синхронизацию времени (Type: NoSync).

• /manualpeerlist — задает список DNS-имен и/или IP-адресов серверов, которые могут выступать источниками времени для синхронизации.

  Адреса разделяются символом пробела, а в конце каждого адреса через запятую может быть задан дополнительный параметр, значение которого складывается из следующих флагов:

  • 0x1 (SpecialInterval) — указывает, что между отправкой запросов к этому серверу нужно использовать специальный интервал, заданный параметром SpecialPollInterval, который по умолчанию имеет значение 32768 секунд (9 часов). Если флаг не задан, то используется стандартное значения в 604800 секунд (7 дней).

  • 0x2 (UseAsFallbackOnly) — указывает, что данный сервер необходимо использовать в последнюю очередь как резервный.

  • 0x4 (SymmetricActive) — указывает, что сервер является одноранговым узлом, с которым возможна симметричная синхронизация времени.

  • 0x8 (Client) — означает, что текущий хост должен выступать клиентом по отношению к указанному серверу.

    Значение по умолчанию «time.windows.com,0x9» соответствует комбинации первого и последнего флагов SpecialInterval+Client. Если вам нужно будет указать резервный источник времени, то используйте значение 0xB, чтобы к предыдущему значению добавить флаг UseAsFallbackOnly.

• /update — уведомляет службу об изменении параметров для их принудительного применения. Если параметр не использовать, то изменения вступят в силу при следующем перезапуске службы.

Принудительно запустить синхронизацию времени можно с помощью команды resync:

> w32tm.exe /resync

Sending resync command to local computer
The command completed successfully.

Посмотреть результаты синхронизации можно с помощью команды status:

> w32tm.exe /query /status /verbose

Leap Indicator: 0(no warning)
Stratum: 4 (secondary reference - syncd by (S)NTP)
Precision: -23 (119.209ns per tick)
Root Delay: 0.0081377s
Root Dispersion: 7.8973731s
ReferenceId: 0x0A00010B (source IP:  10.0.1.11)
Last Successful Sync Time: 1/14/2024 11:32:33 AM
Source: dc-1.ald.company.lan,0x9
Poll Interval: 10 (1024s)

Phase Offset: 0.1344197s
ClockRate: 0.0156250s
State Machine: 1 (Hold)
Time Source Flags: 0 (None)
Server Role: 0 (None)
Last Sync Error: 0 (The command completed successfully.)
Time since Last Good Sync Time: 2.2626619s

Учитывая, что со временем топология домена может претерпевать существенные изменения, использовать имена конкретных серверов крайне нежелательно. Лучше будет указать DNS-имя домена:

> w32tm.exe /config /syncfromflags:manual /manualpeerlist:"ald.company.lan,0x9" /update 

В этом случае A-записи нужно будет добавить вручную, автоматически они в домене не создаются. Сделать это можно на контроллере, используя утилиту командной строки ipa.

# for server in $(ipa-replica-manage list | sed 's/: master//'); do ipa dnsrecord-add ald.company.lan @ --a-rec=$(dig +short $server); done

Однако чтобы учесть географическое распределение инфраструктуры, правильным будет создать запись вида «_ntp._udp.имя_домена» и добавить A-записи в соответствующие локации.

Для упрощения предлагаю воспользоваться уже существующей записью «_kerberos._udp». Создадим необходимые A-записи сначала в головном офисе:

$ ipa dnsrecord-add ald.company.lan _kerberos._udp.hq._locations --a-rec=10.0.1.11

  Имя записи: _kerberos._udp.hq._locations
  A record: 10.0.1.11
  SRV record: 0 100 88 dc-1.ald.company.lan., 0 100 88 dc-2.ald.company.lan., 0 100 88 dc-3.ald.company.lan., 50 100 88 dc-4.ald.company.lan., 50 100 88 dc-5.ald.company.lan.

$ ipa dnsrecord-add ald.company.lan _kerberos._udp.hq._locations --a-rec=10.0.1.12
  Имя записи: _kerberos._udp.hq._locations
  A record: 10.0.1.11, 10.0.1.12
  SRV record: 0 100 88 dc-1.ald.company.lan., 0 100 88 dc-2.ald.company.lan., 0 100 88 dc-3.ald.company.lan., 50 100 88 dc-4.ald.company.lan., 50 100 88 dc-5.ald.company.lan

$ ipa dnsrecord-add ald.company.lan _kerberos._udp.hq._locations --a-rec=10.0.1.13
  Имя записи: _kerberos._udp.hq._locations
  A record: 10.0.1.11, 10.0.1.12, 10.0.1.13
  SRV record: 0 100 88 dc-1.ald.company.lan., 0 100 88 dc-2.ald.company.lan., 0 100 88 dc-3.ald.company.lan., 50 100 88 dc-4.ald.company.lan., 50 100 88 dc-5.ald.company.lan

Затем в офисе Санкт-Петербурга:

$ ipa dnsrecord-add ald.company.lan _kerberos._udp.spb._locations --a-rec=10.0.1.14
  Имя записи: _kerberos._udp.spb._locations
  A record: 10.0.1.14
  SRV record: 50 100 88 dc-1.ald.company.lan., 50 100 88 dc-2.ald.company.lan., 50 100 88 dc-3.ald.company.lan., 0 100 88 dc-4.ald.company.lan., 0 100 88 dc-5.ald.company.lan

$ ipa dnsrecord-add ald.company.lan _kerberos._udp.spb._locations --a-rec=10.0.1.15
  Имя записи: _kerberos._udp.spb._locations
  A record: 10.0.1.14, 10.0.1.15
  SRV record: 50 100 88 dc-1.ald.company.lan., 50 100 88 dc-2.ald.company.lan., 50 100 88 dc-3.ald.company.lan., 0 100 88 dc-4.ald.company.lan., 0 100 88 dc-5.ald.company.lan

Проверим работу новых записей:

# nslookup -type=A _kerberos._udp.ald.company.lan dc-1.ald.company.lan
Server:         dc-1.ald.company.lan
Address:        10.0.1.11#53

_kerberos._udp.ald.company.lan  canonical name = _kerberos._udp.hq._locations.ald.company.lan.
Name:   _kerberos._udp.hq._locations.ald.company.lan
Address: 10.0.1.12
Name:   _kerberos._udp.hq._locations.ald.company.lan
Address: 10.0.1.11
Name:   _kerberos._udp.hq._locations.ald.company.lan
Address: 10.0.1.13

Теперь запись «_kerberos._udp.ald.company.lan» можно использовать в настройках службы W32Time на компьютерах Windows. Для синхронизации времени они будут выбирать ближайший к ним контроллер домена.

4. Настройка динамического обновления DNS-записей

Служба каталога FreeIPA и клиентская часть SSSD поддерживают функцию динамического обновления DNS-записей в соответствии с RFC 2136. Чтобы использовать эту функцию, в конфигурационный файл /etc/sssd/sssd.conf достаточно внести несколько строк:

[domain/ald.company.lan]
...
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
...

Операционная система Windows тоже поддерживает указанный протокол. Только есть одно маленькое недоразумение, из-за которого ничего не работает: компьютер использует имя принципала в другом формате, поэтому без добавления псевдонима «desktop-7vkreuo$» к учетной записи компьютера хост сможет выполнять только проверку аутентичности пользователей. У него не получится самому пройти аутентификацию в домене, и в журналах будут появляться сообщения об ошибке «CLIENT_NOT_FOUND». Добавить псевдоним можно с помощью команды host-add-principal утилиты ipa:

admin@dc-1:~$ ipa host-add-principal desktop-7vkreuo.ald.company.lan 'desktop-7vkreuo$'
--------------------------------------------------------------------------
Добавлены новые псевдонимы в запись узла "desktop-7vkreuo.ald.company.lan"
--------------------------------------------------------------------------
  Имя узла: desktop-7vkreuo.ald.company.lan
  Псевдоним учётной записи: host/desktop-7vkreuo.ald.company.lan@ALD.COMPANY.LAN, desktop-7vkreuo$@ALD.COMPANY.LAN

И останется только расширить политику обновления DNS на сервере:

• Для прямой зоны:

  • DN: idnsname=ald.company.lan.,cn=dns,dc=ald,dc=company,dc=lan.

  • Атрибут: idnsUpdatePolicy

  • Старое значение: grant ALD.COMPANY.LAN krb5-self * A; grant ALD.COMPANY.LAN krb5-self * AAAA; grant ALD.COMPANY.LAN krb5-self * SSHFP;

  • Новое значение: grant ALD.COMPANY.LAN krb5-self * A AAAA SSHFP; grant ALD.COMPANY.LAN ms-self . A AAAA;

• Для обратной зоны:

  • DN: idnsname=10.0.1.in-addr.arpa.,cn=dns,dc=ald,dc=company,dc=lan.

  • Атрибут: idnsUpdatePolicy

  • Старое значение: grant ALD.COMPANY.LAN krb5-subdomain 1.0.10.in-addr.arpa. PTR;

  • Новое значение: grant ALD.COMPANY.LAN krb5-subdomain 1.0.10.in-addr.arpa. PTR; grant ALD.COMPANY.LAN ms-subdomain 1.0.10.in-addr.arpa. PTR;

Внести указанные изменения можно через интерфейс IPA https://dc-1.ald.company.lan/ipa/ui, см. рисунок 5.

Картинка с сайта: habr.com

В завершение не помешает настроить на рабочей станции политику обновления DNS, так как по умолчанию Windows-клиенты сначала предпринимают попытку неавторизованных запросов, а уже после переключаются на GSS-TSIG. Это приводит к тому, что в журналах сервера скапливается много лишних предупреждений.

Для устранения проблемы нужно разрешить «только безопасные» (only secure) обновления для DNS-клиента на стороне рабочей станции Windows. Это делается с помощью редактора локальной групповой политики (gpedit.msc), см. рисунок 6.

Картинка с сайта: habr.com

Для проверки настроек вы можете выполнить принудительное обновление DNS-записей на Windows-компьютере командой registerdns утилиты ipconfig:

> ipconfig.exe /registerdns

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

• Включение компьютера.

• Изменение IP-адреса в конфигурации сетевого подключения.

• Продление срока аренды IP-адреса, выданного DHCP-сервером. Такое событие можно вызвать принудительно командой «ipconfig /renew».

На стороне сервера FreeIPA запросы на обновление DNS можно будет найти в журнале daemon.log. Если хосту установить IP-адрес 10.0.1.155, то вы увидите в журнале следующие строки:

# tail -f /var/log/daemon.log | grep -i 'desktop-7vkreuo'
dc-1 named-pkcs11[4920]: client @0x70a05410f640 10.0.1.155#64080/key 
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone 'ald.company.lan/IN': 
deleting rrset at 'DESKTOP-7VKREUO.ALD.COMPANY.LAN' AAAA

dc-1 named-pkcs11[4920]: client @0x70a05410f640 10.0.1.155#64080/key 
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone 'ald.company.lan/IN': 
deleting rrset at 'DESKTOP-7VKREUO.ALD.COMPANY.LAN' A

dc-1 named-pkcs11[4920]: client @0x70a05410f640 10.0.1.155#64080/key 
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone 'ald.company.lan/IN': 
adding an RR at 'DESKTOP-7VKREUO.ALD.COMPANY.LAN' A 10.0.1.155

dc-1 named-pkcs11[4920]: client @0x70a04411a9d0 10.0.1.155#56472/key 
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone '1.0.10.in-addr.arpa/IN': 
deleting rrset at '155.1.0.10.in-addr.arpa' PTR

dc-1 named-pkcs11[4920]: client @0x70a04411a9d0 10.0.1.155#56472/key 
desktop-7vkreuo\$\@ALD.COMPANY.LAN: updating zone '1.0.10.in-addr.arpa/IN': 
adding an RR at '155.1.0.10.in-addr.arpa' PTR DESKTOP-7VKREUO.ALD.COMPANY.LAN.

На стороне клиента возможные ошибки обновления DNS будут появляться в журнале System, см. рисунок 7.

Картинка с сайта: habr.com

5. Проверка функциональных возможностей

5.1 Вход в систему

Для входа в систему доменным пользователем «admin» нужно выбрать «Other user» и ввести имя в формате «admin@ALD.COMPANY.LAN», см. рис. 8. Если вы настроили домен по умолчанию, то можно использовать короткое имя «admin» без указания домена.

Картинка с сайта: habr.com

После входа в операционную систему Windows вы можете проверить состояние из командной строки с помощью утилит whoami и klist.

> whoami.exe
ald\admin

> whoami.exe /groups

GROUP INFORMATION
-----------------

Group Name                                 Type             SID                                           
========================================== ================ ============================================= 
                                           Unknown SID type S-1-5-21-1491017894-2377586105-2170988794-512 
Everyone                                   Well-known group S-1-1-0                                       
BUILTIN\Users                              Alias            S-1-5-32-545                                  
NT AUTHORITY\INTERACTIVE                   Well-known group S-1-5-4                                       
CONSOLE LOGON                              Well-known group S-1-2-1                                       
NT AUTHORITY\Authenticated Users           Well-known group S-1-5-11                                      
NT AUTHORITY\This Organization             Well-known group S-1-5-15                                      
LOCAL                                      Well-known group S-1-2-0                                       
Authentication authority asserted identity Well-known group S-1-18-1                                      
Mandatory Label\Medium Mandatory Level     Label            S-1-16-8192

> klist.exe
Current LogonId is 0:0x396cf

Cached Tickets: (1)

#0>     Client: admin @ ALD.COMPANY.LAN
        Server: krbtgt/ALD.COMPANY.LAN @ ALD.COMPANY.LAN
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 11/19/2023 6:26:37 (local)
        End Time:   11/20/2023 6:26:37 (local)
        Renew Time: 11/26/2023 6:26:37 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: dc-1.ald.company.lan

Чтобы определить, какой именно контроллер обслуживает Windows-компьютер, можно воспользоваться утилитами systeminfo или nltest:

> systeminfo.exe | find /i "logon server"
Logon Server:              \\DC-1


> nltest.exe /dsgetdc:ALD.COMPANY.LAN
           DC: \\dc-1.ald.company.lan
      Address: \\10.0.1.11
     Dom Guid: 808d0975-5d36-47ed-8825-4b4227a348b9
     Dom Name: ald.company.lan
  Forest Name: ald.company.lan
 Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
The command completed successfully

5.2 Автономный вход в систему

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

Продолжительность автономного входа зависит от настроек сетевого интерфейса: если доступа к сети нет или сетевой интерфейс настроен на работу с публичным DNS-сервером, который отклоняет запросы на разрешение локальных имен, то автономный вход будет выполняться без задержек. Если интерфейс включен, но DNS-сервер недоступен, то компьютер будет отправлять до 15 запросов на поиск SRV-записей Kerberos и LDAP-сервисов — общая задержка может составить больше минуты.

Очевидно, что при автономном входе TGT-билет в системе будет отсутствовать:

> whoami
ald\admin

> whoami /groups

GROUP INFORMATION
-----------------

Group Name                                 Type             SID                                           
========================================== ================ ============================================= 
                                           Unknown SID type S-1-5-21-1491017894-2377586105-2170988794-512 
Everyone                                   Well-known group S-1-1-0                                       
BUILTIN\Users                              Alias            S-1-5-32-545                                  
NT AUTHORITY\INTERACTIVE                   Well-known group S-1-5-4                                       
CONSOLE LOGON                              Well-known group S-1-2-1                                       
NT AUTHORITY\Authenticated Users           Well-known group S-1-5-11                                      
NT AUTHORITY\This Organization             Well-known group S-1-5-15                                      
LOCAL                                      Well-known group S-1-2-0                                       
Authentication authority asserted identity Well-known group S-1-18-1                                      
Mandatory Label\Medium Mandatory Level     Label            S-1-16-8192

> klist

Current LogonId is 0:0x95e78b

Cached Tickets: (0)

> systeminfo | find /i "logon server"
Logon Server:              \\DC-1

> nltest /dsgetdc:ALD.COMPANY.LAN
Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

После восстановления доступа к локальной сети билеты Kerberos появляются при первом же успешном обращении к керберизированному сервису. Например, при обращении к общим папкам автоматически появятся билеты krbtgt и cifs:

> whoami
ald\admin

> whoami /groups

GROUP INFORMATION
-----------------

Group Name                                 Type             SID                                           
========================================== ================ ============================================= 
                                           Unknown SID type S-1-5-21-1491017894-2377586105-2170988794-512 
Everyone                                   Well-known group S-1-1-0                                       
BUILTIN\Users                              Alias            S-1-5-32-545                                  
NT AUTHORITY\INTERACTIVE                   Well-known group S-1-5-4                                       
CONSOLE LOGON                              Well-known group S-1-2-1                                       
NT AUTHORITY\Authenticated Users           Well-known group S-1-5-11                                      
NT AUTHORITY\This Organization             Well-known group S-1-5-15                                      
LOCAL                                      Well-known group S-1-2-0                                       
Authentication authority asserted identity Well-known group S-1-18-1                                      
Mandatory Label\Medium Mandatory Level     Label            S-1-16-8192

> klist

Current LogonId is 0:0x95e78b

Cached Tickets: (2)

#0>     Client: admin @ ALD.COMPANY.LAN
        Server: krbtgt/ALD.COMPANY.LAN @ ALD.COMPANY.LAN
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 2/4/2024 11:52:59 (local)
        End Time:   2/5/2024 11:52:59 (local)
        Renew Time: 2/11/2024 11:52:59 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: dc-1.ald.company.lan
#1>     Client: admin @ ALD.COMPANY.LAN
        Server: cifs/dc-1.ald.company.lan @ ALD.COMPANY.LAN
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a90000 -> forwardable renewable pre_authent name_canonicalize 0x80000
        Start Time: 2/4/2024 11:52:59 (local)
        End Time:   2/5/2024 11:52:59 (local)
        Renew Time: 2/11/2024 11:52:59 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: dc-1.ald.company.lan
> systeminfo | find /i "logon server"
Logon Server:              \\DC-1

> nltest /dsgetdc:ALD.COMPANY.LAN
           DC: \\dc-1.ald.company.lan
      Address: \\10.0.1.11
     Dom Guid: 808d0975-5d36-47ed-8825-4b4227a348b9
     Dom Name: ald.company.lan
  Forest Name: ald.company.lan
 Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
        Flags: PDC GC DS LDAP KDC TIMESERV GTIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST CLOSE_SITE
The command completed successfully

5.3 Смена пароля

Функция смены пароля работает штатным образом, если при входе в систему пользователь ввел имя в формате login@REALM.FQDN или это значение было скорректировано автоматически после входа с помощью скриптов, см. рис. 9.

Картинка с сайта: habr.com

5.4 Прозрачная аутентификация при обращении к сетевой папке

Прозрачная Kerberos-аутентификация при обращении к керберизированным сервисам будет работать, так как у пользователя в системе есть TGT-билет.

Для проверки вы можете создать сетевую папку с именем «testshare» прямо на контроллере домена и предоставить к ней доступ пользователю с именем «admin». Для этого в конец файла /etc/samba/smb.conf допишите следующие строки:

# nano /etc/samba/smb.conf 
...
[testshare]
path = /srv/testshare
writable = yes
valid users = admin
write list = admin

После чего создайте указанную папку и перезапустите службу smbd:

# mkdir /srv/testshare
# systemctl restart smbd.service 

Откройте сетевую папку в проводнике Windows по адресу «\\dc-1.ald.company.lan\testshare» и проверьте, что у вас есть доступ без ввода пароля и возможность создавать и редактировать файлы, см. рис. 10.

Картинка с сайта: habr.com

Выполните команду klist в терминале и убедитесь, что там появился дополнительный билет на доступ к службе cifs/dc-1.ald.company.lan:

5.5 Назначение доменным пользователям прав доступа в локальной системе

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

Текущие идентификаторы пользователей и групп можно посмотреть на контроллере домена FreeIPA с помощью утилиты ipa:

$ ipa user-show admin --all | grep ipantsecurityidentifier
  ipantsecurityidentifier: S-1-5-21-1491017894-2377586105-2170988794-500

$ ipa group-show admins --all | grep ipantsecurityidentifier
  ipantsecurityidentifier: S-1-5-21-1491017894-2377586105-2170988794-512

Создать локальные группы на Windows-компьютере и добавить в них участников по идентификаторам можно из PowerShell с помощью командлетов New-LocalGroup и Add-LocalGroupMember, см. рис. 11:

> New-LocalGroup -Name "ALD-User-Admin" -Description "Domain user"

Name           Description
----           -----------
ALD-User-Admin Domain user

> Add-LocalGroupMember -Group "ALD-User-Admin" -Member "S-1-5-21-1491017894-2377586105-2170988794-500"

> New-LocalGroup -Name "ALD-Group-Admins" -Description "Domain group"

Name             Description
----             -----------
ALD-Group-Admins Domain group

> Add-LocalGroupMember -Group "ALD-Group-Admins" -Member "S-1-5-21-1491017894-2377586105-2170988794-512"

Картинка с сайта: habr.com

Целесообразно добавить администраторов домена также в группу локальных администраторов, чтобы у пользователей были все необходимые привилегии для настройки системы без переключения на учетную запись локального администратора:

Add-LocalGroupMember -Group "Administrators" -Member "S-1-5-21-1491017894-2377586105-2170988794-512"

Вместо заключения

Приведенный способ значительно расширяет возможности построения гибридной инфраструктуры, но требует много времени для настройки рабочих станций. Это не проблема, если у вас почасовая оплата, но в большинстве случаев создает значительные затруднения. Поэтому команда ALD Pro разработала графическую утилиту aldpro-join, которая позволяет выполнить все настройки в пару кликов, см. рисунок 12.

Картинка с сайта: habr.com

Приложение написано на языке Python и доступно в публичном репозитории продуктовой команды на GitFlic как в виде исходных кодов, так и в виде скомпилированного с помощью Pyinstaller исполняемого exe-файла.

Чтобы утилита смогла внести необходимые изменения и на локальном компьютере, и в домене, запускать ее нужно от имени локального администратора, а при появлении окна аутентификации требуется предоставить учетные данные привилегированного пользователя домена.

Еще раз акцентирую внимание на том, что утилита работает как для домена ALD Pro, так и для «ванильных» инсталляций FreeIPA. Команда ALD Pro прикладывает значительные усилия для выработки лучших практик использования продуктов технологического стека, и мы будем рады, если наши наработки помогут вам в реализации программы импортозамещения в вашей компании.

For Kerberos authentication implementation, we must use an Alternate Service Account (ASA) for the shared namespace URL we are publishing for all Exchange services.
In our example we are going to use the following:

• mail.domain.com for MAPI Over Http & Outlook Anywhere (OA).
• Autodiscover.domain.com for Autodiscover services.

There are 2 main reasons for using Kerberos authentication:

• Better Security: When using Kerberos authentication, the user who logged into the domain, gets a Ticket Granting Ticket / TGT and use it for up to 10 hours in order to access the domain’s resources.
  This mechanism considered as a highly secured login option.
• Reduce loads on Exchange servers: In large scale deployments,
  You might encounter NTLM scalability issues, such as direct MAPI connectivity causing intermittent NTLM failures and authentication failures (Password POPUPs when using Outlook).
  Kerberos authentication, reduces the loads on Exchange and Domain Controllers by eliminating the need for reauthenticate every time the client opens Outlook since he already has a TGT for authentication.

Alternate Service Account creation in AD:

ASA is a computer account or a user account object in the same Active Directory forest where Exchange servers are installed.
According to Microsoft’s recommendation you should create a computer account instead of a user account, since a computer account doesn’t allow interactive logon and may have simpler security policies than a user account. when creating a computer account, the account’s password doesn’t expire, but the recommendation is to update the password from time to time.
The computer account name is not limited to a specific name, but must be within the maximum of 15 characters.
In order to create the ASA computer account, run the following command from PowerShell with admin privilege (don’t forget to load the Active Directory module first):

New-ADComputer -Name EXCHASA -AccountPassword (Read-Host ‘Enter password’ -AsSecureString) -Description ‘ASA for Exchange — DO NOT DELETE’ -Enabled:$True -SamAccountName EXCHASA -Path “OU=ExchangeServers,DC=domain,DC=com”

Get-ADComputer EXCHASA

Картинка с сайта: gabriel.rabbaa.net

Картинка с сайта: gabriel.rabbaa.net

After the computer account (ASA) was created, we need to enable AES 256 encryption in order to support Kerberos:

Set-ADComputer EXCHASA -add @{“msDS-SupportedEncryptionTypes”=”28″}

run the command bellow to replicate the changes to all domain controllers

repadmin /syncall /ADPe

Configure ASA credential on all Mailbox servers

The core pillar that allows Exchange to work with Kerberos authentication since Exchange 2010 SP1, is the Microsoft Exchange Service Host service that runs on every mailbox server.
The only supported way to configure ASA credentials for Kerberos authentication with Exchange servers is running the RollAlternateServiceAcountPassword.ps1 script on every mailbox server.
The script updates the ASA credentials and distributes it to the relevant mailbox server, which contains the Client Access Service.

• Running the script on the First Mailbox Server:

To run the script on the first Mailbox server, open Exchange Management Shell (EMS).
In case that you are running on Windows 2019 Core Server, type LaunchEMS from CMD.
Now navigate to the Exchange’s scripts directory by running the next command from EMS:

cd $exscripts

Now run the script with the name of the first Mailbox server (SRV-Ex2019N1 in our example) and the name of the domain\ASA computer account as we have created earlier:

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer SRV-ex2019n1.domain.local -GenerateNewPasswordFor domain\EXCHASA$

• In case that asked to “Continue an and make changes”- press Y
• In case that asked to “Change password for ASA in AD”- press Y

Картинка с сайта: gabriel.rabbaa.net

make sure the script run successfully

To run the script on the second and other Mailbox servers rather than the first one, open Exchange Management Shell (EMS) and navigate to the scripts directory as you did at the first server.

.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer SRV-ex2019n2.domain.local -CopyFrom SRV-ex2019n1.domain.local

Картинка с сайта: gabriel.rabbaa.net

In case you have completed running the scripts on all your Exchange 2019 servers, you can continue to the next step.

• Verify all servers are configured with ASA credentials:

Get-ClientAccessService -IncludeAlternateServiceAccountCredentialStatus | fl Name, AlternateServiceAccountConfiguration

Картинка с сайта: gabriel.rabbaa.net

Associating SPNs with the ASA computer account

• Important!
  Before associating SPNs with the ASA computer account, verify that all Mailbox servers were updated with the ASA credentials, which means that the RollAlternateServiceAcountPassword.ps1 script ran against all server.
• In addition, verify that the SPNs that you are using for Exchange services, are not associate with other ASA computer account.
  In order to do so, run the following command for every SPN you are using (in our example mail.domain.com & autodiscover.domain.com)

Setspn -F -Q http/mail.domain.com

You should get an output:
No Such SPN Found

One of the last steps before completing the Kerberos configuration is running the commands for SPNs association used by the Exchange services with the ASA computer account:

Setspn -S http/mail.domain.com domain\EXCHASA$

Setspn -S http/autodiscover.domain.com domain\EXCHASA$

Setspn -S http/mail.domain2.com domain\EXCHASA$

Setspn -S http/autodiscover.domain2.com domain\EXCHASA$

Enable Kerberos authentication for Outlook clients

The last step for Kerberos authentication enablement is the authentication methods for Outlook connectivity by MAPI Over HTTPS & Outlook Anywhere (RPC Over HTTPS / OA).

• In order to run it on all Exchange servers at once, run the next command:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate

Get-OutlookAnywhere | Set-OutlookAnywhere -ExternalClientAuthenticationMethod Ntlm

Картинка с сайта: gabriel.rabbaa.net

Set-OutlookAnywhere -Identity “ZPVWMSG05\Rpc (Default Web Site)” -IISAuthenticationMethods NTLM,Negotiate

To set the MAPI Over HTTPS support for Kerberos authentication, run the following command for every Exchange server:

• In order to run it on all Exchange servers at once, run the next command:

Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate

• In hybrid environments with Exchange Online or if you use OAuth internally, run the following commands on your Exchange 2019 Mailbox servers:

$mapidir = Get-MapiVirtualDirectory -Server SRV-ex2019n1
$mapidir | Set-MapiVirtualDirectory -IISAuthenticationMethods ($mapidir.IISAuthenticationMethods +=’Negotiate’)

These settings MUST be updated to Outlook clients as soon as possible.
In addition, the most important service which responsible for Kerberos authentication at the Exchange servers is the MSExchangeServiceHost service, which is started by default.
If this service is stopped, Kerberos authentication will not work.

In order to speed up the time Outlook will be updated with the new authentication settings, we need to run 2 tasks against all Mailbox servers that are responsible to publish Autodiscover configuration:

• Restart (Recycle) the MSExchangeAutodiscoverAppPool application pool.
• Restart the MSExchangeServiceHost service and verify it is running.

To restart the MSExchangeAutodiscoverAppPool application pool on all Mailbox servers (which are running the Client Access service), use the following commands from Exchange Management Shell (EMS) on one of the Exchange servers:

$cas=Get-ClientAccessService

$cas.name | % {Invoke-Command -ComputerName $_ -ScriptBlock {Restart-WebAppPool -Name MSExchangeAutodiscoverAppPool}}

To restart the MSExchangeServiceHost service on all Mailbox servers, run the following commands:

$cas=Get-ClientAccessService

$cas.name | % {Invoke-Command -ComputerName $_ -ScriptBlock {Restart-Service MSExchangeServiceHost -Force}}

To verify that the MSExchangeServiceHost service is at Running state on all Mailbox servers, run the next command:

$cas.name | % {Get-Service MSExchangeServiceHost}

Verify Outlook connectivity using Kerberos:

To so do, we should examine the HttpProxy logs on every Mailbox server and search for Negotiate.
The HttpProxy logs are located at the Exchange’s installation path, by default it would be located at:
C:\Program files\Microsoft\Exchange Server\V15\Logging\HttpProxy

Rollback / Turn off Kerberos authentication

In case that from some reason Kerberos authentication needs to be turned off, There are simple steps that need to be done:

• Remove the ASA credentials from the Mailbox servers.
• Remove the SPNs used by Exchange, from the ASA computer account.

Remove the ASA credentials from the Mailbox servers by running the following command:

Set-ClientAccessService SRV-ex2019n1 -RemoveAlternateServiceAccountCredentials

In order to remove the ASA credentials from all Mailbox servers, run the next command:

Get-ClientAccessService | Set-ClientAccessService -RemoveAlternateServiceAccountCredentials

Remove the SPNs used by Exchange from the ASA computer account can be done by running the following commands, for every SPN that was registered with the ASA:

Setspn -D http/mail.domain.com domain\EXCHASA$

Setspn -D http/autodiscover.domain.com domain\EXCHASA$

In order to verify that the actions completed successfully, run the following command for every SPN you are using (in our example mail.domain.com & autodiscover.domain.com)

Setspn -F -Q http/mail.domain.com

You should get an output similar to the output in the above screenshot:
No Such SPN Found

• Although you don’t have to do this immediately, you should restart all client computers to clear the Kerberos ticket cache from the computer.

origin