В комментариях к первой части задали правильные вопросы, с ответов на них и начну.

Про что эта статья (в трех частях). Это не статья "какие мы молодцы", это переписанное руководство по дообучению коллег всяким мелочам на примере, приближенном к рабочему. В данном случае - как и куда смотреть в MS AD/логи и Linux на элементарном уровне, что откуда качать и настраивать, и иные базовые задачи. Попутно упомянуто, с какими проблемами столкнулся я, когда переписывал руководство (и какие типовые ошибки допустил, на что мне указали в комментариях к первой части). Повторюсь, на мой взгляд такую базу надо в школе давать, и теоретическую и практическую.

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

В первой части: ставим MS Windows server, готовим AD.

В второй части: ставим Debian, просто запускаем Vault и немного траблшутим.

В третьей части: занимаемся тем, ради чего все и затевалось - логинимся в Vault под доменной учетной записью, раздаем права AD юзерам и AD группам.

Часть 0 из N. Что такое Hashicorp Vault, причем тут AD (LDAP), и кто в кого авторизуется

В любой организации размерами больше 2 человек, рано или поздно появляется необходимость разграничить доступ, и чаще всего самым простым способом - парой логин-пароль. Легче всего настроить одно хранилище логинов-паролей, и затем обращаться к нему (сарказм: все остальные пароли, конечно, хранить в незашифрованном текстовом файле на сетевом диске с общим доступом Everyone/Everyone - чтобы хакерам / тестерам коллегам было удобней). Начну с неочевидного утверждения - если (до недавнего времени) начинался разговор об авторизации (и аутентификации) в рамках большой организации - то рано или поздно на горизонте были или Microsoft Active Directory или Samba.

Hidden text

По Samba и ее развитию на Habr на удивление мало материалов - беглый поиск нашел только статью из 2015 года, и не нашел ничего про патчи июля 2022 для Samba 4.16.4, 4.15.9 и 4.14.14 - в том числе CVE-2022-32744.

К сожалению, или к радости - не все так просто в современной среде. Если бы у нас были только постоянные, исключительно внутренние пользователи и постоянные ПК - все было бы куда проще. Если. У нас есть и одноразовые пароли, и секреты (токены), и сертификаты, и пароли с ограниченным сроком действия (в AD эта функция есть), и пароли с ограниченной областью и временем входа (в AD тоже есть), и облака 100 видов, и масса других ключей. При этом: не все приложения и не все разработчики желают как-то добавлять в свое (даже внутреннее) приложение авторизацию через AD; разработчики даже 1с частенько не желают работать от чего то меньшего, чем от локального администратора или от рута, причем в RDP сессии - им, в 1с, видите ли непривычно, что там есть пересылка отладки. Все доступы к хранению и изменению паролей надо как-то учитывать - то есть настраивать и аудит, и пересылку событий, и какой-то сборщик логов с анализом, а там и автоматизированное реагирование на инциденты не за горами (Qradar и прочие IRP/SOAR/SGRC ). Как следствие - нужно хранилище "секретов вообще", но при этом само хранилище должно выполнять какие-то функции по облегчению жизни - например, по автоматизации смены паролей в том же AD.

Если совсем упростить задачу, то нам в какой-то момент захотелось, кроме вышеперечисленного управления всеми секретами, упростить задачу условно-безопасной передачи паролей третьей стороне. У третьей стороны были индивидуальные постоянные записи в AD, через которую они могли бы авторизоваться в системе хранения прочих секретов. До 2020 года с всеми этими задачами справлялся RatticDB, но его судьба упомянута в первой части. На наш взгляд, все эти задачи по управлению паролями и секретами как раз и решал Vault.

В чем еще профит: и мы, и коллеги из соседних отделов и подрядчиков ходили за одноразовыми и групповыми паролями в Vault через авторизацию в AD, но - у Vault есть функционал по операциям в AD. Конечно, все это можно и скриптом автоматизировать, но рано или поздно скрипт превращается или в какого-то монстра, или в набор слабо связанных скриптов, и данные между десятком скриптов разве что не по шине (RabbitMQ) ходят. Всего этого хотелось избежать.

К сожалению, прекрасная статья (не обсуждая саму организацию, 20$ is 20$) появилась только в 2022 году, а видео из 2020 года я пропустил.

Ссылки для части 0, которые я не добавил с самого начала

Возможности и ограничения Samba 4 как контроллера домена Active Directory

Как в Тинькофф запускали HashiCorp Vault

Hashicorp Vault и как его готовить для разных команд / Юрий Шуткин (Tinkoff.ru)

Части 1-5 были в прошлой статье, поэтому...

Часть 6 из N. Настраиваем Debian 11 для Vault

Скачиваем ISO, создаем VM в VMware Player, тип сети – NAT, далее-далее, LVM – все на одном диске.

Можно и без LVM, нам диск расширять не придется (его и без lvm можно расширять). В случае рабочей сети, возможно, стоит LVM зашифровать. Хуже не будет. Лучше, впрочем, тоже - в любом случае нужен бекап.

