NT клуб (со страниц журнала Изона)

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

Она носит обзорный характер и не претендует на полное описание истории создания и развития ОС линейки NT. В статье использовались материалы из книги Д. Соломона и М. Руссиновича "Внутреннее устройство Microsoft Windows 2000".

Данная книга уникальна в своем роде, я ее рекомендую всем интересующимся "внутренностями" Windows 2000, кто обладает достаточным знаниями для осмысления ее содержания. А знания потребуются основательные!

Краткая предыстория
Как известно, своей популярностью фирма Microsoft обязана IBM-совместимым ПК (Персональным Компьютерам). Именно благодаря им удалось сделать разработку Программного Обеспечения (ПО) массовым и весьма прибыльным делом.

На заре компьютерной эпохи компьютеры представляли собой огромные шкафы, стоящие баснословных денег, а ПО к ним писалось на заказ, зачастую даже фирмой-изготовителем данного компьютера. И стоило оно не меньше, чем сама ЭВМ. Шутка ли — разрабатывать сложные программы на "Ассемблере". Затем, когда мощности компьютеров возросли, стало возможным создавать программы на языках высокого уровня, таких, как C. Это не только ускорило разработку программ, уменьшило их стоимость, но и сделало их переносимыми на уровне исходных текстов.

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

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

Тем не менее, рынок ПК рос, а в стане производителей больших ЭВМ началась тревога: поставки мэйнфреймов стали сокращаться, а виной этому — ПК, которые дешевле и неплохо справляются с задачами, не требующими большого быстродействия, например, в качестве офисной машины. Фирме IBM такое положение дел не нравилось, и она решила захватить только-только зарождающийся рынок ПК, дав задание своим инженерам создать идеальный персональный компьютер. Инженеры решили сделать архитектуру машины открытой и модульной, что несвойственно для IBM, а помочь в разработке ПК попросили мелкую компьютерную фирму Microsoft (смех в зале), занимающуюся разработкой софта для персоналок.
В качестве основы нового компьютера был взят процессор i8088 фирмы Intel, имеющий 16-разрядную архитектуру и 8-разрядную шину данных. Такое странное сочетание было обусловлено двумя моментами: во-первых, Билл Гейтс, глава Microsoft, хотел, чтобы компьютер имел мощный 16-разрядный процессор, а во-вторых, для удешевления и упрощения разработки материнских плат решено было взять CPU (Central Processor Unit — Центральный Процессор), имеющий 8-битную шину данных, вместо полностью 16-разрядного i8086.

В итоге получилось дешево и сердито. Очень скоро рынок персональных компьютеров заполонили ПК IBM, имеющие на своем борту качественную ОС от Microsoft — MSDOS, которая продавалась за копейки. Еще позже появились клоны ПК от IBM, названные "IBM-совместимые ПК", и ситуация стала неконтролируемой. Именно с этого момента и началась эра персональных компьютеров.

Мощности машин росли, скоро вышел процессор i386, позволяющий реализовать такие вещи, доступные ранее только на больших ПК, как многозадачность, виртуальная память, защита... Однако, однозадачная MSDOS даже теоретически не могла все это использовать, так как потеряла бы совместимость со старым ПО, что было недопустимо. Чуть раньше Microsoft разрабатывала совместно с Apple ОС, имеющую графический интерфейс.

Затем Microsoft переключилась на собственную версию ОС с GUI (Graphic User Interface — Графический Интерфейс Пользователя) — Windows. Эта ОС, по сути дела, представляла надстройку над DOS, была 16-разрядной и очень слабо поддерживала такие функции, как многозадачность и защита памяти.

После неудачной попытки продвижения на рынке ПК собственной версии Unix — XENIX — вместе с IBM было решено разработать многозадачную, многопользовательскую, сетевую ОС, не подверженную сбоям и обладающую хорошей переносимостью и быстродействием. Этот проект назвали OS/2. IBM хотела создать единую для всех компьютеров ОС, однако, как позже будет писать Билл Гейтс в своей книге "Дорога в будущее", чем больше ОС становилась ближе к мэйнфреймам, тем дальше она отходила от мира ПК. В конце концов Microsoft бросила этот проект и решила создать собственную ОС, подобную OS/2 и рассчитанную как на маломощные 32-разрядные ПК, так и на многопроцессорные серверы. Этот момент стал точкой отсчета истории линейки NT.

История Windows NT
Истоки Microsoft Windows NT восходят к октябрю 1988 года, когда было решено создать переносимую ОС, совместимую с OS/2, поддерживающую POSIX и мультипроцессорную обработку, обладающую высокой защищенностью и интегрированными средствами работы в сетях. Проект поручили Дэвиду Катлеру (David Cutler — главный консультант фирмы DEC, который 17 лет проработал там, разрабатывая ОС и компиляторы). Он собрал команду инженеров для разработки ОС новой технологии (New Technology — NT). Первоначально планировалось разработать NT с пользовательским и программным (API) интерфейсами в стиле OS/2, однако OS/2 плохо продавалась, а Windows 3.0 имела большой и постоянный успех на рынке. Проанализировав ситуацию на рынке и сложности, связанные с развитием и поддержкой двух несовместимых систем, Microsoft решила создать единую цельную ОС. Windows NT, как было названо следующее поколение Windows-систем, занимает самое значимое место в семействе Windows. Она поддерживает графический интерфейс пользователя, Win32 API — 32-битный программный интерфейс для разработки приложений. Поначалу предполагалось, что Windows NT будет создана за пару лет, но в действительности ее первая версия вышла лишь через 4,5 года — летом 1993-го. Эта версия поддерживала процессоры семейства x-86 (начиная с i386), MIPS R4000 и чуть позже Digital Alpha. ОС получилась более громоздкой и медленной, чем ожидалось, и следующей вехой стал проект Daytona.

Главными целями проекта были: уменьшение размера системы, повышение ее быстродействия и надежности. Windows NT 3.5 вышла осенью 1994-го, а через полгода появилась NT 3.51 с поддержкой процессора IBM PowerPC. Поводом для создания следующей версии послужило желание сделать пользовательский интерфейс, совместимый с Windows 95, и использовать ее технологии.

В результате летом 1996 появилась Windows NT 4.0. При ее разработке Microsoft решила пожертвовать стабильностью ради производительности. С этой целью были внесены изменения в архитектуру: библиотеки менеджера окон и GDI, а также драйверы графических адаптеров были перенесены из пользовательского режима в режим ядра, что повышает скорость выполнения графического ввода-вывода.

В то же время описанные изменения делают операционную систему в принципе менее надежной. На разработку Windows 2000 ушло 3,5 года, на рынке она появилась в декабре 1999-го. Она построена на той же технологии Windows NT, но обладает новой функциональностью, такой, как служба каталогов Active Directory.

В октябре 2001-го на свет появляется следующая версия линейки NT — Windows XP. Ее, в принципе, можно рассматривать как улучшенную версию Windows 2000, хотя эти улучшения, в основном, косметические.

Следует учесть, что каждая новая версия ОС имеет ряд модификаций. Основные вехи развития NT-систем можно представить в следующей последовательности:

Август 1993-го — Windows NT 3.1.
Сентябрь 1994-го — Windows NT 3.5.
Июнь 1995-го — Windows NT 3.51.
Август 1996-го — Windows NT 4.0.
Февраль 2000-го — Windows 2000.
Октябрь 2001-го — Windows XP.

NT club. Часть 6. Архитектура NT
Автор: Creator

Пролог
Следующим этапом изучения ОС семейства NT я решил сделать обзор их архитектуры. Она со временем, конечно, изменялась, но базовые принципы остались непоколебимы. Вообще архитектура Windows 2000 от XP ничем серьезно не отличается (да и от NT 4.0 тоже). Как упоминалось ранее (“NT club. Часть 5. Как это было”), серьезные изменения произошли только в NT 4.0, когда графическая подсистема была перенесена в режим ядра. В процессе своих рассуждений я не буду углубляться в дебри устройства ОС — это совершенно неинтересно той аудитории читателей, на которую рассчитана данная статья. Однако читателю придется-таки столкнуться с рядом терминов, значение которых он может не знать. Тут лучше включить свою “соображалку”, так как ничего особо сложного они собой не представляют. В конце данного материала я объясню, зачем все-таки нужно пользователю в целом представлять устройство своей ОС (имеется в виду домашний пользователь: у корпоративных есть свой бог и учитель — Системный Администратор, который и решает все их проблемы). И последнее. В подготовке статьи широко использовались материалы из книги Д. Соломона и М. Руссиновича “Внутреннее устройство Microsoft Windows 2000”.


Ядерная реакция
Сначала я приведу очень упрощенную (рис.1), однако вполне достаточную для понимания основных принципов функционирования ОС схему архитектуры Windows NT (начиная с NT 4.0). Обратите внимание на линию, разделяющую части кода, выполняющиеся в разных режимах процессора. Прямоугольники над этой линией соответствуют процессам пользовательского режима, компоненты под ней — сервисам режима ядра. Главное отличие этих режимов состоит в том, что код, работающий в режиме ядра, получает доступ ко всем ресурсам ОС и оборудованию, а код пользовательского режима способен лишь вызывать сервисы ОС для манипуляции с оборудованием или внутренними структурами системы. Причем как ядро, так и каждый процесс (задача, приложение) имеет собственное виртуальное адресное пространство. Из всего этого делаем важный вывод: нарушить работу системы может только код режима ядра, пользовательский же код при всем своем желании не может повредить не только систему, но и другие работающие приложения (за исключением разделяемой памяти). Еще один важный момент: ядро ОС (точнее, исполнительная система и микроядро) и драйверы работают в одном адресном пространстве, причем в целях повышения быстродействия в режиме ядра не проводится никаких проверок на правильность передачи параметров процедурам и т.д., что в случае некорректно работающего драйвера может привести к катастрофе — сбою в режиме ядра (ошибка STOP, пользователи обычно называют это Синим Экраном Смерти — BSOD, хотя машина еще вполне работоспособна, и с помощью второго компьютера и отладчика можно найти и устранить проблему). Таким образом, добавление драйвера устройства — единственный способ добавить в систему код режима ядра и в то же время единственный способ “грохнуть” по-настоящему вашу NT, так как при таких сбоях, во-первых, восстановление почти невозможно, а во-вторых, дальнейшая работа может привести к еще большим повреждениям, в том числе и пользовательских данных, что недопустимо. Для предотвращения таких ситуаций Microsoft придумала систему верификации и подписывания драйверов. Сначала компоненты драйвера проходят тест в лабораториях WHQL (Windows Hardware Quality Laboratory) и в случае его успешной сдачи подписываются этой лабораторией как совместимые с данной версией Windows. При установке драйвера в систему ОС проверяет его подпись. Если она есть и является верной и действительной, драйвер устанавливается без вопросов, если есть какие-то проблемы с этим — все зависит от принятой политики подписывания драйверов (отказ от установки, запрос пользователю на установку, установка без запроса). Следует отметить, что данное нововведение появилось в Windows 2000. Ну, а сейчас мы быстро пробежимся по основным компонентам системы.

Пользовательские процессы
Фиксированные процессы поддержки системы, например, диспетчер сеансов. Необходимы для нормальной работы системы. Имеют доступ напрямую к некоторым сервисам ОС, т.е. являются привилегированными процессами.

Процессы сервисов (сервисы Win32). Иначе называются службами. Пример — Планировщик задач. Работают в фоновом режиме, без интерактивного взаимодействия с пользователем.

