Проверка windows server 2003 на ошибки

Проверка системных файлов Windows

Многие знают, что проверить целостность системных файлов Windows можно с помощью команды sfc /scannow (впрочем, это знают не все), но мало кто знает, как еще можно использовать данную команду для проверки системных файлов.

В этой инструкции я покажу, как осуществить проверку для тех, кто вообще не знаком с данной командой, а после этого расскажу о различных нюансах ее использования, которые, думаю, будут интересны. См. также более подробную инструкцию для последней версии ОС: проверка и восстановление целостности системных файлов Windows 10 (плюс видео инструкция).

Как проверить системные файлы

В базовом варианте, если у вас есть подозрение на то, что необходимые файлы Windows 8.1 (8) или 7 были повреждены или потеряны, вы можете использовать специально предусмотренный для этих случаев инструмент самой операционной системой.

Итак, для проверки системных файлов, проделайте следующие шаги:

1. Запустите командную строку от имени администратора. Для этого в Windows 7 найдите этот пункт в меню Пуск, кликните по нему правой кнопкой мыши и выберите соответствующий пункт меню. Если у вас Windows 8.1, то нажмите клавиши Win + X и запустите «Командная строка (Администратор)» из меню, которое появится.
2. В командной строке введите sfc /scannow и нажмите Enter. Эта команда выполнит проверку целостности всех системных файлов Windows и попытается их исправить в том случае, если были обнаружены какие-либо ошибки.

Однако, в зависимости от ситуации, может оказаться, что использование проверки системных файлов в таком виде не в полной мере подходит для данного конкретного случая, а потому расскажу о дополнительных возможностях команды утилиты sfc.

Дополнительные возможности проверки с помощью SFC

Полный список параметров, с которыми можно запустить утилиту SFC выглядит следующим образом:

Что это нам дает? Предлагаю посмотреть по пунктам:

• Вы можете запустить только проверку системных файлов без их исправления (ниже будет информация о том, зачем это может пригодиться) с помощью sfc /verifyonly
• Имеется возможность проверить и исправить только один системный файл, выполнив команду sfc /scanfile=путь_к_файлу (или verifyfile, если исправлять не требуется).
• Для проверки системных файлов не в текущей Windows (а, например, на другом жестком диске) можно использовать sfc /scannow /offwindir=путь_к_папке_windows

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

Возможные проблемы при проверке

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

• Если при запуске sfc /scannow вы видите сообщение о том, что Защите ресурсов Windows не удается запустить службу восстановления, проверьте, что служба «Установщик модулей Windows» включена, а тип запуска установлен «Вручную».
• Если у вас в системе есть модифицированные файлы, например, вы заменяли значки в проводнике или что-то еще, то выполнение проверки с автоматическим исправлением вернет файлы в первоначальный вид, т.е. если вы меняли файлы специально, это придется повторить.

Может оказаться, что sfc /scannow не удастся исправить ошибки в системных файлах, в этом случае вы можете ввести в командной строке

findstr /c:»[SR]» %windir%LogsCBSCBS.log >»%userprofile%Desktopsfc.txt»

Эта команда создаст текстовый файл sfc.txt на рабочем столе со списком файлов, исправление которых не удалось — при необходимости вы можете скопировать необходимые файлы с другого компьютера с той же версией Windows или с дистрибутива ОС.

А вдруг и это будет интересно:

Почему бы не подписаться?

Рассылка новых, иногда интересных и полезных, материалов сайта remontka.pro. Никакой рекламы и бесплатная компьютерная помощь подписчикам от автора. Другие способы подписки (ВК, Одноклассники, Телеграм, Facebook, Twitter, Youtube, Яндекс.Дзен)

Здравствуйте. У меня после введения sfc /scannow ответ такой : Проверка 0% завершена. Защита ресурсов Виндовс не обнаружила нарушений целостности. Почему — то нет 100% проверки. В чем может быть причина? обновления также не устанавливаются на компьютер.

Добавьте в статью, что в этой команде только один пробел — после «sfc». После палочки пробела нет. Или просто скопируйте:
sfc /scannow

А зачем это добавлять? В инструкции и так нет пробела..

Независимо от того, есть пробел или нет, команда выполняется правильно

У меня просто мелькнуло меню с фоном и пропало. И списка на столе не появилось — словно и не вводил ничего.

А вы в командной строке вводили (которое черное и большое) или просто в окошко «выполнить»? В командной строке от администратора нужно.

Довольно давно пользуюсь этим сайтом Только сейчас заметил здесь всегда всё работает

