Часть 2 из 2, Hashicorp Vault – связка с AD LDAP
Часть 3. Политики и пользователи
Политики в Vault по сути напоминают права или access list (ACL). К юзеру или группе привязан ACL, с разного рода правами же.
Часть 3.1 Настройка образца политик
Сначала настроим политики – потому что пользователи и группы привязаны в политике, а ввиду убогого GUI делается это не очевидно. Да и в руководстве по политикам прописано как-то странновато.
Посмотрим, что у нас есть:
vault status
окей, сервер работает
vault secrets list
кто вы, я вас не знаю – сообщает нам сервер. Придется представиться: согласно Token authentication
vault login (и вводим токен, сгенерированный выше)
vault secrets list
vault policy list
Создадим шаблон под политику:
nano policyUSER1.hcl
Внутри:
# policyUSER1
# Write and manage secrets in key/value secrets engine
path "kv_UserAD/*" {
capabilities = [ "create", "read", "update", "delete", "list" ]
}
Почитаем help
vault policy write -h
vault policy write policyuser1 /home/vuser/policyUSER.hcl
nano policy_groupad_fullacess1.hcl
Содержание:
# policy_groupad_fullacess1
path "kv_groupAD/*" {
capabilities = [ "create", "read", "update", "delete", "list" ]
}
Выполним
vault policy write policy_groupad_fullacess1 /home/vuser/policy_groupad_fullacess1.hcl
Посмотрим
vault policy list
vault policy read policy_groupad_fullacess1
Окей, все видно.
Часть 3.2 Привяжем LDAP к AD
Идем и читаем Auth Methods
Без чтения дальше продолжать бессмысленно. Особенно внимательно читаем LDAP Auth Method
Включаем LDAP по руководству, раздел Configuration
vault auth enable ldap
Сначала настроим связку с AD – потому что сейчас в Vault пользователей нет.
cd /home/vuser
Учитывать: пробелы и переносы строк значимы, если не поставите пробел перед закрывающим “\”, то получите проблемы. Учтите, в тестовой конфигурации пароль прописан в исполняемом файле в открытом виде, не забудьте потом удалить файл и историю.
nano ad_auth_1.sh
#!/bin/sh
vault write auth/ldap/config \
url="ldap://192.168.32.155:389" \
groupdn="OU=N Watch,OU=Zoo MSK,DC=contoso,DC=lab" \
groupfilter="(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))" \
userdn="OU=N Watch,OU=Zoo MSK,DC=contoso,DC=lab " \
userattr=sAMAccountName \
groupattr="memberOf" \
insecure_tls=false \
deny_null_bind=true \
use_token_groups=true \
starttls=false
и выполняем
sh ad_auth_1.sh
теперь нам надо бы проверить что все работает и привязать юзеров к политикам.
Проверим через GUI
User- Ivanov, Password - Pa$$word3
Получаем ошибку:
Authentication failed: 1 error occurred: * error connecting to host "ldap://192.168.32.155:389": LDAP Result Code 200 "Network Error": dial tcp 192.168.32.155:389: connect: connection refused
Посмотрим в CLI
vault login -method=ldap username=Ivanov
та же ошибка, а все почему? Потому что по невнимательности я прописал
url="ldap://192.168.32.155:389" \
а AD у нас где? 192.168.31.151
и заодно, insecure_tls=false – а у нас ничего для TLS нет, так что читаем руководство еще раз,
insecure_tls - (bool, optional) - If true, skips LDAP server SSL certificate verification - insecure, use with caution!
В БОЕВОЙ СРЕДЕ НЕ ЗАБЫВАЕМ СЕРТИФИКАТЫ AD!
И мы же не прописали самое главное – bindDN!
Исправляемся, не зря в ldapsearch проверяли. Не забываем про “\”, кроме последней строки
binddn="CN=Vault connector,OU=Vault,OU=Robo base,DC=contoso,DC=lab " \
bindpass="Pa!!word2"
Исправляем, выполняем
vault auth disable ldap
vault auth enable ldap
sh ad_auth_1.sh
Учтите:
1) При выполнении vault auth disable ldap – будут удалены не только настройки ldap, но и пользователи. У нас пока пользователей нет, а когда будут – попробуйте и увидите.
2) При каждой удачной команде vault login(и так далее) – вы будете получать новый токен. Поэтому лучше бы держать две SSH сессии – одну с vault login и root token, а вторую для проверок. Я в тексте не пишу про переключение, потому что по лени ввожу vault login каждый раз.
Проверяем
vault login -method=ldap username=Ivanov
Получаем годное красивое
Error authenticating: Error making API request.
URL: PUT http://192.168.31.155:8200/v1/auth/ldap/login/Ivanov
Code: 400. Errors:
* ldap operation failed: failed to bind as user
И если вы на этом этапе подумали – «Ну что ж, заведем юзера в Vault!» - то вовсе не угадали.
Надо идти в логи AD и смотреть там ошибки авторизации – у какого юзера не идет авторизация. В моем случае – с Source Network Address: 192.168.31.155 прошла успешная авторизация пользователя CONTOSO\VaultSAM
Может быть, проблема в пароле товарища Иванова? Проверим. Сменим Pa$$word3 на Pa!!word3 –а вот и нет.
Но у нас есть товарищ Волк, без имени и фамилии. Проверим!
vault login -method=ldap username=volk
и все работает!
Сменим ему пароль на Pa$$word5 – и все равно все работает!
Чудеса, да и только!
Изучим логи AD: а вот и авторизация пользователя Security ID: CONTOSO\Volk,
Попробуем вход с неправильным паролем товарища Волка: и он успешно отобразится в логах!
а где же авторизация пользователя Ивана Иванова?
Пойдем простым, но странным путем: Сменим в AD: Full name = Ivanov1,Display=Ivanov2, logon- Ivanov3,pre-2000 Ivanov4. После этого сходим в AD еще раз и пропишем ему все же Logon, потому что поле слетает.
И ничего из этого не сработает.
Сравним отображение согласно ldap search:
Вот товарищ Иванов:
# Ivanov1, N Watch, Zoo MSK, contoso.lab
cn: Ivanov1
distinguishedName: CN=Ivanov1,OU=N Watch,OU=Zoo MSK,DC=contoso,DC=lab
displayName: Ivanov2
name: Ivanov1
sAMAccountName: Ivanov4
userPrincipalName: Ivanov3
Вот товарищ Волк:
# Volk, N Watch, Zoo MSK, contoso.lab
dn: CN=Volk,OU=N Watch,OU=Zoo MSK,DC=contoso,DC=lab
cn: Volk
distinguishedName: CN=Volk,OU=N Watch,OU=Zoo MSK,DC=contoso,DC=lab
displayName: Volk
name: Volk
sAMAccountName: Volk
userPrincipalName: Volk@contoso.lab
не, ну вы издеваетесь, да ? Ведь в конфигурации у нас прописан не upn, а userattr=sAMAccountName \
(возможны варианты: userattr (string, optional) - Attribute on user attribute object matching the username passed when authenticating. Examples: sAMAccountName, cn, uid)
Есть у нас правда еще параметр upndomain – добавим и его.
upndomain=contoso.lab \
и все равно не работает. Выхода нет – удалим товарища Иванова, удалим upndomain и создадим Иванова снова, но у же с другим upn. Интересно
$OUP = "OU=N Watch,OU=Zoo MSK,DC=CONTOSO,DC=LAB"
$Pwd = ConvertTo-SecureString "Pa$$word3" -AsPlainText -Force
New-ADUser -name "Ivan Ivanov" -Accountpassword $Pwd -DisplayName "Ivan Ivanov" -Enabled $true -Path $OUP -SamAccountName "Ivanov" -userPrincipalName "Ivanov@contoso.lab"
Remove-Variable -Name Pwd
Пробуем – в Vault ошибка та же самая, но в AD логах появляется ошибка авторизации -
Account For Which Logon Failed: Account Name: Ivanov
Сменим пароль товарищу Иванову ! С Pa$$word3 на Pa!!word3
ВЖУХ И ТЫ П ЗАЛОГИНИЛСЯ
WTF спросите вы, почему залогинился то? Почему товарищ Волк логинился и с Pa!!word5 и с Pa$$word5, а товарищ Иванов не может? Ответ на этот вопрос можете поискать самостоятельно, но он не так важен. Важно другое - Мы ж не прописывали кому куда можно?
Так и есть, не прописывали.
deny_null_bind в настройке есть, userfilter есть, политика по минимуму - ["default"], а настройки «do not login user without user ldap in Vault – я не вижу. Отсюда следует интересная проблема, про которую ниже.
Перепишем товарища Ивана Петра.
$OUP = "OU=N Watch,OU=Zoo MSK,DC=CONTOSO,DC=LAB"
Remove-ADUser -Identity "CN=Ivan Petr,OU=N Watch,OU=Zoo MSK,DC=CONTOSO,DC=LAB" -Confirm:$false
$Pwd = ConvertTo-SecureString "Pa!!word4" -AsPlainText -Force
New-ADUser -name "Ivan Petr" -Accountpassword $Pwd -DisplayName "Ivan Petr" -Enabled $true -Path $OUP -SamAccountName "Petrov" -userPrincipalName "Petrov@contoso.lab"
Remove-Variable -Name Pwd
Add-ADGroupMember -Identity "VltADM" -Members Petrov
Get-ADGroupMember -Identity "VltADM" | ft
Часть 3.3 Заводим MS AD юзеров в Vault LDAP
Не забудем перейти в соседнюю сессию или перелогинимся
vault login
Юзер у нас ходит, а политик ему не назначили – так заведем.
vault write auth/ldap/users/Ivanov
и получим ошибку, Must supply data or use –force
Заведем сразу с политикой -
vault write auth/ldap/users/Ivanov policies=policyuser1
vault login -method=ldap username=Ivanov
работает, отлично – политика и токен["default" "policyuser1"],а как с группой быть?
В конфиге я считерил и сразу прописал
groupfilter="(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))
В конфиге я считерил и сразу прописал
groupfilter="(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={{.UserDN}}))" \
это известное читерство, описанное тут Поиск всех групп пользователя AD по протоколу LDAP, и случайно мне попавшееся в обсуждении на hashicorp
и в google groups ,да и в документации в разделе Group Membership Resolution, но как-то совсем косо, с первого второго и далее раза не очевидно.
Проверим:
vault login -method=ldap username=Petrov
теперь логинится, и получает политику ["default"]
Пропишем группу AD
vault login
vault policy list
vault write auth/ldap/groups/VltADM policies=policy_groupad_fullacess1
vault login -method=ldap username=Petrov
и получим что: Верно. Индейскую народную национальную избу мы получим. Логин есть – политики нет.
vault list auth/ldap/groups
vault delete auth/ldap/groups/VltADM
vault write "auth/ldap/groups/Vault login" policies=policy_groupad_fullacess1
vault login -method=ldap username=Petrov
["default" "policy_groupad_fullacess1"]
Теперь про неприятное.
Удалим пользователя Иванова без очистки токенов.
vault delete auth/ldap/users/Ivanov
зайдем им
vault login -method=ldap username=Ivanov
ОП – и у нас по прежнему есть старая политика. Для сброса придется в обязательном порядке отзывать токены –
Получить список токенов
vault list auth/token/accessors
Перебрать каждый
vault token lookup -accessor EHlDQ1tFHEgA9aq0R6IptIjo
и так по всем. Не самая удобная процедура с точки зрения CLI, ну так Vault не под CLI заточен.