Анализ трафика, генерируемого при загрузке и входе в систему Windows 2000

Анализ трафика, генерируемого при загрузке и входе в систему Windows 2000

Размещено: 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

На этой страничке

Введение

Обзор компонент Windows 2000

Описание процесса загрузки и входа в систему Windows 2000

Вход юзера в систему

Заключение

Приложение А. Среда тестирования

Приложение Б. Порты TCP/IP, применяемые в процессе проверки подлинности

 

Введение

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

Подключение клиентов к сети Windows 2000, в какой употребляется протокол динамической конфигурации узлов (Dynamic Host Configuration Protocol, DHCP), средство автоматического предназначение личных Айпишников (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

Средство предназначения личных Айпишников

Служба DNS

Протокол Kerberos

Протокол LDAP

Протокол SMB

Удаленный вызов процедур (MSRPC)

Служба времени

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

Протокол DHCP

Начальной целью использования протокола DHCP было обеспечение каждого DHCP-клиента правильной настройкой TCP/IP.

В процессе получения опций в главном употребляется восемь сообщений:

DHCPDiscover. DHCP-клиенты употребляют данное сообщение с целью обнаружения в сети, по последней мере, 1-го DHCP-сервера.

DHCPOffer. Каждый DHCP-сервер, получив запрос от клиента, инспектирует его возможность приема правильных опций и предлагает их получить DHCP-клиенту.

DHCPRequest. DHCP-клиент посылает запрос в ответ на 1-ое предложение, приобретенное от DHCP-сервера.

DHCPAcknowledge. Избранный DHCP-сервер употребляет это сообщение для доказательства выделения опций DHCP-клиенту.

DHCPNack. DHCP-сервер употребляет это сообщение для извещения клиента о том, что запрашиваемые опции TCP/IP недействительны.

DHCPDecline. DHCP-клиент употребляет это сообщение для извещения сервера о том, что предложенные опции TCP/IP недействительны.

DHCPRelease. DHCP-клиент употребляет это сообщение для извещения сервера о том, что выданные конфигурационные опции клиентом больше не употребляются.

DHCPInform. Этот тип сообщения является новым. Он определен в документе RFC 2131. В случае, если клиент уже получил Айпишник (к примеру, при настройке вручную), то он может использовать этот тип сообщения для получения дополнительных характеристик опции (относящихся к Айпишнику) от DHCP-сервера.

Способности DHCP-сервера расширяются при наличии системы DDNS. В данном случае DHCP-сервер может употребляться для динамической регистрации Айпишников и имени клиентов. При настройках, применяемых по дефлоту, DHCP-сервер устанавливает соответствие для Айпишников клиентов на DNS-сервере. Записи этого типа известны под заглавием Pointer Record (PTR RR).

Анализ трафика, генерируемого при загрузке и входе в систему Windows 2000

Для получения дополнительной инфы о 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)

Средство предназначения личных Айпишников

В Windows 2000 включено средство предназначения личных Айпишников (Automatic Private IP Addressing, APIPA), с помощью которого DHCP-клиентам будут назначены Айпишники даже в этом случае, если в сети нет ни 1-го доступного DHCP-сервера. Средство предназначения адресов APIPA разрабатывалось для компов, работающих в границах одной сабсети, в какой отсутствует DHCP-сервер. Средство APIPA автоматом назначает Айпишника из зарезервированного для этого спектра адресов (с 169.254.0.1 по 169.254.255.254). Это значит, что в этом случае, если клиент во время загрузки не сумел связаться с локальным DHCP-сервером для обновления арендованного адреса, то он будет использовать Айпишник, назначенный ему APIPA, до того времени, пока не будет восстановлена связь с DHCP-сервером. Таковой метод работы отличается от метода, применяемого в Windows NT 4.0, когда при отсутствии соединения с DHCP-сервером клиент продолжал использовать выданный ему ранее адресок, срок аренды которого еще не истек.

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

HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet

ServicesTcpipParametersInterfaces

Где – это адаптер, настроенный для использования протокола 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, для получения адреса хотя бы 1-го контроллера и для регистрации его имени и Айпишники в базе данных зоны 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).

Существует 6 первичных сообщений Kerberos. Эти 6 сообщений в реальности представляют собой три типа деяния, каждое из которых содержит запрос клиента и ответ центра распространения ключей (Key Distribution Center, KDC). 1-ое действие заключается во вводе клиентом пароля. Клиент Kerberos рабочей станции отсылает запрос «AS» в службу проверки подлинности (Authentication Service) центра KDC, запрашивая у службы проверки подлинности билет в качестве ответа для того, чтоб подтвердить, что юзеры являются теми, за кого себя выдают. Служба проверки подлинности инспектирует учетные данные юзеров и отсылает вспять билет предоставления билета (Ticket Granting Ticket, TGT).

2-ое действие состоит в том, что клиент запрашивает доступ к службе либо ресурсу, отсылая 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 может употребляться поверх нескольких сетевых протоколов:

Анализ трафика, генерируемого при загрузке и входе в систему Windows 2000
Прирастить набросок

При установлении 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 0×1
assoc grp 0×0 xmit 0x16D0 recv 0x16D0
MSRPC: Version = 5 (0×5)
MSRPC: Version (Minor) = 0 (0×0)
MSRPC: Packet Type = Bind
+ MSRPC: Flags 1 = 3 (0×3)
MSRPC: Packed Data Representation
MSRPC: Fragment Length = 72 (0×48)
MSRPC: Authentication Length = 0 (0×0)
MSRPC: Call Identifier = 1 (0×1)
MSRPC: Max Trans Frag Size = 5840 (0x16D0)
MSRPC: Max Recv Frag Size = 5840 (0x16D0)
MSRPC: Assoc Group Identifier = 0 (0×0)
+ 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-
5D1F-11C9-91A4-08002B14A0FA l

2

Сервер

Клиент

MSRPC

c/o RPC-привязка Ack: call 0×1 assoc
grp 0xC85D xmit 0x16D0 recv

3

Клиент

Сервер

MSRPC

c/o RPC-запрос: call 0×1 opnum
0×3 context 0×0 hint 0×84

4

Сервер

Клиент

MSRPC

c/o RPC-ответ: call 0×1
context 0×0 hint 0×80 cancels 0×0

Также можно инкапсулировать пакеты 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).

Наверх странички

Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.