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

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

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

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

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

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

Реклама

Изменение временной зоны в Волгоградской области

Регулярная смена порядка исчисления поясного и летнего времени остается любимой забавой законодательной и исполнительной властей во многих странах мира. Не проходит и нескольких лет после предыдущего изменения, как готовится новый законопроект, далее он принимается и становится законом, а суровые законы в России хотя и компенсируются необязательностью их исполнения, но порядок исчисления времени к ним не относится, тем более затрагивает он нас всех. Наша страна здесь и в самом деле не одинока. Например, в этом году мы оказались в «компании»  Северной Кореи, Марокко и Чили, которые тоже поменяли свои временные зоны. Microsoft непрерывно отслеживает планируемые изменения временных зон и летнего времени по всему миру и постоянно обновляет информацию в своем блоге Microsoft Daylight Saving Time & Time Zone Blog. Далее выходят обновления операционных систем и другого ПО, содержащие изменения во временных зонах. Если соответствующие законы принимаются заблаговременно, хотя бы за несколько месяцев до вступления в силу нового поясного или летнего времени, то необходимые обновления, позволяющие автоматически перевести время на компьютерах в назначенный день и час, публикуются заранее.

Хуже обстоят дела, когда решения принимаются буквально накануне. Именно такая ситуация возникла с переводом часов в Волгоградской области. Здесь в ночь на 28 октября стрелки часов были переведены на 1 час вперед, иными словами, Волгоград и область перешли из временной зоны UTC+3 (московское время) в UTC+4. Поскольку закон об изменении исчисления времени был принят только в начале октября (а, к слову, референдум по соответствующему вопросу состоялся в Волгоградской области еще в марте), то времени на выпуск и тестирование обновлений временных зон попросту не осталось. Как обычно в таких ситуациях, Microsoft ограничилась рекомендациями по ручной (или через назначенное задание) установке другой временной зоны, а обновление, учитывающее принятые изменения поясного времени для Волгоградской области, будет выпущено позже.

Как следует из сообщения в блоге Microsoft, до выхода обновления следует перенастроить временную зону на компьютерах, расположенных в Волгоградской области, на (UTC+04:00) Saratov, что приведет к немедленному переводу отображаемого времени на один час вперед. В будущем, после выпуска и установки обновления временных зон показания времени меняться не будут, однако потребуется вручную или скриптом изменить наименование временной зоны на (UTC+04:00) Volgograd. Обратите внимание, что сейчас такой временной зоны среди доступных нет, она появится в будущем.

Для изменения временной зоны из командной строки выполните

tzutil.exe /s «Saratov Standard Time»

А если у вас где-либо (мало ли?) еще сохранились Windows XP и Windows Server 2003, выберите одну из доступных зон UTC+4, однако убедитесь, что флажок Automatically adjust clock for daylight saving changes сброшен. Например, можно воспользоваться временной зоной Caucasus Standard Time, тем более в ней не предусмотрен переход на летнее время. Аналогичное действие из командной строки будет иметь вид

tzchange.exe /c «Caucasus Standard Time»

 

 

Ошибка активации Windows 10 0xC004C008

Еще до того, как в Microsoft приняли решение временно приостановить распространение версии Windows 10 1809, мне удалось, используя Media Creation Tool, подготовить установочную флешку с новой версией Windows.  Проблема исчезновения пользовательских файлов мне не грозила, т.к. устанавливал Windows на новый компьютер без операционной системы (DOS не в счет). Для установки приобрел коробочный продукт Windows 10 Pro, хотя с выходом версии 1809 из содержимого коробки меня интересовал лишь продуктовый ключ (и несколько радовал глаз красивый сертификат подлинности в виде наклейки на коробке). В всяком случае, сомнений в подлинности программного продукта не было никаких, коробка была новая и нераспечатанная. Каково же было удивление, причем весьма неприятное, когда после установки и ввода продуктового ключа Windows отказалась активироваться через Интернет и возвратила ошибку активации 0xC004C008! Ошибка означает, что данный продуктовый ключ уже был использован.

Ошибка активации через Интернет вовсе не означает решительный отказ в активации, всегда следует пробовать выполнить активацию по телефону. В крайнем случае, придется общаться со специалистом Центра активаций Microsoft. В моем случае удивляло то, что и компьютер, и коробка с Windows 10 были новыми.

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

  1. Хотите ли активировать Windows?
  2. Хотите ли активировать Windows 10?
  3. Выполнялась ли ранее активация Windows 10 на данной системе?
  4. Код ошибки оканчивается на C008? (В этой группе вопросов перечисляются разные коды ошибок активации)
  5. Хотите ли повторно активировать Windows 10 в связи с заменой оборудования?
  6. И последний вопрос — сколько установок Windows 10 было ранее активировано на данном продуктовом ключе? — здесь ответил «1».

После этого телефонный робот предлагает отправить с телефона id установки и затем генерирует и отправляет ответный код. Иные ответы в рамках данной последовательности приводят к предложению пообщаться с представителем технической поддержки Microsoft.

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

 

Аудит доменных компьютеров с LAPS

В продолжение темы про LAPS решил рассказать, как находить компьютеры, на которых не работает LAPS, хотя должен.

Соответствие стандартам является условием прохождения любого аудита информационной безопасности. К требованиям, предъявляемым к локальным административным учетным записям, относятся их уникальность на разных системах, сложность в подборе и регулярная смена. В доменной инфраструктуре соблюдение этих требований обеспечивает штатный инструмент LAPS .

