Конечная цель проектов импортозамещения в ИТ — полный отказ от операционной системы 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.
Внесите требуемые значения, см. рисунок 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
Windows-компьютер может совершать ненужные запросы SAM LOGON к контроллеру домена — это сильно замедляет процедуру входа. Чтобы этого не происходило, нажмите кнопку «Advanced» — так вы перейдете к расширенным настройкам. На вкладке «WINS» отключите NetBIOS для сетевого подключения, см. рисунок 3.
Чтобы Windows-компьютер работал в составе домена, ему нужно предоставить логин и пароль от доменной учетной записи, которую мы создали ранее. Логин учетной записи соответствует имени компьютера. Посмотреть текущее значение и изменить его можно с помощью стандартной оснастки sysdm.cpl (System Device Manager), см. рисунок 4.
Пароль учетной записи компьютера можно задать с помощью команды 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.
В завершение не помешает настроить на рабочей станции политику обновления DNS, так как по умолчанию Windows-клиенты сначала предпринимают попытку неавторизованных запросов, а уже после переключаются на GSS-TSIG. Это приводит к тому, что в журналах сервера скапливается много лишних предупреждений.
Для устранения проблемы нужно разрешить «только безопасные» (only secure) обновления для DNS-клиента на стороне рабочей станции Windows. Это делается с помощью редактора локальной групповой политики (gpedit.msc), см. рисунок 6.
Для проверки настроек вы можете выполнить принудительное обновление 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.
5. Проверка функциональных возможностей
5.1 Вход в систему
Для входа в систему доменным пользователем «admin» нужно выбрать «Other user» и ввести имя в формате «admin@ALD.COMPANY.LAN», см. рис. 8. Если вы настроили домен по умолчанию, то можно использовать короткое имя «admin» без указания домена.
После входа в операционную систему 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-10 секунд. При недоступности отдельных контроллеров время входа значительно возрастает.
Совет: не забудьте отключить NetBIOS для сетевого подключения, это значительно ускоряет время входа.
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 successfully5.3 Смена пароля
Функция смены пароля работает штатным образом, если при входе в систему пользователь ввел имя в формате login@REALM.FQDN или это значение было скорректировано автоматически после входа с помощью скриптов, см. рис. 9.
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.
Выполните команду 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"
Целесообразно добавить администраторов домена также в группу локальных администраторов, чтобы у пользователей были все необходимые привилегии для настройки системы без переключения на учетную запись локального администратора:
Add-LocalGroupMember -Group "Administrators" -Member "S-1-5-21-1491017894-2377586105-2170988794-512"Вместо заключения
Приведенный способ значительно расширяет возможности построения гибридной инфраструктуры, но требует много времени для настройки рабочих станций. Это не проблема, если у вас почасовая оплата, но в большинстве случаев создает значительные затруднения. Поэтому команда ALD Pro разработала графическую утилиту aldpro-join, которая позволяет выполнить все настройки в пару кликов, см. рисунок 12.
Приложение написано на языке Python и доступно в публичном репозитории продуктовой команды на GitFlic как в виде исходных кодов, так и в виде скомпилированного с помощью Pyinstaller исполняемого exe-файла.
Чтобы утилита смогла внести необходимые изменения и на локальном компьютере, и в домене, запускать ее нужно от имени локального администратора, а при появлении окна аутентификации требуется предоставить учетные данные привилегированного пользователя домена.
Еще раз акцентирую внимание на том, что утилита работает как для домена ALD Pro, так и для «ванильных» инсталляций FreeIPA. Команда ALD Pro прикладывает значительные усилия для выработки лучших практик использования продуктов технологического стека, и мы будем рады, если наши наработки помогут вам в реализации программы импортозамещения в вашей компании.
Contents
Windows_authentication_against_FreeIPA#
Windows authentication against FreeIPA#
This article describes direct integration between FreeIPA and Windows
machine, i.e. without involving Active Directory server. This
article does not apply to configurations where trust between AD and
FreeIPA was established. Note also that the described
configuration is not supported by FreeIPA development team and also is
not supported by Red Hat Enterprise Linux Identity Management product. A
work on making possible to login to Windows machines already enrolled
into a trusted Active Directory forest is ongoing and is not available
yet in any released FreeIPA version.
-
If you already have AD we recommend using this system with AD and
using trusts between AD and IPA. -
If you do not have AD then use Samba 4 instead of it. As of Samba
4.3, Samba AD can establish cross-realm trusts. The feature is still
incomplete and lacks proper access controls but it can be configured
to trust FreeIPA. -
If neither of the two options work for you you can configure Windows
system to work directly with IPA as described below. It is an option
of last resort because IPA does not provide the services windows
client expects and FreeIPA development team does not support this
mode. If this is good enough for you, fine by us. -
Build a native Windows client (cred provider) for IPA using latest
Kerberos. This would be really useful if someone does that because we
don’t have capacity to not build this ourselves. With the native OTP
support in IPA it becomes a real business opportunity to provide a
native 2FA inside enterprise across multiple platforms. But please do
it open source way otherwise we would not recommend you
FreeIPA is not an Active Directory server#
FreeIPA is not a re-implementation of Microsoft Active Directory.
FreeIPA is focused on Linux (and other standards compliant) systems.
For this reason FreeIPA without configured AD trust can
provide only
authentication service
for Windows hosts (via standard Kerberos
protocol).
FreeIPA can’t provide account database for Windows hosts in the same way
as AD does. You have to create local Windows account and appropriate
account mapping for each user if you select direct Windows<=>FreeIPA
integration. (This limitation doesn’t apply if you use AD
trust.)
Project pGina could help you to overcome some
limitations.
Configure FreeIPA#
1. Create the host principal in the web interface
2. Create IPA users to correspond to Windows users
3. Reset the user's IPA password to a known password using the web interface or CLI,
the user will be prompted to change at first log in.
4. On the IPA server run
ipa-getkeytab -s [kdc DNS name]
-p host/[machine-name]
-e arcfour-hmac
-k krb5.keytab.[machine-name]
-P
At the prompt enter a random MACHINE_PASSWORD
(you will enter this later on the windows machine too).
Note: you can change the -e argument to include also
AESenctypesfromFreeIPA2.1.4andhigher. (FreeIPA ticket ``\ ```2038`` <https://fedorahosted.org/freeipa/ticket/2038>`__\ ``)
Note: Windows machines names cannot exceed 15 characters
-- pointed out by Han Boetes on 2013-01-03 on freeipa-users mailing list
Configure Windows (ksetup)#
1. ksetup /setdomain [REALM NAME] 2. ksetup /addkdc [REALM NAME] [kdc DNS name] 3. ksetup /addkpasswd [REALM NAME] [kdc DNS name] 4. ksetup /setcomputerpassword [MACHINE_PASSWORD] (the one used above) 5. ksetup /mapuser * * 6. Run gpedit.msc, open the key called: "Network Security: Configure encryption types allowed for Kerberos” under: Computer Configuration Windows Settings Security Settings Local Policies Security Options and deselect everything except RC4_HMAC_MD5 7. *** REBOOT *** 8. Add local user accounts for all users that need to be able to log in. 9. Log in as [user]@[REALM] with the initial password, you will be prompted to change the password then logged in.
Note: Configuring encryption types is not needed from FreeIPA 2.1.4
and higher. (FreeIPA ticket
2038)
The FreeIPA team thanks ‘Jimmy’ for providing this information on the
freeipa-users
mailing list. See mailing list archives for the original text. Several
amendments were made.
In most cases Windows desktops or servers will typically be joined to a Windows domain controller running Microsoft’s Active Directory, however this is not the only option.
It is possible to join Windows to a FreeIPA realm and then log into the Windows computer with an account from FreeIPA as it makes use of Kerberos for single sign on (SSO). FreeIPA is an open-source project sponsored by Red Hat, which attempts to provide similar functionality to Active Directory for Linux and Unix systems.
This may be a good option if you already run a large Linux or Unix environment, but need to have a small amount of Windows servers capable of using the same centrally managed user accounts.
We are assuming that you already have FreeIPA set up and ready to use. We will only be detailing how to configure the Windows operating system to join an existing Kerberos realm. In this example FreeIPA is setup on the example.com domain.
FreeIPA will only be providing the authentication service for our Windows server here with Kerberos. FreeIPA is not able to maintain an account database for Windows computers in the same manner that Active Directory does, so we therefore still need to create local Windows accounts for each user on the Windows computer, although they will have no passwords set in Windows.
Configure FreeIPA
Log into FreeIPA and under Identity, select Hosts. Click the +Add button to create a new host.
In this instance the hostname of our Windows computer is ‘windows’, we also specify the DNS domain afterwards. As FreeIPA is managing DNS for me, this is prefilled. if you are not using FreeIPA to manage DNS then you may need to manually enter the domain name.
Next on the FreeIPA server we need to run the ipa-getkeytab command to generate a keytab file for the Windows computer. In order to perform administrative tasks on the IPA server we must first authenticate, we do this with the kinit command and specify the IPA admin user, as shown below.
[root@ipa ~]# kinit admin Password for [email protected]:
You can run the ‘klist’ command afterwards to check that you have a valid ticket.
Now we can run the ipa-getkeytab command as shown below. The -s option is used to specify the IPA server, which in this example is ipa.example.com – the server we are running this command on. The -p option is used to specify the principal-name of the host, which in this case is ‘host/’ followed by the fully qualified domain name (FQDN) of the Windows computer that we added through the FreeIPA web interface previously. The -e option is used to specify the encryption type used to generate the keys, here we’re using arcfour-hmac. The -k option is used to specify the keytab file that we want to create, in this case the file krb5.keytab.windows will be made in the current working directory. Finally the -P option is used to specify the password for the key, you will need to remember this as we will enter it on the Windows computer later.
[root@ipa ~]# ipa-getkeytab -s ipa.example.com -p host/windows.example.com -e arcfour-hmac -k krb5.keytab.windows -P New Principal Password: Verify Principal Password: Keytab successfully retrieved and stored in: krb5.keytab.windows
If you get the error message “Kerberos User Principal not found. Do you have a valid Credential Cache?” be sure that you successfully ran the ‘kinit’ command.
Configure Windows
The Windows computer will need to be able to resolve the name of the IPA server with DNS, so ensure that Windows has appropriate DNS configuration for this. As my FreeIPA server is managing DNS, I have simply set the Windows machine to use FreeIPA for DNS.
On the Windows computer, open command prompt as administrator and run the below commands. Note that the Realm must be specified in capital letters, as this is the custom for realm names in Linux/Unix. In my example the realm is EXAMPLE.COM and the key distribution center (KDC) is the FreeIPA server, which for me is ipa.example.com
ksetup /setdomain [REALM] ksetup /addkdc [REALM] [KDC] ksetup /addkpasswd [REALM] [KDC] ksetup /setcomputerpassword [PASSWORD] ksetup /mapuser * *
Note that the Password above is the one that we set in the FreeIPA web interface for the host principal earlier. The /mapuser command will map all accounts within the EXAMPLE.COM Kerberos realm to any existing account of the same name on this Windows computer.
These changes will require a reboot, as you will be advised, hold off on this for now.
Next press the Windows key + R to open the Run window, type gpedit.msc and select OK. This will open up the Local Group Policy Editor for the machine.
From the Computer Configuration options, select Windows Settings > Security Settings > Local Policies > Security Options > Network Security: Configure encryption types allowed for Kerberos.
In this instance we will select everything except for the first two DES options. The official FreeIPA documentation claims to only require RC4_HMAC_MD5 selected, but I received an error regarding supported encryption types with only this enabled. Select Apply or OK to save the changes.
Once this is complete, reboot the Windows machine to apply the ksetup changes from earlier.
When the Windows machine is back up, create a local user account that maps to a user that exists in FreeIPA. In my example I have a user called ‘test’ that was created in the FreeIPA web interface, so I will create a user with the username of test in Windows. You do NOT need to set a password on this user account in Windows, as authentication will be handled by FreeIPA.
You can create a local user account by pressing the Windows key + R to open the Run window, and enter ‘mmc’ then select OK.
Once the MMC window opens, select File > Add/Remove Snap-in…
From the next window, select Local Users and Groups, then click the “Add >” button, followed by Finish, then OK. From here you can create your local user accounts in Windows. Remember, we do NOT want to add any passwords to these. The username also needs to match the username that exists in FreeIPA.
Configure Remote Desktop
By default a fresh user account will not be able to connect via remote desktop unless it has been given permission to do so. While you still have the Local Users and Groups console open through MMC, go to Groups and select the Remote Desktop Users group and add your user account that was just created to this group.
Before performing the first login, you’ll want to temporarily disable remote desktops Network Level Authentication (NLA) on the Windows server otherwise you will receive an error about NLA failing to contact a Windows domain controller on first login. This only seems to happen when logging into an account for the first time with an expired password that requires changing. Once the password has been set and is no longer in an expired state, logging in with NLA will work fine.
That’s it, you should now be able to log into Windows with this account. You will need to specify username@REALM to login, so if you’ve been following this example I’ll be using [email protected]. Don’t forget that the realm name must be in caps. Also by default when you create a new user account in FreeIPA the password will be in the expired state and will need to be changed on first login, as shown below.
By doing this we no longer need to access this singular Windows server with local user accounts, we can now access it with our accounts in the FreeIPA Kerberos realm. Granted we still have to create a local account on the Windows computer initially, however the authentication is handled centrally on the FreeIPA server using Kerberos, no passwords are stored on the Windows machine which can make credential management easier.
Troubleshooting
I had all sorts of different problems along the way while originally setting this up, so I have documented them all here along with associated solutions. In most cases the steps above should “just work”. Hopefully these solutions are useful, as most of these errors came from the Windows server, and of course when you perform a Google search for those errors you get solutions for fixing the problems in Windows, rather than answers relating to FreeIPA.
- There are currently no logon servers available to service the logon request.
For me this was due to a lack of DNS on the Windows server. The Windows server was not pointing to a DNS server that had the required records for FreeIPA. As I have set my FreeIPA server itself to provide DNS, the fix here was to simply use the FreeIPA server for DNS.If your instance of FreeIPA is not configured to manage DNS, it can be added on by installing the ipa-server-dns package. To set it up, run the ‘ipa-dns-install’ command and follow the prompts. As I was setting this up to manage DNS for the domain example.com, I received the below error message.
2016-12-29T04:27:00Z DEBUG The ipa-dns-install command failed, exception: ValueError: DNS zone example.com. already exists in DNS and is handled by server(s): a.iana-servers.net., b.iana-servers.net.
This was simply because DNS for the example.com domain exists out there on the Internet already. I temporarily changed the /etc/resolv.conf file to point to the FreeIPA server itself rather than an external DNS server and then ran ipa-dns-install again. During this process you can specify an external forwarder to use. If you already have some other DNS server that handles the records for your Kerberos realm, you’ll likely want to use this instead of configuring FreeIPA to manage DNS.
- The encryption type requested is not supported by the KDC.
When I attempted to Windows connect via remote desktop, I was asked to change my expired password. This is expected, as it is required for all new accounts created in FreeIPA by default. After entering my new password, I received the error “The encryption type requested is not supported by the KDC.” This was because originally in Windows I did not enable enough encryption types, with all selected except for the first two DES options as mentioned previously I was able to log in without further problems. Scroll up a little bit and take a loon at the section where we configured this. - preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed.
When trying to log in through remote desktop, I received some generic message about the login failing. Only when I checked the /var/log/krb5kdc.log file on the FreeIPA server did this make sense.
Dec 28 20:44:14 ipa.example.com krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.12: NEEDED_PREAUTH: [email protected] for kadmin/[email protected], Additional pre-authentication required
Dec 28 20:44:14 ipa.example.com krb5kdc[44950](info): preauth (encrypted_timestamp) verify failure: Decrypt integrity check failed
Dec 28 20:44:14 ipa.example.com krb5kdc[44950](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.12: PREAUTH_FAILED: [email protected] for kadmin/[email protected], Decrypt integrity check failed
If you know anything about Kerberos, you’ll know that it’s important for all servers to maintain the same time. In this case, my Windows server was in my local timezone of AEDT, but the FreeIPA server was in PST. I was able to resolve this by setting the timezone on the FreeIPA server with the below command so that it matched the time of the Windows server.
[root@ipa log]# date Wed Dec 28 20:45:04 PST 2016 [root@ipa log]# timedatectl set-timezone Australia/Sydney [root@ipa log]# date Thu Dec 29 15:46:29 AEDT 2016
I suggest our guide on configuring NTP in Linux if you need further assistance with this.
This one was fairly straightforward, after many login attempts while performing troubleshooting I locked out the account in FreeIPA. The /var/log/krb5kdc.log file on the FreeIPA server showed:
Dec 29 15:46:39 ipa.example.com krb5kdc[44950](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.12: CLIENT KEY EXPIRED: [email protected] for krbtgt/[email protected], Password has expired
Dec 29 15:46:49 ipa.example.com krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.12: LOCKED_OUT: [email protected] for kadmin/[email protected], Clients credentials have been revoked
While attempting to set a new password on first login with a new account, I was not choosing a strong enough password as per my FreeIPA password policy. This resulted in the below error message in the /var/log/kadmind.log file on the FreeIPA server. The solution was of course to use a stronger password.
Dec 29 15:54:58 ipa.example.com kadmind[44955](Error): password quality module empty rejected password for [email protected]: Empty passwords are not allowed Dec 29 15:54:58 ipa.example.com kadmind[44955](Notice): chpw request from 192.168.1.12 for [email protected]: Password is too short
I’m not exactly sure how I fixed this, basically the below is what showed in the /var/log/krb5kdc.log file on the FreeIPA server when the Windows server reported this error.
Dec 29 15:55:16 ipa.example.com krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.12: NEEDED_PREAUTH: [email protected] for krbtgt/[email protected], Additional pre-authentication required
Dec 29 15:55:16 ipa.example.com krb5kdc[44951](info): AS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.12: ISSUE: authtime 1482987316, etypes {rep=18 tkt=18 ses=18}, [email protected] for krbtgt/[email protected]
Dec 29 15:55:16 ipa.example.com krb5kdc[44951](info): TGS_REQ (7 etypes {18 17 23 3 1 24 -135}) 192.168.1.12: UNKNOWN_SERVER: authtime 0, [email protected] for krbtgt/[email protected], Server not found in Kerberos database
Basically I reran the ksetup commands mentioned above, performed the reboot again, and everything was fine, so it’s possible I had some sort of typo the first time around or that my DNS was not properly configured the first time I ran through the ksetup commands. Other things to check would be that the host principal in FreeIPA correctly matches the hostname of the Windows server and the value specified in the -p option when running ipa-getkeytab.
The solution, as advised, is to disable NLA on the Windows computer. This will fail as there is no Windows domain controller to contact as we’re using FreeIPA. I have found that this is only a problem when connecting with remote desktop with a new account for the first time. After the first login and the expired password for the account has been reset, turning NLA back on seems to work without issue. Note that leaving NLA on may be problematic in the future when an accounts password expires. As long as you change the password on some other Linux server or directly in FreeIPA itself this should not be a problem and you should be fine to leave NLA enabled.
For any other connectivity issues, I’d recommend confirming the firewall on your FreeIPA server is allowing the necessary ports through from the Windows server. There are a fair amount of ports required for everything to work nicely, if in doubt you can try temporarily disabling your firewall and testing again as this should either confirm or deny whether or not the firewall was the issue. If it was, simply check the firewall logs and view the traffic that is being dropped, or better yet just do this rather than temporarily reducing your security by disabling the firewall.
Summary
To get the full features that Microsoft Windows offers, it is recommended that you join the Windows machine to an Active Directory domain. However if this is not practical due to a small number of Windows machines in your environment, it is possible to perform the steps above in order to log into Windows using user credentials from FreeIPA by using Kerberos, providing us with single sign on.
While that sounds good in theory this solution can often be difficult to get working correctly, as you have seen in the troubleshooting section above I had my fair share of random errors during the setup process.
Окружение
- Astra Linux Special Edition 1.6
- Astra Linux Special Edition 1.7 Update 2 (№ 2022-0819SE17)
- Astra Linux Common Edition 2.12
- ПК СВ «Брест» 2.9 Astra Linux Special Edition 1.6 Update 9 (№ 20211008SE16)
Вопрос
Возможно ли ввести в домен FreeIPA рабочие станции с ОС Windows 10?
Ответ
FreeIPA не поддерживает ввод в домен рабочих станций с ОС Windows.
Вариант ограниченного взаимодействия Windows-систем с FreeIPA-доменом на уровне Kerberos приведен в статье.
Подготовка
- Выключите старый контроллер домена клиентские ВМ.
- Склонируйте новые клиентские ВМ и подготовьте их к введению в домен.
- Склонируйте ВМ tmpl-rocky9-server в lin-dc.
- Настройте статический ip-адрес 10.20.30.10.
nmtui - Проверьте FQDN-имя в /etc/hostname и /etc/hosts
- Отключите SELinux:
setenforce 0
nano /etc/selinux/config
SELINUX=disabled- Отключите firewalld:
systemctl disable firewalld - Перезагрузите ВМ.
- Включите синхронизацию времени с ntp-сервером.
Установка FreeIPA
- Установите необходимые пакеты:
dnf update && dnf install ipa-server ipa-server-dns - Запустите установочный скрипт:
ipa-server-install
Do you want to configure integrated DNS (BIND)? [no]: yes
Server host name [lin-dc.lab.lan]:
Please confirm the domain name [lab.lan]:
Please provide a realm name [LAB.LAN]:
Directory Manager password: specialist
Password (confirm): specialist
IPA admin password: specialist
Password (confirm): specialist
Do you want to configure DNS forwarders? [yes]:
Following DNS servers are configured in /etc/resolv.conf: 77.88.8.8
Do you want to configure these servers as DNS forwarders? [yes]:
All detected DNS servers were added. You can enter additional addresses now:
Enter an IP address for a DNS forwarder, or press Enter to skip: 77.88.8.1
DNS forwarder 77.88.8.1 added. You may add another.
Enter an IP address for a DNS forwarder, or press Enter to skip:
DNS forwarders: 77.88.8.8, 77.88.8.1
Do you want to search for missing reverse zones? [yes]:
Checking DNS domain 30.20.10.in-addr.arpa., please wait ...
Do you want to create reverse zone for IP 10.20.30.10 [yes]:
Please specify the reverse zone name [30.20.10.in-addr.arpa.]:
Checking DNS domain 30.20.10.in-addr.arpa., please wait ...
Using reverse zone(s) 30.20.10.in-addr.arpa.
NetBIOS domain name [LAB]:
Do you want to configure chrony with NTP server or pool address? [no]:
Continue to configure the system with these values? [no]: yes
- Проверьте работоспособность KDC.
Ввод Linux-клиента в домен FreeIPA
- Введите клиентов в домен:
apt update && apt install freeipa-client
ipa-client-install --mkhomedir --enable-dns-updates - Откройте веб-интерфейс FreeIPA по адресу https://lin-dc.lab.lan и создайте трех пользователей — director, manager и support.
- На lin-dc отключите требование смены пароля при первом входе:
kinit admin
ipa user-mod LOGIN --setattr=krbPasswordExpiration=20241231235959Z - Проверьте возможность получения тикета на клиентской машине под любой из учетных записей.
- Перезагрузите машину.
- Авторизуйтесь на клиентской машине под любым из них.
Ввод Windows-клиента в домен FreeIPA
- В веб-интерфейсе FreeIPA перейдите в раздел Hosts.
- Добавьте новый хост, указав имя машины и ip.
- Перейдите в консоль FreeIPA и сгенерируйте новый ключ для принципала:
kinit admin
ipa-getkeytab -s lin-dc.lab.lan -p host/win-client.lab.lan@LAB.LAN -e aes256-cts,aes128-cts,aes256-sha2,aes128-sha2,camellia256-cts-cmac,camellia128-cts-cmac -k /etc/krb5.keytab -P - Проверьте список принципалов:
klist -k - Проверьте статус хоста в веб-интерфейсе FreeIPA.
- На машине WIN-CLIENT выполните следующие команды:
ksetup /setdomain LAB.LAN
ksetup /addkdc LAB.LAN lin-dc.lab.lan
ksetup /addkpasswd LAB.LAN lin-dc.lab.lan
ksetup /setcomputerpassword specialist
ksetup /mapuser * * - На машине WIN-CLIENT запустите gpedit.msc и настройте параметр:
Windows Settings > Security Settings > Local Policies > Security Option
Network Security: Configure encryption types allowed for Kerberos
Разрешите все, кроме DES*
- Перезагрузите ВМ и авторизуйтесь под доменной учеткой, явно указав realm. (support@LAB.LAN).
Для того, чтобы не указывать realm полностью, воспользуйтесь следующим конфигом:
