Опубликовано: 01 августа 2000 г. | Переведено: 01 сентября 2006 г.
Службы Microsoft Enterprise Services
Для получения информации о службах Enterprise Services посетите веб-узел http://www.microsoft.com/learning/default.asp
Список составителей
Грэг Молнар (Greg Molnar) (EN) - USMCS MidWest
Кит Олинджер (Keith Olinger) (EN) - USMCS MidWest
Дэвид Трулли (David Trulli) (EN) – руководитель проектов, Microsoft Enterprise Customer Solutions
Маркус Вилцинскас (Markus Vilcinskas) (EN) – руководитель проектов, Microsoft Enterprise Services
На этой странице
| Приложение Б. Порты TCP/IP, используемые в процессе проверки подлинности |
Введение
Процесс загрузки и входа в систему используется ОС Microsoft Windows для проверки компьютера или пользователя в сетевом окружении Windows. Понимание механизма работы процесса загрузки и входа пользователя в систему является ключом к пониманию принципов сетевого взаимодействия ОС Windows 2000. В данном официальном документе читатель сможет получить детальную информацию об этих процессах, при этом будет рассмотрено:
| • | Подключение клиентов к сети Windows 2000, в которой используется протокол динамической конфигурации узлов (Dynamic Host Configuration Protocol, DHCP), средство автоматического назначение частных IP-адресов (Automatic Private Internet Protocol addressing, APIPA) и статическая адресация. |
| • | Использование клиентами Windows 2000 системы DDNS (Dynamic Domain Naming System), поддерживаемой ОС Windows 2000 для обнаружения контроллеров домена и других серверов в имеющейся инфраструктуре, наличие которых необходимо для загрузки и входа в систему. Также будет рассмотрено то, каким образом клиенты Windows 2000 регистрируют свои имена в системе DDNS. |
| • | Использование протокола LDAP (Lightweight Directory Access Protocol) при поиске в службе каталогов Active Directory информации, необходимой для загрузки и входа в систему. |
| • | Использование протокола безопасности Kerberos при проверке подлинности. |
| • | Использование удаленного вызова процедур (MS Remote Procedure Calls, MSRPC). |
| • | Использование протокола SMB (Server Message Block) для передачи информации о настройках групповой политики и прочих данных во время загрузки и входа в систему. |
Кроме непосредственного рассмотрения основных компонентов Windows 2000, используемых при загрузке и входе в систему, в данном документе также будет рассмотрено то, что происходит на каждом из этапов работы этих процессов, и какой объем сетевого трафика при этом генерируется. Рассмотрение начинается с обзора компонентов ОС Windows 2000, используемых при загрузке и входе в систему. Далее рассматривается сам процесс загрузки и входа пользователя в систему.
По ходу рассмотрения данного материала будет использоваться информация, полученная с помощью сетевого монитора, которая позволит определить, что происходит в конкретной точке. Также там, где это было возможно, в тексте представлены ссылки на внешние источники, в которых можно получить дополнительную информацию. В основном ссылки даются на следующие материалы:
| • | Документы RFC проблемной группы проектирования сети Интернет (Internet Engineering Task Force, IETF). |
| • | Документация Microsoft Windows 2000 Resource Kit. |
| • | Статьи базы знаний центра поддержки Microsoft. |
| • | Материалы книг Microsoft серии «Полевые заметки» (Notes from the Field) (EN). |
| • | Различные веб-ресурсы. |
Прочитав данный официальный документ и поняв его суть, системные архитекторы и администраторы смогут лучше организовывать и поддерживать сети на базе Windows 2000. Руководствуясь данным документом, проектировщики сетей также смогут точно определять правильное местоположение основных компонентов для обеспечения надежной работы процессов загрузки и входа в систему в сети Windows 2000. С помощью этого документа специалисты, занимающиеся поддержкой, смогут решать возникающие проблемы, сравнивая информацию данного руководства с той, что имеется у них.
Целевая аудитория
Данный документ предназначен системным администраторам и сетевым архитекторам, занимающимся планированием и внедрением сетей на базе Windows 2000, а также их управлением. Предполагается, что им уже известны:
| • | Принципы взаимодействия в сетях на основе Windows NT или 2000. |
| • | Протокол TCP/IP. |
| • | Способы проверки сетевых маршрутов. |
Более полную информацию по основным службам Windows 2000, представленную в материалах Windows 2000 Resource Kit, Microsoft TechNet и серии книг «Полевые заметки» (Notes from the Field), мы будем рассматривать применительно к процессам загрузки и входа в систему. Рекомендуется иметь под рукой данные материалы и использовать их в качестве источников дополнительной информации при прочтении данного документа.
Обзор компонентов Windows 2000
Для того, чтобы понять процесс загрузки и входа в систему Windows 2000, необходимо вначале рассмотреть новые или обновленные протоколы, а также службы, которые задействованы в данном процессе. В данном разделе проводится краткий обзор следующих протоколов и служб, задействованных в процессах загрузки и входа в систему:
| • | Протокол DHCP Средство назначения частных IP-адресов |
| • | Служба DNS |
| • | Протокол Kerberos |
| • | Протокол LDAP |
| • | Протокол SMB |
| • | Удаленный вызов процедур (MSRPC) |
| • | Служба времени |
Более полную информацию о каждом протоколе или службе можно получить, воспользовавшись ссылками, представленными в каждом разделе.
Протокол DHCP
Первоначальной целью использования протокола DHCP было обеспечение каждого DHCP-клиента правильной настройкой TCP/IP.
В процессе получения настроек в основном используется восемь сообщений:
| • | DHCPDiscover. DHCP-клиенты используют данное сообщение с целью обнаружения в сети, по крайней мере, одного DHCP-сервера. |
| • | DHCPOffer. Каждый DHCP-сервер, получив запрос от клиента, проверяет его возможность приема правильных настроек и предлагает их получить DHCP-клиенту. |
| • | DHCPRequest. DHCP-клиент отправляет запрос в ответ на первое предложение, полученное от DHCP-сервера. |
| • | DHCPAcknowledge. Выбранный DHCP-сервер использует это сообщение для подтверждения выделения настроек DHCP-клиенту. |
| • | DHCPNack. DHCP-сервер использует это сообщение для уведомления клиента о том, что запрашиваемые настройки TCP/IP недействительны. |
| • | DHCPDecline. DHCP-клиент использует это сообщение для уведомления сервера о том, что предложенные настройки TCP/IP недействительны. |
| • | DHCPRelease. DHCP-клиент использует это сообщение для уведомления сервера о том, что выданные конфигурационные настройки клиентом больше не используются. |
| • | DHCPInform. Этот тип сообщения является новым. Он определен в документе RFC 2131. В случае, если клиент уже получил IP-адрес (например, при настройке вручную), то он может использовать этот тип сообщения для получения дополнительных параметров настройки (относящихся к IP-адресу) от DHCP-сервера. |
Возможности DHCP-сервера расширяются при наличии системы DDNS. В этом случае DHCP-сервер может использоваться для динамической регистрации IP-адресов и имени клиентов. При настройках, используемых по умолчанию, DHCP-сервер устанавливает соответствие для IP-адресов клиентов на DNS-сервере. Записи этого типа известны под названием Pointer Record (PTR RR).
Для получения дополнительной информации о DHCP, обратитесь к:
| • | Документу RFC 1541 |
| • | Документу RFC 2131 |
| • | Разделу по принципам сетевого взаимодействия с помощью протоколов DHCP, TCP/IP документации Windows 2000 Server Resource Kit (Dynamic Host Configuration Protocol, TCP/IP Core Networking Guide, Windows 2000 Server Resource Kit) (EN) |
Средство назначения частных IP-адресов
В Windows 2000 включено средство назначения частных IP-адресов (Automatic Private IP Addressing, APIPA), благодаря которому DHCP-клиентам будут назначены IP-адреса даже в том случае, если в сети нет ни одного доступного DHCP-сервера. Средство назначения адресов APIPA разрабатывалось для компьютеров, работающих в пределах одной подсети, в которой отсутствует DHCP-сервер. Средство APIPA автоматически назначает IP-адреса из зарезервированного для этого диапазона адресов (с 169.254.0.1 по 169.254.255.254). Это означает, что в том случае, если клиент во время загрузки не смог связаться с локальным DHCP-сервером для обновления арендованного адреса, то он будет использовать IP-адрес, назначенный ему APIPA, до тех пор, пока не будет восстановлена связь с DHCP-сервером. Такой алгоритм работы отличается от алгоритма, используемого в Windows NT 4.0, когда при отсутствии соединения с DHCP-сервером клиент продолжал использовать выданный ему ранее адрес, срок аренды которого еще не истек.
Вы можете отключить средство назначения адресов APIPA, воспользовавшись редактором реестра для добавления в указанный ниже раздел реестра следующего ключа:
HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet
Services\Tcpip\Parameters\Interfaces\
Где - это адаптер, настроенный для использования протокола DHCP, и для которого необходимо отключить возможность назначения адресов с помощью средства APIPA.
Добавьте следующий ключ:
Имя ключа: IPAutoconfigurationEnabled
Тип ключа: REG_DWORD
Значение в шестнадцатеричной системе исчисления: 0 (значение 0 отключает поддержку механизма APIPA для этого адаптера).
Примечание. В случае, если даже ключ IPAutoconfigurationEnabled отсутствует, то по умолчанию считается, что он есть и имеет значение 1, что соответствует включенному состоянию средства APIPA.
Для того, чтобы изменения вступили в силу, необходимо перезагрузить компьютер. Это описано в статьях 244268 и 244268, которые Вы можете найти на веб-узле http://search.support.microsoft.com/ .
Служба DNS
Основным механизмом размещения служб и разрешения имен в ОС Windows 2000 является служба DNS (Domain Name System). В состав Windows 2000 входит служба DNS, тесно связанная с этой операционной системой, что обеспечивает интеграцию со службой каталогов Active Directory и обеспечивает поддержку обновлений DNS. Но, не смотря на это, любая другая служба DNS, совместимая с BIND 8.2.2, может использоваться совместно с Windows 2000. Поддержка DNS в Windows 2000 реализована в качестве стандартной замены службы WINS (Windows Internet Naming Service), использующей NetBIOS, которая ранее применялась для обеспечения динамической поддержки Windows–клиентов. Обе службы поддерживают возможность динамического обновления имен в своих базах данных, но WINS использует пространство плоских имен и не обладает такой возможностью расширения, как DNS. Переходя на использование DNS, Windows 2000 не только начинает соответствовать всем стандартам сети Интернет, но и предоставляет иерархическую структуру пространства имен, обеспечивающую возможность расширения для соответствия требованиям больших сетей.
Процессы загрузки и входа в систему Windows 2000 используют DNS для обнаружения таких служб, как LDAP и Kerberos, для получения адреса хотя бы одного контроллера и для регистрации его имени и IP-адреса в базе данных зоны DNS.
Информация о системе DNS Windows 2000 и требования к ней детально представлены в документации Windows 2000 Resource Kit, а также в книге серии «Полевые заметки» Организация служб предприятия Active Directory (Notes from the Field book Building Enterprise Active Directory Services) (EN).
Для получения дополнительной информации обратитесь к следующим материалам:
| • | Руководствам «Разрешение имен в службе каталогов Active Directory» и «Распределенные системы» документации Windows 2000 Resource Kit (Windows 2000 Resource Kit: Name Resolution in Active Directory, Distributed Systems Guide) (EN). |
| • | Руководствам «Служба DNS ОС Windows 2000» и «Принципы сетевого взаимодействия с использованием протоколов TCP/IP» документации Windows 2000 Resource Kit (Windows 2000 Resource Kit: Windows 2000 DNS, TCP/IP Core Networking Guide) (EN). |
| • | Документам RFC 1035, RFC 1036. |
Протокол Kerberos
Протокол Kerberos версии 5 по умолчанию используется в ОС Windows 2000 для проверки подлинности. Протокол Kerberos был разработан в Массачусетском технологическом институте (Massachusetts Institute of Technology, MIT) в конце 80-х для использования в проекте «Athena», сейчас же его версия 5 описана в документе IETF RFC 1510.
Kerberos версии 5 является протоколом аутентификации. Он позволяет компьютерам осуществлять взаимную аутентификацию. Другими словами, он позволяет компьютерам идентифицировать друг друга. Он также является основой для всех систем безопасности. До тех пор, пока сервер не будет полностью уверен в том, что Вы являетесь тем, за кого себя выдаете, как он не сможет обеспечить надежный доступ к своим ресурсам? Как только сервер идентифицирует Вас, он сможет определить, имеются ли у Вас соответствующие полномочия на доступ к его ресурсам.
Хотя в действительности протокол Kerberos и не предполагалось использовать для авторизации пользователей с целью доступа к ресурсам, тем не менее, реализация протокола Kerberos V5 Microsoft позволяет осуществлять безопасную передачу учетных данных пользователей. Для получения сведений о задействованных для этого полях данных, обратитесь к веб-узлу http://www.microsoft.com/technet/archive/interopmigration/mgmt/kerberos.mspx (EN).
Существует шесть первичных сообщений Kerberos. Эти шесть сообщений в действительности представляют собой три типа действия, каждое из которых содержит запрос клиента и ответ центра распространения ключей (Key Distribution Center, KDC). Первое действие заключается во вводе клиентом пароля. Клиент Kerberos рабочей станции отсылает запрос "AS" в службу проверки подлинности (Authentication Service) центра KDC, запрашивая у службы проверки подлинности билет в качестве ответа для того, чтобы подтвердить, что пользователи являются теми, за кого себя выдают. Служба проверки подлинности проверяет учетные данные пользователей и отсылает назад билет предоставления билета (Ticket Granting Ticket, TGT).
Второе действие заключается в том, что клиент запрашивает доступ к службе или ресурсу, отсылая TGS-запрос в службу Ticket Granting Service (TGS) центра KDC. Служба TGS возвращает клиенту индивидуальный билет, который он может использовать для получения доступа к запрашиваемой службе на любом сервере, на котором она работает.
Третье действие заключается в том, что клиент Kerberos предъявляет серверу билет на доступ к службе и запрашивает разрешение на доступ к необходимой ему службе или ресурсу. Эти сообщения называются «AP». В реализации Microsoft идентификаторы безопасности (Security ID, SID) содержатся в поле PAC, которое является частью билета, отсылаемого на сервер. Это третье действие не требует ответа от сервера, если только клиент не запросил выполнить взаимную аутентификацию. Если же клиент запросил взаимную аутентификацию, то сервер возвращает клиенту сообщение, содержащее метку времени аутентификации (authenticator timestamp). В случае обычного входа в домен все эти три действия происходят перед тем, как пользователь получит доступ к рабочей станции.
Для получения дополнительной информации по использованию Kerberos в Windows 2000 обратитесь к веб-узлу http://www.microsoft.com/windows2000/techinfo/howitworks/security/kerberos.asp (EN).
Протокол LDAP
Протокол LDAP (Lightweight Directory Access Protocol) является разновидностью протокола DAP (Directory Access Protocol). Он создан специально для того, чтобы клиенты могли подавать запросы, создавать, обновлять и удалять информацию, хранящуюся в каталоге. Изначально он применялся для доступа к каталогам X.500, но он также может использоваться для доступа к изолированным серверам каталогов. Windows 2000 поддерживает протокол LDAP как версии 3, так и версии 2.
Работа по протоколу LDAP
Принятая в LDAP общая модель предполагает, что все операции клиента, связанные с протоколом, выполняются на сервере. Клиент передает серверу запрос, в котором указана та операция, которую должен выполнить сервер. С этого момента вся ответственность за выполнение необходимых операций в каталоге ложится на сервер. По завершению выполнения необходимых операций сервер возвращает клиенту либо результат операции, либо сообщение об ошибке.
Информационная модель LDAP основана на записи, в которой содержится информация о каком-то объекте (например, человеке). Записи состоят из атрибутов, имеющих одно или несколько значений. Каждый атрибут имеет определенный синтаксис написания, определяющий допустимые значения атрибута и то, каким образом эти значения задействованы при выполнении операций с каталогом. Атрибутами могут выступать: строковые значения IA5 (ASCII), URL-ссылки и открытые ключи.
Возможности протокола LDAP
Windows 2000 обеспечивает поддержку протокола LDAPv3 в соответствии с тем, как это описано в документе RFC 2251. Ключевой особенностью протокола является то, что:
| • | Поддерживаются все элементы протокола LDAPv2 (протокол описан в документе RFC 1777). |
| • | Протокол работает прямо поверх TCP или другого транспортного протокола, обходя большинство задержек, связанных с необходимостью преобразований на сеансовом уровне/уровне представления данных, которые использовались в DAP X.500. |
| • | Большинство элементов данных протокола могут быть представлены в виде обычных строковых записей (например, различающихся имен). |
| • | Могут быть возвращены ссылки на другие серверы (это описывается в следующем разделе). |
| • | Можно использовать механизм SASL (Simple Authentication and Security Layer) совместно с протоколом LDAP для предоставления зависимых служб безопасности. |
| • | Теперь можно использовать национальные символы для значений атрибутов и различающихся имен, поскольку был использован набор символов ISO (International Standards Organization) 10646. |
| • | В протокол могут быть добавлены расширения для поддержки новых операций, а также могут использоваться средства управления, расширяющие возможности имеющихся операций. |
Ссылка LDAP
Ссылка LDAP – это один из механизмов, которыми пользуется контроллер домена для уведомления клиентского приложения о том, что у него нет копии запрашиваемого объекта (или, что более точно, что у него нет того раздела дерева каталога, в котором этот объект мог бы находиться, т.е. фактически существовать). Эта ссылка указывает клиенту наиболее вероятное место расположения объекта, которое клиент принимает в качестве исходных параметров поиска контроллера домена в DNS. В идеальном варианте ссылки всегда указывают на тот контроллер домена, в котором действительно находится объект. Тем не менее, не исключена ситуация, при которой тот контроллер, на который была дана ссылка, даст еще одну ссылку. Обычно контроллеру не требуется много времени для того, чтобы определить отсутствие объекта и проинформировать об этом клиента. Служба каталогов Active Directory возвращает ссылки в соответствии с тем, как это определено в документе RFC 2251.
RootDSE
RootDSE является вершиной логического пространства имен и, к тому же, вершиной дерева, по которому осуществляется поиск с помощью LDAP. Атрибуты rootDSE определяют оба раздела каталога (домен, схему и настройки разделов каталога), которые являются особыми для отдельно взятого контроллера домена и для леса раздела каталога корневого домена.
RootDSE публикует информацию о сервере LDAP, включая информацию о том, какую версию LDAP он поддерживает, поддерживаемые механизмы SASL и механизмы управления, точно так же, как и различающееся имя для его записи подсхемы.
Клиенты подсоединяются к rootDSE, в начале работы по LDAP.
LDAP поверх TCP
Сообщения протокола LDAP PDU (Protocol Data Units) включаются непосредственно в поток данных, передаваемый по протоколу TCP. В документе RFC 2251 определена рекомендация, согласно которой на сервере устанавливается служба, прослушивающая назначенный порт 389. Служба каталогов Active Directory по умолчанию использует порт 389 для связи с контроллерами домена. Кроме этого служба каталогов Active Directory поддерживает порт 636 для защищенной связи по протоколу LDAP с применением SSL (Secure Sockets Layer). Контроллер домена Windows 2000, выступающий в роли сервера глобального каталога (Global Catalog, GC) будет использовать порт 3268 для связи по протоколу LDAP и порт 3269 - для защищенной связи по протоколу LDAP с использованием SSL.
Использование протокола LDAP при загрузке и входе в систему
Протокол LDAP широко используется во время процесса загрузки Windows 2000 и входа в систему. Клиент использует LDAP во время процесса поиска контроллера домена, необходимого для определения того контроллера домена, который он будет использовать. Протокол LDAP также используется для поиска применимых к компьютеру или пользователю объектов групповой политики. Наконец, протокол LDAP используется во время процесса автоматической подачи заявки для обнаружения подходящих сертификатов для клиента.
Для получения дополнительной информации обратитесь к следующим материалам:
| • | Документация Windows 2000 Resource Kit. |
| • | Техническое руководство по Active Directory ОС Windows 2000 (Windows 2000 Active Directory Technical Reference) (EN) |
| • | Документы RFC: 1777, 1778, 1779, 1959, 1960, 1823. |
| • | Документы RFC: 2251-2256. |
Протокол SMB
Протокол SMB (Server Message Block) – это протокол, обеспечивающий совместное использование ресурсов в сетях MS-Net, LAN Manager и Windows. Также имеются соответствующие решения для OS/2, Netware, VMS и Unix-систем, разработанные такими производителями, как AT&T, HP, SCO, а при использовании Samba – свыше 33 других. Протокол SMB используется в среде клиент-сервер для обеспечения доступа к файлам, принтерам, почтовым ячейкам (mail slots), именованным каналам (named pipes) и интерфейсам прикладного программирования (Application programming interface, API). Он был совместно разработан компаниями Microsoft, IBM и Intel в середине 80-х годов. Как показано ниже на рисунке, SMB может использоваться поверх нескольких сетевых протоколов:
Увеличить рисунок
При установлении SMB-соединения с сервером клиент сначала согласовывает диалект (разновидность протокола SMB, которую они будут использовать). После того, как клиент установил соединение, он может отсылать серверу SMB-команды, позволяющие ему получить доступ к ресурсам.
В основном все SMB-команды можно отнести к четырем категориям:
| • | Команды для управления сессией. |
| • | Команды для работы с файлами. |
| • | Команды управления печатью. |
| • | Команды для работы с сообщениями. |
Безопасность протокола SMB развивалась параллельно с развитием тех платформ, которые использовали данный протокол. В базовой модели протокола SMB определены два уровня безопасности:
| • | Уровень общих ресурсов. В данном случае защита осуществляется на уровне общих ресурсов сервера. Для получения доступа к каждому общему ресурсу необходим пароль. При этом только тот клиент, которому он известен, сможет получить доступ ко всем файлам, доступным на этом общем ресурсе. Эта модель безопасности была первой, которая применялась в протоколе SMB, и она же являлась единственной моделью безопасности доступной в протоколах Core и CorePlus. В Windows для рабочих групп (Windows for Workgroups) vserver.exe по умолчанию применяла этот уровень безопасности, точно так же его использовала ОС Windows 95. |
| • | Пользовательский уровень. В данном случае защита применяется отдельно для каждого файла каждого общего ресурса и основана на правах доступа пользователей. Каждый пользователь (клиент) должен войти на сервер под своей учетной записью и пройти аутентификацию. После завершения проверки подлинности клиент получает соответствующий идентификатор пользователя (user ID), который он должен предъявлять для получения доступа к ресурсам сервера. Такая модель безопасности была впервые реализована в протоколе LAN Manager 1.0. |
Протокол SMB неоднократно изменялся. Самой последней версией протокола SMB является протокол CIFS (Common Internet File System) ОС Windows 2000, который является незначительно измененным вариантом протокола NT LM 0.12, использовавшимся ранее. В следующем разделе детально описывается последняя реализация протокола SMB.
Поддержка протокола SMB через протокол CIFS в Windows 2000
Протокол CIFS является стандартным решением, с помощью которого пользователи сети Windows могут совместно использовать файлы в корпоративных интрасетях и сети Интернет. CIFS является расширенной версией протокола SMB. Протокол CIFS является открытой, кроссплатформенной реализацией протокола SMB, который в настоящее время является черновым вариантом интернет-стандарта. Впервые протокол CIFS был представлен в пакете обновлений SP3 для ОС Windows NT 4.0 и является „родным” протоколом совместного использования файлов для ОС Windows 2000. CIFS является одним из вариантов протокола NTLM 0.12.
Реализация протокола SMB/CIFS в Windows 2000
В протоколе CIFS определен ряд команд, используемых для обеспечения передачи данных между компьютерами, работающими в сети. Система переадресации формирует запросы к удаленным компьютерам в соответствии со стандартами протокола CIFS. CIFS-команды можно пересылать по сети к удаленным устройствам. Система переадресации также использует CIFS для обращения к стеку протокола локального компьютера. CIFS-сообщения можно классифицировать следующим образом:
| • | Сообщения установления соединения (Connection establishment messages) состоят из команд, которыми начинается и заканчивается соединение системы перенаправление с общим ресурсом на сервере. |
| • | Сообщения пространства имен (Namespace messages) и сообщения манипулирования файлами (File Manipulation messages) используются системой переадресации для получения доступа к файлам на сервере, а также открытия их для чтения и записи. |
| • | Сообщения принтера (Printer messages) используется системой переадресации для отправки данных в очередь печати на сервере, а также для получения информации о состоянии очереди печати. |
| • | Различные сообщения (Miscellaneous messages) используются системой переадресации для записи в почтовые ячейки (mail slots) и именованные каналы (named pipes). |
В ОС Windows 2000 протокол CIFS поддерживает распределенные реплицируемые виртуальные тома (например, распределенную файловую систему (Distributed File System, DFS)), блокировку файлов и записей, уведомление об изменении фалов, операции чтения с опережением и записи после выполнения операции. CIFS-соединения устанавливаются поверх стандартной SMB-сессии и механизма разрешения адресов.
Работа по протоколам SMB/CIFS в Windows 2000
Когда приходит запрос на открытие общего файла, система ввода/вывода запрашивает систему переадресации, которая, в свою очередь, запрашивает систему переадресации о выборе подходящего транспортного протокола. Для запросов NetBIOS эти пакеты инкапсулируются в пакеты IP-протокола и доставляются через сеть соответствующему серверу. Сервер получает запрос и отсылает в ответ на него данные.
В ОС Windows NT 4.0 при разрешении имен с помощью службы WINS (Windows Internet Name Service) и службы DNS (Domain Name System) использовался порт 134 протокола TCP. Благодаря расширениям, внесенным в CIFS и NetBT, теперь имеется возможность устанавливать прямые соединения поверх протокола TCP/IP, используя порт 445 протокола TCP. При этом все еще можно использовать оба механизма разрешения адресов в ОС Windows 2000. Имеется также возможность отключить одну из этих служб или обе, путем внесения соответствующих изменений в реестр.
Использование протокола SMB во время загрузки и входа в систему
Протокол SMB используется клиентом ОС Windows 2000 во время загрузки и входа в систему для загрузки объектов групповой политики, соответствующих этой рабочей станции или пользователю. Основной SMB-операцией, которая будет рассмотрена для процессов запуска и входа в систему, будет согласование SMB-диалекта. Этот процесс представляет собой обмен данными между клиентом и сервером с целью определения того, какой из SMB-диалектов они будут использовать. Протокол SMB также используется при создании ссылок DFS на общие ресурсы, к которым предоставляется доступ. Основной составляющей SMB-трафика, генерируемого во время процесса загрузки и входа в систему, будут объекты групповой политики, загружаемые клиентом.
Для получения дополнительной информации обратитесь к:
| • | Техническому руководству: Протоколы стека TCP/IP и службы Windows 2000 (Windows 2000 TCP/IP Protocols and Services Technical Reference) (EN). |
Удаленный вызов процедур MSRPC
В качестве самого простого примера того, что такое RPC, можно привести ситуацию, когда один компьютер запрашивает другой компьютер о возможности использования его вычислительной мощности. Протокол RPC позволяет одному процессу запрашивать другой процесс, запущенный на другом компьютере в сети, о возможности им выполнения инструкций первого процесса.
В процессе RPC задействованы:
| • | Клиентское приложение. Подает запрос на удаленное выполнение. |
| • | Клиентский суррогат (Client stub). Преобразует вызовы в/из стандартного формата NDR. |
| • | Client RPC Runtime Library. Преобразует NDR в сетевые сообщения. Транспортный протокол управляет соединениями в сети. |
| • | Server RPC Runtime Library. Преобразует NDR в сетевое сообщение. |
| • | Серверный суррогат (Server stub). Преобразует вызовы в/из стандартного формата NDR. |
| • | Серверное приложение. Выполняет требуемые инструкции. |
RPC однозначно определяются по номеру интерфейса (UUID), номеру операции (opnum) и номеру версии. Номер интерфейса определяет группу связанных удаленных процедур. Примером интерфейса может выступить служба сетевого входа, у которой UUID имеет значение 12345678-1234-ABCD-EF00-01234567CFFB.
Пример вызова RPC:
MSRPC: c/o RPC Bind: UUID 12345678-1234-ABCD-EF00-01234567CFFB call 0x1
assoc grp 0x0 xmit 0x16D0 recv 0x16D0
MSRPC: Version = 5 (0x5)
MSRPC: Version (Minor) = 0 (0x0)
MSRPC: Packet Type = Bind
+ MSRPC: Flags 1 = 3 (0x3)
MSRPC: Packed Data Representation
MSRPC: Fragment Length = 72 (0x48)
MSRPC: Authentication Length = 0 (0x0)
MSRPC: Call Identifier = 1 (0x1)
MSRPC: Max Trans Frag Size = 5840 (0x16D0)
MSRPC: Max Recv Frag Size = 5840 (0x16D0)
MSRPC: Assoc Group Identifier = 0 (0x0)
+ MSRPC: Presentation Context List
RPC не зависит от низкоуровневых транспортных протоколов. Microsoft RPC (MSRPC) может использовать несколько различных транспортных протоколов, таких как TCP/IP, IPX/SPX или NetBEUI.
Большинство интерфейсов RPC используют динамические порты для связи в сети. В этом случае возникает необходимость использовать особый интерфейс, называемый сопоставителем конечных точек (End Point Mapper). Этот интерфейс всегда прослушивает порт 135 для TCP/IP-соединений и имеет номер UUID E1AF8308-5D1F-11C9-91A4- 08002B14A0FA.
Прежде чем клиент сможет вызвать процедуры, он должен осуществить привязку к интерфейсу. В том случае, если удалось установить привязку, он может выслать запрос к сопоставителю конечных точек (End Point Mapper), в котором будет указан UUID необходимого интерфейса. Сопоставитель конечных точек возвращает номер порта, который клиент может использовать для соединения.
В следующей таблице указана последовательность пакетов, которыми обмениваются стороны, участвующие в этом процессе:
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | MSRPC | c/o RPC-привязка: UUID E1AF8308- |
| 2 | Сервер | Клиент | MSRPC | c/o RPC-привязка Ack: call 0x1 assoc |
| 3 | Клиент | Сервер | MSRPC | c/o RPC-запрос: call 0x1 opnum |
| 4 | Сервер | Клиент | MSRPC | c/o RPC-ответ: call 0x1 |
Также можно инкапсулировать пакеты MSRPC в SMB. В данном случае клиент и сервер для обмена данными используют дескриптор ранее открытого файла.
Процессы загрузки и входа в систему Windows 2000 используют интерфейсы сетевого входа в систему (Netlogon) и службы репликации каталога (Directory Replication Service, DRS). Интерфейс Netlogon используется в домене для установления защищенного канала между клиентом и контроллером домена. Служба DRS в первую очередь используется для связи контроллеров домена с серверами глобального каталога. Тем не менее, она также предоставляет интерфейс, который используется во время процесса входа в систему. Служба DRS обеспечивает преобразование имен к формату, который может использоваться в протоколе LDAP.
Для получения дополнительной информации обратитесь к следующим материалам:
| • | Раздел «Сетевой трафик, генерируемый клиентом в Active Directory» книги Организация служб предприятия Active Directory: заметки на полях ("Active Directory Client Network Traffic," Notes from the Field BuildingEnterprise Active Directory Services) (EN) |
| • | Статья 159298 раздела TechNet: Анализ RPC-трафика TCP/IP ("Analyzing Exchange RPC Traffic Over TCP/IP [159298]" on TechNet) (EN) |
Служба времени
В состав Windows 2000 входит служба времени W32Time (Windows Time), предоставляющая механизм синхронизации системного времени в домене между клиентами Windows 2000. Синхронизация времени происходит во время процесса загрузки компьютера.
Для выполнения синхронизации используется следующая иерархия систем в домене:
| • | Все клиентские настольные компьютеры используют в качестве источника времени свой контроллер домена. |
| • | Все рядовые серверы используют тот же источник, что и клиентские настольные компьютеры. |
| • | Все контроллеры домена используют Хозяев операций (Operations Masters) первичного контроллера домена (Primary domain controller, PDC) в качестве источника синхронизации. |
| • | При выборе источника синхронизации хозяева операций первичного контроллера домена руководствуются иерархией доменов. |
Примечание. Хозяева операций описываются в Главе 7 «Руководство по распределенным системам» документации Windows 2000 Server Resource Kit (Distributed Systems Guide Windows 2000 Server Resource Kit) (EN).
Для получения дополнительной информации обратитесь к следующим материалам:
| • | Статья 216734, в которой описывается процесс синхронизации времени, а также выбор авторизованного источника времени. |
| • | Документы RFC: 1769, 2030. |
Методы проверки подлинности в домене Windows 2000
В ОС Windows 2000 поддерживаются два разных метода проверки подлинности при входе в домен: Kerberos и NTLM. Использование Kerberos в качестве протокола аутентификации в ОС Windows 2000 изменяет используемый по умолчанию Windows протокол NTLM на протокол, использующий стандарты сети Интернет.
Протокол проверки подлинности, используемый по умолчанию в ОС Windows 2000, основан на протоколе Kerberos версии 5. Этот протокол разработан Массачусетским технологическим институтом (Massachusetts Institute of Technology, MIT) и описан в документе RFC 1510. Использование протокола Kerberos при проверке подлинности полностью изменяет способ обмена данными безопасности между клиентами, серверами и контроллерами домена в сети Windows.
При использовании протокола Kerberos клиенты запрашивают у центра распространения ключей (Key Distribution Center, KDC) так называемые билеты сеанса. Билеты сеанса содержат информацию, которую может использовать сервер для проверки того, может ли клиент пройти проверку подлинности на данном сервере. Затем клиент использует эти билеты при проверке подлинности для получения доступа к необходимым ему ресурсам. Kerberos обеспечивает только перенос необходимой для проверки подлинности информации от клиента к тому ресурсу, к которому он пытается получить доступ. Kerberos не обеспечивает авторизацию для получения доступа к ресурсам. Он только осуществляет перенос информации, необходимой для авторизации, к системам.
В целях обеспечения совместимости со старыми системами в ОС Windows 2000 оставлена возможность использования NTLM-аутентификации. Клиенты Windows 2000 будут использовать протокол NTLM для проверки подлинности в том случае, если они работают в домене, основанном не на ОС Windows 2000, в качестве члена домена NT 4 или рабочей группы, а также в том случае, если необходимо работать со старыми приложениями, использующими протокол NTLM при проверке подлинности.
Далее более подробно будет рассмотрен протокол проверки подлинности Kerberos, а также будет рассмотрено его использование во время загрузки и входа в систему. Протокол NTLM, используемый при запуске и входе в систему, остался таким же, как и в Windows NT 4.0. Он подробно описан в книге Организация служб предприятия Active Directory: полевые заметки (Notes from the Field series book Building Enterprise Active Directory Services) (EN).
Для получения дополнительной информации обратитесь к следующему документу:
| • | «Руководство по распределенным системам» документации Windows 2000 Resource Kit (Windows 2000 Resource Kit: Authentication; Distributed Systems Guide). |
Описание процесса загрузки и входа в систему 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 байтов для последовательности, используемой для проверки адреса.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | *широковещательный пакет (*BROADCAST) | DHCP | Команда обнаружения «Discover» |
| 2 | Сервер | *широковещательный пакет (*BROADCAST) | DHCP | Команда предложения «Offer» |
| 3 | Клиент | *широковещательный пакет (*BROADCAST) | DHCP | Команда запроса «Request» |
| 4 | Сервер | *широковещательный пакет (*BROADCAST) | DHCP | Команда подтверждения «ACK» |
| 5 | Клиент | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Запрос, IP-адрес получателя: |
| 6 | Клиент | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Запрос, IP-адрес получателя: |
| 7 | Клиент | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Запрос, IP-адрес получателя: |
| 8 | Сервер | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Ответ, IP-адрес получателя: |
Необходимо отметить то, что если клиенту уже был выделен адрес, то при перезагрузке он будет обновлен DHCP-сервером. Для обновления будут использоваться только два пакета: пакет запроса (Request) и пакет подтверждения (Ack), указанные ниже в таблице в первых двух строках. При том клиент будет использовать RARP, чтобы убедиться в том, что его адрес никто не использует.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | *широковещательный пакет (*BROADCAST) | DHCP | Команда запроса «Request» |
| 2 | Сервер | *широковещательный пакет (*BROADCAST) | DHCP | Команда подтверждения «ACK» |
| 3 | Клиент | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Запрос, IP-адрес получателя: |
| 4 | Клиент | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Запрос, IP-адрес получателя: |
| 5 | Клиент | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Запрос, IP-адрес получателя: |
| 6 | Сервер | *широковещательный пакет (*BROADCAST) | ARP_RARP | ARP: Ответ, IP-адрес получателя: |
Обнаружение контроллера домена
Клиентскому компьютеру необходимо получать самую последнюю информацию о конфигурации сети во время каждой фазы загрузки. Поэтому он должен обнаружить хотя бы один контроллер домена в своем домене.
В домене Windows 2000 каждый контроллер домена также является LDAP-сервером. Для получения списка доступных контроллеров домена клиенту необходимо запросить у DNS SRV-записи источников с именем
_ldap._tcp.dc._msdcs.DnsDomanName .
Ниже в таблице представлен обмен пакетами, происходящий при этом процессе:
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | DNS | 0x1:Std Qry for |
| 2 | Сервер | Клиент | DNS | 0x1:Std Qry Resp. for |
Домен Windows 2000 является некой административной границей, которая не зависит от структуры имеющейся сети. Компьютеры в сетевом окружении могут быть объединены в сайты. Сайт в Windows 2000 представляет собой набор IP-подсетей, использующих быстрое, надежное соединение друг с другом. На практике сети LAN или сети, имеющие более быстрое соединение, рассматриваются как сети с высокой пропускной способностью, достаточной для организации сайта на их основе. Домен может охватывать несколько сайтов, кроме того, один сайт может входить в состав нескольких доменов.
Увеличить рисунок
Во время запуска клиентского компьютера служба локатора (locator service) пытается обнаружить ближайший сайт и сохранить его имя в реестре. Если клиенту известно, к какому сайту он принадлежит, то он может запросить у DNS-сервера данные о контроллерах домена его сайта. Формат такого запроса следующий:
_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DnsDomanName
Ниже приводится последовательность пакетов, обмен которыми происходит во время этого процесса.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | DNS | 0x1:Std Qry for _ldap._tcp.Default- |
| 2 | Сервер | Клиент | DNS | 0x1:Std Qry Resp. for |
Ниже представлен процесс поиска клиентом службы 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
on class INET addr.(2 records present)
DNS: Resource Record: dcclab22.dcclab.local. of type Host Addr on class INET addr.
DNS: Resource Record: dcclab21.dcclab.local. of type Host Addr on class INET addr.
Клиент случайным образом выбирает один контроллер домена для дальнейшего взаимодействия, при этом он не делает различия между локальными и удаленными подсетями, поскольку считает, что каждый член сайта является компьютером, расположенным на достаточно близком расстоянии от него.
Как было ранее отмечено, имеется возможность выбора контроллера домена в виде концепции сайта. После обнаружения контроллера домена клиент с помощью LDAP-запросов пытается определить, является ли данный контроллер наиболее близким.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 2 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (4) |
| 3 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 4 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (4) |
Клиент осуществляет поиск по следующим атрибутам, которые он указывает в своем запросе:
| • | DNS-имя домена. |
| • | Имя узла. |
| • | Глобальный уникальный идентификатор домена (Domain GUID). |
| • | Идентификатор безопасности домена (Domain SID). |
В том случае, если данные контроллера домена совпадает с той информацией, что указана в базе данных Active Directory для него, он отсылает назад следующую информацию о себе:
| • | DomainControllerName |
| • | DomainControllerAddress |
| • | DomainControllerAddressType |
| • | DomainGUID |
| • | DomainName |
| • | DNSForestName |
| • | DCSiteName |
| • | ClientSiteName |
Наиболее важной для клиента информацией является имя сайта. В шестнадцатеричном дампе ответа, полученного от сервера, будет содержаться только одно имя сайта в том случае, если клиент является членом сайта, к которому принадлежит контроллер домена:
00000: 00 A0 C9 F1 A0 00 00 01 02 33 BF E7 08 00 45 00 . ....3..E.
00010: 00 D4 E9 90 00 00 80 11 00 00 0A 00 00 16 0A 00 ._...........
00020: 00 18 01 85 04 04 00 C0 B6 57 30 84 00 00 00 9C ......[para]W0...
00030: 02 01 02 64 84 00 00 00 93 04 00 30 84 00 00 00 ...d..."..0...
00040: 8B 30 84 00 00 00 85 04 08 6E 65 74 6C 6F 67 6F 0.....netlogo
00050: 6E 31 84 00 00 00 75 04 73 17 00 00 00 FD 01 00 n1...u.s......
00060: 00 48 44 82 88 4E 79 85 47 A8 CA 16 1D 55 23 B2 .HDNyG..U#
00070: E0 06 64 63 63 6C 61 62 05 6C 6F 63 61 6C 00 C0 .dcclab.local.
00080: 18 08 64 63 63 6C 61 62 32 32 C0 18 06 44 43 43 ..dcclab22..DCC
00090: 4C 41 42 00 08 44 43 43 4C 41 42 32 32 00 09 44 LAB..DCCLAB22..D
000A0: 43 43 4C 41 42 32 34 24 00 17 44 65 66 61 75 6C CCLAB24$..Defaul
000B0: 74 2D 46 69 72 73 74 2D 53 69 74 65 2D 4E 61 6D t-First-Site-Nam
000C0: 65 00 C0 50 05 00 00 00 FF FF FF FF 30 84 00 00 e.P....0..
000D0: 00 10 02 01 02 65 84 00 00 00 07 0A 01 00 04 00 .....e.........
000E0: 04 00 ..
В случае, если клиент взаимодействует с контроллером домена, который не входит в сайт, членом которого является клиент, контроллер домена также в ответе указывает имя сайта, к которому принадлежит клиент:
00000: 00 20 78 E0 AA 2B 00 20 78 01 80 69 08 00 45 00 . x+. x.i..E.
00010: 00 C9 FD A8 00 00 7F 11 28 64 0A 00 00 16 0B 00 ....(d......
00020: 00 02 01 85 04 03 00 B5 C8 55 30 84 00 00 00 91 ......U0...'
00030: 02 01 01 64 84 00 00 00 88 04 00 30 84 00 00 00 ...d.....0...
00040: 80 30 84 00 00 00 7A 04 08 6E 65 74 6C 6F 67 6F 0...z..netlogo
00050: 6E 31 84 00 00 00 6A 04 68 17 00 00 00 7D 01 00 n1...j.h....}..
00060: 00 48 44 82 88 4E 79 85 47 A8 CA 16 1D 55 23 B2 .HDNyG..U#
00070: E0 06 64 63 63 6C 61 62 05 6C 6F 63 61 6C 00 C0 .dcclab.local.
00080: 18 08 64 63 63 6C 61 62 32 32 C0 18 06 44 43 43 ..dcclab22..DCC
00090: 4C 41 42 00 08 44 43 43 4C 41 42 32 32 00 0B 44 LAB..DCCLAB22..D
000A0: 43 43 52 4F 55 54 45 52 32 24 00 05 53 69 74 65 CCROUTER2$..Site
000B0: 32 00 05 53 69 74 65 31 00 05 00 00 00 FF FF FF 2..Site1.....
000C0: FF 30 84 00 00 00 10 02 01 01 65 84 00 00 00 07 0.......e....
000D0: 0A 01 00 04 00 04 00 .......
В этом случае клиент посылает еще один запрос DNS-серверу, с просьбой представить список контроллеров, входящих в этот сайт. Ниже представлена таблица, в которой представлен обмен пакетами, происходящий в такой ситуации. Клиент пытается отыскать контроллер домена в Сайте2 (Site2) и после LDAP-запросов он обращается к Сайту1 (Site1).
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | DNS | 0x1:Std Qry for |
| 2 | Сервер | Клиент | DNS | 0x1:Std Qry Resp. for |
| 3 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 4 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (4) |
| 5 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 6 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (4) |
| 7 | Клиент | Сервер | DNS | DNS 0x2:Std Qry for |
| 8 | Клиент | Сервер | DNS | 0x2:Std Qry Resp. for |
Нет необходимости в наличии контроллера домена в каждом сайте. Каждый контроллер домена проверяет все сайты в лесу и стоимость репликации. Контроллер домена регистрирует себя на всех сайтах, в которых нет контроллера домена, а также для которых стоимость репликации минимальна. Этот процесс также известен как автоматическое обслуживание сайта (automatic site coverage). Это означает, что клиенты будут использовать следующий контроллер домена, стоимость доступа к которому минимальна.
В процессе поиска ближайшего контроллера домена используются 10 сетевых пакетов, создающие трафик общим объемом приблизительно 2000 байтов.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | ARP_RARP | ICMP Эхо-запрос: от 10.00.00.24 к |
| 2 | Сервер | Клиент | ARP_RARP | ICMP Эхо-ответ: к 10.00.00.24 от |
| 3 | Клиент | Сервер | DNS | 0x1:Std Qry for _ldap._tcp.Default- |
| 4 | Клиент | Сервер | DNS | 0x2:Std Qry for _ldap._tcp.Default- |
| 5 | Сервер | Клиент | DNS | 0x1:Std Qry Resp. for |
| 6 | Сервер | Клиент | DNS | 0x2:Std Qry Resp. for |
| 7 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 8 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (4) |
| 9 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 10 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (4) |
| 11 | Клиент | Сервер | ARP_RARP | ICMP Эхо-запрос: от 10.00.00.24 к 10.00.00.22 |
| 12 | Клиент | Сервер | ARP_RARP | ICMP Эхо-ответ: к 10.00.00.24 от |
Более подробную информацию о процессе поиска домена можно получить из раздела «Разрешение имен в 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 байтов трафика.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | C согласование, диалект = NT LM 0.12 |
| 2 | Сервер | Клиент | SMB | R negotiate, Dialect # = 5 |
| 3 | Клиент | Сервер | MSRPC | c/o RPC-привязка: UUID E1AF8308-5D1F- |
| 4 | Сервер | Сервер | MSRPC | c/o RPC-привязка Ack: call 0x1 assoc |
| 5 | Клиент | Сервер | MSRPC | c/o RPC-запрос: call 0x1 opnum 0x3 |
| 6 | Сервер | Клиент | MSRPC | c/o RPC-ответ: call 0x1 |
| 7 | Клиент | Сервер | MSRPC | c/o RPC-привязка: UUID 12345678-1234- |
| 8 | Сервер | Клиент | MSRPC | c/o RPC-привязка Ack: call 0x1 assoc |
| 9 | Клиент | Сервер | R_LOGON | RPC-вызов клиента |
| 10 | Сервер | Клиент | R_LOGON | RPC-ответ сервера |
| 11 | Клиент | Сервер | R_LOGON | Ошибка: Bad Opcode (Функция не существует) |
| 12 | Сервер | Сервер | R_LOGON | Ошибка: Bad Opcode (Функция не существует) |
| 13 | Клиент | Клиент | MSRPC | c/o RPC-привязка: UUID 12345678-1234- |
| 14 | Сервер | Клиент | MSRPC | c/o RPC-привязка Ack: call 0x3 assoc |
| 15 | Клиент | Клиент | R_LOGON | Ошибка: Bad Opcode (Функция не существует) |
| 16 | Сервер | Клиент | R_LOGON | Ошибка: Bad Opcode (Функция не существует) |
Примечание. Текущая версия программы 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 байтов.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | DNS 0x3:Std Qry for |
| 2 | Сервер | Клиент | SMB | DNS 0x3:Std Qry Resp. for |
| 3 | Клиент | Сервер | LDAP | LDAP ProtocolOp: SearchRequest (3) |
| 4 | Сервер | Сервер | LDAP | LDAP ProtocolOp: SearchResponse (4) |
| 5 | Клиент | Сервер | Kerberos | Kerberos KRB_AS_REQ (запрос |
| 6 | Сервер | Клиент | Kerberos | Kerberos KRB_AS_REP |
| 7 | Клиент | Сервер | Kerberos | Kerberos KRB_TGS_REQ (запрос |
| 8 | Сервер | Клиент | Kerberos | Kerberos KRB_TGS_REP |
| 9 | Клиент | Сервер | R_LOGON | Kerberos KRB_TGS_REQ (запрос |
| 10 | Сервер | Клиент | R_LOGON | Kerberos KRB_TGS_REP |
Все билеты, получаемые клиентом, можно просмотреть с помощью утилиты Kerbtray из пакета Microsoft Resource Kit.
В итоге клиент может подключиться к общему ресурсу IPC$ контроллера, при этом будет сгенерированно приблизительно 3,600 байтов трафика.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | SMB C настройка сеанса & X |
| 2 | Сервер | Клиент | SMB | SMB R настройка сеанса & X |
| 3 | Клиент | Сервер | SMB | SMB C подключение дерева & X, Общий ресурс = \\DCCLAB22.DCCLAB.LOCAL\IPC$ |
| 4 | Сервер | Клиент | SMB | SMB R подключение дерева & X, Тип = IPC$ |
Ссылки 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 минут для определения конфигурации домена.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | C transact2 NT Получить DFS-ссылку |
| 2 | Сервер | Клиент | SMB | R transact2 NT Получить DFS-ссылку (ответ на пакет 105) |
Затем клиент выполняет команду ping и отправляет LDAP-запрос для того, чтобы снова получить информацию о контроллере домена.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | ICMP | Эхо-запрос: от 10.00.00.100 к 10.00.00.22 |
| 2 | Сервер | Клиент | ICMP | Эхо-ответ: к 10.00.00.100 от |
| 3 | Клиент | Сервер | UDP | Src порт: неизвестен, (1041); Dst порт: |
| 4 | Сервер | Клиент | UDP | Src порт: неизвестен, (389); Dst порт: неизвестен |
Преобразование имен
У каждого объекта в Active Directory есть соответствующее имя. Имеются различные форматы имен, такие, как основное имя пользователя (User principal name, UPN), различаемые имена (Distinguished names, DN), а также ранние имена «домен\пользователь» ("domain\user") из Windows NT. Вовсе не обязательно, чтобы имя было строковой записью. В качестве имени может выступать все, что уникальным образом идентифицирует объект. В зависимости от того, какой службе требуется указать имя в качестве параметра, может понадобиться преобразование имени из одного формата в другой.
Для преобразования имен из одного формата в другой используется API DsCrackNames. Более подробную информацию об этом можно найти в MSDN (Microsoft Developers Network). Перед тем, как клиент сможет воспользоваться этой функцией, ему необходимо будет выполнить привязку дескриптора к службе каталогов с помощью команды DSBind, а по завершении выполнения операции ему необходимо отменить привязку к службе каталогов с помощью DSUnbind.
Ниже в таблице представлен обмен пакетами, происходящий во время процесса трансляции. Общий объем трафика, генерируемого при этом, составляет приблизительно 6600 байтов.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | MSRPC | c/o RPC-привязка: UUID E1AF8308-5D1F- |
| 2 | Сервер | Клиент | MSRPC | c/o RPC-привязка Ack: call 0x1 assoc |
| 3 | Клиент | Сервер | MSRPC | c/o RPC-запрос: call 0x1 opnum 0x3 |
| 4 | Сервер | Клиент | MSRPC | c/o RPC-ответ: call 0x1 context |
| 5 | Клиент | Сервер | MSRPC | c/o RPC-привязка: UUID E3514235-4B06- |
| 6 | Сервер | Клиент | MSRPC | c/o RPC-привязка Ack: call 0x1 assoc |
| 7 | Клиент | Сервер | MSRPC | c/o RPC Alt-Cont: UUID E3514235- |
| 8 | Сервер | Клиент | MSRPC | c/o RPC Alt-Cont Rsp: call 0x1 |
| 9 | Клиент | Сервер | MSRPC | c/o RPC-запрос: call 0x1 opnum 0x0 |
| 10 | Сервер | Клиент | MSRPC | c/o RPC-ответ: call 0x1 context |
| 11 | Клиент | Сервер | MSRPC | c/o RPC-запрос: call 0x2 opnum 0xC |
| 12 | Сервер | Клиент | MSRPC | c/o RPC-ответ: call 0x2 context |
| 13 | Клиент | Сервер | MSRPC | c/o RPC-запрос: call 0x3 opnum |
| 14 | Сервер | Клиент | MSRPC | c/o RPC-ответ: call 0x3 context |
| 15 | Клиент | Сервер | MSRPC | c/o RPC-запрос: call 0x4 opnum 0x1 |
| 16 | Сервер | Клиент | MSRPC | c/o RPC-ответ: call 0x4 context |
LDAP RootDSE
Затем клиент запрашивает информацию из LDAP RootDSE. RootDSE является стандартным атрибутом, определенным в спецификации LDAP 3.0. RootDSE содержит информацию о сервере каталога, включая информацию о его характеристиках и конфигурации. Ответ будет содержать стандартный набор данных в соответствии с документом RFC 2251. Одним из элементов, который будет возвращен в этом ответе, будет поддерживаемый механизм Simple Authentication и Security Layer (SASL). В этом случае возвращается GSS-SPNEGO.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 2 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (4) |
| 3 | Клиент | Сервер | Kerberos | KRB_TGS_REQ |
| 4 | Сервер | Клиент | Kerberos | KRB_TGS_REP |
| 5 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
| 6 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
Загрузка групповой политики
Затем на компьютер загружаются соответствующие объекты групповой политики. После этого клиент завершает вызов RPC, необходимый для преобразования его имени в различающееся имя, и выполняет с помощью протокола LDAP поиск информации политики, необходимой для данного компьютера, а затем загружает ее с помощью протокола SMB (Server Message Block).
Поиск политики
Ниже в таблице представлен обмен пакетами, происходящий, когда клиент выполняет операцию привязки дескриптора к каталогу LDAP. Для выполнения LDAP-запросов необходимо, чтобы клиент установил привязку дескрипторов к службе каталогов до того, как начнет поиск информации. На этом этапе процесса входа в систему клиента он выполняет привязку дескриптора к Active Directory для того, чтобы осуществить поиск групповой политики, которую необходимо применить к клиенту. В приведенной ниже последовательности пакетов также отображен LDAP-запрос клиента для определения того, какую групповую политику необходимо применить. Каждая операция привязки дескриптора генерирует трафик объемом около 1675 байтов. В этом случае при поиске политики генерируется около 3527 байтов сетевого трафика.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
| 2 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
| 3 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
| 4 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
| 5 | Клиент | Сервер | TCP | .AP..., len: 173, seq: 978423034- |
| 6 | Сервер | Клиент | TCP | AP..., len: 294, seq:3068556899- |
| 7 | Клиент | Сервер | TCP | ....S., len: 0, seq: 978497639- |
| 8 | Сервер | Клиент | TCP | .A..S., len: 0, seq:3068641675- |
| 9 | Клиент | Сервер | TCP | .A...., len: 0, seq: 978497640- |
| 10 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
| 11 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
| 12 | Клиент | Сервер | TCP | .AP..., len: 129, seq: 978498933- |
| 13 | Сервер | Клиент | TCP | .AP..., len: 171, seq:3068642008- |
| 14 | Клиент | Сервер | TCP | .AP..., len: 203, seq: 978499062- |
| 15 | Сервер | Клиент | TCP | .AP..., len: 201, seq:3068642179- |
| 16 | Клиент | Сервер | TCP | .AP..., len: 467, seq: 978423207- |
| 17 | Сервер | Клиент | TCP | .AP..., len: 1273, seq:3068557193- |
После того, как клиент определяет подходящую политику, он создает вторую DFS-ссылку. То же самое будет происходить в большинстве других случаев при попытках клиента соединиться с общим ресурсом Windows 2000.
Загрузка политик по протоколу SMB
Процесс завершается соединением клиента с SYSVOL (стандартным общим ресурсом контроллера домена) и загрузкой политик, что приводит к генерированию трафика общим объемом 1018 байтов.
В данном случае приведен пример очень простой конфигурации. Количество записей, показанных на рисунке, будет значительно больше, в случае более сложных настроек групповой политики.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | C подключение дерева & X, Общий ресурс = \\DCCLAB22.MAIN.LOCAL\SYSVOL |
| 2 | Сервер | Клиент | SMB | R подключение дерева & X, Тип = _ |
| 3 | Клиент | Сервер | SMB | C NT создание & X, Файл = \main.local\Policies\{31B2F340-016D- |
| 4 | Сервер | Клиент | SMB | R NT создание & X, FID = 0x4000 |
| 5 | Клиент | Сервер | SMB | C чтение & X, FID = 0x4000, чтение 0x1a |
| 6 | Сервер | Клиент | SMB | R чтение & X, чтение 0x1a |
Автоматическая подача заявок на сертификаты клиента
Каждый раз после применения объектов групповой политики происходит автоматическая подача заявок на сертификаты. Во время этого процесса происходит следующее:
| • | Выполняется проверка статуса сертификатов компьютера. Если имеются проблемы с сертификатами, то выполняется автоматическая подача заявки. |
| • | Выполняется загрузка сертификатов центра сертификации предприятия из корневого хранилища предприятия в Active Directory (процесс известен так же, как доверительная привязка инфраструктуры открытых ключей (PKI trust anchor)). |
| • | Выполняется загрузка сертификатов центра сертификации, способного выдавать сертификаты смарт-карт из Active Directory. |
Клиент подает запрос для получения информации LDAP RootDSE (ниже в таблице приведен обмен пакетами), а затем использует LDAP для завершения процесса автоматической подачи заявки.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | DNS | DNS 0x3:Std Qry for |
| 2 | Сервер | Клиент | DNS | DNS 0x3:Std Qry Resp. Auth. NS is |
| 3 | Клиент | Сервер | DNS | DNS 0x4:Std Qry for |
| 4 | Сервер | Клиент | DNS | DNS 0x4:Std Qry Resp. Auth. NS is |
| 5 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
| 6 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
| 7 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
| 8 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
| 9 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 10 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (simple) (5) |
| 11 | Клиент | Сервер | LDAP | ProtocolOp: UnbindRequest (2) |
| 12 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
| 13 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
| 14 | Клиент | Сервер | LDAP | ProtocolOp: SearchRequest (3) |
| 15 | Сервер | Клиент | LDAP | ProtocolOp: SearchResponse (simple) (5) |
| 16 | Клиент | Сервер | LDAP | ProtocolOp: UnbindRequest (2) |
| 17 | Клиент | Сервер | LDAP | ProtocolOp: UnbindRequest (2) |
Более подробное рассмотрение третьего пакета показывает, что этот пакет является запросом на получение информации о конфигурации служб открытых ключей, используемых в домене. Ниже показано содержимое одного из пакетов:
LDAP: ProtocolOp: SearchRequest (3)
LDAP: ProtocolOp = SearchRequest
LDAP: Base Object = CN=Public Key
Services,CN=Services,CN=Configuration,DC=dcclab,DC
LDAP: Scope = Single Level
LDAP: Deref Aliases = Never Deref Aliases
LDAP: Size Limit = No Limit
LDAP: Time Limit = 0x00002710
LDAP: Attrs Only = 0 (0x0)
LDAP: Filter Type = Equality Match
LDAP: Attribute Type = cn
LDAP: Attribute Value = NTAuthCertificates
LDAP: Attribute Value = cACertificate
Синхронизация времени
Затем происходит обновление времени на клиентском компьютере, путем синхронизации с контроллером домена, выполняющим проверку подлинности. Ниже представлен обмен пакетами, соответствующий этому процессу синхронизации. Примите во внимание то, что при этом используется порт 123. Общий объем сетевого трафика, генерируемого при этом, равен 220 байтов.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | NTP | Src порт: неизвестен, (1051); Dst порт: протокол NTP (Network Time Protocol) (123); длина = 76 (0x4C) |
| 2 | Сервер | Клиент | NTP | Src порт: протокол NTP (Network Time Protocol), (123); Dst порт: Неизвестен (1051); длина = 76 (0x4C) |
Обновление системы DDNS
На последнем этапе процесса загрузки происходит обновление имени клиента в базе данных DNS. Процесс динамического обновления записей DNS в Windows 2000 основан на процедурах, описанных в документе RFC 2136.
Вначале клиент определяет, имеется ли у DNS-сервера центр, обслуживающий зону клиента. При этом генерируется сетевой трафик общим объемом 225 байтов.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | DNS | 0x1:Std Qry for dcclab24.main.local. |
| 2 | Сервер | Клиент | DNS | 0x1:Std Qry Resp. Auth. NS is |
Затем клиент выполняет динамическое обновление своего имени на DNS-сервере. В случае, если обновляются как записи A RR, так и PTR RR клиента, то объем общего трафика, генерируемого при этом, будет равен 1800 байтов.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | DNS | DNS 0x4:Dyn Upd PRE records to |
| 2 | Сервер | Клиент | DNS | 241 99.703125 00010233BFE7 INTEL |
| 3 | Клиент | Сервер | DNS | DNS 0x5:Std Qry for 0.0.10.in- |
| 4 | Сервер | Клиент | DNS | 0x5:Std Qry Resp. for 0.0.10.in-addr.arpa. of type SOA |
| 5 | Клиент | Сервер | DNS | 0x6:Dyn Upd PRE/UPD records to 24.0.0.10.in- |
| 6 | Сервер | Клиент | DNS | 0x6:Dyn Upd Resp. PRE/UPD records to |
Реальный объем трафика, генерируемого при динамическом обновлении, зависит от многих условий. Прежде всего он зависит от того, был ли клиент уже зарегистрирован. Затем на него может влиять конфликт с уже имеющейся записью. Также учитывается и то, используется ли DHCP. В данном примере предполагается, что те настройки, которые используются по умолчанию, позволяют клиенту обновлять только свои записи A RR, в то время как за обновление записей PTR RR отвечает DHCP-сервер.
И последним, но не менее важным, является то, что объем трафика также зависит от конфигурации DNS-сервера и от того, каким образом настроено безопасное динамическое обновление.
Примечание. В случае, если DDNS не используется, Вам необходимо отключить функцию динамического обновления на клиенте. Отключение этой функции позволит сэкономить сетевой трафик, генерируемый бесполезными попытками произвести обновление притом, что оно не поддерживается. Динамическое обновление можно отключить в дополнительных свойствах TCP/IP для соответствующего сетевого соединения. Ниже на рисунке показано, где именно эта функция отключается:
Завершение
Процесс загрузки компьютера завершается, когда клиент разрывает открытые соединения с контроллером домена, обмениваясь пакетами, указанными ниже в таблице. При этом генерируется 473 байта сетевого трафика.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | C отключение дерева |
| 2 | Сервер | Клиент | SMB | R отключение дерева |
| 3 | Клиент | Сервер | SMB | C отключение дерева |
| 4 | Сервер | Клиент | SMB | R отключение дерева |
| 5 | Клиент | Сервер | SMB | C выход & X |
| 6 | Сервер | Клиент | SMB | R выход & X |
Зная эту последовательность обмена пакетами при анализе трафика можно определить завершение процесса загрузки системы и начало процесса входа пользователя в систему. Теперь система готова к использованию. На экране отображается окно входа в систему.
Вход пользователя в систему
Обзор
После завершения процесса загрузки на экране отображается окно входа в систему. Пользователь может выполнить вход в домен с этого компьютера. Нажатие комбинации клавиш Ctrl-Alt-Delete и ввод действующих учетных данных пользователя (имени пользователя и пароля) для входа в домен приводит к началу процесса интерактивного входа клиента, который заканчивается загрузкой оболочки Windows NT, после чего пользователь может начать интерактивное взаимодействие с системой. Важно отметить, что процесс входа пользователя в систему фактически является сокращенной версией процесса загрузки компьютера, поскольку использует ряд процессов, описанных ранее. Ниже приведена диаграмма, описывающая работу этого процесса:
Идентификация пользователя
Во время входа в систему Windows 2000 пользователю предоставляется три различных способа ввода информации об учетной записи. Первым способом является использование имени учетной записи, имеющейся в диспетчере учетных записей безопасности (Security Accounts Manager, SAM), и выбора домена. Этот способ входа в систему используется по умолчанию. Вторым способом является использование полного имени, которое выглядит как: @. Третьим способом является использование основного имени пользователя (User Principle Name, UPN), которое определяется в документации Windows 2000 Resource Kit следующим образом:
«Основное имя пользователя (User principal name, UPN) – это имя, формат которого напоминает адрес электронной почты и которое однозначно определяет пользователя. UPN состоит из двух частей: части, идентифицирующей пользователя, и доменной части. Обе части разделены символом "@". UPN выглядит как @, например, liz@noam.reskit.com. Каждому пользователю автоматически назначается по умолчанию UPN, где часть будет такой же, как и имя пользователя, используемое для входа в систему, а часть - DNS-имя домена Active Directory, в котором расположена учетная запись пользователя. В случае, если для входа в систему используется UPN, то пользователь не сможет выбрать домен из списка в диалоговом окне.
Вы можете указать для UPN произвольное значение. Например, даже если учетная запись пользователя Liz принадлежит домену noam.reskit.com, ее UPN может иметь значение liz@reskit.com. Во время входа пользователя в систему учетная запись пользователя проверяется путем поиска в глобальном каталоге учетной записи с таким значением UPN. Благодаря тому, что UPN являются независимыми от имени доменов, администраторы могут переносить пользователей из одного домена в другой, не изменяя значения UPN, тем самым, делая перемещение пользователей в домене незаметным для самих пользователей».
Использование протокола Kerberos для проверки подлинности пользователя во время его входа в систему
Во время входа пользователя в систему генерируется запрос на выполнение проверки подлинности по протоколу Kerberos для получения билета сеанса. Затем процесс входа в систему запрашивает ключ сеанса для службы у центра KDC с помощью службы Ticket Granting Service.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | Kerberos | KRB_AS_REQ |
| 2 | Сервер | Клиент | Kerberos | KRB_AS_REP |
| 3 | Клиент | Сервер | Kerberos | KRB_TGS_REQ |
| 4 | Сервер | Клиент | Kerberos | KRB_TGS_REP |
Во время процесса входа пользователя в систему запрашиваются следующие билеты:
| • | Kerberos: Server Name = $ |
| • | Kerberos: Server Name =$ |
| • | Kerberos: Server Name = krbtgt. |
| • | Kerberos: Server Name = ldap.. |
Как было отмечено ранее, размер Kerberos-пакетов зависит от количества групп, членом которых является пользователь.
Загрузка групповой политики
Процесс получения данных групповой политики аналогичен тому, что был описан ранее в разделе, посвященному процессу загрузки компьютера. Клиент использует "DS API DSCrackNames" для выполнения преобразования имен и получения информации о политиках с последующей загрузкой их по протоколу LDAP.
Во время входа в систему процессом входа запрашиваются следующие билеты:
Увеличить рисунок
Затем клиент устанавливает соединение с контроллером по протоколу SMB и загружает необходимые файлы политики.
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | C согласование, Диалект = NT LM 0.12 |
| 2 | Сервер | Клиент | SMB | R согласование, Диалект # = 5 |
| 3 | Клиент | Сервер | SMB | C настройка сеанса & X |
| 4 | Сервер | Клиент | SMB | R настройка сеанса & X |
| 5 | Клиент | Сервер | SMB | C подключение дерева & X, Общий ресурс = \\DCCLAB22.MAIN.LOCAL\SYSVOL |
| 6 | Сервер | Клиент | SMB | R подключение дерева & X, Тип = _ |
| 7 | Клиент | Сервер | SMB | C NT создание & X, Файл = \main.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini |
| 8 | Сервер | Клиент | SMB | R NT создание & X |
| 9 | Клиент | Сервер | SMB | C чтение & X, FID = 0x8005, Read 0x1a at 0x00000000 |
| 10 | Сервер | Клиент | SMB | R чтение & X, Read 0x1a |
Приведенная последовательность обмена пакетами отображает процесс подключения клиента к системному разделу и загрузку политики пользователя. Информацию об общем объеме трафика, генерируемого при агрузке данных групповой политики можно получить из Главы 5 книги издательства Microsoft Press Организация служб предприятия Active Directory: заметки на полях (Chapter 5 of the Microsoft Press book Building Enterprise Active Directory Services, in the Notes from the Field series) (EN).
Завершение
Клиент разрывает соединение с контроллером домена. При этом используется порт 445. Обмен пакетами, происходящий при этом процессе, отображен ниже в таблице:
| Пакет | Источник | Получатель | Протокол | Описание |
| 1 | Клиент | Сервер | SMB | SMB C отключение дерева |
| 2 | Сервер | Клиент | SMB | SMB R отключение дерева |
| 3 | Клиент | Сервер | SMB | SMB C выход & X |
| 4 | Сервер | Клиент | SMB | SMB R выход & X |
Теперь пользователь вошел в систему. Ниже в таблице указан общий объем трафика, затраченного в процессе входа в систе у.
| Протокол | Количество пакетов | Необходимое количество байт |
| SMB | 16 | 3070 |
| ICMP | 4 | 114 |
| UDP | 12 | 96 |
| NBT | 17 | 1164 |
| TCP | 86 | 6019 |
| MSRPC | 16 | 3872 |
| LDAP | 4 | 3226 |
| Kerberos | 12 | 14229 |
Примечание. Примите во внимание то, что в предыдущей таблице указан общий объем затраченного трафика при условии, что пользователь являлся только членом групп, используемых по умолчанию, и при этом никакие особые групповые политики не использовались.
Заключение
Мы детально рассмотрели процесс загрузки компьютера и входа в систему Windows 2000. Как уже было сказано во введении, понимание этих процессов поможет как при проектировании инфраструктуры сетей Windows 2000, так и при системном администрировании.
В данном документе представлен большой объем материала, который, вероятно, придется прочесть не один раз для полного понимания, и к которому иногда придется обращаться.
Для укрепления Вашего понимания концепций, описанных в данном документе, я бы порекомендовал настроить среду тестирования и использовать сетевой монитор для изучения процессов, происходящих в сети. Использование данного документа во время анализа процессов, происходящих в сети, позволит Вам понять, что происходит на каждой стадии.
Все свои вопросы и комментарии Вы можете направлять на этот адрес электронной почты: gmolnar@microsoft.com
Приложение A: Среда тестирования
При рассмотрении процессов загрузки и входа в систему Windows 2000 использовалась следующая тестовая системная конфигурация:
| Окружение | Сервер | Клиент |
| Windows 2000 | 1 контроллер домена Windows 2000 в домене Main.Local, на котором были запущены службы: | 1 настольный компьютер, работающий под управлением Windows 2000 Professional. |
| NT 4 | 1 контроллер домена NT 4 SP6a, на котором запущены службы: | 1 настольный компьютер, работающий под управлением Windows 2000 Professional |
| Смешанное | 1 контроллер домена, который был обновлен до Windows 2000, и на котором запущены службы: | 1 настольный компьютер, работающий под управлением Windows 2000 Professional |
| Лес | 1 контроллер домена, работающий под управлением Windows 2000 Server в домене Corp.Main.Local, и на котором запущены службы: |
Все компьютеры (кроме тех, что были особо отмечены) были объединены в сеть с помощью концентратора 10/100 Ethernet. При этом клиенты использовали разные сетевые карты Ethernet. Подключение всех клиентов осуществлялось на скорости 100 Мбит/с.
Анализ обмена пакетами производился с помощью программы Network Monitor v5.00.646. В программу Network Monitor также был добавлен анализатор Kerberos-трафика.
Во всех результатах сетевого тестирования, а также в конфигурациях, задействованных в данном документе, использовался транспортный протокол TCP/IP. TCP/IP по умолчанию используется в качестве основного сетевого протокола в Windows 2000. Кроме того, этот протокол необходим для большинства служб, используемых в процессе запуска и входа в систему.
Приложение Б. Порты TCP/IP, используемые при проверке подлинности
Ниже в таблице приведен исчерпывающий список портов, которые использует Windows.
| Порт | TCP/UDP | Назначение |
| 20 | TCP | Протокол FTP |
| 21 | TCP | Протокол FTP |
| 23 | TCP | Протокол Telnet |
| 25 | TCP | Протокол SMTP IIS |
| 31 | TCP | Netmeeting |
| 42 | TCP | Репликация WINS |
| 52 | TCP | Netmeeting |
| 53 | UDP | Разрешение имен DNS (DNS Name Resolution) TCP-поиск SQL (SQL TCP lookup) |
| 53 | TCP | DNS |
| 67 | UDP | Аренда адреса по протоколу DHCP (BOOTP) (DHCP Lease (BOOTP)) |
| 68 | UDP | DHCP Lease Аренда адреса по протоколу DHCP (DHCP Lease) |
| 80 | TCP | Протокол HTTP IIS |
| 88 | UDP | Протокол Kerberos |
| 88 | TCP | Протокол Kerberos |
| 110 | TCP | Протокол POP3 |
| 119 | TCP | Протокол NNTP |
| 135 | TCP | Служба размещения (Location Service) RPC Диспетчер DHCP (DHCP Manager) |
| 137 | UDP | Служба имени NetBIOS (NetBIOS Name Service) Доверительные отношения NT 4.0 (NT 4.0 Trusts) |
| 137 | TCP | Регистрация WINS (WINS Registration) |
| 138 | UDP | Служба датаграмм NetBIOS (NetBIOS Datagram Service) Вход в систему (Logon Sequence) Доверительные отношения NT 4.0 (NT 4.0 Trusts) Сквозная проверка подлинности (Pass Through Validation) |
| 139 | TCP | Служба сеанса NetBIOS (NetBIOS Session Service) Совместное использование файлов (File Sharing) |
| 161 | UDP | Протокол SNMP |
| 162 | UDP | Ловушки SNMP (SNMP Trap) |
| 215 | TCP | Netmeeting |
| 389 | TCP | Протокол LDAP |
| 443 | TCP | Протокол HTTP SSL |
| 445 | TCP | Протокол SMB или CIFS |
| 464 | UDP | Службы смены пароля и ключа Kerberos (Kerberos kpasswd) |
| 500 | UDP | Протокол сопоставления безопасности и управления ключами в сети Интернет (IPSEC isakmp IKE) |
| 531 | TCP | Протокол IRC |
| 560 | TCP | Служба репликации содержимого сервера сайта (Content Replication Service Site Server) |
| 636 | LDAP поверх SSL (LDAP over SSL) | |
| 731 | TCP | Netmeeting |
| Dynamic | UDP | Netmeeting |
| 888 | TCP | Вход в систему и среду (Login and Environment Passing) |
| Dynamic | TCP | Репликация каталогов (Directory Replication) |
| 1109 | TCP | Протокол POP с проверкой Kerberos (POP with Kerberos) |
| 1433 | TCP | TCP-сеанс SQL (SQL TCP session) |
| 1645 | UDP | Аутентификация RADIUS (RADIUS Authentication) |
| 1646 | UDP | Проверка учетных записей RADIUS (RADIUS Accounting) |
| 1723 | TCP | Протокол PPTP Control Channel (IP Protocol 47 GRE) |
| 1755 | TCP | Netshow |
| Dynamic | UDP | Netshow |
| 1812 | UDP | Аутентификация RADIUS (RADIUS Authentication) |
| 1813 | UDP | Проверка учетных записей RADIUS (RADIUS Accounting) |
| 1863 | TCP | MSN Messenger |
| 2053 | TCP | Демультиплексор Kerberos (Kerberos de-multiplexor) |
| 2105 | TCP | Шифрованный вход по протоколу Kerberos (Kerberos encrypted rlogin) |
| 3268 | Доступ к глобальному каталогу по протоколу LDAP (Global Catalog LDAP) | |
| 3269 | Доступ к глобальному каталогу по протоколу LDAP поверх SSL (Global Catalog LDAP over SSL) | |
| 3389 | RDP | Службы терминалов (Terminal Services) |
| 8000 | TCP | Система CyberCash (кредитный шлюз) (CyberCash (credit gateway)) |
| 8001 | TCP | Система CyberCash (администратор) (CyberCash (admin)) |
| 8002 | TCP | Система CyberCash (монетный шлюз) (CyberCash (coin gateway)) |
| 10140-10179 | TCP | Диапазон портов DCOM (DCOM port range) |
Для просмотра всех портов в Windows NT на своем локальном компьютере откройте ветку:
%winnt%/system32/drivers/etc/services
Ниже в таблице представлен список общих портов:
| Проверка подлинности. Службы проверки подлинности проверяют подлинность пользователя или устройства, который запрашивает доступ к ресурсу. | |
| Служба | Тип |
| Служба проверки подлинности AFS/Kerberos (AFS/Kerberos authentication service) | TCP-порт 7004 - afs3-kaserver |
| Служба проверки подлинности AFS/Kerberos (AFS/Kerberos authentication service) | UDP-порт 7004 - afs3-kaserver |
| Служба проверки подлинности (Authentication Service) | TCP-порт 113 - ident |
| Служба проверки подлинности (Authentication Service) | UDP-порт 113 - ident |
| Центр распределения сертификатов (Certificate Distribution Center) | TCP-порт 223 – cdc |
| Центр распределения сертификатов (Certificate Distribution Center) | UDP-порт 223 - cdc |
| Funk Software Inc. | TCP-порт 1505 - funkproxy |
| Funk Software Inc. | UDP-порт 1505 - funkproxy |
| Протокол входа на узел (Система управления доступом к контроллеру терминального доступа (Terminal Access Controller Access Control System, TACACS)) (Login Host Protocol (TACACS)) | TCP-порт 49 - bbn-login |
| Протокол входа на узел (Система управления доступом к контроллеру терминального доступа (Terminal Access Controller Access Control System, TACACS)) (Login Host Protocol (TACACS)) | UDP-порт 49 - bbn-login |
| Служба баз данных TACACS (TACACS-Database Service) | TCP-порт 65 - tacacs-ds |
| Служба базы данных TACACS (TACACS-Database Service) | UDP-порт 65 - tacacs-ds |
| Служба каталогов. Службы каталога разрешения имен предоставляют возможности разрешения имен и поиска, позволяя пользователям или устройствам обнаруживать сетевые ресурсы, при этом для поиска используя легко читаемые или запоминаемые человеком имена. | |
| Служба | Тип |
| Привязка имен AppleTalk (AppleTalk Name Binding) | TCP-порт 202 - at-nbp |
| Привязка имен AppleTalk (AppleTalk Name Binding) | UDP-порт 202 - at-nbp |
| Служба размещения каталога (Directory Location Service) | TCP-порт 197 - dls |
| Служба размещения каталога (Directory Location Service) | UDP-порт 197 - dls |
| Монитор службы размещения каталога (Directory Location Service Monitor) | TCP-порт 198 - dls-mon |
| Монитор службы размещения каталога (Directory Location Service Monitor) | UDP-порт 198 - dls-mon |
| Протокол LDAP (Lightweight Directory Access Protocol) | TCP-порт 389 - ldap |
| Протокол LDAP (Lightweight Directory Access Protocol) | UDP-порт 389 - ldap |
| Протокол SMB поверх TCP/IP (Microsoft-DS) | TCP-порт 445 - microsoft-ds |
| Протокол SMB поверх TCP/IP (Microsoft-DS) | UDP-порт 445 - microsoft-ds |
| Служба WINS (Microsoft\'s Windows Internet Name Service) | TCP-порт 1512 - wins |
| Служба WINS (Microsoft's Windows Internet Name Service) | UDP-порт 1512 - wins |
| Служба имен NETBIOS (NETBIOS Name Service) | TCP-порт 137 - netbios-ns |
| Служба имен NETBIOS (NETBIOS Name Service) | UDP-порт 137 - netbios-ns |
| Службы Hostname на компьютерах SRI-NIC (NIC Host Name Server) | TCP-порт 101 - hostnames |
| Службы Hostname на компьютерах SRI-NIC (NIC Host Name Server) | UDP-порт 101 - hostnames |
| Служба каталогов Prospero Directory Service (непривилегированная) (Prospero Directory Service non-priv) | TCP-порт 1525 – prospero-np |
| Служба каталогов Prospero Directory Service (непривилегированная) (Prospero Directory Service non-priv) | UDP-порт 1525 - prospero-np |
| DNS-сервер (Domain Name Server) | TCP-порт 53 – domain |
| DNS-сервер (Domain Name Server) | UDP-порт 53 – domain |
| Служба Host Name Server | TCP-порт 42 - nameserver |
| Служба Host Name Server | UDP-порт 42 - nameserver |
| Служба HOSTS2 Name Server | TCP-порт 81 - hosts2-ns |
| Служба HOSTS2 Name Server | UDP-порт 81 - hosts2-ns |
| Протокол Streettalk | TCP-порт 566 - streettalk |
| Протокол Streettalk | UDP-порт 566 - streettalk |
| Шифрование | |
| Служба | Тип |
| Kerberos | TCP-порт 750 - kerberos-sec |
| Kerberos | TCP-порт 751 - kerberos_master |
| Kerberos | TCP-порт 88 - kerberos |
| Kerberos | UDP-порт 750 - kerberos-sec |
| Kerberos | UDP-порт 751 - kerberos_master |
| Kerberos | UDP-порт 88 - kerberos |
| Администрирование базы данных kadmin протокола Kerberos версии 5 (kerberos administration) | TCP-порт 749 - kerberos-adm |
| Администрирование базы данных kadmin протокола Kerberos версии 5 (kerberos administration) | UDP-порт 749 - kerberos-adm |
| Центр распределения ключей Kerberos (Kerberos Key Distribution Center) | Служба Windows NT – центр распределения ключей Kerberos (Windows NT Service - Kerberos Key Distribution Center) |
| kerberos-master | TCP Port 751 - kerberos-master |
| Маршрутизация. Маршрутизирующие протоколы обеспечивают обмен информацией между сетями. Из этого списка исключен протокол TCP/IP, поскольку его используют все узлы в сети. Необходимо отметить то, что наличие протоколов, отличных от TCP/IP, может сигнализировать о том, что присутствуют другие версии клиентских ОС и/или конфигурации сети. | |
| Служба | Тип |
| Протокол AppleTalk (AppleTalk Protocol) | Служба Windows NT – протокол AppleTalk (Windows NT Service - AppleTalk Protocol) |
| Маршрутизация AppleTalk (AppleTalk Routing Maintenance) | TCP-порт 201 – at-rtmp |
| Маршрутизация AppleTalk (AppleTalk Routing Maintenance) | UDP-порт 201 - at-rtmp |
| Appletalk Update-Based Routing Pro. | TCP-порт 387 - aurp |
| Appletalk Update-Based Routing Pro. | UDP-порт 387 – aurp |
| Информация о зоне AppleTalk (AppleTalk Zone Information) | TCP-порт 206 - at-zis |
| Информация о зоне AppleTalk (AppleTalk Zone Information) | UDP-порт 206 - at-zis |
| Протокол пограничных шлюзов (Border Gateway Protocol) | TCP-порт 179 - bgp |
| Протокол пограничных шлюзов (Border Gateway Protocol) | UDP-порт 179 - bgp |
| Протокол IPX | TCP-порт 213 – ipx |
| Протокол IPX | UDP-порт 213 – ipx |
| Процесс локальной маршрутизации (на сайте) (Local routing process (on site)) | UDP-порт 520 – router |
Обсуждение статьи на форуме