Root key что это

Создание корневого ключа служб распространения ключей (KDS)

В этой статье ИТ-специалист описывается, как создать корневой ключ службы распространения ключей Майкрософт (kdssvc.dll) на контроллере домена с помощью Windows PowerShell для создания паролей управляемой учетной записи службы в Windows Server 2012 или более поздней версии.

Контроллеры домена (DC) требуют корневого ключа для начала создания паролей gMSA. Групповые управляемые учетные записи служб создаются только через 10 часов после создания ключа, чтобы все контроллеры доменов успели выполнить схождение своих репликаций Active Directory. Ожидание до 10 часов является мерой безопасности, чтобы предотвратить создание паролей до того, как все контроллеры домена в среде могут отвечать на запросы gMSA. Попытка использовать gMSA слишком скоро может завершиться ошибкой, когда узел gMSA пытается получить пароль, так как ключ, возможно, не был реплика добавлен ко всем контроллерам домена. Ошибки извлечения паролей gMSA также могут возникать при использовании контроллеров домена с ограниченными расписаниями реплика или при возникновении проблемы с реплика.

Удаление и повторное восстановление корневого ключа может привести к проблемам, когда старый ключ продолжает использоваться после удаления из-за кэширования ключа. Служба распространения ключей (KDC) должна быть перезапущена на всех контроллерах домена, если корневой ключ повторно создан.

Минимальным требованием для выполнения этой процедуры является членство в группе Администраторы домена, Администраторы предприятия или другой эквивалентной группе. Дополнительные сведения об использовании подходящих учетных записей и участия в группах см. в разделе Локальные группы и группы домена по умолчанию.

Для выполнения команд Windows PowerShell, которые используются для администрирования групповых управляемых учетных записей служб, необходима 64-разрядная архитектура.

Создание корневого ключа KDS с помощью командлета Add-KdsRootKey

1. На контроллере домена Windows Server 2012 или более поздней версии запустите Windows PowerShell на панели задач.
2. Введите следующие команды в командную строку Windows PowerShell и нажмите клавишу ВВОД: Add-KdsRootKey -EffectiveImmediately

Совет Для предоставления контроллерам доменов достаточного времени для получения ключей перед их использованием можно использовать параметр «Срок действия». Использование Add-KdsRootKey -EffectiveImmediately добавит корневой ключ к целевому контроллеру домена, который будет использоваться службой KDS немедленно. Однако другие контроллеры домена не смогут использовать корневой ключ до тех пор, пока реплика не будет успешно выполнено.

Корневые ключи KDS хранятся в Active Directory в контейнере CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=; . У них есть атрибут msKds-DomainID, который связывается с учетной записью компьютера контроллера домена, создавшего объект. Если этот контроллер домена понижен и удален из домена, значение будет ссылаться на могилу учетной записи компьютера. Вы можете игнорировать сломанное значение, так как оно используется только для того, чтобы помочь администратору отслеживать объект при его создании. Вы также можете изменить значение атрибута и указать его на объект компьютера другого контроллера домена в лесу.

В тестовых средах с одним контроллером домена можно создать корневой ключ KDS и установить начальную дату в прошлом, выполнив указанные ниже действия. Это позволит избежать периода ожидания для генерирования ключа. Убедитесь, что событие 4004 было зарегистрировано в журнале событий KDS.

Создание корневого ключа KDS в тестовой среде для незамедлительного использования

1. На контроллере домена Windows Server 2012 или более поздней версии запустите Windows PowerShell на панели задач.
2. Введите следующие команды в командную строку Windows PowerShell и нажмите клавишу ВВОД: $a=Get-Date$b=$a.AddHours(-10)Add-KdsRootKey -EffectiveTime $b Либо введите одну команду: Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

Что такое ТРМ ( Trusted Platform Module) ?

Доверенный платформенный модуль (TPM) – это микросхема, предназначенная для реализации основных функций, связанных с обеспечением безопасности, главным образом с использованием ключей шифрования. Модуль TPM обычно установлен на материнской плате настольного или переносного компьютера и осуществляет взаимодействие с остальными компонентами системы посредством системной шины.
Компьютеры, оснащенные модулем TPM (рис. 1), имеют возможность создавать криптографические ключи и зашифровывать их таким образом, что они могут быть расшифрованы только модулем TPM (рис. 2). Данный процесс, часто называемый «сокрытием» ключа («wrapping» key) или «привязкой» ключа («binding» key), помогает защитить ключ от раскрытия. В каждом модуле TPM есть главный скрытый ключ , называемый ключом корневого хранилища (Storage Root Key, SRK), который хранится в самом модуле TPM. Закрытая часть ключа, созданная в TPM, никогда не станет доступна любому другому компоненту системы, программному обеспечению, процессу или пользователю.