Здравствуйте. Я сохранил файлик с теми файлами которые не удалось восстановить. А как их исправить теперь?

Вообще, предполагается, что они автоматически будут исправлены. Если нет… то в теории конечно можно их с точно рабочей аналогичной машины взять, но не факт, что это хороший вариант. Если система Windows 10, возможно, лучше переустановку сделать с сохранением данных.

Источник

SFC и DISM: Проверка и Восстановление системных файлов в Windows

Всякий раз, когда что-то идет не так с компьютером или ноутбуком, есть ряд инструментов для устранения неполадок, которые вы можете выполнить, чтобы попытаться устранить проблему. В Windows 10/8/7 есть несколько встроенных команд, которые можно использовать для проверки и восстановления поврежденных системных файлов, которые со временем вызывают проблемы при изменении. Одним из способов устранения неполадок, связанных с Windows, является проверка системы и восстановление системных файлов. Это может помочь во всех типах проблем, таких как медленная система, синий экран смерти, внезапные сбои питания и сбои системы.

Рассмотрим, как запустить средство проверки системных файлов в Windows с помощью командной строки CMD и PowerShell, таких команд как sfc /scannow и инструмента DISM. Хочу заметить, что для обновления Anniversary Update Windows 10, будет лучше использовать методы именно с PowerShell.

Проверка и Восстановление системных файлов через CMD

Средство проверки системных файлов сканирует ваш компьютер на предмет любого повреждения или изменений в системных файлах, которые в противном случае могли бы помешать нормальной работе вашего ПК. Оттуда он заменяет файл правильной версией, чтобы обеспечить бесперебойную работу. С помощью командной строки можно попытаться сканировать и восстановить системные файлы поздних операционных систем, как Windows 10/8/7 / Vista. Разберем две команды sfc /scannow и DISM с помощью CMD.

1. Использование инструмента System File Checker (SFC)

Запустите командную строку (CMD) от имени администратора. Нажмите «поиск» и напишите просто «cmd» или «командная строка», далее по ней правой кнопкой мыши и запуск от имени админа.

Задайте команду sfc /scannow и дождитесь окончания процесса.

Примечание: После сканирования вашей системы будет выдан один из трех результатов:

• Ошибок системных файлов не будет.
• Будут ошибки системных файлов и Windows восстановит их автоматически.
• Windows обнаружила ошибки, но не может восстановить некоторые из них.

Если у вас показывает вариант 3, что ошибка обнаружена и система не может восстановить, то загрузитесь в безопасном режиме и проделайте заново процедуру. Советую отключить шифрование EFS и Bitlocker , если на момент проверки они имеются. Ничего не получилось? Двигаемся ниже.

2. Использование инструмента Deployment Image and Service Management (DISM)

Если вышеуказанное не работает в безопасном режиме, есть один последний способ проверить повреждение в системных файлах и исправить их. Используем инструмент Deployment Image and Service Management (DISM). Команда работает с системами Windows 8/8.1/10. Откройте обратно командную строку от имени администратора и используйте следующую команду:

DISM /ONLINE /CLEANUP-IMAGE /RESTOREHEALTH

Процесс может занять длительное время с зависанием процентной шкалы. Закончив работу, перезагрузите компьютер и запустите обратно sfc /scannow, чтобы убедиться, что ошибок нет или ошибка пропала.

Проверка и Восстановление системных файлов через PowerShell

Мы будем использовать Windows PowerShell, чтобы показать, как использовать службу обслуживания и управления DISM для сканирования и исправления поврежденных системных файлов в Windows 10. Этот способ будет более эффективный для обновления Anniversary windows 10, чем командная строка.

1. Использование инструмента System File Checker (SFC)

Запустите PowerShell от имени администратора. Нажмите «поиск» и наберите windows powershell, после нажмите правой кнопкой мыши и выберите от имени админа.

Задайте в окне PowerShell команду sfc /scannow. Если сканирование обнаружит какие-либо проблемы, Windows попытается их исправить. Если Windows не сможет их исправить, он предупредит вас, что необходимы дальнейшие исследования и действия. Двигайтесь ниже, если обнаружены ошибки.

2. Использование инструмента Deployment Image and Service Management (DISM)

Сканирование DISM обнаруживает поврежденные системные файлы и Windows попытается исправить их, и даст вам отчет о ходе работы в конце. Если Windows не сможет найти файлы, необходимые для восстановления поврежденных системных файлов, вам также будет предоставлена ​​информация о том, что делать дальше, со ссылкой на веб-сайт Microsoft и варианты устранения неполадок. Задайте ниже команду в окно PowerShell.

DISM /ONLINE /CLEANUP-IMAGE /RESTOREHEALTH

Если DISM все исправил или не выявил ошибки, то перезагрузите ноутбук, компьютер и запустите для проверки обратно sfc /scannow.

Источник

Description of System File Checker (Sfc.exe)

This article describes System File Checker (Sfc.exe), which is a command-line utility used with the Windows File Protection (WFP) feature.

Original product version: Windows 10 — all editions, Windows Server 2012 R2
Original KB number: 310747

Summary

System File Checker gives an administrator the ability to scan all protected files to verify their versions. If System File Checker discovers that a protected file has been overwritten, it retrieves the correct version of the file from the cache folder ( %Systemroot%System32Dllcache ) or the Windows installation source files, and then replaces the incorrect file. System File Checker also checks and repopulates the cache folder. You must be logged on as an administrator or as a member of the Administrators group to run System File Checker. If the cache folder becomes damaged or unusable, you can use the sfc /scannow , the sfc /scanonce , or the sfc /scanboot commands to repair its contents.

System File Checker tool syntax

Sfc [/Scannow] [/Scanonce] [/Scanboot] [/Revert] [/Purgecache] [/Cachesize=x]

/Scannow : Scans all protected system files immediately and replaces incorrect versions with correct Microsoft versions. This command may require access to the Windows installation source files.

/Scanonce : Scans all protected system files one time when you restart your computer. This command may require access to the Windows installation source files when you restart the computer. The SfcScan DWORD value is set to 2 in the following registry key when you run this command:

/Scanboot : Scans all protected system files every time you start your computer. This command may require access to the Windows installation source files every time you start your computer. The SfcScan DWORD value is set to 1 in the following registry key when you run this command:

/Revert : Returns scan to the default setting (do not scan protected files when you start the computer). The default cache size is not reset when you run this command. This command is equivalent to the /Enable switch in Windows 2000.

/Purgecache : Purges the file cache and scans all protected system files immediately. This command may require access to the Windows installation source files.

/Cachesize=x : Sets the file cache size to x megabytes (MB). The default size of the cache is 50 MB. This command requires you to restart the computer, and then run the /purgecache command to adjust the size of the on-disk cache. This command sets the SfcQuota DWORD value to x in the following registry key:

For more information about the Windows File Protection feature, see Description of the Windows File Protection feature.

Источник

Запись создана 12 марта, 2008

Sfc [/Scannow] [/Scanonce] [/Scanboot] [/Revert] [/Purgecache] [/Cachesize=x]•    /Scannow — Проверить все защищенные системные файлы и заменить ошибочные версии файлов исходными версиями. Начать проверку немедленно. В процессе выполнения данной команды программе Sfc может потребоваться доступ к установочным файлам Windows.

•    /Scanonce — Проверить все защищенные системные файлы при следующей перезагрузке компьютера. После перезагрузки программе Sfc может потребоваться доступ к установочным файлам Windows. При запуске программы Sfc с параметром /Scanonce параметру системного реестра SfcScan типа DWORD присваивается значение

2. Данный параметр находится в следующем разделе реестра:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

•    /Scanboot — Проверять все защищенные системные файлы при каждой загрузке компьютера. При каждой загрузке компьютера программе Sfc может потребоваться доступ к установочным файлам Windows. При запуске программы Sfc с параметром /Scanboot параметру системного реестра SfcScan типа DWORD присваивается значение

1. Данный параметр находится в следующем разделе реестра:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

•    /Revert — Восстановить параметры проверки, используемые по умолчанию (не проверять защищенные файлы при загрузке компьютера). Использование данной команды не изменяет размер кэша. Данный параметр аналогичен параметру /Enable, который использовался в Windows 2000.

•    /Purgecache — Очистить файловый кэш и выполнить проверку всех защищенных системных файлов. Начать проверку немедленно. В процессе выполнения данной команды программе Sfc может потребоваться доступ к установочным файлам Windows.

•    /Cachesize=x — Установить размер файлового кэша равным x мегабайтам (МБ). По умолчанию размер файлового кэша равен 50 МБ. Для фактического изменения размера кэша на диске необходимо перезагрузить компьютер и запустить программу Sfc.exe с параметром /purgecache. При запуске программы Sfc с параметром /Cachesize параметру системного реестра SfcQuota типа DWORD присваивается значение x. Данный параметр находится в следующем разделе реестра:
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

» Запись из раздела windows | 2 комментария

Комментарии



событий (ID) и кодами, по-прежнему остаются весьма туманными, а соответствующие описания в документации — неточными. К тому же здесь мы вновь сталкиваемся с теми же проблемами построения отчетов, архивирования, оповещения и объединения данных, которые имели место в Windows NT Server. Дополнительные трудности также связаны со страстью Microsoft к внесению в продукты множественных изменений в интерпретацию ID от версии к версии. Однако, если иметь под рукой необходимые инструменты и знать, что именно следует искать, из журнала безопасности можно почерпнуть очень много ценной информации.

В этой первой статье из планируемой серии материалов, посвященных журналам безопасности Windows 2003, я представлю общий обзор политики аудита и структуры самого журнала безопасности, что наверняка будет полезно для новичков в данной области. Более продвинутых «следопытов» журналов безопасности может заинтересовать информация, содержащаяся в примечаниях «Новое в Windows 2003» по каждой из рассматриваемых здесь категорий. В примечаниях содержится обзор тех существенных изменений, которые претерпел журнал безопасности системы Windows 2003. На экране 1 показана закладка Filter диалогового окна Event Viewer?s Security Properties, из которой следует, что все события, связанные с системой безопасности, делятся на девять категорий аудита. В последующих статьях будет более подробно рассмотрена каждая из этих категорий, а также будет показано, как можно извлечь из этих ценных ресурсов максимальное количество информации.

Экран 1. Категории системы безопасности в Event Viewer

Event Viewer

Журнал безопасности можно просматривать с помощью оснастки Event Viewer консоли Microsoft Management Console (MMC). События отображаются в виде некоторого набора стандартных полей, и каждый ID имеет уникальное описание. Стандартными являются поля идентификатора (ID), даты (date), времени (time), имени пользователя (username), имени компьютера (computer name), источника (source), категории (category) и типа (type). Для многих ID, в соответствии с архитектурой системы безопасности Windows, поле имени пользователя отображается как not useful (не используется), соответственно в таких случаях нужно в описании события просматривать поля, содержащие относящуюся к пользователю информацию. В поле имени компьютера всегда содержится имя локальной системы, поэтому информация из этого поля может быть полезной в основном в тех случаях, когда в общую базу данных объединяется информация из журналов нескольких разных компьютеров. Поле источника служит для того, чтобы отображать информацию о том, какой компонент системы или приложение послужили причиной данного события, но при этом для всех событий, занесенных в журнал безопасности, в данном поле будет установлено значение Security. В поле категории отображается одна из девяти категорий аудита, а поле типа может содержать значение Success Audit (аудит был успешен) или Failure Audit (неудачная попытка аудита). Таким образом, по этому полю можно отделить, например, события успешной регистрации в системе от отказов в регистрации. Описание события представляет собой совокупность статического текста на обычном языке и изменяемого списка динамических строк, вставляемых в определенные позиции в этом статическом тексте. Наиболее важная информация по многим событиям содержится именно в строках описания, существуют и программные инструменты для анализа этих данных и построения соответствующих отчетов.

В утилите Event Viewer имеется ряд механизмов поиска и фильтрации, но их возможности весьма ограниченны. Посредством данной утилиты можно выполнять сохранение и/или очистку журнала безопасности. Для сохранения копии журнала (после щелчка правой кнопкой и выбора пункта Save Event Log As) можно выбрать один из трех предлагаемых форматов: «родной» формат Event Viewer (файл с расширением .evt), формат данных, разделяемых запятой (Comma-Separated Value CSV), или формат с разделителем в виде табуляции.

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

В Event Viewer можно задать максимально допустимый размер журнала безопасности и предопределить те действия, которые система Windows должна выполнить при достижении журналом максимального размера. Чтобы увидеть окно установки этих параметров, следует щелкнуть правой кнопкой мыши на соответствующем журнале и выбрать пункт Properties («Свойства»). Здесь можно предписать Windows при необходимости перезаписывать более ранние события, прекращать дальнейшую регистрацию до тех пор, пока кто-либо не очистит журнал, или перезаписывать события, произошедшие ранее заданного количества дней. В последнем случае при заполнении журнала дальнейшая запись событий будет временно прекращена, пока не пройдет достаточно времени для того, чтобы в журнале появились события, удовлетворяющие установленным временным критериям и, соответственно, допускающие удаление.

Категории аудита

Можно настроить Windows 2003 таким образом, чтобы в журнал безопасности записывались только те события, которые соответствуют заданным категориям аудита. Для этого в списке из девяти категорий политики аудита нужно выбрать только те, что представляют интерес для занесения соответствующих им событий в журнал. Чтобы просмотреть действующие в данный момент настройки политики аудита компьютера, запустите, как показано на экране 2, редактор групповых политик (Group Policy Editor, GPE) и раскройте следующую ветвь: Local Computer PolicyComputer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesAudit Policy. Обратите внимание, что порядок перечисления и наименования категорий журнала безопасности (экран 1) и соответствующих им политик аудита (экран 2) слегка различаются. Если посмотреть на экран 2, увидим, что для каждой категории можно включить аудит событий с успешным и/или неудачным результатом либо вообще отключить аудит для данной категории событий. Например, можно для категории Audit account logon events (выполнять аудит попыток регистрации с учетной записью в системе) включить аудит только для неудачных попыток, в результате чего в журнале событий Windows будут фиксироваться только те попытки регистрации в системе, которые по каким-либо причинам закончились неудачей.

Экран 2. Политики аудита системы безопасности

Упомянутые девять категорий аудита охватывают весьма широкий круг действий. Можно наблюдать за процедурами регистрации в системе и аутентификацией, за работой администратора, за поддержкой пользователей, групп и компьютеров, за действиями пользователей, связанными с доступом к файлам, за изменениями важных настроек параметров безопасности, за выполнением тех или иных программ, за изменениями свойств в Active Directory (AD) и т. д. Ниже приводятся краткие описания для каждой категории событий.

Регистрация и аутентификация

Одним из наиболее эффективных методов контроля действий пользователей и выявления атак на системы являются наблюдения за событиями регистрации в системе. Поскольку среда Windows имеет доменную архитектуру, для процессов регистрации в системе и аутентификации применяются различные подходы: если пользователь осуществляет регистрацию на своем компьютере при помощи доменной учетной записи, то данная система должна пройти процедуру аутентификации в AD на соответствующем контроллере домена (DC). Для отслеживания каждого из типов этих действий (или обоих вместе) в системе безопасности используются две категории событий: с помощью категории Logon/Logoff выполняется аудит событий, связанных с регистрацией, а категория Account Logon позволяет отслеживать события аутентификации.

Если мы вспомним эпоху Windows NT, то там категория Account Logon отсутствовала, а была только категория Logon/Logoff, что создавало значительные проблемы при необходимости отслеживать попытки аутентификации в домене. Информация о событиях категории Logon/Logoff записывалась в журналы тех компьютеров, где эти события произошли, т. е. в журналы рабочих станций и серверов домена, но не контроллеров домена. Поэтому, если требовалось отследить неудачные попытки регистрации в системах, приходилось просматривать журналы событий на каждой рабочей станции и сервере домена. Но еще хуже, что не было возможности отслеживать попытки регистрации с неавторизованных компьютеров.

Ситуация изменилась с появлением семейства продуктов Windows 2000, в них уже была предусмотрена категория Account Logon (хотя, на мой взгляд, название для нее было выбрано неудачно — правильнее было бы назвать эту категорию Authentication). Теперь стало возможным регистрировать все происходящие в домене события категории Account Logon на контроллере домена. Правда, при этом все равно требовалось отслеживать события на всех контроллерах домена, но, согласитесь, это намного лучше, чем просматривать журналы безопасности на каждом компьютере сети.

Несмотря на появление категории Account Logon, сохранилась и существовавшая категория событий Logon/Logoff. Причина этого заключается в том, что данная категория может помочь при необходимости проконтролировать весь сеанс регистрации в целом. При этом события категории Account Logon информируют о том, кем, где и когда предпринимались попытки регистрации в системе, а события категории Logoff/Logon сообщают о продолжительности этих сеансов. Кроме того, события типа Logon/Logoff содержат более подробную информацию о причинах неудачи той или иной попытки регистрации в системе.

Новое в Windows 2003. В Windows 2000 имеется набор идентификаторов для событий успешной аутентификации и еще один набор ID для событий неудачной аутентификации. В Windows XP события категории Account Logon не претерпели каких-либо изменений, но в системе Windows 2003 события этой категории содержат некоторые дополнительные данные. Следует также отметить, что разработчики Microsoft, по совершенно необъяснимым причинам, удалили некоторые ID для определенных событий неудачной аутентификации и объединили их с соответствующими событиями успешной аутентификации.

Управление учетными записями и доступ к службе каталогов

