Существует несколько вариантов решения данной задачи:
- Использование единого пароля на всех компьютерах. Пароль может устанавливаться либо во время деплоя с помощью MDT или SCCM, либо с помощью предпочтений групповых политик после деплоя. Обычно при таком подходе пароль никогда не меняется, а значит рано или поздно утечет (при увольнении администратора или пользователь может подглядеть ввод пароля), при этом скомпрометированный пароль дает доступ ко всем ПК в организации.
- Единоразовая установка уникального пароля на каждом ПК. Обычно происходит при деплое. Вариантов масса — начиная от ручной генерации случайного пароля и сохранении его в системе учета паролей (Keepass, OnePassword, Excel), заканчивая автоматической генерацией пароля по алгоритму известному администраторам, где входными данными является имя ПК. Зная алгоритм, администратор может на месте рассчитать пароль и авторизоваться на любом ПК. Минусы примерно аналогичны варианту 1: Уволенный администратор сохраняет возможность войти на любой ПК, зато при компрометации пароля пользователем он получает доступ только к одному ПК, а не ко всем сразу.
- Использование системы, которая будет автоматически генерировать случайные пароли для каждого ПК и менять их по установленному расписанию. Минусы предыдущих вариантов тут исключены — скомпрометированный пароль будет изменен по расписанию, и уволенный администратор через некоторое время не сможет авторизоваться на ПК даже если и украдет действующую на момент увольнения базу паролей.
Одной из таких систем является LAPS, установку и настройку которой мы разберем в этой статье.
LAPS
LAPS расшифровывается как Local Administrator Password Solution и является наследником решения AdmPwd, которое было поглощено Microsoft и переименовано в LAPS. LAPS бесплатен и не требует дополнительных расходов на инфраструктуру, так как использует Active Directory в качестве базы данных. Поддержка доступна в рамках Microsoft Premier Support Services.
Официальная страница продукта
Автор оригинальной AdmPwd разработал новый продукт AdmPwd.E, но бесплатная версия ограничена 20 ПК, так что подойдет не всем. Официальный сайт.
LAPS поставляется с обширной документацией (только на английском) и вообще оставляет впечатление крайне продуманного и надежного решения.
Архитектура
Система состоит из следующих компонентов:
- Агент — Расширение групповой политики устанавливаемое на все управляемые ПК через MSI. Отвечает за генерацию пароля и сохранении его в соответствующем объекте AD.
- Модуль PowerShell. Используется для настройки LAPS.
- Active Directory. Хранит пароль локального администратора.
Агент вызывается при каждом обновлении групповой политики и выполняет следующие задачи:
- Проверяет не истек ли срок действия пароля локального администратора
- Генерирует новый пароль, если текущий истек или требуется его замена до истечении срока действия
- Меняет пароль локального администратора
- Сохраняет пароль в соответствующем атрибуте объекта AD
- Сохраняет срок действия пароля в соответствующем атрибуте объекта AD
Пароль может быть прочитан администраторами, а также промаркирован как требующий замены при следующем обновлении политики.
Полная диаграмма работы LAPS приведена на следующем изображении.
Установка и настройка LAPS
Для начала установим средства управления LAPS на компьютер, с которого будем осуществлять настройку.
Запускаем msi пакет и устанавливаем все Managemnt Tools, которые включают LAPS UI, модуль PowerShell и шаблоны групповой политики.
Если у вас настроено централизованное хранилище шаблонов групповых политик, то сразу переносим файлы «Admpwd.admx» и «En-us\AdmPwd.adml» из "%SystemRoot%\PolicyDefinitions" в "\\contoso.com\SYSVOL\contoso.com\policies\PolicyDefinitions".
Следующим шагом будет добавление новых атрибутов в схему AD. Для этого необходимо открыть консоль PowerShell от имени учетной записи с правами «Schema Admin» и сначала импортировать модуль командой «Import-module AdmPwd.PS», а затем обновить схему командой «Update-AdmPwdADSchema».
Затем нужно удостовериться, что только администраторы имеют доступ к свежесозданным атрибутам. Это необходимо, так как пароли хранятся в AD в открытом виде, и доступ к ним регулируется AD ACL. Для этого воспользуемся командой «Find-AdmPwdExtendedrights -identity <OU, где расположены учетные записи ПК> | Format-Table».
Эта команда возвращает список учетных записей/групп, которые будут иметь доступ к паролям хранящимся в AD. Если вы обнаружили «лишние» учетные записи/группы, то воспользуйтесь утилитой ADSIEdit для корректной настройки прав доступа. Убедитесь, что право доступа «All extended rights» не отмечено для тех групп, которые не должны иметь доступ к паролям.
Если же вы хотите дать доступ к паролям дополнительным группам или учетным записям воспользуйтесь командой «Set-AdmPwdReadPasswordPermission -OrgUnit <OU, где расположены учетные записи ПК> -AllowedPrincipals <Пользователи или группы>».
Права доступа для принудительной смены еще не истекшего пароля при следующем обновлении групповых политик выдаются следующей командой: «Set-AdmPwdResetPasswordPermission -Identity <OU, где расположены учетные записи ПК> -AllowedPrincipals <Пользователи или группы>»
Затем необходимо выдать права самим компьютерам на модификацию данных атрибутов. Для этого воспользуемся командой «Set-AdmPwdComputerSelfPermission -OrgUnit <OU, где расположены учетные записи ПК>»
Следующим шагом будет настройка групповой политики. Мы можем контролировать сложность и срок годности паролей, имя учетной записи пароль которой будет меняться, а также включать и выключать работу LAPS.
Имя учетной записи нужно указывать только в том случае, если это специально созданная учетная запись. Если это встроенная ученая запись, то этот параметр надо оставить в «Not configured» (Даже если учетная запись переименована), так как встроенная учетная запись будет найдена по well-known SID.
Следующим этапом будет установка расширения групповой политики на ПК. Это можно возложить на групповые политики, на SCCM, либо на другое средство развертывания приложений. Следует отметить, что по умолчанию msi пакет устанавливает только клиентскую часть, так что развертывание не требует передачи дополнительных параметров инсталлятору. Перезагрузка ПК потребуется только при развертывании через групповые политики.
Для просмотра пароля проще всего воспользоваться LAPS UI. Вводим имя компьютера в соответствующее поле и нажимаем «Search». Если мы все сделали правильно, то вы увидите пароль в соответствующем поле.
Заключение
В этой статье были рассмотрены основные этапы развертывания LAPS. Больше информации доступно в документации поставляемой вместе с продуктом. LAPS также обладает средствами логирования своих действий, что не было рассмотрено в данной статье, но описано в документации.
Комментарии (27)
kaasnake
03.03.2019 23:26Мы создали учетную запись, которая имеет очень ограниченные полномочия в домене, но добавили ее в группу локальных администраторов рабочих станций и выключили локального админа вообще. Меняем пароль по расписанию и я пока не сталкивался с ситуацией, когда нам нужно было что-то дополнительно.
Dshuffin Автор
03.03.2019 23:35+1Локальная учетка администратора нужна если ПК по какой-либо причине не может связаться с контроллером домена. Во всех остальных случаях используются доменные учетные записи с правами администратора ПК. При вашем подходе, при смене пароля вам необходимо обойти все компьютеры в организации и войти с этой учеткой для того чтобы закэшировать новый пароль.
kvant21
04.03.2019 13:14А кэширование учетных данных на рабочих станциях при этом включено или выключено? Если выключено, то у вас нет аварийного входа в случае, если нет связи с доменом. Если включено, то креативный пользователь mimikatz может натворить больших дел у вас в сети — см NotPetya.
scruff
04.03.2019 08:49Парни, философский вопрос назрел, не по теме администратора, но по паролям. Берем СЕО (CFO), короче шишку компании, которому по барабану все ИТ-политики и прочее и который вам говорит — мне не нужны эти 30,60,90- дневные пароли, хочет чтобы не истекало. Как бороться с такими «опасными» типами? Если для таких случаев решение по установке такого типа Идетификатора, который удовлетворил бы потребностям пользователя и условиям ИБ?
acyp
04.03.2019 09:59Авторизация по ключу?
scruff
04.03.2019 10:04SMART?
acyp
04.03.2019 10:28Ну в том числе. По токену, смарт-карте, просто на флешке записан ключ авторизации. Материалов на хабре было множество, как для windows- так и для linux-систем, если необходимо, то могу дать ссылки.
У меня так удаленщики-фрилансеры авторизуются. UPD (сертификатом)
Andrusha
04.03.2019 16:34Вообще вопрос скорее организационный, чем технический. Бороться беседами с предоставлением примерного варианта развития событий при компрометации пароля. Просто есть вероятность, что такой человек и к токенам-смарткартам будет относиться так же несерьёзно, так что в любом случае ликбез не помешает.
Shrim
04.03.2019 10:43Какая-то «буханка-троллейбус.jpg»
Зачем ставить какого-то агента, если есть ADSI провайдер WinNT.
# python 3.6 import struct import win32com.client def set_password(computername, password): # подключаемся к компьютеру computer = win32com.client.GetObject(f"WinNT://{computername}") # перебираем все его объекты (пользователи, группы) for obj in computer: # игнорируем всё, кроме пользователей if obj.Class != "User": continue # вычисляем админа по SID sid = bytes(obj.objectSid) if struct.unpack("i", sid[-4:])[0] == 500: admin = obj break else: raise WindowsError( f"На компьютере {computername}" f" не найдена учетная запись администратора!" ) # DONT_EXPIRE_PASSWD + NORMAL_ACCOUNT + PASSWD_CANT_CHANGE admin.userflags = 66112 # устанавливаем пароль admin.SetPassword(password) # сохраняем все изменения admin.SetInfo() if __name__ == "__main__": set_password("QWERTY-123", "40_Thousand_Monkeys")
Пример урезан, оставлено только самое необходимое.
То же самое пишется на любом удобном вам языке, на том же PowerShell.
Пароли генерируем и храним любым удобным (а главное безопасным) способом, например так в статье — в атрибуте объекта AD (это уже через провайдера LDAP).
Естественно, у учетки из под которой запущен скрипт, должно хватать прав, на изменение пароля.
Через провайдера WinNT также можно переименовать локального админа, например, чтобы на всех машинах он звался одинаково, можно проверить, нет ли в группе локальных администраторов «левых» учеток (не всегда и не у всех ИБ на должном уровне).
Помимо смены «протухших» паролей, необходимо регулярно проверять, не был ли пароль изменён (подходит ли сохранённый).kvant21
04.03.2019 14:39+1Только не забудьте защитить атрибут объекта, в котором пароль будете хранить, а то обычные поля компьютерных объектов по умолчанию весь домен может читать. А после этого сделать какой-то тул для просмотра этого атрибута, потому что в ADUC его видно не будет.
А еще что-то придумать для клиентов, которые не постоянно онлайн, чтобы не пропускали время запуска скрипта.
А также не забудьте открыть везде порты, чтобы COM-RPC работал с сервера, на котором скрипт запускается, к клиентам — а то по умолчанию, например, клиенты общаются с контроллером домена только в режиме pull.
Ну и как следует защитить учетную запись, от которой запускается скрипт — прав у нее в сети будет немало.
Или можно вместо всей этой головной боли использовать LAPS, официальное и поддерживаемое (бесплатное) решение от Microsoft.
whiplash
04.03.2019 15:51Не нужно так делать.
1. Про права на чтение сказали ниже.
2. А rename отлично делается через GPP/GPO.
navion
04.03.2019 14:50Недавно вышла ещё одна бесплатная штука для гранулярной настройки политики паролей с чёрными списками и инструкцией в трёх частях: Lithnet Password Protection
alnikor
05.03.2019 00:12Удивлён, что столь старая штука вызвала столь позитивный отклик аудитории.
На самом деле уникальный пароль локального админа, тот ещё геморрой. У вас может отсутствовать возможность подключиться к домену по тем или иным причинам, в итоге нет доступа к паролю.
Опять же, пароль от локального админа при физическом доступе к станции — вопрос скорее времени, чем сложности получения. Конечно нельзя отметать опечатанные по всем «параноидальным правилам», но кто такие в жизни видел?
Если бы LASP умел ставить фиксированный пароль на все станции, а не генерировать уникальные, цены бы ему не было.kvant21
05.03.2019 02:33Опасные вы вещи говорите — все ведь ровно наоборот.
Именно потому что привилегии локального админа сравнительно легко достижимы, они должны быть изолированы в пределах одной рабочей станции. Иначе повысившись на одной станции можно по всей сети расползтись — что наглядно всем желающим и продемонстрировал NotPetya еще полтора года назад.alnikor
05.03.2019 08:51-1Петюня использовал уязвимости, которые позволяли повышать права до привилегированных не зависимо от начальных. Т.е. любой пользователь уже вектор атаки, даже гостевая учётная запись.
Опять же, для распространения по сети использовалась уязвимость SMB1, для использования которой аутентификация вообще не требовалась.
Уникальные у вас пароли или нет локального администратора, вообще не играло ни какой роли.
На мой взгляд лучшая практика — не использовать встроенного администратора вообще, а создавать новую учётную запись.
Это, кстати тоже явная недоработка LAPS, он способен управлять лишь 1 учётной записью на конечном ПК.
По итогу имеем явный дискомфорт управления конечными ПК, и огромный шанс нарушения правил разделения учётных записей (когда администраторы начинают использовать привилегии на уровне домена). И да, к сожалению работать под минимальными правами, на уровне подкорки, принято лишь у *unix администраторов.kvant21
05.03.2019 11:19+1NotPetya помимо эксплойта EternalBlue использовал mimikatz чтобы вытащить из памяти lsass lm-хэши локальных администраторов, и дальше пробовал с ними ходить по сети. Например, вот здесь есть об этом.
А чем плох встроенный администратор? Тривиально ведь найти на машине всех остальных. Разве что UAC у него выключен по умолчанию. Так ведь включить можно, да и вообще согласно Microsoft «UAC is not a security feature».alnikor
05.03.2019 15:16Отлично, он бы вытащил учётную запись доменного пользователя вместо локального админа, что дальше? :))) Если используются кешированные данные авторизации, локальный админ меньшее из того что может у вас утеч :)))
А ещё лучше когда в итоге работы LAPS люди начинают ходить под доменным админом (или вы в идеальном мире живёте :))
И тогда петюня получает доменного админа на подносе :)))
Вообще вы случаем не из «пароль надо менять каждые 90 дней»? :)Xeonkeeper
05.03.2019 15:38Под доменным админом на рабочие станции пользователей? За такое руки надо отрубать (и не только тем, кто ходит, но и тем, кто это допустил). И какая вообще зависимость между LAPS и тем, что люди используют доменного админа где попало?
И вы хотите сказать, что пароли не меняете?
kvant21
05.03.2019 16:07Не, я не из идеального мира, но из мира людей, применяющих политики назначения прав пользователей, чтобы доменные админы не заходили случайно куда не следует.
Первую часть не понял. Петя собирает все что есть в lsass, а дальше если у вас из этого списка кто-то вхож на другие рабочие станции как админ, то Петя приезжает и на них тоже.
Xeonkeeper
05.03.2019 12:36Хорошая, старая штука. Конечно, вызывает некоторые неудобства, но как и вся безопасность тут либо удобнее, либо безопаснее. На вскидку вспомню несколько кейсов.
1. Например, удаление УЗ подменного компьютера из АД, когда подменный компьютер долго не находится в сети. Т.е. стоит в принципе забыть об удалении УЗ компьютеров, только блокировка.
2. После внедрения пришлось подтюнить MDT, чтобы он использовал staging OU, иначе деплой фейлился после очередного обновления GP.
3. Стоит внимательнее относится к политикам паролей, т.е. настроив для LAPS пароли вида «SDFAHO23DFJSSDFK6» необходимо убедиться в том, что локальная политика безопасности даст использовать такие «простые» пароли.
Да в принципе это и не проблемы, просто нюансы, которые сразу вспомнились.
exadmin
Компания с 500+ компьютерами. Год-два назад запустил Wireshark, накачал 2гб траффика и начал искать интересное. По словам "administrator" нашел, что ИТ придумали такое: раз в 6-8 часов запускается visual-basic скрипт, который лезет на ftp, скачивает с него key-value файлик, где для каждой рабочей станции свой вполне сепьюрный пароль локального админа. Пошел ручками скачал файлик проверил что все ко всем подходит, отписал ребятам. После чего они перешли на LAPS. Вспомнилось вот :)