* Windows Server 2008 R2 с установленной ролью контроллера домена.
* Рядовой сервер Windows Server 2008 R2 с установленной консолью GPMC.
* Windows 7 с установленным пакетом Remote Server Administration Tools (RSAT).
По внятности — передано в соответствующие службы. Спасибо за сообщение!
Что касается самой ошибки, она и ее решение описаны в нашей базе знаний: http://www.netwrix.com/kb_RZST_0091pB.
Если Вас не затруднит, сообщите, пожалуйста, о том, помогло ли Вам это решение.
Бывает, ходишь с расстегнутой не при дамах будь сказано ширинкой, все поглядывают косо — и никто не скажет. Спасибо, что сообщили об этой неточности! Конечно, возможности долгосрочного хранения логов не отсутствуют, хоть они и довольно громоздки.
Так что, видимо, Вашим огорчением мы обязаны Дону. Нас это в свою очередь огорчает. Но мы уже придумали, как исправить ситуацию с техническими неточностями наших замыслов и работаем над новым проектом. Надеюсь, он Вам понравится!
Что касается приведенного Вами продукта GFI и его более современной версии — у нас есть конкурентный продукт NetWrix Event Log Manager (http://www.netwrix.com/event_log_archiving_consolidation_freeware.html). При общей равной «весовой категории» у нашей программы есть некоторые преимущества перед ним. Если Вам интересно, могу привести подробности.
Но это инструменты для сбора логов. Вы же согласны с тем, что ими не осуществляется аудит изменений групповых политик полностью?
>Антон, ваша программа, может быть, и хороша, но вот начало со впариванием было неудачным.
Максим, Вы правы. Мы это уже поняли и работаем над этим.
Спасибо!
Автор совершенно справедливо отмечает, что Events in security logs are notifications saying that in GPO were made any changes but are not saying what exactly was changed. То есть описанным путем нельзя получить главного — информации о том, что именно изменилось. Такой аудит только позволит некоторым подозрениям развиться в болезненную фобию, а не выявить реальную причину инцидента.
При обсуждении затрат на реализацию этого решения Дженифер придется заготовить фразу типа «это, конечно, не решает нашу проблему полностью, но лучших вариантов просто нет» — и отрепетировать оптимистичное выражение лица.
Пол с легкостью получил бы вместо нее бонус за решение задачи, если бы предложил – как Вы думаете, что?!
Конечно, решение, которое позволяет получить значения измененных параметров до и после изменения!
Приведенные Вами варианты решений имеют недостатки:
1. Обработка всех записей журналов событий приводит к большому количеству неинформативных данных. Найти информацию о реальных изменениях в полученных .xml – непростая задача.
2. Сбор данных осуществляется на каждом сервере. А если в компании их 300? Найти нужную информацию будет серьезной проблемой!
3. Хранение архивов журналов безопасности требует большого дискового пространства. В развитых средах через месяц такого хранения потребуются дополнительные меры по его организации. Долгосрочное – в течение нескольких лет — хранение далеко не всегда может быть осуществлено таким образом.
Спасибо за отзыв и за совет!
В целом так и есть на сегодняшний день, с одной деталью: NetWrix File Server Change Reporter производит мониторинг файловых серверов на NetApp Filer и EMC.
Подробнее можете посмотреть здесь blog.wadmin.ru/2012/02/powershell-grouppolicy-module/
Вы правы
>Фичи раскрыты плохо.
Полагаю, тоже правы.
Дело в том, что это перевод материала www.windowsitpro.com/article/enterprise-identity/windows-server-8-active-directory-moves-142521. Так что в некотором смысле мы снимаем с себя ответственность. Хотя мы, конечно, старались выбрать статью получше.
С уважением,
Антон
Что касается самой ошибки, она и ее решение описаны в нашей базе знаний: http://www.netwrix.com/kb_RZST_0091pB.
Если Вас не затруднит, сообщите, пожалуйста, о том, помогло ли Вам это решение.
Эта возможность есть у нас в планах, но конкретные сроки назвать сейчас невозможно.
А все отчеты стандартные отчеты, которые есть в программе, можно посмотреть здесь www.netwrix.com/ru/Active_Directory_Change_Reporter_Report_Samples.html
С уважением,
Антон Че
Бывает, ходишь с расстегнутой не при дамах будь сказано ширинкой, все поглядывают косо — и никто не скажет. Спасибо, что сообщили об этой неточности! Конечно, возможности долгосрочного хранения логов не отсутствуют, хоть они и довольно громоздки.
Честно сказать, мы при написании этого поста положились на Дона Джонса (http://concentratedtech.com/about/don-jones.php), который написал на английском языке whitepaper www.netwrix.com/download/WhitePapers/NetWrix_WP_The_Audit_Zone_Five_Stories_of_Suspense_and_Security.pdf, и не проверяли его текста.
Так что, видимо, Вашим огорчением мы обязаны Дону. Нас это в свою очередь огорчает. Но мы уже придумали, как исправить ситуацию с техническими неточностями наших замыслов и работаем над новым проектом. Надеюсь, он Вам понравится!
Что касается приведенного Вами продукта GFI и его более современной версии — у нас есть конкурентный продукт NetWrix Event Log Manager (http://www.netwrix.com/event_log_archiving_consolidation_freeware.html). При общей равной «весовой категории» у нашей программы есть некоторые преимущества перед ним. Если Вам интересно, могу привести подробности.
Но это инструменты для сбора логов. Вы же согласны с тем, что ими не осуществляется аудит изменений групповых политик полностью?
С уважением,
Антон Ч.
Максим, Вы правы. Мы это уже поняли и работаем над этим.
Спасибо!
С уважением,
Антон Ч.
Автор совершенно справедливо отмечает, что Events in security logs are notifications saying that in GPO were made any changes but are not saying what exactly was changed. То есть описанным путем нельзя получить главного — информации о том, что именно изменилось. Такой аудит только позволит некоторым подозрениям развиться в болезненную фобию, а не выявить реальную причину инцидента.
При обсуждении затрат на реализацию этого решения Дженифер придется заготовить фразу типа «это, конечно, не решает нашу проблему полностью, но лучших вариантов просто нет» — и отрепетировать оптимистичное выражение лица.
Пол с легкостью получил бы вместо нее бонус за решение задачи, если бы предложил – как Вы думаете, что?!
Конечно, решение, которое позволяет получить значения измененных параметров до и после изменения!
Приведенные Вами варианты решений имеют недостатки:
1. Обработка всех записей журналов событий приводит к большому количеству неинформативных данных. Найти информацию о реальных изменениях в полученных .xml – непростая задача.
2. Сбор данных осуществляется на каждом сервере. А если в компании их 300? Найти нужную информацию будет серьезной проблемой!
3. Хранение архивов журналов безопасности требует большого дискового пространства. В развитых средах через месяц такого хранения потребуются дополнительные меры по его организации. Долгосрочное – в течение нескольких лет — хранение далеко не всегда может быть осуществлено таким образом.
С уважением,
Антон Ч.
Да, это возможно. Обращайтесь, организуем.
В целом так и есть на сегодняшний день, с одной деталью: NetWrix File Server Change Reporter производит мониторинг файловых серверов на NetApp Filer и EMC.