Предпочтения групповых политик (GPP — Group Policy Preferences) – мощное расширение технологии групповых политик Windows, упрощающая работу по настройке и управлению парком компьютеров, и являющаяся своего рода заменой скриптам в GPO. Одной из возможностей GPP – возможность управления паролями локальных и сервисных учетных записей, широко используемая многими администраторами, которые даже не подозревают о небезопасности этой технологии. В этой статье мы поговорим, почему не стоит использовать возможности Group Policy Preferences по управлению паролями.
В Group Policy Preferences существуют 5 различных политик, позволяющих задать пароль пользователя/администратора.
- Локальные учетные записи (Local Users and Group) – с помощью GPP администратор может создать/изменить локальную учетную запись и задать ее пароль (достаточно часто эта политика используется для смены пароля локального администратора на всех ПК организации)
- Сетевые диски (Drive Maps) – GPP позволяют подключить (смапить) пользователю сетевой диск с определенным именем пользователя и паролем
- Источники данных (Data Sources) – при создании источника данных можно задать имя пользователя и пароль учетной записи, под которой будет выполняться подключение.
- Задания планировщика Windows (Scheduled Tasks) – задания планировщика можно запускать из-под определенного пользователя
- Службы (Services) – GPP позволяют указать учетную запись и ее пароль, из под которой будет запускаться конкретная служба (вместо ученой записи Local System)
После того, как администратор сохраняет пароль в любой из перечисленных выше политик GPP, он сохраняется в каталоге соответствующей GPO в специальном XML файле и дальнейшем храня на контроллерах домена в папке SYSVOL. Пароль в XML файле хранится в зашифрованном виде, однако для шифрования/расшифровки пароля используется крайне нестойкий симметричный алгоритм AES 32 (это отмечает даже сама Microsoft).
Допустим, администратор с помощью GPP настроил политику, меняющую пароль локального администратора на всех ПК. Система в этом случае сохранит зашифрованный пароль в каталоге GPO в файле groups.xml. Посмотрим на содержимое этого файла (файл в нашем примере хранится в каталоге \\winitpro.ru\SYSVOL\winitpro.ru\Policies\{POLICY_ID}\Machine\Preferences\Groups):
Зашифрованный пароль содержится в значении поля CPASSWORD. Самое интересное заключается в том, что Microsoft сама на MSDN выложила в паблик 32 битный AES ключ, используемый для шифрования пароля (http://msdn.microsoft.com/en-us/library/2c15cbf0-f086-4c74-8b70-1f2fa45dd4be.aspx#endNote2)
Соответственно, специалисту ничего не мешает написать скрипт, позволяющий расшифровать значение пароля, хранящегося в XML файле (алгоритм AES симметричный и при наличии ключа шифрования без труда позволяет получить исходный текст).
В Windows Server 2012 / Windows Server 2012 R2 разработчики Microsft добавили предупреждение о небезопасности хранения паролей в таком виде. При попытке указать пароль через GPP появляется предупреждающее окно:
Также важно отметить тот файкт, что в MetaSploit-е модуль получения и расшифровки паролей, хранящихся в GPP присутствует еще с 2012 года. Это означает, что злоумышленники практически в автоматическом режиме могут реализовать это вектор атаки.
Ну что, вы и в дальнейшем планируете использовать Group Policy Preferences для управления паролями?
Уважаемый автор, а как Вы меняете пароли локального администратора?
У меня пока схема такая. При запуске ПК он пытается асинхронно открыть страничку IIS’a по определенному урлу, после чего на сервере запускается утилита меняющая пароль этому ПК.
Сергей, не могли бы вы по подробней рассказать про данный механизм.
Спасибо.
Павел, вот осбуждение смены пароля локального админа, ближе к концу предложен вариант с веб сервером. http://social.technet.microsoft.com/Forums/ru-RU/ff37eb08-31ad-4495-9403-f6bf71e463ab/-?forum=scrlangru
Правда мне пришлось его переделать (из-за кривости моих рук не на всех ПК срабатывал), нужно было ковырять права на доступ по сети к ПК, иначе часто скрипт не мог получить доступ к ПК, чтобы сменить пароль. Пришлось воспользоваться утилитой pspasswd.exe. Конечно не совсем секьюрно получается, ибо пароль передается в открытом виде, н оменя пока устраивает. А вообще я планирую, в дальнейшем, как и автор данного сайта заблокировать встроенную учетку админа. Там будет намного меньше проблем.
Спасибо, будем делать.
Если не затруднит, расскажите потом о своих результатах )
Я не стал городить огород:
http://1drv.ms/N102ot
Есть корпоративная система хранения паролей, которая позволяет обращаться к паролям посредствам API.
В ней внесены пароли локальных админов, которые генерируются автоматически после окончания срока действия.
Нужно было, что бы они были синхронизированы с локальными учетными записями администраторов в подразделениях компании, кок можно безопасней.
Вот с Вашей подачи и родилась сия процедура.
Про небезопасность задание паролей через gpo но какова альтернатива? Через logon скрипты не лучше ведь.
Я предпочитаю совсем отключать учетную запись локального администратора. Если же в ней возникнет необходимо — ее всегда можно локально активировать и сбросить пароль. Согласен, неудобно, но в грамотно организованной сети — к использованию локальных учеток прибегать практически не приходится…
Возможно, я бы подумал о скрипте, удаленно меняющем пароли лок.админа, через тот же WMI или PoSH, однако это не спасет от перехвата трафика.
А вообще, у всех методик есть свои сильные и слабые стороны и логон скрипты, ничем не лучше. 100% безопасного метода смены паролей локальных администраторов, увы не существует…
Миром правят не президенты, они просто паяцы, а некая надмирная финансовая олигархия, использующая для управления древнейший принцип – хлеба и зрелищ этим двуногим.
Microsoft, как и прочие финансовые пирамиды, верой и правдой служит политике этой олигархии. Национализм, шовинизм, терроризм, наркомания, алкоголизм, голод, интернет и прочее-прочее являются составляющими частями зрелищной политики. Все это нам, а не им.
А вот что страшно для них – это ИНАКОМЫСЛИЕ за закрытыми наглухо компьютерными системами и сетями. Это непредсказуемая бомба, пострашнее любой термоядерной. Поэтому Microsoft и далее будет блудить языком о безопасности, паролях, политиках, настройках, а руками эти системы открывать.
политика GPP смены пароля, читается компьютером
ну да, по умолчанию дается доступ на чтение пользователем… так что мешает сделать запрет на чтение этой политики?
Даже если дать права только компьютерам, никто не мешает запустить любой процесс от System и прочитать файлы политики.
Павел, интересно у вас получилось. А можете подсказать, какие правила в фаерволе необходимо разрешить, чтобы смена пароля проходила успешно?
Сори, за ожидание — много работы.
С фаерволом есть вопросы:
На стороне сервера — все просто входящие правило для 81 порта, а вот с клиентов пока руки не дошли… в процессе
Да ничего, сам тоже завален )
Буду ждать результата, воспользуюсь, так сказать, чужим трудом )
На стороне сервера:
разрешить подключение для протокола TCP и локального порта 81, профиль: Домен
На стороне клиента:
для $namePC = [System.Net.Dns]::GetHostByAddress($ipPC).HostName необходимо разрешить подключение для протокола UDP и локального порта 137, область: только для IP=X.X.X.X сервера, профиль: Домен
для $Admin.SetPassword($PasswordProperties.Password) необходимо разрешить подключение для протокола TCP и локального порта 445, область: только для IP=X.X.X.X сервера, профиль: Домен
Я не стал устанавливать действие «Разрешить только безопасное подключение» в правилах для фаервола, но это возможно в принципе.
Павел, огромнейшее спасибо.
Как разгребу текущие дела переделаю свой вариант на Ваш.
Прошлый вариант — работал только в виртуальной тестовой среде, текущий боевой вариант, проходит апробацию в одном из подразделений http://1drv.ms/N102ot. Пока все довольны.
Павел, а ссылочка ваша битая. Можете обновить?
Просто я убрал общий доступ от директории OneDrive. Хорошо я сделаю для вас. После обеденного перерыва сегодня.
Вот ссылка http://1drv.ms/1AX7zYJ. Пользуйтесь на здоровье.
Павел, спасибо большое! Слил. Если требуется — можете закрывать. Буду пробовать.
В качестве продолжения темы предлагаю познакомится с официальным решение Microsoft по управлению паролями локальных администраторов в домене Local Administrator Password Solution
В мае 2014 года Microsoft выпустила обновление безопасности (MS14-025 – KB 2962486), полностью отключающее возможность задать пароль локального пользователя через GPP.