Пользовательские приложения. Бывают пяти видов: Win32, Windows 3.1, MS-DOS, POSIX и OS/2.

Подсистемы окружения. Образуют окружение операционной среды, предоставляя сервисы ОС. Существует 3 подсистемы: Win32, POSIX и OS/2.
Обратите внимание на прямоугольник с DLL-подсистем. Дело в том, что процессы пользовательского режима не могут вызывать сервисы ядра ОС напрямую, вместо этого они используют DLL (Dynamically Loadable Library — динамически загружаемая библиотека) соответствующих подсистем окружения.

Компоненты режима ядра
Исполнительная система. Содержит базовые сервисы ОС (управление памятью, процессами и потоками, защиту, ввод/вывод и взаимодействие между процессами).

Ядро — низкоуровневые функции ОС (планирование потоков, диспетчеризация прерываний и исключений и т.д.). Предоставляет набор процедур и базовых объектов исполнительной системе для реализации более сложных структур.

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

Уровень абстрагирования от оборудования. Изолирует другие компоненты режима ядра от специфики оборудования данной платформы.
Подсистема поддержки окон и графики. Реализует функции графического интерфейса пользователя (GUI). Обеспечивает поддержку окон, элементов управления пользовательского интерфейса и отрисовку графики.

Тяжело в учении, легко в бою
К чему я все это вам рассказываю? Важно, чтобы пользователь понимал, где произошел сбой, чтобы потом его устранить. Если вы знаете источник ошибки, установить причину и ликвидировать ее не составит особого труда. Для примера приведу случай, произошедший со мной полгода назад. У одного моего знакомого на довольно мощной машине стояла Windows XP Home Edition. ОС я устанавливал сам, так что за ее работоспособность отвечал тоже я. Сам знакомый и вся его семья в компьютерах разбирается довольно слабо, но знаний для набора текста и работы с Интернетом хватает. Однажды мне позвонил этот товарищ и рассказал грустную историю примерно такого содержания. Установил он себе WarCraft III, начал играться, но, как только к нему приближалось вражеское войско, машина перезагружалась. Как будет рассуждать неосведомленный в архитектуре ОС пользователь: ага, машина перезагружается — значит, глючит либо игрушка (что скорее всего), либо Windows (как надоело это глюкало!). Методы решения проблемы: переустанавливаем игру, не помогло — переустанавливаем Windows, снова не помогло — удаляем либо игру, либо Windows (и наслаждаемся жизнью;)). А вот логическая цепочка знающего пользователя (моя в данном случае): компьютер перезагружается — значит, возникает серьезная ошибка класса STOP, что приводит к появлению BSOD (Синего Экрана Смерти), но так как в опциях системы по умолчанию стоит перезагрузка при таких ошибках, то синего экрана мы не видим. Эту версию подтверждает сообщение после сброса и запись в системном журнале. Далее: ошибки подобного рода могут возникать только в коде, работающем в режиме ядра, т.е. либо в исполнительной системе ОС (что маловероятно), либо в драйверах устройств. Информацию о сбойном драйвере можно получить в системном журнале. Я же просто просмотрел в шестнадцатеричном вьювере (Lister в Total Commander) файл дампа сбойного участка памяти (он (файл) находится в папке %SystemRoot%\Minidump), где после ключевого слова STOP и параметров ошибки были перечислены загруженные драйверы, а перед ними шел наш виновник. Им оказался драйвер интегрированной звуковой карты. Покопавшись в настройках игрушки, я обнаружил опцию Использовать 3D звук (вроде так, а может, Использовать EAX). Тут мне стала ясна вся картина происшедшего. Игра при появлении новых юнитов на горизонте пыталась сыграть их звук, используя 3D-возможности аудиокарты, но либо сама плата такими возможностями не обладает, либо они криво реализованы в плате или в драйвере — в любом случае это приводило к плачевным последствиям. Варианты решения данной проблемы: сменить драйвер или аудиокарту либо отключить 3D-звук в игре. Я как ленивый человек выбрал последний вариант. В итоге все заработало без проблем. Думаю, этот поучительный случай заставит вас логически думать при возникновении подобных проблем.