Устанавливаем без GUI, только SSH (на скрине не выбран) и standard utilities.

После установки заходим как юзер (vuser), смотрим адрес (ip a) и дальше работаем по SSH. Вспоминаем, что ip 192.168.31.151 закреплен за сервером с AD. В больших организациях за статическими ip адресами нужен учет, в любом IPAM – хоть в SolarWinds IPAM, хоть в Netbox, хоть в phpIPAM. Netbox, по моему, лучший.

Полезные ссылки

Ведение систем IPAM и DCIM в NetBox: начинаем с кабельного журнала,

Организация IPAM и переезд с phpIPAM в NetBox: советы и подводные камни.

Vi тут и застрять можно, и никакого q!
su
nano /etc/network/interfaces

До изменений:
The primary network interface
allow-hotplug ens33
iface ens33 inet dhcp

После изменений:

iface ens33 inet static
address 192.168.31.155
netmask 255.255.255.0
gateway 192.168.31.2
dns-nameserver 192.168.31.151

Сразу настроим NTP
systemctl status systemd-timesyncd
nano /etc/systemd/timesyncd.conf
(и пропишем что нам надо)

Поставим массу нужного и не нужного.
nano /etc/apt/sources.list
добавим
deb http://deb.debian.org/debian bullseye main contrib non-free

Он сказал поехали и запил водой.
apt update
apt list --upgradable
apt upgrade -y

apt install sudo curl gnupg2 unzip openssl ldap-utils tcpdump –y
(нужно из этого не все, но часть нужна для примеров отладки)

В рабочей среде не забываем про использование sudo - правим
nano /etc/sudoers

Где-то тут перезагрузимся
systemctl reload
и, наконец, переходим к установке vault.

Часть 7 из N. Скачивание Vault

При попытке сделать по руководству

wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg >/dev/null

получим запрет. Упомянутые тут зеркала Yandex и Express 42 или недоступны, или содержат ссылки на старый релиз на официальном сайте (до июля работали). Но на официальном сайте есть прямые ссылки на http, и указан sha256, смекаете?

Часть 8 из N. Выбор дистрибутива Vault

Если верить release notes (даже на 22 августа 2022), то ничего новее 11.0 не было с 21 июня. При этом на https://www.vaultproject.io/downloads лежит ссылка на ault_1.11.2_linux_amd64.zip
с sha256 – ace4138269cb7214c73529f984b793d66074e3a3ad373eaa77bc9b39490d9ef9 для vault_1.11.2_linux_amd64.zip

Cледите за цифрами, я по ошибке сначала скачал vault_1.1.2_linux_amd64.zip вместо vault_1.11.2_linux_amd64.zip

Скачиваем с официального сайта, сверяем md5 и прочие sha на хосте -
Get-FileHash vault_1.11.2_linux_amd64.zip -Algorithm SHA256

Закачаем архив куда положено ему. Из командной строки
pscp c:\soft\vault_1.11.2_linux_amd64.zip vuser@192.168.31.155:/home/vuser

или из powershell
.\pscp c:\soft\vault_1.11.2_linux_amd64.zip vuser@192.168.31.155:/home/vuser

(pscp из комплекта к putty, можно Winscp заменить или как угодно еще).

Пойдем обратно в терминал Debian
cd /home/vuser
ls

Распакуем архив
unzip vault_1.11.2_linux_amd64.zip

и дальше пойдем от рута, хотя это и неправильно.
su
mv ./vault /usr/local/bin/
vault –h

На следующем шаге все руководства, включая официальное, рекомендуют запустить в dev-режиме. Dev режим – когда конфигурация не сохраняется, все в памяти.

Окей,
vault server -dev
оно запустилось, и что? CTRL-C

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

Часть 9 из N. Первичная установка Vault

Нам интересно настроить связку с AD, поэтому пойдем быстро и без SSL (и CA для SSL у меня в стенде пока нет):

Cd /
mkdir datalab
cd datalab
mkdir vaultdata
cd /home/vuser
nano vaultconfig1.hcl

Содержимое vaultconfig1.hcl:

storage "raft" {
  path = "/datalab/vaultdata"
  node_id = "node1"
}
listener "tcp" {
  address = "192.168.31.155:8200"
  tls_disable = "true"
}
api_addr = "http://192.168.31.155:8200"
cluster_addr = "https://192.168.31.155:8201"
ui = true

Почти все как в официальной документации, кроме адресов.

Важный момент: следите за пробелами/позицией (в nano для этого есть CTRL-C) и учитывайте перенос строк – точнее, их разницу между Windows (rn) и linux(n). В дальнейшем это мне здорово портило жизнь.

Запускаемся в сессии рута:

vault server -config=/home/vuser/vaultconfig1.hcl

На этом в данной сессии (рута) больше работ нет. Приложение работает "как приложение".