С помощью категории Account Management можно отслеживать изменения в учетных записях пользователей, групп и компьютеров, кроме того, она незаменима при наблюдении за некоторыми видами действий. Наилучший подход к управлению доступом состоит в том, чтобы предоставлять доступ группам, а не отдельным пользователям. С помощью категории событий Account Management можно легко идентифицировать случаи изменения членства в группах. Во многих случаях злоумышленники, получившие права административного доступа к системе, сначала создают новую учетную запись, а затем используют ее для дальнейших атак. С помощью событий категории Account Management факт создания новой учетной записи может быть легко выявлен. Использование категории Account Management может также помочь заставить администратора более ответственно относиться к своей работе. Если кем-то была случайно удалена учетная запись пользователя или внесены некорректные изменения в настройки пользователя или группы, то с помощью аудита событий категории Account Management подобные действия можно отследить.

Категория Directory Service Access обеспечивает низкоуровневый аудит объектов AD и их свойств. Поскольку данная категория имеет непосредственное отношение к AD, то активировать аудит подобных событий на системах, которые не являются контроллерами домена, не имеет ни малейшего смысла. Данная категория в значительной степени пересекается с Account Management, поскольку пользователи, группы и компьютеры тоже являются объектами AD. Но если отчеты Account Management содержат данные по высокоуровневым изменениям для пользователей, групп и компьютеров, то, применяя категорию Directory Service Access, можно обеспечить аудит объектов AD (в том числе пользователей, групп и компьютеров) на очень низком уровне. В категории Account Management каждому типу объектов и каждому событию доступа к объекту соответствует уникальный идентификатор ID. С другой стороны, в категории Directory Service Access для всех типов действий существует единственный идентификатор с ID 566. К ID 566 относятся тип объекта, имя объекта, имя пользователя, получившего доступ к объекту, а также тип доступа. В примере события, показанном на экране 3, администратор изменил в учетной записи Susan параметр job title.

Хотя категория Directory Service Access обладает весьма богатыми возможностями, тем не менее использоваться может лишь небольшая их часть. На контроллерах доменов Windows 2000 политика аудита событий Directory Service Access настроена по умолчанию таким образом, чтобы в журнал записывались как удачные, так и неудачные попытки изменений объектов AD, что приводит к наличию огромного количества событий. Отметим также, что названия типов объектов и свойств поступают в события с ID 566 непосредственно из схемы AD и могут при этом выглядеть весьма загадочно. Например, поле user?s city (город) отображается в виде «/» (местонахождение) а поле last name (фамилия) представлено в виде sn (surname). Обычно для обеспечения аудита событий, связанных с пользователями, группами и компьютерами, наибольший практический интерес представляет категория Account Management. Однако при этом следует понимать, что выполнять аудит изменений, вносимых в другие важнейшие объекты AD, такие как групповые политики (GPO) или организационные подразделения (organizational unit, OU), можно только с помощью категории Directory Service Access.

Новое в Windows 2003. В Windows 2003 исправлена имевшаяся в Windows 2000 ошибка, связанная с изменениями и сбросом пользовательского пароля. В документации на Windows 2000 указывается, что сбросу пароля в журнале событий соответствует ID 628, хотя на самом деле процедурам как сброса, так и изменения пароля в системном журнале соответствует один и тот же ID 627 и они всегда отображаются в отчетах как события смены пароля. В Windows 2003 смене пароля соответствует ID 627, а сбросу пароля — ID 628.

Аудит доступа к файлам

В принципе с помощью категории Object Access можно следить за доступом к файлам, папкам, принтерам, разделам реестра и системным службам, но в большинстве случаев данная категория используется для отслеживания доступа к файлам и папкам. Как только будет включен аудит по данной категории, в журнале безопасности сразу же отобразится некоторое количество событий, касающихся доступа к объектам в базе безопасности SAM. Однако каких-либо других событий, связанных с доступом к файлам или другим объектам, вы здесь, вероятнее всего, не увидите, поскольку каждый объект имеет свои настройки параметров аудита, а по умолчанию почти у всех объектов аудит отключен. Это правильная практика, поскольку, если в системе будет включен аудит попыток доступа к каждому файлу или объекту, то данная система до своей полной остановки будет заниматься только обработкой этих событий, а ее журнал безопасности быстро переполнится, вне зависимости от назначенного ему объема. Я рекомендую применять эту категорию только к критически важным файлам, действительно требующим механизмов слежения за доступом к ним.

