Перейти к содержимому

LAPS и backup: вместе не лучше?

08.11.2018

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

Рассмотрим следующий сценарий. Допустим, в нашей инфраструктуре имеется множество серверов, включенных в домен. Для управления паролями локальных административных учетных записей внедрена технология LAPS (Local Administrator Password Solution). Частота смены пароля оставлена стандартной — каждые 30 дней.

По какой-то причине нам потребовалось восстановить один из серверов из резервной копии (или из снапшота виртуальной машины). Backup, разумеется, есть, и восстановление проходит успешно. Однако после восстановления обнаруживается, что войти в систему под доменной учётной записью невозможно, поскольку связь с доменом потеряна. Проблема небольшая, ведь достаточно переподключить компьютер в домен, тем более это делается достаточно быстро. Однако прежде необходимо войти в систему с правами локального администратора. Дело нехитрое — считаем мы — ведь технология LAPS как раз и приспособлена для обновления на регулярной основе пароля локального администратора и хранения актуальных паролей в Active Directory. С помощью приложения LAPS UI, скриптом или иным способом просматривая атрибут ms-Mcs-AdmPwd в объекте компьютера в AD, мы получаем пароль LAPS и успешно входим в систему. Это удачный вариант развития событий, обычно так и происходит. Однако в редких случаях зарегистрироваться в системе не удается: ранее сохраненный пароль LAPS не подходит. А если в системе нет других незаблокированных административных учетных записей, мы получаем после восстановления неработоспособный и неуправляемый сервер. 

Необходимо отметить, что вероятность такого события невелика: в конфигурации по умолчанию и при использовании резервной копии за предыдущий день она составляет примерно 1/900. Но вероятность существует и быстро растет (по квадратичному закону), если потребуется использовать более ранние резервные копии.

Какие условия способствуют возникновению проблемы? Как известно, доменный компьютер проходит аутентификацию в домене с использованием внутреннего компьютерного пароля, который изменяется, по умолчанию, каждые 30 дней. Групповые политики LAPS в конфигурации по умолчанию тоже предусматривают изменение паролей 1 раз в 30 дней. Указанные процессы происходят независимо. Если из резервной копии будет восстановлен образ операционной системы с устаревшим компьютерным паролем, то такой сервер потеряет связь с доменом (т.е. не сможет установить защищенный канал). А если за время, прошедшее после создания резервной копии, изменится и пароль LAPS, то и возникнет опиcываемая проблема: для повторного ввода сервера в домен требуется войти в систему с правами локального администратора, а пароль локального администратора, действовавший на момент создания резервной копии, неизвестен.

Здесь важное значение приобретает задача о хранении истории пролей LAPS. Из типовых решений, не требующих разработки собственных сценариев и приложений, можно порекомендовать внедрение Корзины AD. Помимо того, что Корзина AD полезна и для многих других применений, ежедневное создание моментального снимка Active Directory позволит просматривать историю паролей LAPS за все прошедшие дни со сроком давности до 1,5 месяцев. Для того чтобы посмотреть пароль LAPS за выбранную дату, потребуется на домен-контроллере смонтировать соответствующий снапшот Аctive Directory, опубликовать его как сервис LDAP на выбранном порту и подключиться к нему с помощью консоли Active Directory Users and Computers. Как уже отмечалось, пароль LAPS следует искать в атрибуте ms-Mcs-AdmPwd объекта компьютера.

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

Наконец, нельзя исключать стандартные и «неофициальные» методы сброса пароля. Во-первых, они работают даже в ситуациях, когда ничто другое не помогает, во-вторых, некоторые из них позволяют обойтись исключительно стандартными инструментами Windows Server, не привлекая сторонние утилиты. И наконец, при минимальной предварительной подготовке сброс пароля удлиняет процедуру восстановления всего на несколько минут.

Обладатели лицензий с Software Assurance могут воспользоваться доступным им Microsoft Diagnostics and Recovery Toolset (DART) из комплекта Microsoft Desktop Optimization Pack (MDOP), который содержит средство сброса пароля на незагруженной операционной системе. Благодарю Михаила Комарова за подсказку. 🙂

Для остальных тезисно опишу метод, который надежно работает на всех современных клиентских и серверных ОС Windows и задействует только штатные средства. За подробностями и скриншотами можно обратиться к другим статьям. Итак, для сброса неизвестного пароля администратора (но при наличии физического доступа к серверу) необходимо:

  1. загрузиться с инсталляционного диска или носителя Windows Server, желательно, с которого выполнялась установка операционной системы;
  2. запустить Windows Recovery Environment (Windows RE), перейдя в окне Windows Setup с кнопкой Install now по ссылке Repair your computer;
  3. выбрать Troubleshoot и в разделе Advanced Options запустить Command prompt;
  4. перейти на диск с установленной операционной системой и перейти в папку \Windows\System32;
  5. скопировать файл Userman.exe в Userman.bak и затем скопировать файл cmd.exe в Userman.exe, перезаписывая существующий;
  6. перезагрузить сервер и загрузить ранее восстановленную операционную систему;
  7. на Welcome screen щелкнуть значок Ease of access, однако теперь вместо Специальных возможностей запустится Командная строка в контексте Local System;
  8. с помощью команды NET USER сменить пароль локального администратора.

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

 

Реклама
Добавить комментарий

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

%d такие блоггеры, как: