Описание процесса загрузки и входа в систему Windows 2000
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- 978423207, ack:3068556899, win:17069, src: 1048 dst: 389 |
6 | Сервер | Клиент | TCP | AP…, len: 294, seq:3068556899- 3068557193, ack: 978423207, win:16081, src: 389 dst: 1048 |
7 | Клиент | Сервер | TCP | ….S., len: 0, seq: 978497639- 978497639, ack: 0, win:16384, src: 1050 dst: 389 |
8 | Сервер | Клиент | TCP | .A..S., len: 0, seq:3068641675- 3068641675, ack: 978497640, win:17520, src: 389 dst: 1050 |
9 | Клиент | Сервер | TCP | .A…., len: 0, seq: 978497640- 978497640, ack:3068641676, win:17520, src: 1050 dst: 389 |
10 | Клиент | Сервер | LDAP | ProtocolOp: BindRequest (0) |
11 | Сервер | Клиент | LDAP | ProtocolOp: BindResponse (1) |
12 | Клиент | Сервер | TCP | .AP…, len: 129, seq: 978498933- 978499062, ack:3068642008, win:17188, src: 1050 dst: 389 |
13 | Сервер | Клиент | TCP | .AP…, len: 171, seq:3068642008- 3068642179, ack: 978499062, win:16098, src: 389 dst: 1050 |
14 | Клиент | Сервер | TCP | .AP…, len: 203, seq: 978499062- 978499265, ack:3068642179, win:17017, src: 1050 dst: 389 |
15 | Сервер | Клиент | TCP | .AP…, len: 201, seq:3068642179- 3068642380, ack: 978499265, win:17520, src: 389 dst: 1050 |
16 | Клиент | Сервер | TCP | .AP…, len: 467, seq: 978423207- 978423674, ack:3068557193, win:16775, src: 1048 dst: 389 |
17 | Сервер | Клиент | TCP | .AP…, len: 1273, seq:3068557193- 3068558466, ack: 978423674, win:17520, src: 389 dst: 1048 |
После того, как клиент определяет подходящую политику, он создает вторую DFS-ссылку. То же самое будет происходить в большинстве других случаев при попытках клиента соединиться с общим ресурсом Windows 2000.