Апрельские тезисы
Итак, мы вкратце рассмотрели архитектуру NT-образных систем. Теперь перейдем к обзору файловых систем, которые стандартно поддерживаются этими ОС (а нестандартно, с помощью сторонних драйверов, можно обеспечить работу с любой файловой системой). Следует учесть, что NTFS (New Technology File System) существует в виде нескольких версий, совпадающих с номером NT (5.1 для XP, например; наличие Service Pack'ов эту закономерность может нарушить), соответственно нововведения ФС (Файловой Системы) не будут поддерживаться старой версией NT, поэтому лучше использовать с ОС родную версию ФС. Вот список файловых систем, поддержка которых стандартно включена в Windows 2000/XP:
• NTFS — исключительно для NT-систем.
• FAT12 — поддержка дискет.
• FAT16 — для совместимости с MS-DOS.
• FAT32 — ФС, используемая в Windows 95 и 98.
• CDFS — файловая система компакт-дисков.
• UDF — универсальный формат дисков.

Также поддерживается распределенная файловая система (Distributed File System — DFS) и файловая система с шифрованием (Encrypted File System — EFS). Строго говоря, это не настоящие ФС. DFS представляет собой расширение сетевого сервиса и позволяет объединять в единый логически том сетевые ресурсы, а EFS — надстройка над NTFS, обеспечивающая функции шифрования. Ну, а теперь остановимся подробнее на каждой файловой системе.

CDFS
CDFS (Compact Disk File System), используемая в Windows 2000 (вроде, и в XP) выполнена по стандарту ISO 9660, согласно которому к именам файлов предъявляются следующие требования:
• Имя не превышает 32 символа.
• Все буквы строчные.
• Глубина вложения каталогов — не более 8 уровней.
Опытные пользователи заметят, что эти ограничения в большинстве случаев обходятся без проблем. В XP встроены средства для записи дисков с этой ФС.

UDF
UDF (Universal Disk Format) — файловая система, соответствующая стандарту ISO 13346, предназначенная для доступа в режиме чтения к DVD-ROM- и CD-ROM-дискам. В будущем планируется обеспечить доступ и на запись.


FAT12
ФС FAT (File Allocation Table) получила свое название из-за способа организации данных — таблицы размещения файлов. Она ориентирована на небольшие диски и простые структуры каталога. FAT12 является 12-битной верcией FAT, соответственно она может адресовывать 212 кластеров (минимальных логически адресуемых единиц данных на диске). Это ограничение и небольшое количество вхождений в корневой каталог определяет использование этой ФС. Сейчас она применяется на дискетах, раньше ее использовали на винчестерах, но эта ФС была быстро вытеснена улучшенной версией — FAT16. Диск с использованием любой FAT имеет следующую структуру (см. рис.1).
Корневой каталог имеет фиксированный размер. Каталоги — специальные файлы с элементами для каждого файла, содержащегося в этом каталоге. Эти элементы включают:
• Имя файла (8+3 символа).
• Байт атрибута (8 бит).
• Время модификации (16 бит).
• Дату модификации (16 бит).
• Первый размещаемый блок (12 бит для FAT12).
• Размер файла (32 бита).

Специальная надстройка над FAT, называемая VFAT (Virtual FAT), обеспечивает поддержку длинных имен файлов. Это следует учесть, так как некоторые старые DOS-утилиты могут запороть диск с длинными именами файлов, считая поврежденной структуру FAT. Все версии FAT не обладают функциями защиты данных и автоматического восстановления, посему я рекомендую их применять только для обеспечения совместимости.

FAT16
Улучшенная версия FAT. Максимальный размер тома равен 4095 Мб, размер кластера определяется размером тома и находится в диапазоне от 512 байт до 64 Кб. Число кластеров не превышает 216.

FAT32
Модифицированная версия FAT. Размер тома увеличен до 127 Гб, число кластеров — до 232. Позволяет использовать при одинаковых размерах томов кластеры меньшего размера, чем FAT16, что увеличивает эффективность организации данных. Впервые поддержка этой ФС появилась в Windows 95 OSR2. Все версии NT до 4.0 включительно ее не поддерживают (для поддержки в NT 4.0 нужен соответствующий Service Pack).

NTFS
Ну вот и дошли до самого интересного. Данная ФС является основной для NT. Без нее Windows NT уже и не NT (с этим трудно поспорить ввиду отсутствия в других ФС поддержки управления избирательным доступом и аудита). Эта файловая система обеспечивает эффективность, надежность и совместимость, невозможные в других поддерживаемых файловых системах, способна адресовывать до 264 кластеров (в текущей реализации — до 232) и работать с кластерами оптимальных размеров. NTFS — журналируемая, основанная на транзакциях ФС, обладающая функциями самовосстановления. Здесь необходимы небольшие пояснения.

Все операции с метаданными в NTFS разбиваются на неделимые блоки — транзакции. Каждая транзакция может быть выполнена успешно либо, в случае сбоя, откачана назад. Незавершенные транзакции не допускаются. Все транзакции регистрируются в файле журнала. Такой механизм обеспечивает абсолютную целостность структуры ФС, но допускает потерю пользовательских данных (архиредкое явление), так как журналировать все данные было бы неэффективно. В случае сбоя системы, например, в результате потери питания, при загрузке запускается программа AUTOCHK, проверяющая флаг "Грязный" тома. Если он установлен, запускается утилита CHKDSK, выполняющая 3 прохода: анализа, повторов и откатов. Таким образом обеспечивается выполнение либо откат всех незавершенных транзакций. Это очень упрощенная схема, но она позволяет понять преимущества журналируемой ФС над другими.

Структура NTFS довольно проста, хотя и сложнее, чем в FAT. Каждый распределенный на томе сектор принадлежит некоторому файлу, даже метаданные — информация, описывающая саму ФС. NTFS основана на атрибутах и обрабатывает все файлы как объекты с набором атрибутов, определенных как системой, так и пользователем. Каждый файл на томе с NTFS представлен записью в главной файловой таблице (MFT — Master File Table), аналоге FAT. Записи в MFT сортируются по алфавиту, что позволяет использовать двоичный поиск, существенно ускоряющий работу ФС. Для еще большей оптимизации диспетчером кэша используется алгоритм отложенной (lazy — ленивый) записи, когда данные не пишутся сразу на диск, а хранятся в памяти до тех пор, пока нагрузка на процессор не уменьшиться, а затем сбрасываются на диск фоновым процессом. Однако подобная практика чревата нехорошими последствиями в случае отказа питания. Журналирование не спасет пользовательских данных, хотя и обеспечит целостность структуры ФС. Вот почему любой уважающий себя администратор не ставит сервер без ИБП (Источник Бесперебойного Питания). В итоге, согласно авторитетным тестам, по быстродействию FAT выигрывает только на небольших томах с небольшим количеством файлов, в остальных случаях пальма лидерства остается за NTFS. Если вы хотите еще больше ускорить работу NTFS, воспользуйтесь следующим советом: отключите автоматическое обновление времени последнего доступа к файлу. Для этого в реестр по адресу HKLM\SYSTEM\CurrentControlSet\Control\FileSystem добавьте параметр NtfsDisableLastAccessUpdate типа REG_DWORD и установите его в 1. Существуют и другие способы оптимизации работы ФС, однако о них как-нибудь в другой раз. Ну, а сейчас я перечислю те функции, которые поддерживает наша героиня.

• Разреженные файлы. Это файлы, очень большие логически, но занимающие на диске только необходимый объем. Эта технология используется самой NT и СУБД (Системами Управления Базами Данных).

• Журнал изменений. Служит для регистрации всех изменений файлов на томе. Используется службой каталогов Active Directory и службой индексирования. Находится в папке System Volume Informa-tion в корне диска.

• Поддержка коротких имен. Это необходимо для совместимости с MS-DOS-программами. Каждый раз при создании файла NTFS делает дополнительную запись в MFT, содержащую короткий эквивалент имени. Эту опцию можно отключить, воспользовавшись ключом реестра Ntfs Disable8 dot3NameCreation в папке HKLM\SYSTEM\Current Control Set\Control\FileSystem, установив его в 1.

• Компрессия файлов и каталогов. NTFS обеспечивает динамическое, прозрачное для приложений сжатие файлов и каталогов на манер MS-DOS-утилит DriveSpace и Stack. Атрибут Сжатый можно установить как для всего тома, так и для отдельных файлов и каталогов. Сжатие возможно на разделах с кластером, не превышающим 4 Кб. Степень сжатия варьируется в зависимости от типа данных и максимальна для текстовых документов и файлов, созданных с помощью MS Office. Советую попробовать поэкспериментировать с утилитой COMPACT.

• Многопоточные файлы. Один и тот же файл может содержать несколько именованных потоков, содержащих разную информацию, причем размер файла высчитывается согласно содержимого главного, безымянного потока. Ради шутки можно создать файл, занимающий все место на диске, но обладающий нулевой длиной с точки зрения ПО. Писать в потоки можно с помощью перенаправления ввода-вывода: Echo Бла-бла-бла! > File.txt:First. Аналогично читаем: More < File.txt:First. Внимание! Данная функция поддерживается только в NTFS, и при копировании на тома с другой ФС информация в именованных потоках пропадет.

• Жесткие связи. Для одного и того же файла можно создать несколько имен внутри тома. При этом мы не увеличиваем количество файлов, а лишь делаем своеобразный ярлык. Файл остается на диске до тех пор, пока не удалят последнюю жесткую связь на него. Эта и 2 последующие технологии давно используются в UNIX-системах.

• Точки переопределения. Любой файл или каталог может быть точкой переопределения. Это способ представления имен системой ввода/вывода. Простейший пример: Диск D: монтируется в каталог C:\Disks\ D\. В итоге, зайдя в этот каталог, мы попадем на диск D:, хотя путь не изменится.

• Переходы NTFS. Позволяют спроецировать каталог-адресат в другой подкаталог. Т.е., зайдя в такой каталог, мы попадем в совсем другое место ФС. Чем-то напоминает предыдущий пункт, не правда ли? Доступны только на NTFS 5.0 и 5.1.

• Динамическое отслеживание ярлыков. Отслеживает перемещение файлов, на которые указывают ярлыки, соответственно изменяя ссылку на эти файлы в ярлыках. Работает только на локальных дисках с NTFS 5.0 и 5.1.

• Управление избирательным доступом. С помощью таблиц управления доступом (Access Control List — ACL) можно гибко разграничивать доступ к файлам и папкам. Можно работать как с отдельными пользователями, так и с группами, одновременно используя наследование прав доступа.

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

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

В дополнение ко всему вышесказанному: существующий том с FAT можно преобразовать в NTFS без потери данных с помощью команды CONVERT, однако эффективность такого решения не очень высокая из-за особенностей процесса преобразования. Вот, собственно, и все, что должен знать пользователь о файловых системах. Если нужна более подробная информация — ищите соответствующую литературу. Я же широко использовал в данной статье материалы книги Федора Зубанова "Microsoft Windows 2000. Планирование, развертывание, управление".

P.S.: Надеюсь, убедил использовать NTFS везде, где это возможно. При грамотной настройке и обслуживании NT + NTFS показывают чудеса производительности и устойчивости. Ну, а с кривыми руками и M16 не более чем дубина.
See you later!

Вдогонку
Хотелось бы дополнить предыдущую статью о файловых системах следующей полезной информацией.
Во-первых, имена файлов в NTFS хранятся в 2-байтовой кодировке Unicode, что автоматически означает возможность называть файлы на любом языке, хоть на китайском (лишь бы шрифт соответствующий был), и не нуждаться в переключении кодовой страницы для их (имен) правильного отображения.
Во-вторых, советую интересующимся поэкспериментировать с командой FSUTIL, которая позволяет управлять разреженными файлами, жесткими связями и т.д., и MOUNTVOL — управление точками переопределения (точки повторной обработки). Об NTFS мы, возможно, подробнее поговорим позднее.
Ну, а сейчас перейдем к другой важной особенности NT-систем — службам.

Служу Советскому Союзу!
В любой многозадачной ОС есть механизм для запуска процессов, не взаимодействующих с пользователем (не интерактивных), т.е. работающих в фоновом режиме.
В Unix-системах такие процессы называются демонами (от Daemon — дух, не путать с демоном ), а в NT они носят имя сервисов, Win32-сервисов или служб.
Последний перевод слова Service в данном случае наиболее правильный, так как под сервисами в терминологии Microsoft подразумеваются также драйверы устройств. Данный механизм удобен для решения таких задач, как реализация клиент-серверного приложения, где сервер оформлен в виде службы (например, web-сервер).
Службы состоят из трех частей:
• Сервисное приложение (Ser-vice Application). Это, собственно, и есть служба.
• Программа управления службой (Service Control Program, SCP). Данная программа позволяет запускать, останавливать, конфигурировать и осуществлять другие действия над службой.
• Диспетчер управления службами (Service Control Manager, SCM). Посылает команды SCP непосредственно службе. Своего рода координатор работы служб.
Ну, а теперь поговорим о каждом из этих компонентов подробнее.

Служба
Служба представляет собой обыкновенную Win32-программу, реализованную как GUI или консольное приложение.
Единственное отличие — наличие кода для обработки команд от SCM и возврата ему статусной информации. У большинства служб нет пользовательского интерфейса, поэтому они реализуются как консольные приложения, но есть и интерактивные GUI службы.
В состав любой NT включен большой набор стандартных служб. Многие из них по умолчанию отключены. Вы также можете добавить свои службы или даже запустить любую программу как службу с помощью таких утилит, как SvrAny.
Каждая служба может быть запущена как отдельный процесс (точнее, поток в отдельном процессе) либо как поток в общем процессе, разделяя его с другими службами. Второй вариант имеет как преимущества, так и существенные недостатки.
Наличие одного процесса вместо нескольких уменьшает нагрузку на систему (накладные расходы меньше), однако, если "навернется" одна служба, за ней "посыплются" и все остальные — общее адресное пространство, права доступа и ресурсы, да и "убить" можно только весь процесс целиком. Ряд стандартных служб работает именно по второй схеме, так что не удивляйтесь, обнаружив у себя в Диспетчере задач несколько процессов с именем svchost.exe — это стандартный разделяемый процесс для служб.
Несколько особо важных служб работают в процессе SCM (services.exe) и серверном процессе локальной аутентификации (lsass.exe).

SCM
Диспетчер управления службами исполняется в процессе services.exe и является консольным Win32-приложением.
Именно он отвечает за своевременный запуск, остановку и другие операции над службами, а также за взаимодействие SCP и служб.
Это краеугольный камень реализации служб в NT-системе.

SCP
Программа управления службами является Win32-приложением, способным посылать команды SCM. Она может поставляться вместе со службой, реализуя дополнительные возможности администрирования.
Также возможно использование стандартных SCP из комплекта ОС, таких, как GUI-оснастка Службы (Services) или консольная программа SC.
С консольной SCP побалуйтесь сами, я же рассмотрю некоторые особенности реализации служб на примере управления ими с помощью оснастки Службы.
Сначала надо ее запустить — например, из меню Пуск\Программы\Панель управления\Производительность и обслуживание\Администрирование\Службы (для русской XP). Вы увидите список служб, их состояние и другую информацию.
Приведем для примера конфигурацию службы Telnet (удаленная консоль).
Двойной щелчок левой кнопкой мышки по названию откроет окно свойств данной службы. Рассмотрим каждую закладку.


Общие
Закладка Общие содержит следующие сведения:
• Имя службы.
• Выводимое имя ("понятное" имя, необязательный параметр).
• Описание — комментарии по роду деятельности службы.
• Исполняемый файл.
• Тип запуска: Авто, Вручную, Отключено. При типе Авто служба запускается при загрузке машины; если стоит Вручную, то ее может запустить пользователь или программа; Отключено — запуск невозможен.
• Состояние. Отображает состояние службы. Ниже находятся кнопки для управления работой службы.
• Параметры запуска — параметры командной строки, передаваемые службе.

Вход в систему
На закладке Вход в систему отображаются 2 параметра:
• Вход в систему — учетная запись, с правами которой служба будет работать в системе. Это важный параметр, так как определяет ресурсы, к которым будет иметь доступ служба. Служба может работать от имени системы, причем соответствующая галочка разрешает взаимодействие с рабочим столом, или от имени любой другой учетной записи — нужно лишь указать пароль и подтверждение.
• Профили оборудования. Здесь разрешается или запрещается запуск службы для определенных профилей оборудования. Например, у вас есть ноутбук с док-станцией, причем последняя имеет сетевую карточку. Логично было бы создать 2 профиля: с и без док-станции. Соответственно все сетевые службы во втором случае не нужны, и их можно смело отключить для данного профиля, выиграв в производительности.

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

• Действия при сбое службы — действия, которые должен выполнить компьютер при первом, втором и последующих сбоях службы. Поле может иметь следующие значения: Не выполнять никаких действий, Перезапуск службы, Запуск программы, Перезагрузка компьютера. В зависимости от выбранных вариантов могут стать активными другие поля.
• Сброс счетчика ошибок — количество дней, после которых счетчик ошибок обнулится.
• Перезапуск службы — интервал в минутах, после которого служба перезапустится.
• Программа — имя программы, запускаемой после сбоя.
• Параметры командной строки — параметры, предаваемые программе, запускаемой после сбоя.
• Дописать в командную строку счетчик ошибок. Дает возможность запускаемой программе проанализировать, сколько раз служба сбоила.
• Параметры перезагрузки компьютера: время в минутах, через которое произойдет перезагрузка, и сообщение, которое будет отправлено другим компьютерам сети.

Зависимости
Ряд служб зависит от других служб, драйверов и групп служб.
Если не запустится служба — не запустятся и все зависимые от нее. Закладка Зависимости дает возможность проанализировать возможные конфликты на почве зависимости . Здесь мы увидим 2 поля:

• Служба зависит от следующих компонентов — список компонентов, от которых зависит служба. Если не загрузится один из них — служба не сможет запуститься.
• Следующие компоненты зависят от службы — список компонентов, которые не смогут работать, если служба не запустится.

Заключение
Думаю, данного материала на первых порах хватит. Настраивая службы, можно добиться заметного повышения быстродействия. Главное — не перестараться с отключением всего подряд: обращайте внимание на зависимости и не балуйтесь с учетными записями. Данный материал почерпнут из мозга автора, а также из книг Федора Зубанова "Microsoft Windows 2000. Планирование, развертывание, управление" и Д. Соломона и М. Руссиновича "Внутреннее устройство Microsoft Windows 2000".

Опровержение
Дальнейший текст содержит опровержение эпиграфа по отношению к реестру . Я понимаю, что многие пользователи знакомы с понятием реестра, тем не менее, сейчас мы поговорим именно о нем. Хотелось бы разложить по полочкам основные сведения о реестре. Интересующимся могу посоветовать ряд книг Ольги Кокоревой о реестре различных Windows, ну, а для изучения внутренней структуры оного (ау, программисты!) просьба прочитать соответствующий раздел не раз мною упомянутой книги Д. Соломона и М. Руссиновича "Внутреннее устройство Microsoft Windows 2000". Ну что ж, начнем!

Who is who?
На смену ini-файлам, имеющим ряд концептуальных ограничений, еще в Windows 3.1 было введено понятие реестра — регистрационной базы данных, хранящей различные настройки ОС и приложений. Изначально реестр был предназначен только для хранения сведений об объектах OLE (Object Linking and Embedding — связь и внедрение объектов) и сопоставлений приложений расширениям имен файлов, однако позже его структура и границы использования расширились. Реестры разных версий Windows имеют различия; это нужно помнить при импорте reg-файлов. В Windows 2000 и XP в архитектуру реестра были введены важные новшества, улучшающие функциональность данного компонента ОС. Реестр хранится в бинарном (двоичном) виде, поэтому для ручной работы с ним необходима специальная программа — редактор реестра. В XP это Regedit.exe, в других версиях NT ими являются Regedit.exe и Regedt32.exe, имеющий дополнительные возможности работы с реестром (Regedt32.exe есть и в XP, но на самом деле он всего лишь вызывает Regedit.exe). Есть и другие программы, в том числе и консольные (Reg.exe). Ручным модифицированием параметров реестра мы займемся чуть позже, а сейчас рассмотрим основные группы сведений, хранящихся в этой базе данных.

• Программы установки. Любая грамотно написанная программа под Windows должна иметь свой инсталлятор-установщик. Это может быть встроенный в ОС Microsoft Installer либо любой другой. В любом случае инсталлятор использует реестр для хранения своих настроек, позволяя правильно устанавливать и удалять приложения, не трогая совместно используемые файлы.

• Распознаватель. При каждом запуске компьютера программа NTDETECT.COM и ядро Windows распознает оборудование и сохраняет эту информацию в реестре.

• Ядро ОС. Хранит много сведений в реестре о своей конфигурации, в том числе и данные о порядке загрузки драйверов устройств.

• Диспетчер PnP (Plug and Play). Абсолютно необходимая вещь для большинства пользователей, которая избавляет их от мук по установке нового оборудования (не всегда, правда ). Неудивительно, что он хранит свою информацию в реестре.

• Драйверы устройств. Хранят здесь свои параметры.

• Административные средства. Например, такие, как Панель управления, MMC (Micro-soft Management Console) и др.

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

• Аппаратные профили. Позволяют создавать несколько конфигураций с различным оборудованием (помните мой пример про ноутбук с док-станцией в прошлой статье?).

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

Вот мы и разобрались с предназначением реестра. Теперь обратим свое внимание на логическую структуру реестра. Для лучшего понимания материала рекомендуется запустить Regedit.exe, только ничего пока не трогайте .

Структура реестра
Первая аналогия, которая приходит в голову при взгляде на реестр в Regedit.exe, — как похоже на файловую систему! И точно, налицо древовидная структура. Папкам здесь соответствуют ключи (keys) или разделы (ветви), а файлам — параметры (values). Разделы могут содержать как вложенные разделы (sub keys), так и параметры. На верхнем уровне этой иерархии находятся корневые разделы (root keys). Они перечислены в таблице 1.

Таблица 1. Корневые разделы

Тип данных Описание
REG_BINARY Двоичные данные. Большинство сведений об аппаратных компонентах хранится в виде двоичных данных и выводится в редакторе реестра в шестнадцатеричном формате
REG_DWORD Данные, представленные целым числом (4 байта). Многие параметры служб и драйверов устройств имеют этот тип и отображаются в двоичном, шестнадцатеричном или десятичном форматах
REG_EXPAND_SZ Строка Unicode переменной длины. Этот тип данных включает переменные, обрабатываемые программой или службой
REG_MULTI_SZ Многострочный текст Unicode. Этот тип, как правило, имеют списки и другие записи в формате, удобном для чтения. Записи разделяются пробелами, запятыми или другими символами
REG_SZ Текстовая Unicode строка фиксированной длины
REG_DWORD_LITTLE_ENDIAN 32-разрядное число в формате “остроконечников” — младший байт хранится первым в памяти. Эквивалент REG_DWORD
REG_DWORD_BIG_ENDIAN 32-разрядное число в формате “тупоконечников” — старший байт хранится первым в памяти
REG_LINK Символическая ссылка Unicode. Только для внутреннего использования (некоторые корневые разделы являются такой ссылкой на другие подразделы)
REG_NONE Параметр не имеет определенного типа данных
REG_QWORD 64-разрядное число
REG_QWORD_LITTLE_ENDIAN 64-разрядное число в формате “остроконечников”. Эквивалент REG_QWORD
REG_RESOURCE_LIST Список аппаратных ресурсов. Используется только в разделе HKLM\HARDWARE
REG_FULL_RESOURCE_DESCRIPTOR Дескриптор (описатель) аппаратного ресурса. Применяется только в HKLM\HARDWARE.
REG_RESOURCE_REQUIREMENTS_LIST Список необходимых аппаратных ресурсов. Используется только в HKLM\HARDWARE.

Типы данных
Все параметры реестра имеют фиксированный тип. В таблице 2 я приведу полный список используемых типов. Не все из них используются в разных версиях NT — REG_QWORD явно предназначен для 64-битной версии XP. Следует учесть, что ряд типов используется только системой в некоторых разделах, и создать свой параметр такого типа с помощью редактора реестра не получится.

Таблица 2. Типы параметров

Тип данных
Описание
REG_BINARY
Двоичные данные. Большинство сведений об аппаратных компонентах хранится в виде двоичных данных и выводится в редакторе реестра в шестнадцатеричном формате
REG_DWORD
Данные, представленные целым числом (4 байта). Многие параметры служб и драйверов устройств имеют этот тип и отображаются в двоичном, шестнадцатеричном или десятичном форматах
REG_EXPAND_SZ
Строка Unicode переменной длины. Этот тип данных включает переменные, обрабатываемые программой или службой
REG_MULTI_SZ
Многострочный текст Unicode. Этот тип, как правило, имеют списки и другие записи в формате, удобном для чтения. Записи разделяются пробелами, запятыми или другими символами
REG_SZ
Текстовая Unicode строка фиксированной длины
REG_DWORD_LITTLE_ENDIAN
32-разрядное число в формате “остроконечников” — младший байт хранится первым в памяти. Эквивалент REG_DWORD
REG_DWORD_BIG_ENDIAN
32-разрядное число в формате “тупоконечников” — старший байт хранится первым в памяти
REG_LINK
Символическая ссылка Unicode. Только для внутреннего использования (некоторые корневые разделы являются такой ссылкой на другие подразделы)
REG_NONE
Параметр не имеет определенного типа данных
REG_QWORD
64-разрядное число
REG_QWORD_LITTLE_ENDIAN
64-разрядное число в формате “остроконечников”. Эквивалент REG_QWORD
REG_RESOURCE_LIST
Список аппаратных ресурсов. Используется только в разделе HKLM\HARDWARE
REG_FULL_RESOURCE_DESCRIPTOR
Дескриптор (описатель) аппаратного ресурса. Применяется только в HKLM\HARDWARE.
REG_RESOURCE_REQUIREMENTS_LIST
Список необходимых аппаратных ресурсов. Используется только в HKLM\HARDWARE.

Хранение реестра
Элементы реестра хранятся в виде атомарной структуры. Реестр разделяется на составные части, называемые ульями (hives), или кустами. Ульи хранятся на диске в виде файлов. Некоторые ульи, такие, как HKLM\HARDWARE, не сохраняются в файлах, а создаются при каждой загрузке, то есть являются изменяемыми (vola-tile). При запуске системы реестр собирается из ульев в единую древовидную структуру с корневыми разделами. Перечислим ульи реестра и их местоположение на диске (для NT старше версии 4.0) в таблице 3.

Таблица 3. Ульи реестра

Улей
Расположение
HKLM\SYSTEM
%SystemRoot%\system32\config\system
HKLM\SAM
%SystemRoot%\system32\config\SAM
HKLM\SECURITY
%SystemRoot%\system32\config\SECURITY
HKLM\SOFTWARE
%SystemRoot%\system32\config\software
HKLM\HARDWARE
Изменяемый улей
HKLM\SYSTEM\Clone
Изменяемый улей
HKU\<SID_пользователя>
%USERPROFILE%\ntuser.dat
HKU\<SID_пользователя>_Classes
%USERPROFILE%\Local Settings\Application Data\Microsoft\Windows\UsrClass.dat
HKU\.DEFAULT
%SystemRoot%\system32\config\default

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

• ALT — резервная копия улья HKLM\SYSTEM (отсутствует в XP).
• LOG — журнал транзакций, в котором регистрируются все изменения реестра.
• SAV — копии ульев в том виде, в котором они были после завершения текстовой фазы установки.

Дополнительные сведения
Реестр является настоящей базой данных, поэтому в нем используется технология восстановления, похожая на оную в NTFS. Уже упомянутые LOG-файлы содержат журнал транзакций, который хранит все изменения. Благодаря этому реализуется атомарность реестра — то есть в данный момент времени в реестре могут быть либо старые значения, либо новые, даже после сбоя. Как видим, в отличие от NTFS, здесь обеспечивается сохранность не только структуры реестра, но и данных. К тому же, реестр поддерживает такие фишки NTFS, как управление избирательным доступом и аудит событий — система безопасности пронизывает всю NT снизу доверху. Да, эти функции доступны только из Regedt32.exe или Regedit.exe для XP. А еще весь реестр или его отдельные части можно экспортировать в текстовые reg-файлы (Unicode для Windows 2000 и старше), редактировать их в блокноте, а затем экспортировать обратно. Во многих редакторах реестра можно подключать любые доступные ульи реестра, в том числе и на удаленных машинах (при соответствующих полномочиях). Есть возможность делать резервные копии с помощью программы NTBackup. И многое другое. Ну, а на сегодня наш маленький ликбез окончен.

А что это такое?
Сегодня речь пойдет о консоли, а если точнее, о командном интерпретаторе (командной строке), так как под словами "консоль" (console) и "оболочка" (shell) понимают программу-посредника между пользователем и ОС. Термин же "командный интерпретатор" подчеркивает режим, в котором происходит взаимодействие оператора с машиной — командный текстовый. Это один из старейших способов общения с ЭВМ. Практически все ОС, даже самые современные, содержат в своем составе программу, позволяющую управлять системой с помощью текстовых команд, набранных с клавиатуры. Это не архаика, как можно подумать сразу: наличие графического объектно-ориентированного интерфейса не может сделать консоль (здесь и далее я понимаю под термином "консоль" командный интерпретатор) ненужной или бесполезной. Многие вещи реализуемы быстрее с помощью консоли. Конечно, всегда можно найти или написать программу, позволяющую обеспечить нужную функциональность, но стоит ли так делать, если в самой ОС есть все необходимое? Одно из правил грамотного администратора гласит: используй стандартные средства. Или хотя бы умей ими пользоваться. Значит, будем изучать, что же полезного может нам предложить командный режим работы с компьютером.

Приступим-с!
Любой пользователь, имевший дело с ОС класса DOS (Disk Operating System — Дисковая Операционная Система), прекрасно знает, что такое текстовый режим и командная строка. Возможно, он также знает, что стандартный command. com можно заменить чем-нибудь другим, например, bash'ем (привет UNIX'оидам!), правда, с некоторыми ограничениями: DOS, в отличие от разных UNIX'ов, не является многозадачной ОС, к тому же, работает в реальном режиме процессора, а не защищенном. Делается это элементарной командой shell=[[диск:] путь] имя_файла [параметры] в файле config.sys. В NT же изначально используется графический режим, а текстовый мы можем увидеть только в начале загрузки системы, при крахе (BSOD) и включив полноэкранный режим в каком-либо консольном приложении с помощью комбинации ALT+Enter (DOS или Win32, неважно). Однако графический режим работы видеоадаптера (звучит, конечно, глупо, однако надо понимать, что видеокарта и соответственно дисплей может работать как в текстовом, так и в графическом режимах, хотя в обоих случаях в монитор будет поступать аналоговый видеосигнал) предполагает только способ отображения информации. Общаться с системой (не с программой!) мы по-прежнему можем с помощью оболочки, которую сами выбираем. Это может быть графический объектный explorer.exe, а может — текстовый интерпретатор cmd.exe или что-нибудь еще (Диспетчер задач, например). В любом случае эти оболочки будут делиться на текстовые (командные) и графические (кнопочки жать ). Поясню, что это значит. Command.com — текстовый командный интерпретатор, Norton Comman-der уже им не является, хотя и предназначен для текстового режима — при работе с ним мы не вводим текстовые команды с клавиатуры (а те, что вводим, обрабатываются command.com'ом), а имеем дело с кнопками из псевдографики. Таким образом, режим работы дисплея и тип оболочки не имеют ничего общего. Подобьем наши размышления: дисплей может отображать информацию как в текстовом режиме, так и в графическом, независимо от этого мы можем давать команды системе с помощью командного интерпретатора (в широком смысле этого слова) либо набирая с клавиатуры последовательность символов, составляющих команду, либо нажимая с помощью мыши или клавиатуры на те или иные графические объекты (кнопки, пусть и из псевдографики). Надеюсь, читатель разобрался во всей это мути, так как дальше мы наконец-то начнем разговор о нашем текстовом командном интерпретаторе, которым является...