Возникает вопрос, а не запустить ли все это сразу как сервис? И да, и нет. Если делать шифрованный LVM, то при каждой перезагрузке на сервер придется ходить вручную (и, если это VM - через консоль) и вводить ключ для запуска. Если делать автозагрузку сервиса, то все равно - после каждой перезагрузки по умолчанию надо вводить три ключа из пяти. Если прописать и ввод ключей дешифровки в автозагрузку, то я не очень понимаю, насколько это безопасно. Однако тут каждый сам решает, как ему лучше делать в продуктивной среде. Еще один вопрос для боевой среды: где держать файл конфигурации, в домашнем каталоге, или куда-то переместить "для удобства".

Часть 10 из N. Первичная настройка Vault

Дальше есть два пути. Странный и более-менее правильный.

Странный. Открываем браузер и идем на http://192.168.31.155:8200

Получаем вот такую живопись (описанную в руководстве чуть позже, чем ssh – в разделе Web UI):

Более-менее правильный, и в соответствии с руководством: Открываем новую ssh сессию, настраиваем переменную:

export VAULT_ADDR="http://192.168.31.155:8200"

и выполняем первичную инициализацию хранилища.

vault operator init

Кавычки имеют значение, проверяйте.

Пример неправильных кавычек и потом сразу правильных:

получаем пять ключей (параметр настраивается, но по умолчанию 5) и One Ring to rule them all самый главный root токен. Схороните и токен и ключи, распечатайте, а распечатку в сундук.

Пока все идет как по руководству

Если сейчас сходить в браузер, то получим запрос на ввод ключей разблокировки (unseal). Можно ввести там любые три из пяти. Можно в SSH –

vault operator unseal

Можно в GUI.

Часть 11 из N. Мои первые секреты

Для проверки работы авторизации создадим (из GUI) два key-value хранилища.

Path - kv_userAD – и в нем секрет adsecret-user c какой-то парой key/value

Path - kv_groupAD и в нем секрет adsecret-group c другой парой key/value

Картинок не будет, для простых операций GUI достаточен (раньше был только в Ent версии)

Часть 12 из N. Проверка LDAP

Для чего весь этот текст и писался. Практика (моя личная) показывает, что зачастую MS сервисами занимается одна группа, серверами другая, Linux третья. Между ними не всегда присутствует дружба, потому что дружба - это магия, а несанкционированная магия - это ересь. Знать куда смотреть при отладке связи Linux (или IPMI с линукс на серверах) и AD - иногда полезно.

Перед тем как идти дальше в Vault, проверим работу ldap search

ldapsearch -x -b "dc=contoso,dc=lab" -H ldap://192.168.31.151

и получим result: 1 Operations error

Сделаем чуть лучше, зря чтоли специального пользователя заводили?

Сначала посмотрим в AD, какой CN мы сотворили.

Открываем RDP до контроллера домена, AD - users and computers, включаем advanced features:

Ищем и открываем обьект пользователя Vault connector, идем в Attribute editor, листаем до CN

И DN (можно оттуда и скопировать, если печатать лень) –

CN=Vault connector,OU=Vault,OU=Robo base,DC=contoso,DC=lab

Выполняем.

Ключи: -b = searchbase

ldapsearch -b "OU=Robo base,DC=contoso,DC=lab" -H ldap://192.168.31.151 -D "CN=Vault connector,OU=Vault,OU=Robo base,DC=contoso,DC=lab" -W

если у вас на этом этапе возникают ошибки, при вроде правильном пароле - то проверьте кавычки, - или тире, и главное – журнал событий Windows, есть в нем ошибки входа или нет. Если ошибок входа нет – то проблема где-то в CN/OU/кавычках. Иначе вы должны видеть ошибку входа в Event viewer / Security:

В Debian должны появляться ошибки:

ldap_bind: Invalid credentials (49)

additional info: 80090308: LdapErr: DSID-0C090436, comment: AcceptSecurityContext error, data 52e, v4f7c

Возникают? Отлично. В AD users and computers нажмите правую кнопку на юзере и смените ему пароль на Pa!!word2

Проверяем:

ldapsearch -b "OU=Robo base,DC=contoso,DC=lab" -H ldap://192.168.31.151 -D "CN=Vault connector,OU=Vault,OU=Robo base,DC=contoso,DC=lab" -W

Нам, между тем, нужен другой OU -

ldapsearch -b "OU=N Watch,OU=Zoo MSK,DC=contoso,DC=lab" -H ldap://192.168.31.151 -D "CN=Vault connector,OU=Vault,OU=Robo base,DC=contoso,DC=lab" -W

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

Я написал с двойными кавычками, как

$Pwd = ConvertTo-SecureString "Pa$$word2" -AsPlainText -Force

но если вы сделаете

$Pass3 = "Pa$$word3"
Write-Output $Pass3
$Pass4 = 'Pa$$word4'
Write-Output $Pass4
$Pass5 = "Pa`n word5"
Write-Output $Pass5
Remove-Variable -Name Pass3
Remove-Variable -Name Pass4
Remove-Variable -Name Pass5

То увидите какой пароль получился на самом деле. Будьте внимательны в таких вопросах.

В третьей части: занимаемся тем, ради чего все и затевалось - логинимся в Vault под доменной учетной записью, раздаем права юзерам и AD группам.