Для того чтобы активизировать аудит событий для выбранного объекта, нужно открыть его диалоговое окно свойств, выбрать закладку Security, нажать кнопку Advanced, выбрать закладку Auditing, после чего нажать кнопку Add. Например, на экране 4 можно увидеть настройку параметров аудита для файла 1st Quarter Cost Centers.xls, который я открыл из Windows Explorer. Обратите внимание, что можно указывать конкретных пользователей или группы, доступ которых к данному файлу необходимо отслеживать, можно назначать аудит лишь для конкретного типа доступа либо аудит только успешных (или неудачных) попыток доступа к данному объекту. Как только будет включен аудит для соответствующего объекта, Windows начнет регистрировать события открытия, закрытия и другие типы событий для данного объекта согласно выбранной для него политике аудита.

Экран 4. Настройки аудита для объекта

Новое в Windows 2003. Безусловно, журнал безопасности в Windows 2000 выполняет очень важную функцию, информируя о том типе доступа к объекту, который имеет пользователь или приложение, но при этом остается неизвестным, что в действительности пользователь или приложение делают с этим объектом. Предположим, что пользователь А открыл документ, на который у него есть разрешения на чтение и запись. При этом в журнал Windows 2000 записывается событие с ID 560, которое говорит о том, что пользователь, имеющий разрешения доступа List Folder / Read Data и Create Files / Write Data, открыл файл. Когда А закроет файл, в журнал Windows 2000 будет занесено событие с ID 562, означающее, что пользователь закрыл файл. В Windows 2003 добавлено новое событие с ID 567. Если пользователь А изменит содержимое файла на компьютере с Windows 2003, в журнале между событиями открытия и закрытия соответствующего файла будет зарегистрировано событие с ID 567. В нем содержится информация о названии объекта, пользователе и том типе доступа, который этот пользователь в действительности применял. Если в данном месте журнала событие с ID 567 не зарегистрировано, это говорит о том, что пользователь не изменял содержимое файла.

Слежение за выполнением программ

Категория Detailed Tracking предоставляет администратору возможность мониторинга каждой программы, запущенной на системе. Можно контролировать запуск (ID 592) и закрытие (ID 593) пользователями любых приложений. Эти два события могут быть связаны друг с другом через идентификатор процесса (process ID), который можно найти в описаниях обоих событий. Для того чтобы получить полное представление о сеансе работы пользователя, можно задействовать механизмы слежения за процессами с аудитом процедур входа/выхода (logon/logoff), а также открытия/закрытия файлов (file open/close). При этом будет видно, когда пользователь регистрировался в системе, какие запускал программы и к каким файлам из этих программ обращался.

Новое в Windows 2003. В Windows 2003 в категорию Detailed Tracking добавлено два новых события. Событие с ID 601 позволяет отслеживать моменты установки в систему новых служб, что может пригодиться для контроля установки служб на серверах и рабочих станциях с целью проверки их легитимности и выявления наличия несанкционированных служб. При этом нужно понимать, что данное событие может применяться только к системным службам, но не к приложениям, запущенным пользователем на компьютере. Кроме того, для выявления «троянцев» и шпионских программ данное событие также неприменимо, поскольку подобного рода программы обычно не устанавливают себя на системы в качестве служб. Событие с ID 602 информирует о фактах создания задач для службы планировщика, но при этом не отслеживаются моменты внесения изменений, удаления или попыток запуска кем-либо этих задач.

Права пользователей

Для обеспечения контроля возможностей выполнения пользователями функций системного уровня, таких как изменение системного времени или выключение, в Windows применяется система прав пользователей (привилегий). Контроль использования этих прав может быть реализован с помощью категории Privilege Use. Для большинства прав в журнале Windows регистрируются события Privilege Use (ID 577 или 578), однако некоторые виды прав используются настолько часто, что разработчики Microsoft предпочли не регистрировать каждый факт их применения. Вместо этого, когда реализуется какое-либо из этих прав, в журнале Windows просто отражается факт использования права с ID 576.

Новое в Windows 2003. В системе Windows 2000 при попытках просмотреть либо снять содержимое дампа памяти в журнал безопасности заносится событие с ID 578, но в Windows 2003 этого почему-то не происходит. И аналогично, когда кто-то хочет стать владельцем файла или другого объекта, система Windows 2003 не регистрирует никакого события (в Windows 2000 и в этом случае происходит запись события в журнал). Возможно, эти ошибки будут исправлены в первом пакете обновления системы Windows 2003, поскольку в Windows 2000 некоторые ошибки, связанные с аудитом, в выпущенных для данной системы пакетах обновления были устранены.

Изменения политик