Сценарий, представленный ниже, является инструментом аудита. Он показывает, на каких компьютерах в домене (серверах или рабочих станциях) не работает LAPS. При этом можно видеть, где LAPS вообще никогда не запускался, либо на каких системах пароль LAPS устанавливался, но слишком давно. Сценарий возвращает список имен объектов компьютеров в Active Directory, у которых отсутствуют атрибуты LAPS или срок следующего изменения пароля истек. Для каждого компьютера отображается пароль LAPS, если он установлен, и прошедшая дата, когда должна была состояться очередная смена пароля.  Поле остается пустым, если пароль никогда не назначался. В список не попадают заблокированные (disabled) учетные записи компьютеров и неработающие компьютеры, объекты в AD которых изменялись более 90 дней назад.

Import-Module ActiveDirectory
$now = Get-Date
$dt = $now.AddDays(-90)
Get-AdComputer `
-Filter {(enabled -eq $True) -and (whenChanged -ge $dt) -and (OperatingSystem -like "*Server*")} `
-SearchBase ((Get-ADDomain).distinguishedName) -SearchScope Subtree `
-Properties ms-Mcs-AdmPwd,ms-Mcs-AdmPwdExpirationTime `
| Where-Object {$_.distinguishedName -notlike "*OU=Domain Controllers*"} `
| Select-Object name,@{Name="AdmPwd"; Expression={($_."ms-Mcs-AdmPwd")}},`
@{Name="AdmPwdExpTime"; Expression={[datetime]::fromFileTime($_."ms-Mcs-AdmPwdExpirationTime")}} `
| where-object {($_.AdmPwdExpTime -lt $now) -Or ($_.AdmPwd -notlike "*")}`
| Format-Table name,AdmPwd,@{Label="AdmPwdExpTime"; `
    Expression={($_.AdmPwdExpTime).ToString("dd.MM.yyyy") -replace "^.+1601$", ""}}

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

В представленном виде сценарий выводит информацию по серверным операционным системам. Для того чтобы получить статистику по клиентским компьютерам,  необходимо в строке 5 условие (OperatingSystem -like «*Server*») заменить на (OperatingSystem -notlike «*Server*»).

Поясню, почему строка оказалась такой длинной.

В параметре Filter командлеты Get-AdComputer невозможно использовать атрибут distinguishedName, поскольку это составной атрибут: он не хранится в AD, а формируется динамически при обращении к объекту. Фильтровать по нему можно только за счет передачи вывода Get-AdComputer в Where-Object. В данном случае из результатов должны быть исключены контроллеры домена, на которых агент LAPS не устанавливается. Предполагается, что контроллеры домена находятся в стандартном расположении — в OU Domain Controllers или ниже по иерархии.

Атрибуты AD, содержащие в своем имени дефис, нужно сначала переименовать, так, чтобы их новые имена не содержали дефиса, и лишь затем использовать в дальнейших конвейерных операциях. Это выполняется в особой конструкции вида @{Name=»AdmPwd»; Expression={($_.»ms-Mcs-AdmPwd»)}} внутри Select-Object.

Время следующего изменения пароля LAPS сохраняется в атрибуте AD в формате Int64. PowerShell не понимает дату в таком формате напрямую, поэтому используется преобразование .Net DateTime.FromFileTime(Int64). Аналогичная проблема, кстати возникает, если стоит задача посмотреть в AD дату последнего входа пользователя в систему.

1601 год известен историкам сильным неурожаем в европейской части России, приведшему в конечном итоге к Смутному времени. Нам же этот год интересен тем,  что отсчет времени в переменных формата дата/время Int64 начинается именно 1 января 1601 года. Чтобы ничего не значащая дата не выводилась для компьютеров, в объектах которых срок следующего изменения пароля LAPS не определен, применяется замена с регулярным выражением
-replace «^.+1601$», «»

 

Хранение истории паролей LAPS

LAPS (Local Administrator Password Solution) от Microsoft широко применяется как средство защиты административных учетных записей на доменных компьютерах. LAPS предоставляет механизм централизованного назначения уникальных паролей, их регулярной смены и не дает возможному злоумышленнику воспользоваться локальными учетными записями для организации атак типа Pass-the-Hash с целью получения контроля над все большим числом устройств в сети организации. Немаловажно и то, что LAPS является штатным, и к тому же бесплатным средством обеспечения безопасности.

В процессе эксплуатации большого парка компьютеров на рабочих местах редко, но с неизменной регулярностью, приходится сталкиваться с ситуацией, когда пароль LAPS не подходит. Причем не подходит, когда в нем есть потребность: компьютер (именно клиентский компьютер, с серверами такое не наблюдал) теряет связь с доменом, и чтобы повторно ввести компьютер в домен, необходимо войти в систему с учетной записью локального администратора.

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

Сам факт потери компьютером регистрации в домене не зависит от того, внедрена ли в организации технология LAPS или нет. Клиентский компьютер все равно приходится повторно вводить в домен. Другой факт, который удалось выяснить опытным путем — войти в систему удается по предыдущему, ранее установленному паролю LAPS. Хотя нет полной уверенности в последующем описании, но можно предположить, что проблема возникает в результате целой последовательности событий и проявляется на клиентах LAPS именно по причине частой смены пароля. Возможно, следующая последовательность действий приводит к описываемой, повторюсь, достаточно редкой ошибке.
Читать далее…