Обсуждение статьи "Как правильно сформировать keytab-файл с несколькими SPN..."

[egor]

Оставляйте свои замечания и комментарии к статье Егора Левинца "Как правильно сформировать keytab-файл с несколькими принципалами сервисов в среде Active Directory" (http://pro-ldap.ru/art/levintsa/20160420-ktpass/)

[smake]

Небольшой скрипт для автоматизации.

Код: [Выделить]

#https://pro-ldap.ru/art/levintsa/20160420-ktpass/

$pass = -join ((65..90) + (97..122) | Get-Random -Count 12 | % {[char]$_})
$pass

$domain = "TEST.LOCAL"
$domainl = $domain.ToLower()
$lhostname = "www"
$ip = "192.168.1.3"
$fqdn = $lhostname + "." + $domain.ToLower()
$dc1, $dc = $domain.ToLower().Split(".")
$dc1u = $dc1.ToUpper()


#adding object "Computer" to ad Computers
dsadd computer "CN=$lhostname,CN=Computers,DC=$dc1,DC=$dc"

#setting two default spn
setspn -A HTTP/$domainl@$domain $lhostname
setspn -A HTTP/$fqdn@$domain $lhostname
setspn -A HTTP/$lhostname@$domain $lhostname

#setting password for computer with name lhostname and generating tmp keytab
ktpass.exe /princ HTTP/$domainl@$domain /mapuser $dc1u\$lhostname$ /ptype KRB5_NT_SRV_HST /pass "$pass" /out krb5.tmp.keytab +answer

#taking current kvno
$kvno = Get-ADComputer $lhostname -property msDS-KeyVersionNumber | select -Expand msDS-KeyVersionNumber

#adding second spn to new keytab
ktpass.exe /princ HTTP/$lhostname@$domain /mapuser $dc1u\$lhostname$ /ptype KRB5_NT_SRV_HST /pass "$pass" -setpass /kvno $kvno /in krb5.tmp.keytab /out krb5.tmp.keytab -setupn
ktpass.exe /princ HTTP/$fqdn@$domain /mapuser $dc1u\$lhostname$ /ptype KRB5_NT_SRV_HST /pass "$pass" -setpass /kvno $kvno /in krb5.tmp.keytab /out krb5.keytab -setupn

#cleaning
rm krb5.tmp.keytab
mv .\krb5.keytab .\Desktop

#adding dns records
Add-DnsServerResourceRecordA -Name $lhostname -ZoneName $domainl -AllowUpdateAny -IPv4Address $ip -CreatePtr

[egor]

Спасибо, интересно!

Я далёк от PowerShell, поэтому дилетантский вопрос: Вы не пробовали найти командлеты-аналоги для setspn и ktpass? Ну и уж наверняка можно найти замену для dsadd и rm/mv .

Егор

[smake]

Честно говоря нет, я и сам далек от powershell, закончил на cmd =)
mv/rm - привычные для меня unix команды, поэтому использовал их. (да и оно работает на 2016)
Но спасибо за наводку, посмотрю, отпишусь сюда, если найду.

[Aleksey.Maksimov]

Здравсвуйте, Егор.
 
Прочитал Вашу статью и у меня возникают большие сомнения относительно правильности использования метода, когда добавляется SPN с именем домена (без имени хоста или сервиса) к какой-либо учётной записи (имеется ввиду HTTP/windom.net@WIMDOM.NET).
А что Вы будете делать, когда потребуется создать аналогичные записи для других сервисов или серверов?
Повторное создание SPN с именем HTTP/windom.net@WIMDOM.NET для другой учётной записи уже будет выглядеть как явная ошибка, с точки зрения той же утилиты setspn, так как перед регистрацией SPN она всегда проверяет уникальность SPN-записей во всём каталоге Active Directory.

[egor]

Здравствуйте! А с какой целью Вы планируете добавлять ещё одну запись с тем же самым SPN?

Егор

[Aleksey.Maksimov]

Егор, наверно Вы меня не поняли.

Вы пишете статью про "правильное" формирование keytab-файла и при этом описываете то, что в keytab включается помимо SPN-записи с fqdn сервера(или службы) ещё и SPN-запись с fqdn имеми домена оправдывая это "удобстовом" (типа теперь вообще можно будет разные имена использовать на веб-сервере). Но смысл в том, что это неправильно и так делать нельзя. Это противоречит логике управления SPN в Active Directory.
Представьте, что условно завтра Вам потребуется развернуть ещe 2,3,4... новых веб-сервера аналогичных, и чтобы для каждого сервера поддерживалась кучка разных SPN...и следуя Вашей логике, можно будет сделать аналогичные keytab-файлы для каждого из этих серверов. Но это совсем не так, ибо утилиты управления SPN проверяют уникальность SPN-записей во всём домене.
Вы можете проверить это сами. Просто попытайтесь вручную создать одну и туже SPN-запись вида HTTP/windom.net@WIMDOM.NET двум разным учётным записям.

setspn -A HTTP/windom.net SERVER1
setspn -A HTTP/windom.net SERVER2

[egor]

Простите, если ввёл Вас в заблуждение словом "правильно" =) . Оно относилось лишь работе с неочевидными возможностями инструмента ktpass, чтобы кто-то, решающий задачу формирования keytab-файла с несколькими SPN, избежал тех плясок вокруг KVNO, с которыми столкнулся я сам. Ни в коем случае я не претендую на "правильность" распределения сервисов по серверам или планирования dns-именования. Вообще, в unix-среде не принято позиционировать свои решения как единственно правильные =) .

С другой стороны, это решение оказалось жизнеспособным, уже сколько лет прошло, а ребята не жалуются =) . Вполне логично, если в конторе WINDOM Inc обращаются на корпоративный сайт по адресу http://windom.net , а не http://webserver.windom.net .

... описываете то, что в keytab включается помимо SPN-записи с fqdn сервера(или службы) ещё и SPN-запись с fqdn имеми домена оправдывая это "удобстовом" (типа теперь вообще можно будет разные имена использовать на веб-сервере)...

Перечитал статью, про подобное "удобство" там не сказано ни слова =( . Речь шла о том, что если www и sandbox являются CNAME для webserver, то для них не нужно добавлять отдельные SNP в keytab-файл, достаточно SPN для webserver.

Но смысл в том, что это неправильно и так делать нельзя. Это противоречит логике управления SPN в Active Directory.
Представьте, что условно завтра Вам потребуется развернуть ещe 2,3,4... новых веб-сервера аналогичных, и чтобы для каждого сервера поддерживалась кучка разных SPN...и следуя Вашей логике, можно будет сделать аналогичные keytab-файлы для каждого из этих серверов. Но это совсем не так, ибо утилиты управления SPN проверяют уникальность SPN-записей во всём домене.
Вы можете проверить это сами. Просто попытайтесь вручную создать одну и туже SPN-запись вида HTTP/windom.net@WIMDOM.NET двум разным учётным записям.

setspn -A HTTP/windom.net SERVER1
setspn -A HTTP/windom.net SERVER2

Охотно соглашусь, что Вы правы. Но снова хочу спросить: зачем так делать? Или лучше так: кто в здравом уме будет пытаться внедрять такой нелепый dns-план? Мне кажется, Ваши опасения немного преувеличены.

Егор