Компьютеры, оснащенные модулем TPM, также могут создавать ключи, которые будут не только зашифрованы, но и привязаны к определенной системной конфигурации . Такой тип ключа может быть расшифрован только в том случае, если характеристика платформы, на которой его пытаются расшифровать, совпадает с той, на которой этот ключ создавался. Данный процесс называется «запечатыванием» ключа в модуле TPM. Дешифрование его называется «распечатыванием» («unsealing»). Модуль TPM также может запечатывать и распечатывать данные, созданные вне модуля TPM. При использовании запечатанного ключа и такого программного обеспечения, как BitLocker™ Drive Encryption, Вы можете обеспечить блокировку данных до тех пор, пока они не будут перенесены на компьютер с подходящей аппаратной или программной конфигурацией.

При использовании модуля TPM закрытая часть пар ключей хранится вне памяти, доступ к которой имеет операционная система. Ключи могут быть запечатаны модулем TPM, при этом точное решение о том, является ли система надежной, будет принято до того, как ключи будут распечатаны и готовы к использованию. Поскольку модуль TPM для обработки инструкций использует собственное встроенное программное обеспечение и логические схемы , его работа не зависит от операционной системы. Благодаря этому обеспечивается его защита от возможных уязвимостей внешнего программного обеспечения.

К омпьютеры с ОС Windows 8.1 уже поддeрживали функцию Trusted Computing с установкой чипа Trusted Platform Module (TPM). Если раньше поддержка TPM была опциональной и отключаемой, то с пeреходом на спецификации TPM 2.0 этот стандарт стал обязательным для всех устройств под Windows 8.1 и функция не пoдлежит дезактивации.

Trusted Platform Module (TPM) — криптопроцессор, в котором хранятся криптогpафические ключи для защиты информации. Библиотека TPM в операционной системе преднaзначена для проверки цифровой подписи программ, для установки апдейтов в диcтанционном режиме и т.д. Фактически, компьютер с TPM 2.0 нельзя рассматривать как устройство, нaходящееся под полным контролем пользователя.

Спецификации TPM разpаботаны некоммерческой организацией Trusted Computing Group, в кoторую входят только американские компании AMD, Cisco, Hewlett-Packard, IBM, Intel, Microsoft и Wave Systems. Незавиcимые эксперты предупреждали, что TPM можно рассматривать как бэкдoр и есть большая вероятность, что доступ к криптографическим ключам имеет Агентство нaциональной безопасности.

Компания Microsoft объявила, что с янвaря 2015 года поддержка стандарта TPM 2.0 станет обязательной для всех сертифицировaнных устройств Windows ( Федеральное управление по информациoнной безопасности Германии опубликовало , в котором опровергло информацию о том, что ее эксперты когда-либо предупреждали кого-либо об опасности установки Windows 8, хотя и признали нaличие некоторых сомнений относительно связки Windows 8 с аппаратным обеспечением TPM 2.0).

Почему SSH-ключ — безопасная альтернатива паролю

Рассказываем о SSH-ключах: какие бывают, как генерировать и где хранить.

Мы используем пароли, чтобы войти в учетную запись в соцсети, почту, панель управления Selectel. С помощью пароля также можно зайти на арендованный сервер. У этого, правда, есть весомые недостатки. О них и более безопасной альтернативе — SSH-ключах — мы расскажем в тексте.

Пароли: их особенности и минусы

Связка логин/пароль используется для авторизации в системе. Проще говоря, для того, чтобы приложение, операционная система — все, что стоит за окошком с вводом пароля, поняло, что вы — это действительно вы.

Пароли — это привычно и просто. Но их использование влечет ряд недостатков:

• Пароль можно подобрать. Часто мы выставляем пароли, которые легко запомнить. А значит, это какие-то сочетания слов или цифр. Есть способы создать более безопасный пароль — использовать случайный набор букв и цифр, генерировать длинный пароль. Но это приводит к следующей проблеме.
• Безопасные пароли, особенно если их много, практически невозможно запомнить. В итоге, если вы все-таки забыли какой-то из них, придется тратить время и силы на восстановление.
• Часто (как раз из-за пункта 2) люди останавливают один и тот же «проверенный» пароль на множество аккаунтов. В итоге, если пароль «утечет», злоумышленник получит доступ сразу к нескольким вашим аккаунтам.
• Наконец, связку логин/пароль можно подсмотреть.

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

Добавим, что серверы — очень популярная цель для злоумышленников. Поскольку они постоянно «смотрят» в интернет, машины подвергаются брутфорсу, или подбору паролей. По наблюдениям специалистов Selectel первая атака на сервер начинается спустя 10-15 минут после его появления в сети.

SSH для подключения к серверу

Большинство пользователей устанавливает на серверы операционную систему Linux, а подключаются к ним по SSH.

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

SSH-ключи: какие бывают и как работают

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

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

Для аутентификации нужно два SSH-ключа — открытый и закрытый.

Открытый ключ

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

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

Закрытый ключ

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

Теперь разберемся, как открытый и закрытый ключи применяются при использовании протокола SSH.

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

По сути, между клиентом и сервером происходит небольшая «перекличка», по которой сервер определяет, свой перед ним или чужой. Достаточно просто это изображено на схеме:

Преимущества SSH-ключей

Использовать SSH-ключи безопаснее, чем связку логин/пароль. Давайте перечислим почему:

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

• Приватный SSH-ключ недоступен из внешней сети. Пароль-фраза будет необходима исключительно для идентификации пользователя на сервере.

• Закрытый ключ стандартно находится в каталоге, к которому у обычного пользователя нет доступа (в случае Unix-подобных систем).

• Для кражи приватного ключа злоумышленник должен иметь полный доступ к правам администратора операционной системы. Другими словами, необходим доступ к привилегиям sudo. Как правило, они есть, например, у пользователя root или того, кому аналогичные привилегии были назначены вручную.

Как мы писали выше, при создании ключа можно дополнительно зашифровать приватный ключ паролем. Его нужно будет ввести, чтобы посмотреть или скопировать SSH-ключ. В итоге, даже если злоумышленники получат доступ к root, им понадобятся дополнительные усилия для подбора пароля. Установка пароля является необязательным шагом, но он существенно повысит безопасность.

Кроме того, ключи довольно просто использовать. SSH-ключ устанавливается (сохраняется) единоразово, его не нужно вводить каждый раз, как это было бы в случае пароля. Но нужно учитывать, что если вы запаролили доступ к SSH-ключу, то этот пароль придется вводить каждый раз.

Где хранить SSH-ключи

Итак, мы поняли, что стоит озаботиться правильным хранением закрытого SSH-ключа. Есть несколько вариантов.

• Можно хранить ключи на разного рода внешних накопителях — флешки, съемные SSD-диски и т.д. Естественно, они должны храниться в защищенном месте. Носить флешку с SSH-ключами в качестве брелка на ключах точно не стоит.
• Также можно хранить ключ на виртуальном диске. Нельзя назвать это полноценно безопасным вариантом, зато в случае утечки данных злоумышленникам еще нужно будет понять, куда можно применить SSH-ключ.
• Подойдут для этих целей и специальные менеджеры паролей, которые заточены на их хранение. Например, Bitwarden, Keeper, Passbolt и другие. К выбору ПО тоже стоит подойти ответственно.
• Если вы клиент Selectel, можете воспользоваться менеджером секретов. Сервис сейчас в бете, что влияет на его функциональность, однако хранить SSH-ключи в нем можно. На их защите — двухфакторная аутентификация панели управления my.selectel.

Как использовать SSH-ключ

Чтобы соединяться с сервером по SSH-ключу, его нужно сгенерировать. Как это сделать достаточно быстро, мы подробно описали в инструкции. В Selectel этот ключ можно указать сразу при заказе выделенного или облачного сервера.

Установить SSH-ключ на сервере можно и с помощью терминала (CLI). В каталоге, где располагается пара ключей, нужно скопировать сгенерированный публичный SSH-ключ и вставить в список авторизованных публичных ключей на сервере. В папку /home/username/.ssh/authorized_keys, где username – ваше имя пользователя.

Аутентификация с использованием SSH-ключа

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

Подключиться к серверу при помощи SSH-ключа можно с помощью команды:

~$ ssh -i username@server IP