cmd.exe
Да, именно это и есть стандартная консоль (помните наше соглашение?) для NT. Запустить ее можно, нажав Win+R и набрав cmd. Есть и command.com, но он предназначен для совместимости с приложениями DOS и работает через NTVDM. Консоль можно поставить в качестве оболочки вместо Проводника (explorer'а), что и делает система в режиме загрузки "Безопасный режим с поддержкой командной строки" (оболочку можно заменить, указав в boot.ini ключ /SAFEBOOT ALTERNATESHELL= <имя_файла> или изменив соответствующее значение в реестре). Первое, что я рекомендую сделать, это изучить справку по командной строке, поставляемую с системой. В Центре поддержки XP можно получить не только сведения по настройке консоли, но и информацию по имеющимся командам (а их там о-го-го) и программам (DOS'овским в том числе). Свои настройки командный процессор хранит в реестре, они индивидуальны для каждого пользователя, и основная их часть находится по адресу: HKCU\Console и HKCU\Software\Microsoft\Com-mand Processor. Здесь следует сделать небольшое отступление. Все, что мы вводим с клавиатуры в консоль, является командой, однако есть внутренние команды, которые встроены в сам интерпретатор, а есть внешние консольные программы, вызываемые интерпретатором по нашей просьбе. Именно поэтому, неправильно введя команду, мы получим сообщение «"" не является внутренней или внешней командой, исполняемой программой или пакетным файлом». Консоль просто не знает такой команды или не нашла исполняемого файла (.com, .exe, .bat, .cmd) с таким именем. Заметьте: к исполняемым файлам относятся также пакетные файлы (.bat, .cmd), содержащие набор команд, которые выполнятся консолью при их запуске. Получить справку по часто используемым командам можно, набрав в консоли help. Для любой (ну, почти любой — зависит от разработчика) команды также есть ключ /?, который выводит помощь по команде и ее параметрам. Пользуйтесь этим! И еще. Если в имени файла есть некоторые спецсимволы, вроде пробела, то имя нужно заключать в двойные кавычки.