В тех журналах безопасности, которые мне довелось просматривать, я так и не обнаружил нескольких событий категории Policy Changes, которые, в соответствии с документацией Microsoft, должны записываться в журнал. Так, одни события, связанные с протоколом IP Security (IPSec), похоже, никогда не регистрируются в журнале (например, ID 613, 614 и 616), в то время как другие (ID 615) регистрируются. И тем не менее категория Policy Changes предназначена для регистрации событий, связанных с изменениями конфигурации параметров безопасности, включая изменения доверительных отношений, политики Kerberos, шифрующей файловой системы EFS и параметров QoS.

Новое в Windows 2003. В системе Windows 2000 событие с ID 615 относилось к категории Detailed Tracking, но в Windows 2003 оно перекочевало в категорию Policy Change. И это всего лишь один из примеров тех загадочных и ненужных изменений, которые мне удалось выявить при сравнении событий в системах Windows 2000 и Windows 2003. А вот еще одно интересное изменение: в документации утверждается, что при назначении и аннулировании пользовательских прав в журнал Windows заносятся события, имеющие соответственно ID 608 и 609. Однако в журнале Windows 2000 ни одно из этих событий не регистрируется. Что касается системы Windows 2003, то здесь при изменениях в правах пользователей происходит запись в журнал событий с ID 608 и 609, за исключением тех случаев, когда это связано с изменениями прав регистрации, таких как Allow logon locally и Access this computer from the network. В Windows 2003 для такого рода событий, в отличие от заявленных в документации ID 608 и 609, используются идентификаторы ID 621 и 622 (соответственно для предоставления и лишения прав). Подобные необъяснимые и недокументированные изменения приводят к нарушениям работы программ мониторинга и построения отчетов, которые выполняют фильтрацию и анализ событий, основываясь на категориях, ID, или на поле, расположенном в определенном месте в описании события.

Системные события

Категория System Events является вместилищем для разнообразных событий, касающихся системы безопасности. В данной категории система предоставляет информацию о процессах начальной загрузки (ID 512) и выключения (ID 513), а также о работе различных компонентов системы безопасности (в частности, о процессах регистрации и процедурах аутентификации) во время начальной загрузки системы. Здесь есть два чрезвычайно полезных события, а именно: событие с ID 517, информирующее пользователя об очистке журнала событий и о том, кто это сделал, и событие с ID 520, которое присутствует только в Windows 2003.

Новое в Windows 2003. При тестировании Windows 2003 в категории System Events единственным новым событием, которое мне действительно удалось обнаружить, было событие с ID 520. Наличие данного события в журнале говорит о том, что системные время и дата были изменены, здесь же в его описании приводятся новое и старое значения даты и времени.

Журнал безопасности является чрезвычайно мощным средством контроля действий пользователей и персонала подразделений ИТ, а также обнаружения вторжений, но при этом весьма непростым средством. Чем более глубоко удастся вникнуть в особенности его структуры, тем больших успехов можно добиться при работе с ним и тем больше данных можно извлечь из любых журналов безопасности с помощью имеющихся средств построения отчетов и выдачи оповещений.

Примечание автора

Данная серия статей построена на базе курса Security Log Secrets компании Monterey Technology Group.

---

Редактор Windows IT Pro и ведущий инструктор и разработчик курсов для программы по безопасности Windows NT/2000 института MIS Training. Его компания, Monterey Technology Group, занимается консалтингом в области информационной безопасности. Связаться с ним можно по адресу: rsmith@monterey techgroup.com

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

Для удобства чтения, а также предоставления логов третьей стороне, рекомендуется перенаправлять вывод команд в файл: ( >c:имя_файла.txt)

1. диагностика AD (Active Directory)

Синтаксис:

dcdiag [/s:<DomainController>] [/n:<NamingContext>] [/u:<Domain><UserName> /p:{* | <Password> | «»}] [{/a | /e}] [{/q | /v}] [/i] [/f:<LogFile>] [/c [/skip:<Test>]] [/test:<Test>] [/fix] [{/h | /?}] [/ReplSource:<SourceDomainController>]

Пример:

dcdiag /v /c /d /e /s:имя_домена > c:dcdiagn.txt

2. Эта команда применима до WS 2003, не поддерживается WS 2008 и выше.   Диагностика сети:

netdiag /v > c:netdiagn.txt

3. Диагностика репликации: (запускается на каждом контролере домена)

repadmin /showrepl имя_домена /verbose /all /intersite > c:repli.txt

4. Диагностика DNS:

dnslint /ad /s "ip_адрес"