Чтобы каждый раз не указывать путь, достаточно скопировать закрытый ключ в папку /home/имя пользователя/.ssh.

Если вы подключаетесь к серверу впервые, появится следующее сообщение:

Компьютер не узнает удаленный сервер. Это нормально для первого подключения. Необходимо в ответном сообщении ввести yes и продолжить, нажав кнопку Enter. Если ранее вы не указывали пароль для шифрования ключей, вы подключитесь и авторизуетесь на сервере автоматически.

Разместите SSH-ключ на облачном сервере Selectel

Для безопасного подключения по зашифрованному протоколу SSH

Отключение аутентификации по паролю на сервере

Без отключения входа по логину и паролю использование SSH-ключей теряет большую часть преимуществ. Поэтому рекомендуем отключить аутентификацию по паролю.

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

Если ключ не будет установлен, а вы отключите аутентификацию по паролю, вы потеряете доступ к серверу. Восстановить его получится лишь из-под пользователя root или другого администратора с привилегиями sudo.

Итак, отключаем аутентификацию по паролю. Подключаемся к удаленному серверу по SSH-ключу. Открываем файл с SSH-конфигурацией, выполнив в терминале следующую команду:

sudo nano /etc/ssh/sshd_config

В файле будет находиться параметр PasswordAuthentication, отмечаемый во многих случаях как комментарий. Символ однострочного комментария (#), находящийся перед названием параметра, необходимо удалить. После – отключить действие параметра, поставив ему значение no.

Сохраните файл и перезапустите службу SSH, чтобы применить изменения.

В ОС Ubuntu или Debian необходимо выполнить данную команду:

sudo service ssh restart

В ОС CentOS/Fedora название службы SSH – sshd. Команда для выполнения перезапуска службы будет исполнятся в таком виде:

sudo service sshd restart

Проделав эти шаги, вы перенастроите службу SSH так, чтобы при аутентификации использовались только ключи.

Заключение

SSH-ключи — хороший способ обезопасить свой сервер от взлома злоумышленниками и разграничить уровни доступа к инфраструктуре среди пользователей. Их легко генерировать, легко хранить и использовать. Чтобы пользоваться всеми преимуществами ключей, рекомендуем оставить только этот способ получения доступа к серверу.

Managed Service Accounts в Windows Server 2016

Ранее я написал обзорную статью про MSA в Windows Server 2008 R2. Теперь, так как вышли новые версии платформы Windows Server, надо добавлять. Ведь есть что, и очень даже интересное. Это – обновлённая версия статьи; оригинальная была написана по Windows Server 2012 RTM, данная уже учитывает существование и Windows Server 2012 R2, и Windows Server 2016.

Работаем с Managed Service Accounts

• Зачем нужны MSA
• Функционал MSA – обычных MSA и современных gMSA
• Подготавливаем лес Active Directory к работе с MSA и gMSA
• Включаем и настраиваем Key Distribution Services
• Создаём gMSA на Windows Server 2012 и выше
• Дополнительные возможности

Зачем нужны MSA

Изначально в Windows NT такого понятия, как “специальный вид учётной записи для приложения-сервиса” не существовало. Была системная учётка SYSTEM , которая олицетворяла собой Одина, Будду, Ктулху и прочих интересных личностей в одном флаконе. Эта учётная запись была неявно включена в BUILTIN\Administrators и обладала всеми правами на системе, которые могут быть – ну а если чем-то не обладала, так от её лица можно было сделать take ownership на любом объекте, имеющем ACL, и в результате всё ж обладать всеми правами. От этой учётки работали все системные процессы, а также запускались сервисы – но подчеркну, сделана она была не именно для запуска сервисов, а чтобы олицетворять “всю систему”.

Вы могли запускать сервисы как от неё, так и от обычной учётной записи пользователя – это менялось в настройках примерно так же, как меняется сейчас:

Пример сервиса, запускающегося от учётной записи SYSTEM
(кликните для увеличения до 406 px на 468 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Да и сервисы свои вы тоже могли создавать, для этого была специальная утилитка srvany, входившая в состав Resource Kit.

Вроде как всё хорошо, но на самом деле – проблемы.

Первая и очевидная состояла в небезопасности выдачи всех-всех-всех прав в системе любому приложению, которому надо было запускаться на фоне. Допустим, берём сервис DHCP Client. Что ему нужно от системы? Возможность доступа к сети, притом небольшую совсем, да возможность записи конфигурации в некоторые ветки реестра (где хранятся настройки сетевых интерфейсов). Всё, что он делает – обменивается несколькими видами ethernet-кадров, да пишет Надо ли ему доступ ко всем данным на всех дисках? К созданию пользователей и смене прав? К раздаче системных привилегий типа “shut down from remote system”? Нет конечно, зачем. Но всё это выдаётся, если работаешь от SYSTEM .

• Надо старательно выдать этой учётной записи только минимально нужные для этой операции права и запретить изначально разрешаемые ей, но не нужные в данном сценарии использования (например, запретить сетевой вход);
• Надо периодически менять у этой учётной записи пароль, а также сделать его стойким;
• Пароль к этой учётной записи будет храниться в системе в виде открытого текста (надо ж при запуске сервиса сымитировать log on as a service, поэтому надо предоставить связку логин-пароль в исходном варианте);
• Пароль может использоваться в нескольких местах (например, когда данная служба на нескольких серверах работает), и доступ к нему возможен на любом из этих серверов от любой учётной записи с правами локального администратора;

Всё это неудобно, небезопасно, заставляет тратить лишнее время, и зачастую сводится к “разово сделаем пароль, поставим галочку, чтобы мозг не конопатил, выдадим права локального админа этой учётке и забудем”.

Managed Service Accounts – MSA (я буду говорить уже именно про новые, gMSA, появившиеся в Windows Server 2012, новая буква g – это Group) – позволяют решить все эти проблемы.

Функционал MSA – обычных MSA и современных gMSA

Managed Service Accounts будут различаться – самый первый вариант, появившийся в Windows Server 2008 R2 (про него предыдущая статья про MSA), будет уметь работать только с одним сервером, и, так как в следующей же операционной системе, Windows Server 2012, появились gMSA, лишённые этого ограничения, речь пойдёт сразу же про них. Называть я их буду MSA, без буквы g, так проще.

• Проблема с минимизацией прав упростилась – MSA – это не пользовательская учётка, выкорчёвывать лишние полномочия не нужно, изначально на локальной системе никаких прав у MSA нет, громоздкий профиль, как пользователь, при логине, она тоже не создаёт. Вы просто добавляете её в нужные группы, чтобы предоставить соответствующие задаче права и полномочия.
• Периодичность смены пароля у MSA задаётся через групповые политики и проводится автоматически.
• Пароль у MSA генерится очень стойкий – 240 символов, половина латинские буквы, половина – цифры. Такой пароль нет смысла подбирать bruteforce’ом, потому что это займёт времени больше, чем линейный перебор всех значений хэша.
• При использовании MSA на нескольких серверах проблемы со сменой пароля также нет – всё делается автоматически.

Из дополнительных преимуществ – MSA использует только Kerberos, поэтому хоть NTLM дополнительно обезопасить можно, в случае с MSA это просто не нужно – проблем с безопасностью LM, NTLMv1 и NTLMv2 у этих учёток нет.

В результате получается очень удобный вид учётных записей для упрощения обслуживания и улучшения ситуации с безопасностью.

Подготавливаем лес Active Directory к работе с MSA и gMSA

Домиком для всех видов MSA – обычных, которые msDS-ManagedServiceAccount , и новых, которые msDS-GroupManagedServiceAccount – будет контейнер CN=Managed Service Accounts,DC=контекст домена , находящийся в корне domain partition вашего домена:

Контейнер Managed Service Accounts в корне domain partition
(кликните для увеличения до 754 px на 530 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Для работы MSA надо будет также включить специальный сервис на выбранном хосте, который будет отвечать за централизованное управление паролями. Этот сервис будет называться KDS – Key Distribution Services.

Необходимые для работы этого сервиса объекты в Active Directory будут создаваться либо сразу, когда поднимается новый лес, либо когда идёт /forestprep при установке первого DC на базе Windows Server 2012. Проверить, что данные операции на уровне леса прошли удачно, можно отследить по трекеру Forest Updates – зайдите в ADSI-редактор и откройте вот такой контейнер:

Просматриваем Forest Updates в лесу Active Directory
(кликните для увеличения до 876 px на 579 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Там, конечно, много всяких других, благо с 2000го Windows Server в Active Directory изменения есть, но нам надо, чтобы были все эти 4 – это будет обозначать, что дефолтные объекты для работы Key Distribution Services были созданы.

Дополнительно можно глянуть рядом расположенный объект, CN=ActiveDirectoryUpdate,CN=ForestUpdates,CN=Configuration,DC=atraining,DC=z . Он будет содержать атрибут revision – нам надо, чтобы этот атрибут был как минимум 11 .

Проверяем версию Forest Updates в Active Directory
(кликните для увеличения до 414 px на 462 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Если всё ОК, то продолжаем.

Включаем и настраиваем Key Distribution Services

Начиная с Windows Server 2012, в Active Directory появляется новый контейнер для хранения данных, находящийся в лесном разделе Configuration:

Контейнер Group Key Distribution Services в Configuration
(кликните для увеличения до 768 px на 537 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Обращающиеся к нему сервисы работают на всех DC под управлением Windows Server 2012 и старше, технически выглядят как вызываемые из библиотеки kdssvc.dll функции по управлению ключевой информацией. Эти функции и будут составлять собой Microsoft Key Distribution Services.

Внутри контейнера CN=Group Key Distribution Service есть два других – один для общих настроек Microsoft Key Distribution Services, называется Server Configuration :

Контейнер Server Configuration в Group Key Distribution Services
(кликните для увеличения до 768 px на 537 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

а второй – для самих ключей, он будет называться Master Root Keys :

Контейнер Master Root Keys в Group Key Distribution Services
(кликните для увеличения до 768 px на 537 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Server Configuration

Здесь будет находиться единственный объект с названием Group Key Distribution Service Server Configuration , класса msKds-ProvServerConfiguration . Из интересного в нём разве что атрибут msKds-Version , равный единице со времён Windows Server 2012 – двойка пока нигде, включая Windows Server 2016 TP5, не обнаружена.

Атрибуты Group Key Distribution Service Server Configuration
(кликните для увеличения до 400 px на 455 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Master Root Keys

Здесь будут находиться сами ключи. Идентифицироваться они будут по CN, равному GUID ключа, класс объекта у них будет msKds-ProvRootKey , а интересных атрибутов у них будет много:

Атрибуты Master Root Key
(кликните для увеличения до 400 px на 455 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Два параметра msKds-CreateTime и msKds-UseStartTime будут содержать время создания объекта и время начала возможности его использования. Логика такова, что после создания объекта ему даётся время на то, чтобы среплицироваться на все DC в лесу. Это время стандартно и составляет 10 часов. До наступления msKds-UseStartTime данный ключ не будет использоваться, DC просто не будут находить его по запросам со стороны функций, работающих с gMSA.

Криптографические параметры будут задавать длины закрытого ( msKds-PrivateKeyLength ) и открытого ( msKds-PublicKeyLength ) ключа RSA, алгоритм совместной генерации общего секретного ключа ( msKds-SecretAgreementAlgorithmID , в нашем случае DH) и сами блобы этих криптографических параметров. В атрибуте msKds-Version будет версия – такая же, как и в предыдущем объекте, а в msKds-KDFAlgorithmID будет название KDF-функции – сейчас там значение SP800_108_CTR_HMAC , пока оно стандартное, но API допускает и возможность других значений из подмножества поддерживаемых CNG KDF-функций (например, SP80056A_CONCAT , или PBKDF2 ). Посмотреть фактическую поддержку KDF на хосте (контроллере домена Active Directory или просто Windows-машине – неважно), можно командой show crypto algo :

Просмотр списка KDF
(кликните для увеличения до 979 px на 599 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

KDF, если что – это аббревиатура от Key Derivation Function, т.е. способа генерации ключа нужной длины из не-криптографического материала (например, из пароля).

Эти параметры можно также просмотреть через командлет Get-KdsConfiguration :

Просмотр параметров службы KDS в Windows Server 2016
(кликните для увеличения до 859 px на 249 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Он, в общем-то, эти же атрибуты и выводит. Парный к нему командлет, Set-KdsConfiguration , позволит изменять параметры – алгоритмы, длины ключей, и всё остальное. Например, можно сменить стандартную KFD-функцию на другую:

Set-KdsConfiguration -KdfAlgorithm «PBKDF2»

По идее, можно ещё сменить сам алгоритм генерации ключевого материала со старого DH на ECDH, или хотя бы увеличить количество бит у DH с 2048 до 4096, но только вот это сейчас (в Windows Server 2016 TP5) не работает по неизвестной причине – надеюсь, к RTM доделают. Меняется т.е. пока только KDF-функция – список доступных вы можете просмотреть через ATcmd , пример есть выше.

Давайте теперь создадим ключ.

Создание нового Root Key

Это несложно – используется командлет Add-KdsRootKey , из параметров у которого только разве что время начала действия ключа. Самый простой способ – создать так:

Тогда ключ создастся и начнётся отсчёт 10 часов – для подстраховки, чтобы среплицировалось во всём лесу Active Directory. Если не хотите ждать – не вопрос. Можно сделать хитро – сгенерить ключ с “минус десятью часами начала работы”:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

В этом случае ключ будет работоспособен сразу же. После создания Вы увидите GUID ключа:

Создание KDS-ключа через PowerShell в Windows Server 2016
(кликните для увеличения до 859 px на 150 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Можно зайти в контейнер с ключами и посмотреть его параметры – опять же, из интересного там пока что будет разве что сервер, на котором Вы создали этот ключ – в атрибуте msKds-DomainID .

Теперь можно и gMSA создать.

Создаём gMSA

Для начала, выберем хост, на котором мы создадим gMSA. Хост должен быть строго на Windows Server 2012 и выше и обладать установленным .NET Framework 4.5 (это будет само собой, если там развёрнуты службы AD DS).

Создание будет несложным – используется тот же командлет, что и раньше:

В качестве обязательных параметров будет имя, которое можно указать сразу после командлета (например, msa1 ):

И надо выбрать – создаём ли “обычный” MSA, привязанный к одному серверу – тогда это выглядит так:

New-ADServiceAccount msa2 -RestrictToSingleComputer

Или создаём именно gMSA, пригодную для использования в кластерах, и тогда надо указать FQDN хоста, на котором мы заводили KDS-ключ (например, server-a.atraining.z ):

New-ADServiceAccount msa1 -DNSHostName server-a.atraining.z

А после – указать все те учётки computer’ов, которые смогут получать доступ к security-информации (паролю, например) новорожденной gMSA, задав их перечень в параметре -PrincipalsAllowedToRetrieveManagedPassword (например, разрешим учётке DC1 ):

New-ADServiceAccount msa1 -DNSHostName server-a.atraining.z -PrincipalsAllowedToRetrieveManagedPassword DC1$

Можно ещё добавить в конец -Enabled $true , и тогда будет полный вариант.

Вот так выглядят созданные учётки (я сделал msa1 нормальной, gMSA, а msa2 – ‘устаревшей’ MSA, чтобы было видно, что в зависимости от параметров командлета New-ADServiceAccount создаются разные типы объектов Active Directory):

MSA и gMSA
(кликните для увеличения до 754 px на 530 px ) Ruslan V. Karmanov rk@atraining.ru Учебный центр Advanced Training info@atraining.ru https://www.atraining.ru/

Дальнейшее использование простое – надо пойти на хосты, на которых планируется использование этой gMSA, и выполнить на них Install-ADServiceAccount . Всё идентично обычному MSA, только можно установить больше чем на 1 хост.

Дополнительные возможности

Вы можете задать криптоалгоритмы, используемые для тикетов Kerberos, выдаваемых этой MSA. Это делается, используя параметр -KerberosEncryptionTypes. Задавать можно несколько, выбор есть из DES, RC4, AES128 и AES256. Например, так:

New-ADServiceAccount msa1 -KerberosEncryptionType AES128|AES256

Можно (и нужно) явно задать промежуток смены пароля для gMSA – теперь же нет явного “хоста-монопольного-владельца-MSA”, от настроек которого это было зависимо:

New-ADServiceAccount msa1 -ManagedPasswordIntervalInDays 60

60, как понятно – это в днях.

Интересный момент – Вы не сможете получить полный доступ к вкладке Attributes у gMSA, если подключаетесь по обычному LDAP. Только если по LDAPS. Ну, это тема отдельного разговора о безопасности Active Directory. Намекну, что сможете через ATcmd.exe :).

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

Очередная технология, ощутимо поднимающая безопасность и упрощающая управление сервисами стала только лучше. Категорически рекомендуется к использованию – более того, ранее заведённые MSA проще переделать как gMSA – чтобы был единый тип объектов, а не два разных. Конечно, это потребует, чтобы в лесу Active Directory были как минимум NT 6.2-системы, но плюсы очевидны – проще делать gMSA, привязанные к 1й машине, чем специальный устаревший тип объектов с неполным функционалом.