Конвейер и другие
Радость изучения команд я оставляю читателям. Мы же сейчас рассмотрим некоторые концептуальные вещи. Итак, по порядку.

• Перенаправление ввода-вывода. По умолчанию входная информация берется из буфера клавиатуры, а результат выводится на экран. Однако это можно изменить — достаточно поставить символы < или > и имя устройства (con, prn, lpt и т.д. — все как в DOS'е) или имя файла. Допустим, нам надо сохранить результат команды dir в файл 1.txt. Мы наберем dir>1.txt. А команда type 1.txt>prn распечатает этот файл. Некоторые стандартные устройства: con — консоль, клавиатура + монитор; prn — принтер; nul — пустое устройство, "черная дыра"; lpt — устройство на параллельном порту; com1 — устройство на первом последовательном порту, как правило, модем.

• Конвейер. Иногда требуется, чтобы результат одной команды был входной информацией другой. В таких случаях используется технология конвейера (pipe — труба). Ее особенность в том, что в цепочки можно выстраивать несколько программ, причем в многозадачной ОС они (программы) могут выполняться одновременно. Классический пример использования этой технологии — программа more, позволяющая выводить на экран информацию порциями. Например, dir | more.

• Переменные. Многие данные удобно задавать с помощью переменных — системных, пользовательских и программных (их можно посмотреть командой set). Например, путь к папке temp задается переменными temp и tmp. Теперь этот путь можно использовать, написав %tmp% — система автоматически подставит нужное значение. Кстати, переменная path задает папки, в которых ищется исполняемый файл, если его имя было задано без указания пути.

• Программирование. Да! В консоли можно программировать, правда, довольно ограниченно (до уровня UNIX'овых консолей cmd не дотягивает, но, учитывая наличие WSH (Windows Script Host), не очень-то и хотелось ). Например, есть операторы условия, цикла и др. Таким образом, можно сохранять в пакетных файлах небольшие, но полезные программки.

Занавес
Это далеко не все, что я хотел вам рассказать о консоли. В будущем я вернусь к этой теме и разберу ее подробнее, ну, а мы пока переходим к следующей теме — о ней вы прочитаете в очередной статье.
Приятного времяпрепровождения! (Во загнул )

Чего, мужики, шумим?
Давненько мы не встречались в нашем клубе. Я решил исправить это нелепое недоразумение и поговорить с вами о таком компоненте ОС Windows 2000/XP/Server 2003, как Microsoft Management Console (MMC, консоль управления Microsoft). Что же это такое? Для начала вернемся в те далекие (или не очень) времена, когда на рынке появилась NT 4.0. У администраторов этой системы и ее предшественников был целый набор административных инструментов, часть из которых была вынесена в панель управления, а другая часть находилась в меню Администрирование. Каждый инструмент представлял собой отдельное приложение пусть и с удобным, но своим интерфейсом. К тому же, приложение могло выполнять сразу несколько функций. По этим причинам начинающим администраторам (а данными утилитами пользуются, в основном, администраторы) было трудно управлять системой, часто они просто терялись в многообразии функций отдельного приложения, в то же время так и не находя нужного им параметра.

Еще один недостаток имеющихся средств управления — ограниченная возможность удаленного администрирования. Администратор, по сути дела, был привязан к машине на базе NT или Windows 95 (после выхода соответствующего пакета). Средства администрирования по протоколу HTTP лишь смягчили проблему, оставив ее открытой. Ну и напоследок следует описать проблему, характерную для больших и очень больших организаций. Представьте себе корпоративную сеть с несколькими филиалами и одним головным подразделением. Администраторы головного подразделения не хотят предоставлять всех полномочий и всех инструментов управления администраторам филиалов (это вполне логично). Что делать? С NT 4.0 и старше данный вопрос решается исключительно организационными мерами: разъяснениями, что можно делать, а что нельзя, и постоянным контролем. Для исправления сложившейся ситуации компания Microsoft решила создать новый универсальный продукт, удовлетворяющий следующим требованиям:

• Должна быть единая универсальная среда, в которой можно выполнять все задачи по управлению системой, используя однотипные приемы и стандартный интерфейс пользователя. Среда должна позволять выполнение нескольких задач одновременно.
• Набор задач должен быть настраиваемым и расширяться/сокращаться по желанию администратора.
• Доступ к инструментам должен выполняться как локально, так и удаленно с самых разнообразных клиентов.
• Инструменты должны обладать возможностью передачи их от одного администратора другому с минимальными затратами.
• API среды должен позволять создавать сторонним фирмам аналогичный инструментарий для своих приложений.

What is it?
MMC является общей расширяемой средой для управляющих приложений, удовлетворяющей вышеперечисленным условиям. Реализована она в виде обычного MDI-приложения (многооконного), широко использующего интернет-технологии. Сама по себе MMC не представляет управляющих функций — это лишь среда для оснасток (snap-in). Оснастка — управляющий компонент, интегрирующийся в MMC. Одна оснастка представляет единицу управления, а их набор — управляющий инструмент. Оснастка может как посылать команды приложению, так и принимать их, а также выступать в качестве элементов интеграции различных приложений. Одновременно в системе можно использовать и MMC, и управляющие приложения других фирм, задействовав их отдельно либо создав ярлыки на них в MMC. Вырисовывается такая схема (см. рис. 1)


Архитектура MMC
Обратите свое внимание на рис. 2. Здесь вы увидите модель консоли управления.

Диспетчер оснасток (Snap-in manager) — основа консоли управления — позволяет добавлять, удалять и модифицировать оснастки, а также разрешает указать, как будет работать данная оснастка: автономно или с дополнительными расширениями. Значения параметров хранятся в файлах с расширением .msc. Из нескольких загруженных оснасток администратор может создать инструмент управления. Этот инструмент сохраняется в MSC-файле для повторного использования и называется документом.
"Монитор маршрутизации" и "Журнал событий" на рисунке являются подгруженными оснастками, с которыми взаимодействует пользователь.
Объединяясь, оснастки создают пространство имен — упорядоченный набор узлов в виде древовидной структуры. Если дерево большое, можно воспользоваться страницей Избранное (интерфейс MMC в целом напоминает Проводник). Для каждого узла можно открывать дочерние окна.


Оснастки
Оснастка (snap-in) — это минимальная единица управления, реализованная в виде OLE Inproc-сервера, исполняемого в контексте MMC. Как уже говорилось, набор оснасток представляет собой инструмент управления. Оснастка способна вызывать другие поддерживаемые в системе элементы управления и DLL. Такая гибкость позволяет создавать инструменты по желанию администратора, заточенные под конкретные задачи. Оснастки бывают самостоятельными и оснастками-расширениями. Самостоятельные оснастки полностью самодостаточны, а оснастки-расширения обеспечивают нужной функциональностью оснастку-родителя. Многие оснастки обладают двойной функциональностью, являясь одновременно самостоятельными и расширяющими, как, например, оснастка Ведение журнала, расширяющая оснастку Управление компьютером. Оснасткам доступны следующие механизмы расширения консоли управления:

• Перечисление имен.
• Расширение контекстного меню.
• Расширение меню Новый (New).
• Расширение меню Задачи (Tasks).
• Расширение панели инструментов и кнопок на ней.
• Расширение страницы свойств.
• Расширение меню Вид (View).
• Организация последовательностей в программах-мастерах.
• Расширение справочной системы.
Думаю, с этим все ясно.

Работа с MMC
Консоль работает в двух основных режимах: авторском (author) и пользовательском (user). Пользовательский режим делится на 3 подрежима:

• полного доступа;
• ограниченного доступа с несколькими окнами;
• ограниченного доступа с одним окном.

Полное управление над инструментом и консолью в целом вы получаете только в режиме автора, в любом пользовательском вы можете лишь использовать его, причем с ограничениями. Для перехода в авторский режим следует загрузить консоль командой mmc, а затем добавить нужный инструмент. Также можно выделить нужный mmc-файл и в контекстном меню по правому щелчку мыши выбрать команду Автор (Author) либо запустить данный файл с ключом /a.

Добавить или удалить оснастку можно в авторском режиме из меню Консоль, Добавить или удалить оснастку (Console, Add/remove Snap-in). Кстати, на закладке Расширения (Extensions) можно отключить ненужные в данный момент оснастки-расширения для добавляемой оснастки.
Для изменения свойств созданного вами инструмента, сохраненного в файле .msc, служит пункт Параметры (Options) меню Консоль (Console), где можно указать необходимый режим доступа.

У MMC есть одно замечательное свойство — панели заданий (taskpads). Это окно с одной или несколькими вкладками, на которых может располагаться список параметров и произвольные задания в виде значка. Заданием может быть команда из меню текущей оснастки, ссылка на web-страницу или любая команда, вызывающая приложение или сценарий. Для создания такой панели необходимо щелкнуть правой кнопкой мыши на нужной вам ветке консоли и выбрать команду Новый вид панели задач (New Taskpad View). Запустится программа-мастер, которая сначала настроит вид этой панели, а потом запустит другой мастер, добавляющий задания на созданную панель. Надо признать, это очень удобная вещь.

Внешний вид оснастки позволяет настроить команда Настроить (Customize) меню Вид (View).

Управление доступом к оснасткам
В дополнение к вышесказанному отмечу возможность управления доступом к оснасткам с помощью групповой политики, которая позволяет разрешить/запретить:

• доступ ко всем оснасткам в авторском режиме;
• использование тех или иных оснасток.

Итак, открываем оснастку Групповая политика (Group Policy) для локального компьютера или любого другого. В ветви Конфигурация пользователя (User Configuration) находим ветвь Консоль управления Microsoft (Microsoft Management Console), где указываем нужные параметры. В списке запрещенных или разрешенных оснасток следует запретить оснастки, использование которых нежелательно. Если вы используете XP или Server 2003, то слева от параметров будете видеть исчерпывающие подсказки, посмотреть на которые можно также на закладке Объяснение.

В заключение
Как видите, MMC — серьезная среда управления с множеством полезных свойств. К сожалению, не многие ею пользуются, так как не догадываются о ее существовании. С одной стороны, MMC — это инструмент администратора, предназначенный для удаленного и локального администрирования машин в сети, с другой же — данная возможность присутствует на всех версиях NT старше 4.0, так почему бы ею не воспользоваться. К тому же, это стандартное и удобное средство, позволяющее вытворять с вашей машиной множество вещей, недоступных другими способами. Так что вперед экспериментировать (только осторожно, я вас предупредил ). Да, в данной статье широко использовались материалы из книги Федора Зубанова "Microsoft Windows 2000. Планирование, развертывание, управление".
До скорой встречи!

Продолжим тему нетрадиционного использования средств администрирования NT-систем;). На этот раз поговорим о такой концептуальной для домена Active Directory вещи, как групповая политика (Group policy). Не пугайтесь слова “домен” — о нем речь идти не будет, мы рассмотрим применение групповой политики только на локальной машине.

Сначала, как всегда, немного теории.

Для эффективного управления пользователями и компьютерами еще в Windows NT 4.0 существовала системная политика, хранящая свои параметры в реестре (она по умолчанию поддерживается и более поздними версиями ОС). С помощью редактора системной политики (System Policy Editor) мы могли изменять заданные установки, тем самым конфигурируя рабочую среду пользователей. Однако данный механизм был весьма ограничен — подробности опустим. С появлением на рынке ОС Windows 2000 и службы каталогов Active Directory ситуация изменилась в лучшую сторону. Теперь мы имеем в своем распоряжении гибкое средство по определению параметров для пользователей и компьютеров — групповые правила (политику). Данный механизм разработан в первую очередь для применения в домене, где показывает всю свою мощь, однако наша статья рассчитана на домашнего пользователя, не обремененного обязанностью администрирования сети компьютеров, объединенных в домен, поэтому рассмотрим только применение групповой политики на одном локальном компьютере.

К слову, даже если у вас есть домашняя сеть, т.е. рабочая группа, а не домен, то с помощью групповых правил вы сможете управлять только своей машиной либо удаленной при соответствующих правах, но не в коем разе не всей сетью. Да зачем это нам нужно? Скажем так, у вас в ОС зарегистрировано несколько пользователей (для NT это закономерность) и вам, как местному администратору, хотелось бы немножко “подправить” настройки программ, в том числе и рабочего стола Windows (отключить всем, скажем, Панель управления от греха подальше), изменить параметры безопасности системы по умолчанию, причем так, чтобы обратно все смогли вернуть только вы. С помощью групповой политики все это делается в один присест. Так что приступим к изучению предмета.

Подробности

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

поведение ОС;
параметры рабочего стола;
параметры приложений;
параметры безопасности;
параметры назначенных и опубликованных приложений (только для домена);
сценарии регистрации пользователя в системе и выхода из нее;
параметры перенаправления папок (только для домена).
Данные правила применяются при входе пользователя в систему (при регистрации) и во время периодических циклов обновления (с контроллеров домена, в случае наличия самого домена).

Для каждого отдельного компьютера имеется набор следующих параметров:

поведение ОС;
параметры рабочего стола;
параметры приложений;
параметры безопасности;
параметры приложений, назначенных для компьютера (только для домена);
сценарии запуска и выключения компьютера.
Эти правила применяются при инициализации ОС, т.е. загрузке, и во время периодических циклов обновления.

Правила групповой политики хранятся в объектах групповой политики, а не в реестре, что было свойственно для системной политики NT 4.0. Объекты бывают двух типов: локальные и нелокальные. Первые хранятся на каждой клиентской машине, вторые — на контроллерах доменов и действуют на сайт, домен, подразделение. Нелокальные правила в случае конфликта перекрывают локальные, иначе просто добавляют свои параметры. Мы рассмотрим только локальный объект. Физически он хранится в папке %System Root%\system32\GroupPolicy. Данная папка имеет следующую структуру (для XP):

Adm — содержит административные шаблоны (.adm);
Machine — данные, специфичные для компьютера;
Scripts — сценарии для компьютера;
Shutdown — сценарии выключения машины;
Startup — сценарии запуска машины;
Registry.pol — файл, содержащий изменения, которые будут внесены в ветку HKEY_ LOCAL_MACHINE реестра;
User — данные, специфичные для пользователя;
Scripts — сценарии для пользователя;
Logoff — сценарии выхода из системы;
Logon — сценарии регистрации в системе;
Registry.pol — файл, содержащий изменения, которые будут внесены в ветку HKEY_ CURRENT_USER реестра;
gpt.ini — некоторые настройки групповой политики и номер версии.

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

Запуск компьютера и сети. Запуск поддержки удаленного вызова процедур (RPC).
Применение политики для компьютера, пользовательский интерфейс не отображается.
Запускаются сценарии автозагрузки. Это происходит по умолчанию скрыто и синхронизировано; каждый сценарий должен быть завершен или прерван до запуска следующего. Таймаут по умолчанию 600 секунд.
Для входа в систему пользователь нажал клавиши CTRL-ALT-DEL (по умолчанию для Windows 2000).
После проверки пользователя (аутентификации) загружается профиль пользователя.
Применяется пользовательская политика, пользовательский интерфейс не отображается.
Запускаются сценарии входа. По умолчанию они работают скрытно и асинхронно, параллельно с запуском Проводника.
Пользовательский интерфейс операционной системы назначается групповой политикой.
Применение

Для начала запустим оснастку групповой политики (как видите, большинство средств администрирования работает именно через MMC). Сделать это можно так: нажать Win+R и ввести gpedit.msc. При этом редактор запустится для правки локального объекта групповых правил данного компьютера, если же его запускать из консоли MMC путем добавления оснастки, то можно указать конкретный компьютер в сети. Ну, а теперь рассмотрим, что реально нам позволяют сделать групповые правила через данную оснастку. Политика делится на конфигурацию пользователя и компьютера, как и было ранее сказано (для сокращения объема статьи я буду приводить только русские названия элементов интерфейса; те, кто пользуется английским вариантом ОС, думаю, без труда их переведут на English). В свою очередь обе группы предоставляют нам следующие основные возможности (для домена их будет побольше):

Сценарии — позволяют автоматизировать процесс включения/выключения компьютера, а также входа/выхода пользователя из системы. Их использование целесообразно для компьютера, входящего в состав домена.
Параметры безопасности — определяют параметры безопасности локальной системы. Данная тема очень обширна, поэтому мы поговорим о ней всерьез в другой раз.
Административные шаблоны — содержат параметры ОС и ее компонентов, хранимые в реестре.
Замечу, что воздействие групповой политики на компьютер реализуется с помощью вспомогательных компонентов, расширений на клиентской стороне, представляющих собой обычные DLL.

Наибольший интерес для нас представляют административные шаблоны. Итак, административные шаблоны — это файлы с расширением .adm, в которых в текстовом виде записаны параметры, модифицирующие реестр компьютера (ветку HKLM для параметров компьютера и HKCU — для пользователя). По умолчанию, к административным шаблонам относятся (перечислим только основные):

Компоненты Windows — содержат сведения о системных приложениях Windows, таких как Internet Explorer, Microsoft Management Console etc.
Система — позволяет изменять системные правила, например, параметры регистрации пользователя, групповой политики, защиты файлов
и т.д.
Сеть — как можно догадаться, содержит настройки сети.
Принтеры — параметры подключенных к системе локальных и удаленных принтеров.
Панель задач и меню Пуск — позволяет управлять свойствами и содержимым данных элементов интерфейса.
Рабочий стол — управляет свойствами рабочего стола, а также параметрами Active Desktop.
Панель управления — настраивает количество элементов в Панели управления и возможности по их управлению.
Довольно богатые возможности, не правда ли? Так давайте ими воспользуемся! Попробуем, например, отключить доступ к дискам из Проводника. Находим ветвь Конфигурация пользователя\Административные шаблоны\ Компоненты Windows\Проводник, а в ней — ключ Запретить доступ к дискам через “Мой компьютер”, и “кликаем” на него 2 раза.
Тут нужны пояснения. Окно изменения свойств имеет две закладки: Параметр и Объяснение.

В первой производится непосредственное редактирование свойства, а вторая служит справочной системой по данному параметру.

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

Ко всему прочему, свойство может иметь несколько дополнительных параметров, указанных ниже (у нас такой случай). В XP появилась строка “Поддерживается”, указывающая на версию ОС, для которой доступно редактирование данной опции.

После повторного входа в систему (нужно, чтобы политика пришла в силу) мы обнаруживаем отсутствие доступа к указанным дискам из Проводника, что и требовалось доказать.

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

Теперь поговорим о создании административных шаблонов. В комплекте с ОС идет ряд шаблонов, таких как System.adm, Inetres.adm и др., предназначенных для базового конфигурирования системы. Вполне возможно, что вам захочется дополнить возможности данных шаблонов способностью настраивать другие приложения (если, конечно, они хранят свои настройки в реестре). Редактировать уже имеющиеся шаблоны не рекомендуется, поэтому лучше создать новый шаблон, а потом добавить его к уже имеющимся. Это можно сделать, щелкнув правой кнопкой на ветке Административные шаблоны в оснастке Групповая политика и выбрав пункт Добавление и удаление шаблонов. После проверки синтаксиса новый шаблон будет загружен в систему.

Все шаблоны лежат в паке %SystemRoot%\inf. Они представляют собой обыкновенные текстовые файлы в формате UNICODE (точнее, двухбайтовый UNICODE — UTF16), поэтому редактировать и создавать новые шаблоны можно в Блокноте. Описание формата шаблона можно найти в справочной системе Windows. Следует отметить, что все параметры групповой политики для приложений (если вы их разработчик) нужно хранить в следующих ветках реестра: HKLM\SOFTWARE\Policies; HKCU\Software\Policies; (HKCU или HKLM)\Software\Microsoft\ Windows\CurrentVersion\Policies, как делает система. Дело в том, что только для этих веток при отключении параметра он удаляется из реестра.

На этом стоит пока остановиться. Экспериментируйте, но только обдуманно и осторожно.

Кхе-кхе... Начнем лекцию

Безопасность операционной системы основана на правилах, регулирующих разные аспекты ее работы. Вместе эти правила составляют единую политику безопасности. В Windows 2000 и более поздних NT-образных ОС политика безопасности представляет собой часть групповой политики (о чем упоминалось в предыдущей моей статье). В свою очередь, она (политика безопасности) состоит из набора правил, объединенных в следующие группы (вся статья основана на примере Windows XP Professional):

Политики (правила, эти термины тождественны) учетных записей. Регулируют работу с паролями, условия блокировок и политику Kerberos в доменах.
Локальные политики. Включают правила аудита событий, назначения привилегий пользователям и группам и некоторые возможности защиты.
Правила журнала регистрации. Регулируют использование журналов регистрации событий: System (Система), Security (Безопасность), Application (Приложение).
Правила групп с ограниченным членством. Устанавливают, кто может быть членом таких групп и в какие группы могут входить группы с ограниченным членством.
Правила системных служб. Определяют работу служб (сервисов) системы.
Правила реестра. Разграничивают доступ к ветвям реестра, определяют параметры аудита и владельца конкретного элемента реестра.
Правила файловой системы. Ограничивают доступ к объектам файловой системы, определяют владельца и параметры ведения аудита. Используется только для томов с NTFS.
Политики открытого ключа. Позволяют настроить, в частности, правила использования файловой системы с шифрованием (EFS, Encrypted File System). Эти политики и все последующие являются дополнительными, они не используются в шаблонах безопасности и не анализируются и не настраиваются оснасткой Анализ и настройка безопасности. О них мы говорить не будем.
Политики ограниченного использования программ. Разрешают/запрещают запуск программ пользователям. Что есть “программа”, определяется по указанному расширению.
Политики безопасности IP. Определяют настройки фильтров IP, а также использование шифрования пакетов (IPSec).
Так выглядит система безопасности NT-систем в общих чертах. Далее мы рассмотрим ее подробнее. Как и в предыдущей статье, речь будет вестись о локальной системе, не обремененной участием в домене, если не указано обратное. Для лучшего усвоения прочтенного текста желательно открыть оснастку Локальная политика безопасности из меню Администрирование кнопки Пуск. Данная оснастка предоставляет доступ к редактированию правил из части описанных групп правил, так как наш гипотетический компьютер не входит в домен. Параметры из остальных групп модифицируются другими способами, например, для объектов файловой системы используется закладка Безопасность (редактор списка контроля доступа — ACL Editor) свойств объекта (что для локального компьютера вполне логично и приемлемо).

Политики учетных записей

Данные правила подразделяются на две (три в случае домена — добавляется политика Kerberos) группы: политика паролей и политика блокировки учетной записи.

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

Так как среди взломщиков (“хакеров” согласно терминологии современного мэйнстрима, хотя это исторически неверно) популярностью пользуются атаки, заключающиеся в подборе пароля по заранее составленному файлу с набором типичных паролей (“словарная атака”) и просто грубому перебору всех возможных комбинаций символов (“brut force”), то необходимо принять меры, страхующие систему от подобных методов взлома. Именно этим и занимается политика блокировки учетной записи. Здесь можно установить количество ошибочных попыток набора пароля до блокировки учетной записи, срок этой блокировки и период сброса счетчика неудачных попыток ввода пароля. Это мощное средство, однако им нужно пользоваться с осторожностью, так как возможен обратный эффект от его действия — взломщик может просто заблокировать аккаунт администратора, перешагнув порог блокировки учетной записи своими попытками подобрать пароль. Именно для этого существует правило, задающее срок этой блокировки (он не должен быть слишком большим).

Локальные политики

Локальные политики определяют правила безопасности локального компьютера. Они делятся на три группы: политики аудита, назначение прав пользователя и параметры безопасности.

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

Права пользователя на выполнение определенных действий устанавливаются по-разному для рабочей станции, рядового сервера и контроллера домена. Правила назначения прав пользователя позволяют настроить привилегии пользователей и/или групп. Например, по умолчанию отлаживать процесс имеет право только администратор, а у вас подрастает сын и уже пытается что-то программировать в Delphi (или еще в чем-нибудь). Естественно, у него ограниченная пользовательская учетная запись в системе, а идея дать ему права администратора выглядит экстремизмом. Вся проблема решается добавлением учетной записи вашего сына в правиле Отладка программ.

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

Остальные политики

Правила журнала регистрации определяют максимальные объемы журналов и способы отслеживания их переполнения. Тут (и далее) нам придется действовать двумя методами, так как оснастка Локальная политика безопасности не позволяет изменять данные параметры. Можно задать эти свойства в оснастке Просмотр событий, а можно воспользоваться оснастками Анализ и настройка безопасности и Шаблоны безопасности (о них мы поговорим чуть позже, а пока загрузите в консоль MMC данные оснастки).

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

Правилами системных служб устанавливаются тип запуска службы (его и некоторые другие свойства можно также задать в оснастке Службы) и права доступа к ней. Это критичные параметры, изменяйте их с умом.

Правила реестра задают права доступа к ветвям реестра, владельца и ведение аудита. Данные параметры можно менять с помощью редактора реестра (Regedit.exe для XP, Regedt32.exe — для остальных NT). Не рекомендуется изменять значения данных свойств для корневой ветви HKEY_LOCAL_MACHINE во избежание неработоспособности системы.

Правила файловой системы, как и правила реестра, разграничивают доступ к ее объектам, назначают владельца и аудит. Изменение этих параметров доступно из закладки свойств Безопасность. Не следует изменять параметры по умолчанию для папок и файлов, используемых системой, таких, как %SystemRoot%, Documents and Settings etc.

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

Анализ и настройка параметров безопасности системы

Вот и настало время воспользоваться открытыми нами оснастками Анализ и настройка безопасности и Шаблоны безопасности. Начнем, пожалуй, со второй оснастки.

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

[Раздел значений]
Правило 1 = Значение
Правило 2 = Значение

Более подробно об их содержимом можно почитать в справке Windows. По умолчанию с системой идет ряд стандартных шаблонов, открывающихся сразу в оснастке Шаблоны безопасности. Они лежат в папке %SystemRoot%\security\ templates. Для каждого шаблона можно просмотреть описание, говорящее о его функциональных возможностях. Редактировать стандартные шаблоны не рекомендуется, лучше создать новый, выбрав в контекстном меню пути поиска пункт Создать шаблон... Кстати, возможно копирование отдельных групп параметров (через контекстное меню), что упрощает создание нового шаблона, т.е. мы будем делать его не с нуля. Если какое-либо правило не определено в шаблоне, то после его применения будет действовать значение по умолчанию.

Оснастка Анализ и настройка безопасности предоставляет нам следующие возможности:

Анализирование политики безопасности на локальном компьютере.
Сравнение установленных значений правил с шаблонными.
Использование в качестве шаблонных правил добавляемые шаблоны.
Формирование новых правил.
Сохранение новых правил в виде шаблона.
Применение вновь созданных правил к системе.
При первом запуске оснастка предложит нам создать или открыть базу конфигурации безопасности. База представляет собой файл, в котором хранятся эталонные параметры безопасности. В базу можно добавлять шаблоны безопасности. По умолчанию она располагается в каталоге %SystemRoot%\security\database. Для создания новой базы (а имеющаяся secedit.sdb недоступна) нужно в контекстном меню элемента Анализ и настройка безопасности выбрать пункт Открыть базу данных... и ввести новое имя, после чего в нее можно импортировать шаблон пунктом меню Импорт шаблона...

После этих действий можно проанализировать безопасность системы. Для этого загрузите нужную базу, после чего в контекстном меню уже упомянутого не раз элемента выберите пункт Анализ компьютера... Затем можно заняться собственно анализом, так как анализировать будем именно мы. Просматривая параметры после запуска анализа, мы заметим, что значки параметров изменились согласно следующим правилам:

Если в базе параметр задан и соответствует установленному в системе, то он помечается галочкой.
Если параметр в базе задан, но не соответствует установленному в компьютере, то он помечается крестиком.
Если параметр не задан в базе, то анализ не выполняется, соответственно и значок не изменяется.
Дополнительно можно просмотреть файл журнала (пункт Показать файл журнала контекстного меню).

После анализа вам наверняка что-то захочется подправить. Любые действия над параметрами сохраняются только в базе. Затем можно выполнить экспорт шаблона для дальнейшего использования. Это делается командой контекстного меню Экспорт шаблона... Ну, а финалом всех наших манипуляций будет конфигурирование машины согласно загруженной базе безопасности. Для этого жмем во все том же меню пункт Настроить компьютер. Вуаля! У нас получилась настроенная, безопасная система, готовый шаблон (если взбредет в голову его потом использовать, скажем, на другом компьютере) и база, позволяющая анализировать текущую конфигурацию с шаблонами. К слову, оснастка Анализ и настройка безопасности в большинстве случаев вполне успешно заменяет оснастки Локальная политика безопасности и Шаблоны безопасности. И еще. Существует ее консольный аналог — утилита secedit.exe, но с ней разбирайтесь сами, устал я .

Введение

После затяжного перерыва возобновляем работу нашего клуба. Как я и обещал, продолжим изучение подсистемы безопасности NT. На этот раз мы остановимся на одном из концептуальных понятий — списке контроля доступа, а также рассмотрим его применение касательно объектов реестра и файловой системы (с чем большинство пользователей и сталкивается на практике). Под файловой системой я, естественно, понимаю "родную" для NT NTFS. Поехали!

Теория

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

Итак, мы знаем, что у нас есть разнообразные объекты, а также пользователи, которые должны в зависимости от своих прав получить или не получить доступ к конкретному объекту. В общих чертах данный процесс выглядит так. Пользователь при входе в систему вводит свое имя и пароль, тем самым производя аутентификацию. Проверяющая подсистема ОС сверяет полученные данные с имеющимися в ее базе. Если они одинаковы, значит, это "свой", впускаем, нет — "пшел вон!" Если процесс аутентификации прошел успешно, запускается первый процесс (программа) сессии данного пользователя (здесь идет серьезное обобщение, впрочем, для нас это не важно), создающий рабочую среду (оболочку и т.д.). Этот процесс получает контекст защиты (так называемый маркер доступа), который идентифицирует пользователя, его группы и привилегии процесса. Все созданные пользователем процессы (т.е. открытые программы) запускаются либо от имени этого процесса, либо его дочерних, что не важно, так как любой процесс получает маркер доступа своего родителя. В итоге ОС может теперь понять, какая программа кем запущена и какие у нее права.

Однако остается еще одна проблема: при обращении программы (процесса) к объекту ОС должна с чем-то сравнить ее маркер доступа для решения вопроса о разрешении/запрещении доступа (это действие называется авторизацией). В разных системах такая структура данных для различных объектов реализована по-разному (в NT она называется дескриптором защиты). Например, в большинстве файловых систем для UNIX каталоги и файлы имеют структуры защиты, состоящие из имени владельца, его группы и группы "остальные", которым соответствует числовое значение, определяющее права доступа. Такая система довольно проста, но не отличается гибкостью, поэтому ведутся разработки для переноса на некоторые ФС технологии списков контроля доступа. В то же время, в других ОС (и NT в том числе) все объекты имеют одинаковую структуру, отвечающую за их защиту — уже упомянутый список контроля доступа. Что же это такое, и чем оно отличается (в положительную сторону) от других методов защиты?

Собственно, разительных отличий нет. И там, и там что-то с чем-то сверяется (этим озабочена та часть ядра, которая отвечает за безопасность — справочный монитор безопасности для NT), а потом выдается либо разрешение на доступ, либо запрет. Однако достоинство списков контроля (управления) доступа (Access Control List, ACL) в их гибкости, т.е. можно очень точно разграничить права, а также в единообразности и универсальности (научился использовать их для файлов, разберешься и для всего остального).
Рассмотрим теперь, что представляет собой дескриптор защиты. Если не углубляться в подробности, то он состоит из следующих основных компонентов:

Номер версии защиты.
Флаги (необязательно).
SID владельца.
SID группы.
Список управления избирательным доступом (Discretionary Access Control List, DACL).
Системный список управления доступом (System Access Control List, SACL).
Теперь поясним, что каждый элемент означает. Итак, с номером защиты и с флагами, думаю, все понятно; нам они, собственно, и неинтересны. А что такое SID владельца? Дело в том, что все объекты, выполняющие в системе какие-нибудь действия (например, пользователи и группы), кроме имени, имеют свой идентификатор защиты (Security Identifier, SID). Именно по нему ОС идентифицирует объект (вспомните содержимое папки RECYCLER, названия вложенных папок — идентификаторы защиты пользователя), что позволяет избежать проблем при повторении имен. Сам идентификатор представляет собой числовое значение переменной длины, формирующееся по правилам, нас здесь не касающимся . В итоге в дескрипторе защиты объекта уже содержится имя его владельца (точнее, его SID). С SID группы аналогично — это идентификатор основной группы владельца (используется только подсистемой POSIX).

А теперь самое вкусное: DACL и SACL. По сути дела, это разновидности ACL. Первый служит для указания прав доступа к объекту для конкретных пользователей и групп (в том числе и встроенных). Второй ответственен за ведение аудита в журнале безопасности соответствующих действий над объектом для указанных пользователей/групп (используется только для файловой системы и реестра). Любой ACL состоит, кроме заголовка, из вхождений (элементов) контроля доступа (Access Control Entries, ACE).

ACE для DACL состоит из SID пользователя/группы и маски доступа, разной для разных типов объектов, а также флагов, отвечающих за наследование. Объекты могут быть контейнерами либо листьями. Контейнеры могут содержать другие контейнеры и/или листья и так далее. ACE бывают двух общих видов (особенности Active Directory не рассматриваем): "доступ разрешен" и "доступ отклонен" (позже я это докажу вам на примере). Причем сначала идут запрещающие ACE, а потом разрешающие (это очень важно: в обратном случае редактор DACL файловой системы, например, сочтет это ошибкой и предложит вам унаследовать DACL родителя, хотя это случается архиредко и связано с использованием устаревших функций Win32).

SACL состоит из ACE двух типов: системного аудита (System Audit ACE) и объекта системного аудита (System Audit Object ACE). Они обеспечивают аудит указанных действий для выбранных пользователей, причем может записываться как "успех", так и "отказ". В плане наследования SACL аналогичен DACL. Если SACL не существует, аудит не ведется.

Алгоритмы

От общей теории перейдем к рассмотрению алгоритмов работы ACL:

Если DACL не существует (null), то все имеют полный доступ (именно с этой точки зрения можно смотреть на FAT).
Если DACL пустой, то никто не имеет доступа.
Если вызываемый процесс (точнее, поток, но это нам не важно) имеет право на захват объекта во владение, то он может стать владельцем объекта и изменить DACL.
Если вызываемый процесс является владельцем, то он может изменить DACL.
Из маски прав доступа удаляется маска доступа каждого ACE типа "доступ отклонен", если SID совпадает с SID маркера доступа процесса.
К полученной маске прав доступа добавляется маска доступа каждого ACE типа "доступ разрешен", если SID совпадает с SID маркера доступа процесса (не считая тех прав, в которых уже отказано).
Полученная маска доступа и определяет права доступа, которые имеет программа, их запрашивающая (точнее, пользователь, ее запустивший — SID-то его).
Это общая схема, тем не менее, дающая нам возможность понять, как все это работает. Теперь подобьем наши знания и добавим новые:

Владелец объекта (по умолчанию его создатель) способен делать с ним все что угодно, так как может изменить DACL (да и SACL тоже).

Пользователь, который имеет права на вступление во владение (администратор, например), способен стать его владельцем со всеми вытекающими...

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

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

Запрет имеет большие привилегии, чем разрешение. Кажется, зачем это надо, ведь можно просто не указать разрешение? А если мне нужно, чтобы конкретный пользователь группы не имел доступа к объекту, а вся группа имела? Не удалять же его из группы !

По умолчанию созданный (или скопированный) объект наследует права доступа (DACL, а также SACL) от родительского контейнера, но это можно изменить. При наследовании ACE удалить невозможно, но можно добавить.

При необходимости можно распространить DACL (и SACL) на все вложенные контейнеры и объекты, тем самым заменив их права.

Будем помнить эти несложные правила. Что ж, я, наверное, утомил читателя пространными рассуждениями о принципах строения и работы ACL. Перейдем к более интересной и полезной практической работе. Перед этим, однако, я настаиваю на том, чтобы вы еще раз прочитали раздел Алгоритмы — это основополагающие сведения.

Практика

Как и говорилось, экспериментировать мы будем над ФС и реестром (в систему встроен графический редактор ACL и консольная версия редактора DACL — cacls.exe). В первую очередь, потому, что это актуально для пользователя, а во вторую — что здесь применяются все возможности ACL (включая наследование). В качестве ОС выбрана русская версия Windows XP Professional. Для начала в Windows XP необходимо отключить опцию Использовать простой общий доступ к файлам из закладки Вид окна Свойства папки Панели управления. Данный режим предназначен для неподготовленных пользователей и весьма ограничен в возможностях. В Windows XP Home Edition вам это сделать не удастся, поэтому нужно будет либо работать в Безопасном режиме (Safe Mode), либо воспользоваться консольной утилитой cacls.exe (или ее расширенным аналогом из Support Tools — xcacls.exe).

Итак, сначала откроем редактор ACL. Для файловой системы достаточно в Проводнике в контекстном меню выбрать пункт Свойства, а затем закладку Безопасность (для папок можно сразу выбрать пункт Общий доступ и безопасность...). Для реестра выбираем нужную ветвь (разграничение доступа идет только на ветви, а не отдельные ключи) и в контекстном меню выбираем пункт Разрешения... (для пользователей Windows NT и 2000 придется воспользоваться программой regedt32.exe, так как только она обладает нужной функциональностью). Так как в обоих случаях используется один и тот же редактор ACL и общие принципы, то продолжать я буду на примере свойств папки.

На нем перечислены пользователи и их права. Можно добавлять новых и удалять уже имеющихся (если позволяет наследование). Однако это лишь вершина айсберга — здесь перечислены только общие типы доступа, основанные на нескольких ACE с одинаковым SID. Проверим? Жмем кнопку Дополнительно и оказываемся в настоящем редакторе ACL.

Как видим, тут перечислены все ACE, причем сначала идут запрещающие. Мы можем добавить, удалить и изменить ACE. При добавлении нас спросят об имени пользователя, которое можно ввести вручную либо воспользоваться поиском, нажав в появившемся окне Дополнительно, Поиск. Кнопка Типы объектов позволяет указать, что мы ищем: пользователей, группы или встроенных пользователей/группы. Кстати, имя имеет вид Имя контейнера (компьютера в нашем случае)\Имя пользователя, хотя можно просто вводить имя пользователя. С удалением все понятно, а редактирование представляет некоторый интерес.

Мы вправе менять такие параметры, как имя пользователя (т.е. выбрали редактировать одно, а потом взяли да и сменили), параметры наследования (вложенные папки, объекты и т.д.), ограничение наследования (галочка внизу, становится доступна, когда выбрано наследование для подпапок и файлов) и собственно сами права. Кнопка Очистить выполняет быструю очистку всех галочек в ACE. Если мы поставим сразу запрещающие и разрешающие галочки, то будет создано два ACE: запрещающее и разрешающее (помните о примере). Причем этого можно добиться также и в самом первом окне (до нажатия кнопки Дополнительно) редактированием базовых типов доступа. Думаю, с этим разобрались.

В расширенный редакторе ACL внизу можно заметить две галочки, отвечающие за наследование. Первая указывает на то, что данный объект наследует права доступа от родительского. Если снять эту галочку, то нам предложат либо скопировать унаследованные права в качестве заданных явно (что в большинстве случаев удобно), либо просто очистить ACL, если нет других ACE, кроме унаследованных. Вторая галочка позволяет заменить разрешения всех объектов и контейнеров заданными здесь, то есть по сути дела заставляет их наследовать права.

Что касается аудита — все абсолютно аналогично рассмотренному DACL включая наследование.

Перейдем к владению (закладка Владелец). По умолчанию владельцем является его создатель, т.е. пользователь либо группа. Однако можно вступить во владение объектом, если вы обладаете таким правом (по умолчанию им обладают члены группы Администраторы) либо если в DACL явно указано, что вы можете изменить владельца. Мы просто выбираем доступного пользователя или группу для владения, если надо, ставим галочку Заменить владельца субконтейнеров и объектов и жмем Применить. Все, объект наш .

Ну и напоследок бросим взгляд на закладку Действующие разрешения. Это полезное нововведение XP, позволяющее не просчитывать в уме права конкретного пользователя/группы. Достаточно выбрать имя, и мы получим список прав на основе имеющихся ACE.

Остается добавить, что внешний вид редактора ACL зависит от объекта, разрешения которого мы редактируем, т.е. могут быть недоступны какие-то опции. Если вам интересно, можете поэкспериментировать с консольными утилитами cacls.exe и xcacls.exe. Первая — аналог простого редактора базовых типов доступа, вторая позволяет работать с разрешениями более точно. Не забывайте, что, перетаскивая объект в другую папку в Проводнике, мы тем самым заставляем его унаследовать права этой папки. Чтобы этого не произошло, необходимо пользоваться консольными утилитами с соответствующими ключами либо файл-менеджерами, поддерживающими эту опцию (Total Commander, например).

Заключение

Надеюсь, приведенная мной информация оказалась вам полезной. Если это так, то я и дальше буду продолжать снабжать вас интересными фактами о системах семейства NT. В данной статье использовались материалы из книги Д. Соломона и М. Руссиновича "Внутреннее устройство Microsoft Windows 2000", а в предыдущей (забыл упомянуть) — книга Федора Зубанова "Microsoft Windows 2000. Планирование, развертывание, управление".

Конец.