| Новые программы oszone.net |  |
Описание процесса загрузки и входа в систему Windows 2000Как только Вы слышите о процессе входа в систему в окружении Windows, Вы вспоминаете о том, что пользователь нажимает комбинацию клавиш ctrl-alt-delete и вводит свои учетные данные (имя пользователя и пароль) для получения доступа к системе. Учетные данные позволяют пользователю получить доступ к ресурсам компьютера, на котором он работает, а также, если компьютер подключен к сети, то и к таким сетевым ресурсам, как приложения, файлы и принтеры, которыми пользователю разрешено пользоваться. Процесс, который позволяет пользователям получать доступ к ресурсам, начинается не тогда, когда пользователь входит в систему, а еще задолго до того, как система будет загружена. В домене Windows 2000 компьютер должен быть настроен в качестве члена домена для того, чтобы пользователи могли входить в его систему и получать доступ к другим сетевым ресурсам. Цель данного раздела – показать то, что происходит при загрузке и входе в систему Windows 2000. Возможность использования NetBIOS поверх протокола TCP/IP отключена на всех компьютерах для того, чтобы сфокусироваться на рассмотрении трафика, генерируемого в сети, в которой используются только компьютеры, работающие под управлением ОС Windows 2000. Однако, имеется возможность настройки каждого компьютера, позволяющая взаимодействовать с клиентами Windows NT, Windows 95 и Windows 98. Детальное описание трафика, генерируемого клиентами Windows NT при загрузке и входе в систему, Вы можете найти в разделе „Сетевой трафик, генерируемый клиентом в Active Directory” книги Организация служб предприятия Active Directory: полевые заметки ("Active Directory Client Network Traffic" chapter of the Notes from the Field series book Building Enterprise Active Directory Services) (EN). Ниже на рисунке приводятся используемые настройки.  Процесс загрузки компьютераКомпьютер, который входит в домен Windows 2000, проходит через процесс загрузки, который подключает его к своему домену. Процесс загрузки позволяет службам компьютера взаимодействовать с другими службами в сети, а также (что является более важным) он просто необходим для того, чтобы пользователи могли использовать интерактивный вход в систему. Ниже представлена схема процесса загрузки компьютера.  Увеличить рисунок Подключение к сети Процесс загрузки компьютера начинается с того, что компьютер подключается к сети и загружает протокол TCP/IP. Настройки TCP/IP позволяют использовать статические или динамические параметры сети. Применение динамической конфигурации предполагает использование DHCP – известной технологии, которая является одним из основных компонентов ОС Windows Server. Использование статической конфигурации означает, что настройка параметров TCP/IP на компьютере осуществляется вручную. Обычно статическая адресация применяется на тех ресурсах сети, изменения в которых происходит не так часто. Обычно это маршрутизаторы или серверы. В примерах, используемых в этом документе, единственными системами, которые используют статическую адресацию, будут серверы. При подключении клиента к сети процесс DHCP начинает отправку в сеть пакетов. Последовательность из команд "Discover", "Offer", "Request" и "ACK", отправленных в четырех первых пакетах, означают работу DHCP. Эти четыре пакета в сумме генерируют 1342 байта сетевого трафика (приблизительно по 342 байта на каждый пакет DHCP), но эта цифра может меняться в зависимости от количества выбранных настроек DHCP. Команды RARP (Reverse ARP) в пакетах с 5 по 8 используются клиентом для того, чтобы убедиться, что адрес не используется другим компьютером в сети. Каждый RARP-пакет генерирует приблизительно 60 байтов сетевого трафика или приблизительно 300 байтов для последовательности, используемой для проверки адреса.
Необходимо отметить то, что если клиенту уже был выделен адрес, то при перезагрузке он будет обновлен DHCP-сервером. Для обновления будут использоваться только два пакета: пакет запроса (Request) и пакет подтверждения (Ack), указанные ниже в таблице в первых двух строках. При том клиент будет использовать RARP, чтобы убедиться в том, что его адрес никто не использует.
Обнаружение контроллера домена Клиентскому компьютеру необходимо получать самую последнюю информацию о конфигурации сети во время каждой фазы загрузки. Поэтому он должен обнаружить хотя бы один контроллер домена в своем домене. В домене Windows 2000 каждый контроллер домена также является LDAP-сервером. Для получения списка доступных контроллеров домена клиенту необходимо запросить у DNS SRV-записи источников с именем _ldap._tcp.dc._msdcs.DnsDomanName . Ниже в таблице представлен обмен пакетами, происходящий при этом процессе:
Домен Windows 2000 является некой административной границей, которая не зависит от структуры имеющейся сети. Компьютеры в сетевом окружении могут быть объединены в сайты. Сайт в Windows 2000 представляет собой набор IP-подсетей, использующих быстрое, надежное соединение друг с другом. На практике сети LAN или сети, имеющие более быстрое соединение, рассматриваются как сети с высокой пропускной способностью, достаточной для организации сайта на их основе. Домен может охватывать несколько сайтов, кроме того, один сайт может входить в состав нескольких доменов.  Увеличить рисунок Во время запуска клиентского компьютера служба локатора (locator service) пытается обнаружить ближайший сайт и сохранить его имя в реестре. Если клиенту известно, к какому сайту он принадлежит, то он может запросить у DNS-сервера данные о контроллерах домена его сайта. Формат такого запроса следующий: _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DnsDomanName Ниже приводится последовательность пакетов, обмен которыми происходит во время этого процесса.
Ниже представлен процесс поиска клиентом службы LDAP с помощью DNS-запроса с указанием параметра "По_умолчанию-Первое-Имя-Сайта" ("Default-First-Site-Name"). Где «По_умолчанию-Первое-Имя-Сайта» ("Default-First-Site-Name") - это первое имя сайта домена Windows 2000, заданное по умолчанию при его создании. Список контроллеров домена можно просмотреть с помощью оснастки DNS консоли MMC. Ниже на рисунке показано окно оснастки DNS. При расширенном просмотре Вы можете увидеть контроллеры домена, которые зарегистрировали свои службы Kerberos и LDAP для данного сайта.  В случае, если DNS-сервер обнаружил запрашиваемую информацию, он отсылает назад список всех ему известных контроллеров домена сайта. DNS: Answer section: _ldap._tcp.Site2._sites.dc._msdcs.dcclab.local. of type Srv Loc Клиент случайным образом выбирает один контроллер домена для дальнейшего взаимодействия, при этом он не делает различия между локальными и удаленными подсетями, поскольку считает, что каждый член сайта является компьютером, расположенным на достаточно близком расстоянии от него. Как было ранее отмечено, имеется возможность выбора контроллера домена в виде концепции сайта. После обнаружения контроллера домена клиент с помощью LDAP-запросов пытается определить, является ли данный контроллер наиболее близким.
Клиент осуществляет поиск по следующим атрибутам, которые он указывает в своем запросе:
В том случае, если данные контроллера домена совпадает с той информацией, что указана в базе данных Active Directory для него, он отсылает назад следующую информацию о себе:
Наиболее важной для клиента информацией является имя сайта. В шестнадцатеричном дампе ответа, полученного от сервера, будет содержаться только одно имя сайта в том случае, если клиент является членом сайта, к которому принадлежит контроллер домена: 00000: 00 A0 C9 F1 A0 00 00 01 02 33 BF E7 08 00 45 00 . ....3..E. В случае, если клиент взаимодействует с контроллером домена, который не входит в сайт, членом которого является клиент, контроллер домена также в ответе указывает имя сайта, к которому принадлежит клиент: 00000: 00 20 78 E0 AA 2B 00 20 78 01 80 69 08 00 45 00 . x+. x.i..E. В этом случае клиент посылает еще один запрос DNS-серверу, с просьбой представить список контроллеров, входящих в этот сайт. Ниже представлена таблица, в которой представлен обмен пакетами, происходящий в такой ситуации. Клиент пытается отыскать контроллер домена в Сайте2 (Site2) и после LDAP-запросов он обращается к Сайту1 (Site1).
Нет необходимости в наличии контроллера домена в каждом сайте. Каждый контроллер домена проверяет все сайты в лесу и стоимость репликации. Контроллер домена регистрирует себя на всех сайтах, в которых нет контроллера домена, а также для которых стоимость репликации минимальна. Этот процесс также известен как автоматическое обслуживание сайта (automatic site coverage). Это означает, что клиенты будут использовать следующий контроллер домена, стоимость доступа к которому минимальна. В процессе поиска ближайшего контроллера домена используются 10 сетевых пакетов, создающие трафик общим объемом приблизительно 2000 байтов.
Более подробную информацию о процессе поиска домена можно получить из раздела «Разрешение имен в Active Directory» документации Windows 2000 Resource Kit (chapter "Name Resolution in Active Directory" of the Windows 2000 Resource Kit) (EN). Установление безопасного канала к контроллеру домена После того, как клиент определит свой сайт и контроллер домена, он может установить безопасный канал к своему контроллеру домена. Безопасный канал – это соединение между членом домена и контроллером домена, устанавливаемое для получения особой информации домена, для обновления особой информации о компьютере в Active Directory (например, пароля), а также для проверки членства в домене. Процесс начинается с согласования того, какой SMB-диалект будут использовать обе стороны. После того, как первый вариант протокола SMB был выпущен в 1984 году, его неоднократно пересматривали и вносили в него дополнения. Это означает то, что клиент и сервер могут использовать различные SMB-диалекты. В таком случае ОС Windows 2000 с обеих сторон должны использовать диалект NTLM 0.12. Этот диалект позволяет использовать кодировку Юникод (Unicode) при обмене информацией. До этого обмен данными происходил в кодировке ASCII. Преимуществом записей в кодировке Юникод является то, что они могут включать имена файлов, имена ресурсов и имена пользователей. Процесс продолжается соединением с интерфейсом сетевого входа (netlogon interface) сервера. В данном процессе должен использоваться сопоставитель конечных портов (End Port Mapper) для того, чтобы подключить клиента к правильному порту сервера. В конце данного процесса клиент отсылает три пакета (NetrServerReqChallenge, NetrServerAuthenticate3 и NetrLogonGetdomainInfo) на этот интерфейс. В течение всего этого процесса генерируется приблизительно 4600 байтов трафика.
Примечание. Текущая версия программы Netmon не может корректно обрабатывать вызовы NetrServerAuthenticate3 и NetrLogonGetdomainInf. Поэтому выше в таблице эти вызовы отмечены как ошибки с отметкой Bad Opcode. Важно. В случае, если сетевое окружения является смешанным (после того, как производилось обновление домена с Windows NT 4 на Windows 2000), необходимо помнить о следующей возможной ситуации. В случае, если единственным доступным контроллером домена для проверки подлинности клиента Windows 2000 будет резервный контроллер домена Windows NT 4.0, то невозможно будет установить безопасный канал. Это было сделано в целях усиления безопасности. Клиентам Windows 2000 известен тип домена, к которому они принадлежат, и они не будут упрощать свой способ проверки подлинности при установке безопасного канала. Данная последовательность обмена пакетами как раз соответствует этому варианту. Она соответствует взаимодействию клиента Windows 2000 в домене Windows NT 4.0. Взаимодействие с основным доменом начинается после того, как клиент не смог установить безопасный канал, из-за чего проверка подлинности домена завершилась неудачно. Проверка подлинности Kerberos и установление сеанса После установления безопасного канала клиент получает все билеты, необходимые для установления IPC$-сеанса с контроллером. Поскольку все контроллеры домена Windows 2000 также являются центрами KDC, клиент попытается обнаружить наиболее близкий к нему центр KDC тем же способом, какой он использовал для обнаружения LDAP-служб. Первое, что необходимо сделать клиенту – это осуществить проверку подлинности в виде обмена билетами AS. В случае успешного завершения проверки он запрашивает билет для контроллера (имя компьютера$ (computer name$)) и службы Kerberos (krbtgt), запущенной на контроллере. Обмен пакетами генерирует трафик общим объемом приблизительно в 8 килобайт. В действительности объем может быть другим в зависимости от количества глобальных (Global) и универсальных (Universal) групп, членами которых является клиент. На каждую такую дополнительную группу приходится приблизительно еще по 28 байтов.
Все билеты, получаемые клиентом, можно просмотреть с помощью утилиты Kerbtray из пакета Microsoft Resource Kit.  В итоге клиент может подключиться к общему ресурсу IPC$ контроллера, при этом будет сгенерированно приблизительно 3,600 байтов трафика.
Ссылки DFS Далее клиент создает ссылку DFS (Distributed File System). DFS-ссылка – это протокол клиент-сервер, используемый для передачи клиенту особой информации о DFS, расположенной на сервере. Она используется по мере необходимости. Общий процесс перенаправления начинается тогда, когда клиент отсылает SMB-пакет с указанием того, что это ссылка DFS. Сервер передает этот запрос DFS-драйверу для завершения его обработки. Впоследствии любой доступ к общим сетевым ресурсам может привести к созданию запроса DFS-ссылки в том случае, если клиенты не обладают информацией об общих ресурсах. Windows 2000 является DFS-клиентом версии 5.0. Эта версия позволяет кэшировать ссылки на корень DFS или организовывать связи на то время, которое укажет администратор. При запуске клиентского компьютера формируется большое количество запросов DFS-ссылок, которые отсылаются клиентом через его домен своему контроллеру домена, который отвечает на них. Этот процесс необходим для того, чтобы клиент был готов обработать любые запросы, направляемые к общим ресурсам DFS доменов. Первые два запроса необходимы для инициализации DFS-клиента. Первый используется для определения имен всех доверенных доменов Windows 2000, к которым клиент может получить доступ. Второй используется для получения списка контроллеров домена, расположенных в домене, начиная с локального сайта. Возвращаемые на эти запросы имена содержат как имена Netbios, так и DNS-имена доменов. Третий запрос необходим для получения действующего пути к серверу, необходимого для соединения с общим ресурсом sysvol. DFS-ссылки создают трафик, минимальный объем которого составляет 394 байта. Реальный объем генерируемого трафика может быть иным и зависеть от количества доверенных доменов и количества контроллеров домена, возвращаемых в ответе. По умолчанию DFS-ссылка используется каждые 15 минут для определения конфигурации домена.
Затем клиент выполняет команду ping и отправляет LDAP-запрос для того, чтобы снова получить информацию о контроллере домена.
Преобразование имен У каждого объекта в Active Directory есть соответствующее имя. Имеются различные форматы имен, такие, как основное имя пользователя (User principal name, UPN), различаемые имена (Distinguished names, DN), а также ранние имена «домен\пользователь» ("domain\user") из Windows NT. Вовсе не обязательно, чтобы имя было строковой записью. В качестве имени может выступать все, что уникальным образом идентифицирует объект. В зависимости от того, какой службе требуется указать имя в качестве параметра, может понадобиться преобразование имени из одного формата в другой. Для преобразования имен из одного формата в другой используется API DsCrackNames. Более подробную информацию об этом можно найти в MSDN (Microsoft Developers Network). Перед тем, как клиент сможет воспользоваться этой функцией, ему необходимо будет выполнить привязку дескриптора к службе каталогов с помощью команды DSBind, а по завершении выполнения операции ему необходимо отменить привязку к службе каталогов с помощью DSUnbind. Ниже в таблице представлен обмен пакетами, происходящий во время процесса трансляции. Общий объем трафика, генерируемого при этом, составляет приблизительно 6600 байтов.
LDAP RootDSE Затем клиент запрашивает информацию из LDAP RootDSE. RootDSE является стандартным атрибутом, определенным в спецификации LDAP 3.0. RootDSE содержит информацию о сервере каталога, включая информацию о его характеристиках и конфигурации. Ответ будет содержать стандартный набор данных в соответствии с документом RFC 2251. Одним из элементов, который будет возвращен в этом ответе, будет поддерживаемый механизм Simple Authentication и Security Layer (SASL). В этом случае возвращается GSS-SPNEGO.
Загрузка групповой политики Затем на компьютер загружаются соответствующие объекты групповой политики. После этого клиент завершает вызов RPC, необходимый для преобразования его имени в различающееся имя, и выполняет с помощью протокола LDAP поиск информации политики, необходимой для данного компьютера, а затем загружает ее с помощью протокола SMB (Server Message Block). Поиск политики Ниже в таблице представлен обмен пакетами, происходящий, когда клиент выполняет операцию привязки дескриптора к каталогу LDAP. Для выполнения LDAP-запросов необходимо, чтобы клиент установил привязку дескрипторов к службе каталогов до того, как начнет поиск информации. На этом этапе процесса входа в систему клиента он выполняет привязку дескриптора к Active Directory для того, чтобы осуществить поиск групповой политики, которую необходимо применить к клиенту. В приведенной ниже последовательности пакетов также отображен LDAP-запрос клиента для определения того, какую групповую политику необходимо применить. Каждая операция привязки дескриптора генерирует трафик объемом около 1675 байтов. В этом случае при поиске политики генерируется около 3527 байтов сетевого трафика.
После того, как клиент определяет подходящую политику, он создает вторую DFS-ссылку. То же самое будет происходить в большинстве других случаев при попытках клиента соединиться с общим ресурсом Windows 2000. Загрузка политик по протоколу SMB Процесс завершается соединением клиента с SYSVOL (стандартным общим ресурсом контроллера домена) и загрузкой политик, что приводит к генерированию трафика общим объемом 1018 байтов.  В данном случае приведен пример очень простой конфигурации. Количество записей, показанных на рисунке, будет значительно больше, в случае более сложных настроек групповой политики.
Автоматическая подача заявок на сертификаты клиента Каждый раз после применения объектов групповой политики происходит автоматическая подача заявок на сертификаты. Во время этого процесса происходит следующее:
Клиент подает запрос для получения информации LDAP RootDSE (ниже в таблице приведен обмен пакетами), а затем использует LDAP для завершения процесса автоматической подачи заявки.
Более подробное рассмотрение третьего пакета показывает, что этот пакет является запросом на получение информации о конфигурации служб открытых ключей, используемых в домене. Ниже показано содержимое одного из пакетов: LDAP: ProtocolOp: SearchRequest (3) Синхронизация времени Затем происходит обновление времени на клиентском компьютере, путем синхронизации с контроллером домена, выполняющим проверку подлинности. Ниже представлен обмен пакетами, соответствующий этому процессу синхронизации. Примите во внимание то, что при этом используется порт 123. Общий объем сетевого трафика, генерируемого при этом, равен 220 байтов.
Обновление системы DDNS На последнем этапе процесса загрузки происходит обновление имени клиента в базе данных DNS. Процесс динамического обновления записей DNS в Windows 2000 основан на процедурах, описанных в документе RFC 2136. Вначале клиент определяет, имеется ли у DNS-сервера центр, обслуживающий зону клиента. При этом генерируется сетевой трафик общим объемом 225 байтов.
Затем клиент выполняет динамическое обновление своего имени на DNS-сервере. В случае, если обновляются как записи A RR, так и PTR RR клиента, то объем общего трафика, генерируемого при этом, будет равен 1800 байтов.
Реальный объем трафика, генерируемого при динамическом обновлении, зависит от многих условий. Прежде всего он зависит от того, был ли клиент уже зарегистрирован. Затем на него может влиять конфликт с уже имеющейся записью. Также учитывается и то, используется ли DHCP. В данном примере предполагается, что те настройки, которые используются по умолчанию, позволяют клиенту обновлять только свои записи A RR, в то время как за обновление записей PTR RR отвечает DHCP-сервер. И последним, но не менее важным, является то, что объем трафика также зависит от конфигурации DNS-сервера и от того, каким образом настроено безопасное динамическое обновление. Примечание. В случае, если DDNS не используется, Вам необходимо отключить функцию динамического обновления на клиенте. Отключение этой функции позволит сэкономить сетевой трафик, генерируемый бесполезными попытками произвести обновление притом, что оно не поддерживается. Динамическое обновление можно отключить в дополнительных свойствах TCP/IP для соответствующего сетевого соединения. Ниже на рисунке показано, где именно эта функция отключается:  Завершение Процесс загрузки компьютера завершается, когда клиент разрывает открытые соединения с контроллером домена, обмениваясь пакетами, указанными ниже в таблице. При этом генерируется 473 байта сетевого трафика.
Зная эту последовательность обмена пакетами при анализе трафика можно определить завершение процесса загрузки системы и начало процесса входа пользователя в систему. Теперь система готова к использованию. На экране отображается окно входа в систему.
Теги:
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
