Microsoft Computer Startup Process

A computer that is a member of a Windows 2000 domain goes through a startup process that connects it to the domain it is a member of. This startup process allows services on the computer to interact or be interacted with on the network, and more importantly, it is required in order for users to interactively log on. This process flow shows the computer startup process.



Connecting to a Network

The computer startup process begins when the computer connects to the network and loads the TCP/IP protocol. TCP/IP can be configured to use either static or dynamic configuration. Dynamic configuration means using the DHCP, which is a well-documented technology that is a core component of the Windows Server operating system. Static addressing means that TCP/IP configuration information has been manually configured on the computer. Typically, static addresses are used for resources that do not change very often, such as routers or servers. In the examples in this paper, the only systems that use static addresses are the servers.

The DHCP process generates the following frames on the network when the client connects to the network. The sequence of "Discover," "Offer," "Request," and "ACK" in the first four frames is the DHCP process in action. These four frames generate 1,342 bytes (about 342 bytes per DHCP frame) of network traffic, but this will vary depending upon the number of DHCP options specified. The Reverse ARPs (RARP) in frames 5 through 8 are preformed by the client to ensure the address is not in use by another computer on the network. Each RARP frame creates about 60 bytes of network traffic or around 300 bytes for the address check sequence.

Frame

Source

Destination

Protocol

Description

1

Client

*BROADCAST

DHCP

Discover

2

Server

*BROADCAST

DHCP

Offer

3

Client

*BROADCAST

DHCP

Request

4

Server

*BROADCAST

DHCP

ACK

5

Client

*BROADCAST

ARP_RARP

ARP: Request, Target IP:
10.0.0.100

6

Client

*BROADCAST

ARP_RARP

ARP: Request, Target IP:
10.0.0.100

7

Client

*BROADCAST

ARP_RARP

ARP: Request, Target IP:
10.0.0.100

8

Server

*BROADCAST

ARP_RARP

ARP: Reply, Target IP:
10.0.0.100

It is important to note that if a client already possesses a lease, then it will simply renew the lease with the DHCP server when it restarts. The renewal includes only the Request and Acknowledgement packets shown in the first two frames below. The client still performs the RARP process to ensure its address is not in use.

Frame

Source

Destination

Protocol

Description

1

Client

*BROADCAST

DHCP

Request

2

Server

*BROADCAST

DHCP

ACK

3

Client

*BROADCAST

ARP_RARP

ARP: Request, Target IP:
10.0.0.100

4

Client

*BROADCAST

ARP_RARP

ARP: Request, Target IP:
10.0.0.100

5

Client

*BROADCAST

ARP_RARP

ARP: Request, Target IP:
10.0.0.100

6

Server

*BROADCAST

ARP_RARP

ARP: Reply, Target IP:
10.0.0.100

Domain Controller Detection

A client computer needs to get the latest configuration status during each startup phase. Therefore, it has to locate at least one controller in its domain.

In a Windows 2000 domain, each controller is also an LDAP server. In order to retrieve a list of available controllers, the client can query the DNS for SRV resource records with the name _ldap._tcp.dc._msdcs.DnsDomanName.

The following frames show an example of this.

Frame

Source

Destination

Protocol

Description

1

Client

Server

DNS

0x1:Std Qry for
_ldap._tcp.dc._msdcs.main.local.
of type Srv Loc on class INET
addr.

2

Server

Client

DNS

0x1:Std Qry Resp. for
_ldap._tcp.dc._msdcs.main.local.
of type Srv Loc on class INET
addr

The Windows 2000 domain is an administrative boundary, which is independent from the structure of a given network. The computer in a given environment can be grouped into sites. A site in Windows 2000 is defined as a set of IP subnets connected by fast, reliable connectivity. As a rule of thumb, networks with LAN speed or better are considered fast networks for the purposes of defining a site. A domain can span multiple sites and multiple domains can cover a site.

W2KSRT05

The locator service of a client attempts to find the closest site during the startup process and stores the name of the site in the registry. If a client knows which site it belongs to, it can send a query for controllers in its site to the DNS server. The format of such a query is:

_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DnsDomanName

The following frames show an example of this.

Frame

Source

Destination

Protocol

Description

1

Client

Server

DNS

0x1:Std Qry for _ldap._tcp.Default-
First-Site-
Name._sites.dc._msdcs.dcclab.local. of
type Srv Loc on class INET addr.

2

Server

Client

DNS

0x1:Std Qry Resp. for
_ldap._tcp.Default-First-Site-
Name._sites.dc._msdcs.dcclab.local. of
type Srv Loc on class INET addr.

The DNS query above shows the client looking for the LDAP Service in the "Default-First-Site-Name." Default-First-Site-Name is the default name given to a Windows 2000 domain site when it is created.

The domain controllers registered for a site can be viewed with the Microsoft Management Console DNS snap-in. The following diagram shows a snapshot of the snap-in. The expanded view shows the domain controllers that have registered their Kerberos and LDAP service for a given site.



If it is possible for the DNS server to locate the requested information, it sends back a list of all known domain controllers in the site.

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.

The client randomly picks up one controller for the additional communication process, and it does not distinguish between local or remote subnets because it considers each member of its site as a computer that is reasonably close to the client.

As already mentioned, it is possible to have an influence on the controller selection in form of the site concept. After retrieving a domain controller, the client tries to determine whether the controller is the closest one in form of LDAP queries.

Frame

Source

Destination

Protocol

Description

1

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

2

Server

Client

LDAP

ProtocolOp: SearchResponse (4)

3

Client

Sever

LDAP

ProtocolOp: SearchRequest (3)

4

Server

Client

LDAP

ProtocolOp: SearchResponse (4)

In the query, the client requires a match for attributes such as its:

                     DNS domain name

                     Host name

                     Domain globally unique identifier (GUID)

                     Domain security identifier (SID)

If the controller does have exactly this information in its Active Directory database, it passes back information about itself such as:

                     Domain controllerName

                     Domain controllerAddress

                     Domain controllerAddressType

                     DomainGUID

                     DomainName

                     DNSForestName

                     DCSiteName

                     ClientSiteName

The most important information for the client is the site name. The hex dump of the response from the server will contain only one site name if the client is a member of the controller's site:

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 ..

If the client is communicating with a controller that is not in the client's site, the controller will also pass back the name of the client's proper site:

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 .......

In this case, the client sends another query to the DNS server asking for the list of controllers in this side. The following table shows an example of this. The client is looking for a domain controller in Site2 and switches to Site1 after the LDAP.

Frame

Source

Destination

Protocol

Description

1

Client

Server

DNS

0x1:Std Qry for
_ldap._tcp.Site2._sites.dc._msdcs.dcc
lab.local.

2

Server

Client

DNS

0x1:Std Qry Resp. for
_ldap._tcp.Site2._sites.dc._msdcs.dcc
lab.local

3

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

4

Server

Client

LDAP

ProtocolOp: SearchResponse (4)

5

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

6

Server

Client

LDAP

ProtocolOp: SearchResponse (4)

7

Client

Server

DNS

DNS 0x2:Std Qry for
_ldap._tcp.Site1._sites.dc._msdcs.dcc
lab.local.

8

Client

Server

DNS

0x2:Std Qry Resp. for
_ldap._tcp.Site1._sites.dc._msdcs.dcc
lab.local

It is not necessary to have a domain controller in each site. Each domain controller checks all sites in a forest and the replication cost. A domain controller registers itself in any site that doesn't have a domain controller for its domain and for which its site has the lowest-cost connection. This process is also known as automatic site coverage. What this means is that clients will use the next domain controller that it has lowest cost to get to.

The default location process of the closest domain controller consists of 10 network packets and creates around 2,000 bytes of traffic.

Frame

Source

Destination

Protocol

Description

1

Client

Server

ARP_RARP

ICMP Echo: From 10.00.00.24 To
10.00.00.22

2

Server

Client

ARP_RARP

ICMP Echo Reply: To 10.00.00.24 From
10.00.00.22 10.0.0.22 10.0.0.24

3

Client

Server

DNS

0x1:Std Qry for _ldap._tcp.Default-
First-Site-
Name._sites.dc._msdcs.dcclab.local.

4

Client

Server

DNS

0x2:Std Qry for _ldap._tcp.Default-
First-Site-
Name._sites.dc._msdcs.dcclab.local.

5

Server

Client

DNS

0x1:Std Qry Resp. for
_ldap._tcp.Default-First-Site-
Name._sites.dc._msdcs.dcclab.

6

Server

Client

DNS

0x2:Std Qry Resp. for
_ldap._tcp.Default-First-Site-
Name._sites.dc._msdcs.dcclab.

7

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

8

Server

Client

LDAP

ProtocolOp: SearchResponse (4)

9

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

10

Server

Client

LDAP

ProtocolOp: SearchResponse (4)

11

Client

Server

ARP_RARP

ICMP Echo: From 10.00.00.24 To
10.00.00.22

12

Client

Server

ARP_RARP

ICMP Echo Reply: To 10.00.00.24 From
10.00.00.22 10.0.0.22 10.0.0.24

More details about the domain locator process can be found in the chapter "Name Resolution in Active Directory" of the Windows 2000 Resource Kit.

Establishing a Secure Channel with the Domain Controller

When the client determines its site and domain controller, it can then create a secure channel with that domain controller. A secure channel is a connection between a domain member and a domain controller established to retrieve domain specific information, to update computer-specific information in the Active Directory, such as the computer password, and to validate the domain membership.

The process starts with a negotiation of the SMB dialect both parties will use. The SMB protocol has undergone many revisions and extensions s e its release in 1984. This means the client and the server may not necessarily be using the same SMB dialect. In this case, both sides are Windows 2000, which uses the dialect NTLM 0.12. This dialect allows exchanges to use Unicode. Prior to this, exchanges were made in ASCII. The benefit of Unicode strings is they can lude file names, resource names, and user names.

The client proceeds by connecting to the netlogon interface of the target. The End Port Mapper must be involved in this process in order to connect the client with the correct port on the server. Finally, the client sends three calls (NetrServerReqChallenge, NetrServerAuthenticate3, NetrLogonGetdomainInfo) to the interface. This process produces approximately 4,600 bytes of traffic.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

C negotiate, Dialect = NT LM 0.12

2

Server

Client

SMB

R negotiate, Dialect # = 5

3

Client

Server

MSRPC

c/o RPC Bind: UUID E1AF8308-5D1F-
11C9-91A

4

Server

Server

MSRPC

c/o RPC Bind Ack: call 0x1 assoc
grp 0xD52C

5

Client

Server

MSRPC

c/o RPC Request: call 0x1 opnum 0x3
contex

6

Server

Client

MSRPC

c/o RPC Response: call 0x1
context

7

Client

Server

MSRPC

c/o RPC Bind: UUID 12345678-1234-
ABCD-EF0

8

Server

Client

MSRPC

c/o RPC Bind Ack: call 0x1 assoc
grp 0x1C04B

9

Client

Server

R_LOGON

RPC Client call
logon:NetrServerReqChallenge(..)

10

Server

Client

R_LOGON

RPC Server response
logon:NetrServerReqChallenge()

11

Client

Server

R_LOGON

Error: Bad Opcode (Function does not
exist)

12

Server

Server

R_LOGON

Error: Bad Opcode (Function does not
exist)

13

Client

Client

MSRPC

c/o RPC Bind: UUID 12345678-1234-
ABCD-EF0

14

Server

Client

MSRPC

c/o RPC Bind Ack: call 0x3 assoc
grp 0x1C04B

15

Client

Client

R_LOGON

Error: Bad Opcode (Function does not
exist)

16

Server

Client

R_LOGON

Error: Bad Opcode (Function does not
exist)

Note The current version of Netmon cannot resolve the calls NetrServerAuthenticate3 and NetrLogonGetdomainInfo correctly. In the previous table, these calls are shown as errors with a Bad Opcode.

Important When an environment is mixed after an upgrade of a Windows NT 4 domain to Windows 2000, it is important to be aware of the following situation. When the only available domain controller for a Windows 2000 client to authenticate with is a Windows NT 4.0 backup domain controller, it will be unable to establish a secure channel. This is by design to rease security. Windows 2000 clients know what type of domain they belong to and will not downgrade their authentication method when setting a secure channel. The following trace sequence shows this scenario. It appears to be identical to the Windows 2000 client in a Windows NT 4.0 domain. The main appears after this because the client was unable to setup a secure channel, thus domain authentication fails.

Kerberos Authentication and Session Creation

After the secure channel has been established, the client will retrieve all necessary tickets to establish an IPC$ session with the controller. Because all Windows 2000 domain controllers are Kerberos Key Distribution Center (KDC), the client tries to detect the closest KDC in the same way it has already done it for the LDAP services.

The first step the client has to perform is the authentication in form of an AS ticket exchange. If this is successfully finished, it requests tickets for the controller (computer name$) and the Kerberos service (krbtgt) that is running on the controller. The packet exchange produces approximately 8 kilobytes (KB). The actual size in a given environment depends on the number of Global and Universal groups that the client is a member of. Each additional group will add about 28 bytes to the total.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

DNS 0x3:Std Qry for
_kerberos._tcp.Default-First-Site-
Name._sites.dc._msdcs.DCCLAB.LOCAL.
of type Srv Loc on class INET

2

Server

Client

SMB

DNS 0x3:Std Qry Resp. for
_kerberos._tcp.Default-First-Site-
Name._sites.dc._msdcs.DCCLAB.LOCAL.
of type Srv Loc on class

3

Client

Server

LDAP

LDAP ProtocolOp: SearchRequest (3)

4

Server

Server

LDAP

LDAP ProtocolOp: SearchResponse (4)

5

Client

Server

Kerberos

Kerberos KRB_AS_REQ (request for
TGT)

6

Server

Client

Kerberos

Kerberos KRB_AS_REP

7

Client

Server

Kerberos

Kerberos KRB_TGS_REQ (request for
DC$)

8

Server

Client

Kerberos

Kerberos KRB_TGS_REP

9

Client

Server

R_LOGON

Kerberos KRB_TGS_REQ (request for
Kerberos Service)

10

Server

Client

R_LOGON

Kerberos KRB_TGS_REP

All the tickets a client has obtained can be viewed with the Kerbtray utility from the Microsoft Resource Kit.

W2KSRT07

Finally, the client can connect to the IPC$ share of the controller, which produces around 3,600 bytes of traffic.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

SMB C session setup & X

2

Server

Client

SMB

SMB R session setup & X

3

Client

Server

SMB

SMB C tree connect & X, Share =
\\DCCLAB22.DCCLAB.LOCAL\IPC$

4

Server

Client

SMB

SMB R tree connect & X, Type = IPC$

DFS Referral

The client then makes a Distributed File System (DFS) referral. A DFS referral is the DFS client-server protocol to get DFS-specific information that exists on the server to the client. It occurs whenever necessary. The general referral process is started when the client sends an SMB packet, indicating it is a DFS referral. The server passes this request to the DFS driver to complete the request. Subsequently, any access to network shares could result in a DFS referral request, if the client does not already have information about that share. Windows 2000 is a DFS version 5.0 client. This version allows caching of referrals to a DFS root or link for a (administrator configurable) specific length of time.

When the client starts up, a number of DFS referral requests are made from the client to one of the domain controllers within the client computer's domain that responds to the request. This process is required so that the client will be ready to handle any requests to domain-based DFS shares.

The first two requests serve to initialize the DFS client. The first is used to learn the names of all trusted Windows 2000 domains that could be the accessed by the client. The second is used to obtain a list of domain controller in the domain order by local site first. The names returned contain both the Netbios name and DNS names of the domains.

The third request is made to obtain the actual server path to connect to a sysvol share.

The DFS referral creates a minimum of 394 bytes of traffic. The actual amount of traffic generated will depend on the number of trusted domains and DCs in the local domain returned in the reply.

By default the DFS referral to learn domain configuration is repeated every 15 minutes.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

C transact2 NT Get DFS Referral

2

Server

Client

SMB

R transact2 NT Get DFS Referral (response to
frame 105)

The client then pings and makes an LDAP request to get the domain controller again.

Frame

Source

Destination

Protocol

Description

1

Client

Server

ICMP

Echo: From 10.00.00.100 To 10.00.00.22

2

Server

Client

ICMP

Echo Reply: To 10.00.00.100 From
10.00.00.22

3

Client

Server

UDP

Src Port: Unknown, (1041); Dst Port:
Unknown (389); Length = 209 (0xD1)

4

Server

Client

UDP

Src Port: Unknown, (389); Dst Port: Unknown
(1041); Length = 188 (0xBC)

Name Translation

Each object in the Active Directory has a name. There are different formats for names available, such as the user pr ipal names, distinguished names, and the earlier "domain\user" names from Windows NT. It is not necessary for a name to be a string. In general, everything that uniquely identifies an object can be considered as a name. Depending on the service that needs a name as parameter, it might be necessary to convert a given name from one format into another.

This is the objective of an API called DsCrackNames, which is used to map names from one format to another. Details about this call can be obtained from the Microsoft Developers Network (MSDN). Before a client can call this function, it has to bind a handle to the directory service with DSBind and if the operation is done it has to unbind from the directory with DSUnbind.

The following frames show the network traffic that comes along with the translation process. The entire process produces approximately 6,600 bytes of traffic.

Frame

Source

Destination

Protocol

Description

1

Client

Server

MSRPC

c/o RPC Bind: UUID E1AF8308-5D1F-
11C9-91A4-08002B14A0FA call 0

2

Server

Client

MSRPC

c/o RPC Bind Ack: call 0x1 assoc
grp 0xD52D xmit 0x16D0 recv 0x1

3

Client

Server

MSRPC

c/o RPC Request: call 0x1 opnum 0x3
context 0x0 hint 0x84

4

Server

Client

MSRPC

c/o RPC Response: call 0x1 context
0x0 hint 0x80 cancels 0x0

5

Client

Server

MSRPC

c/o RPC Bind: UUID E3514235-4B06-
11D1-AB04-00C04FC2DCD2 call 0

6

Server

Client

MSRPC

c/o RPC Bind Ack: call 0x1 assoc
grp 0x1C04C xmit 0x16D0 recv 0x

7

Client

Server

MSRPC

c/o RPC Alt-Cont: UUID E3514235-
4B06-11D1-AB04-00C04FC2DCD2 call 0

8

Server

Client

MSRPC

c/o RPC Alt-Cont Rsp: call 0x1
assoc grp 0x1C04C xmit 0x16D0 recv
0x

9

Client

Server

MSRPC

c/o RPC Request: call 0x1 opnum 0x0
context 0x0 hint 0x38

10

Server

Client

MSRPC

c/o RPC Response: call 0x1 context
0x0 hint 0x3C cancels 0x0

11

Client

Server

MSRPC

c/o RPC Request: call 0x2 opnum 0xC
context 0x0 hint 0x6E

12

Server

Client

MSRPC

c/o RPC Response: call 0x2 context
0x0 hint 0xB4 cancels 0x0

13

Client

Server

MSRPC

c/o RPC Request: call 0x3 opnum
0xC context 0x0 hint 0x6E

14

Server

Client

MSRPC

c/o RPC Response: call 0x3 context
0x0 hint 0xAC cancels 0x0

15

Client

Server

MSRPC

c/o RPC Request: call 0x4 opnum 0x1
context 0x0 hint 0x14

16

Server

Client

MSRPC

c/o RPC Response: call 0x4 context
0x0 hint 0x18 cancels 0x0

LDAP RootDSE

The client then requests information from the LDAP RootDSE. The RootDSE is a standard attribute defined in the LDAP 3.0 specification. The RootDSE contains information about the directory server, luding its capabilities and configuration. The search response will contain a standard set of information as defined in RFC 2251. One of the items returned with this response is the supported Simple Authentication and Security Layer (SASL) mechanism. In this case it returns GSS-SPNEGO.

Frame

Source

Destination

Protocol

Description

1

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

2

Server

Client

LDAP

ProtocolOp: SearchResponse (4)

3

Client

Server

Kerberos

KRB_TGS_REQ

4

Server

Client

Kerberos

KRB_TGS_REP

5

Client

Server

LDAP

ProtocolOp: BindRequest (0)

6

Server

Client

LDAP

ProtocolOp: BindResponse (1)

Load Group Policy

Next, the computer loads applicable Group Policy objects. The client then completes an RPC call to convert its name to a distinguished name and performs an LDAP lookup for policy information that applies to this particular computer and then loads that information using Server Message Block (SMB).

Policy Search

The following frames show the client performing a binding operation to the LDAP directory. LDAP queries require the client to bind to the Directory Service before making a search for information. At this stage of the client logon process, the client is binding to the Active Directory to make a search for Group Policies that apply to the client. This sequence also shows the client making an LDAP request to determine what Group Policies apply. Each bind operation creates about 1,675 bytes of traffic. The policy search creates about 3,527 bytes of traffic in this case.

Frame

Source

Destination

Protocol

Description

1

Client

Server

LDAP

ProtocolOp: BindRequest (0)

2

Server

Client

LDAP

ProtocolOp: BindResponse (1)

3

Client

Server

LDAP

ProtocolOp: BindRequest (0)

4

Server

Client

LDAP

ProtocolOp: BindResponse (1)

5

Client

Server

TCP

.AP..., len: 173, seq: 978423034-
978423207, ack:3068556899, win:17069,
src: 1048 dst: 389

6

Server

Client

TCP

AP..., len: 294, seq:3068556899-
3068557193, ack: 978423207, win:16081,
src: 389 dst: 1048

7

Client

Server

TCP

....S., len: 0, seq: 978497639-
978497639, ack: 0, win:16384,
src: 1050 dst: 389

8

Server

Client

TCP

.A..S., len: 0, seq:3068641675-
3068641675, ack: 978497640, win:17520,
src: 389 dst: 1050

9

Client

Server

TCP

.A...., len: 0, seq: 978497640-
978497640, ack:3068641676, win:17520,
src: 1050 dst: 389

10

Client

Server

LDAP

ProtocolOp: BindRequest (0)

11

Server

Client

LDAP

ProtocolOp: BindResponse (1)

12

Client

Server

TCP

.AP..., len: 129, seq: 978498933-
978499062, ack:3068642008, win:17188,
src: 1050 dst: 389

13

Server

Client

TCP

.AP..., len: 171, seq:3068642008-
3068642179, ack: 978499062, win:16098,
src: 389 dst: 1050

14

Client

Server

TCP

.AP..., len: 203, seq: 978499062-
978499265, ack:3068642179, win:17017,
src: 1050 dst: 389

15

Server

Client

TCP

.AP..., len: 201, seq:3068642179-
3068642380, ack: 978499265, win:17520,
src: 389 dst: 1050

16

Client

Server

TCP

.AP..., len: 467, seq: 978423207-
978423674, ack:3068557193, win:16775,
src: 1048 dst: 389

17

Server

Client

TCP

.AP..., len: 1273, seq:3068557193-
3068558466, ack: 978423674, win:17520,
src: 389 dst: 1048

After the client determines what policies are applicable, it makes a second DFS referral. This will occur ahead of most attempts by a client in Windows 2000 to connect to a share point.

Policy Load Using SMB

The part completes with the client connecting to the SYSVOL (a standard share point on a domain controller) on the domain controller and downloads its policies generating 1,018 bytes of traffic.

W2KSRT08

This is a very simple configuration, so this number will grow with more sophisticated Group Policy implementations.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

C tree connect & X, Share =
\\DCCLAB22.MAIN.LOCAL\SYSVOL

2

Server

Client

SMB

R tree connect & X, Type = _

3

Client

Server

SMB

C NT create & X, File =
\main.local\Policies\{31B2F340-016D-
11D2-945F-00C04FB984F9}\gpt.ini

4

Server

Client

SMB

R NT create & X, FID = 0x4000

5

Client

Server

SMB

C read & X, FID = 0x4000, Read 0x1a
at 0x00000000

6

Server

Client

SMB

R read & X, Read 0x1a

Client Certificate AutoEnrollment

Each time Group Policy objects are applied, the client completes the autoenrollment event. The autoenrollment event does the following:

                     Checks the status of the computer's certificates, and if they are not OK, the client autoenrolls the client

                     Downloads the enterprise's certification authority (CA) certificates from the Active Directory enterprise root store (= PKI trust anchors)

                     Downloads certificates of CAs capable of issuing smart card certificates from Active Directory

The client makes a request to get the LDAP RootDSE (see frames above) information and then uses LDAP to complete autoenrollment.

Frame

Source

Destination

Protocol

Description

1

Client

Server

DNS

DNS 0x3:Std Qry for
_ldap._tcp.Site2._sites.dc._msdcs

2

Server

Client

DNS

DNS 0x3:Std Qry Resp. Auth. NS is
dcclab.local.

3

Client

Server

DNS

DNS 0x4:Std Qry for
_ldap._tcp.dc._msdcs.dcclab22.dcc

4

Server

Client

DNS

DNS 0x4:Std Qry Resp. Auth. NS is
dcclab.local. of

5

Client

Server

LDAP

ProtocolOp: BindRequest (0)

6

Server

Client

LDAP

ProtocolOp: BindResponse (1)

7

Client

Server

LDAP

ProtocolOp: BindRequest (0)

8

Server

Client

LDAP

ProtocolOp: BindResponse (1)

9

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

10

Server

Client

LDAP

ProtocolOp: SearchResponse (simple) (5)

11

Client

Server

LDAP

ProtocolOp: UnbindRequest (2)

12

Client

Server

LDAP

ProtocolOp: BindRequest (0)

13

Server

Client

LDAP

ProtocolOp: BindResponse (1)

14

Client

Server

LDAP

ProtocolOp: SearchRequest (3)

15

Server

Client

LDAP

ProtocolOp: SearchResponse (simple) (5)

16

Client

Server

LDAP

ProtocolOp: UnbindRequest (2)

17

Client

Server

LDAP

ProtocolOp: UnbindRequest (2)

Closer examination of frame 3 in the previous frame reveals that this is a request for configuration information about the public key services in the domain. The following example provides a more detailed view of one of the frames.

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

Time Synchronization

Next, the client updates its time with its authenticating domain controller. The following set of frames shows the time synchronization process. Notice that this occurs on port 123. This sequence creates 220 bytes of network traffic.

Frame

Source

Destination

Protocol

Description

1

Client

Server

NTP

Src Port: Unknown, (1051); Dst Port: Network Time Protocol (123); Length = 76 (0x4C)

2

Server

Client

NTP

Src Port: Network Time Protocol, (123); Dst Port: Unknown (1051); Length = 76 (0x4C)

Dynamic Domain Name System Update

The last part of the startup process is for the client to perform its name update in the DNS database. The Windows 2000 dynamic DNS update is based on RFC 2136. This process is based on RFC 2136.

The client first determines whether the DNS server has the authority for the client's zone. This sequence creates 225 bytes of traffic.

Frame

Source

Destination

Protocol

Description

1

Client

Server

DNS

0x1:Std Qry for dcclab24.main.local.
of type SOA on class INET addr.

2

Server

Client

DNS

0x1:Std Qry Resp. Auth. NS is
main.local. of type SOA on class
INET addr. : Name does not exist

Next, the client makes the dynamic update of its name in the DNS server. This creates about 1,800 bytes of traffic if the client has to update both (A RR and PTR RR).

Frame

Source

Destination

Protocol

Description

1

Client

Server

DNS

DNS 0x4:Dyn Upd PRE records to
dcclab24.dcclab.local.

2

Server

Client

DNS

241 99.703125 00010233BFE7 INTEL
F1A000 DNS 0x4:Dyn Upd Resp. PRE
records to dcclab24.dcclab

3

Client

Server

DNS

DNS 0x5:Std Qry for 0.0.10.in-
addr.arpa. of type SOA

4

Server

Client

DNS

0x5:Std Qry Resp. for 0.0.10.in-addr.arpa. of type SOA

5

Client

Server

DNS

0x6:Dyn Upd PRE/UPD records to 24.0.0.10.in-
addr.arpa

6

Server

Client

DNS

0x6:Dyn Upd Resp. PRE/UPD records to
24.0.0.10.in-addr.arpa

The actual size of the packets for the dynamic update depends on many conditions. First of all, it depends on whether the client was already registered. Next, it depends in whether there is a conflict with an already registered entry. Another aspect for the client traffic is whether DHCP is in use. The default configuration in this scenario is that the client is updating its A RR, whereas the DHCP server is responsible for the PTR RR.

Last but not least, is the traffic also depending on the configuration of the DNS server and how the secure dynamic update behavior is configured.

Note If DDNS is not being used in the environment, you should consider turning off the client's ability to make dynamic updates. Turning this off will save the network traffic generated by the unneeded attempts to make the update by the client in an environment that does not support it. This feature is turned off in the advanced TCP/IP properties for the particular network connection. The location is shown in the following illustration:

W2KSRT09

Completion

The computer startup sequence is completed with the client breaking down its open connections to the domain controller in a sequence similar to the one illustrated in the following table. This creates 473 bytes of traffic.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

C tree disconnect

2

Server

Client

SMB

R tree disconnect

3

Client

Server

SMB

C tree disconnect

4

Server

Client

SMB

R tree disconnect

5

Client

Server

SMB

C logoff & X

6

Server

Client

SMB

R logoff & X

This traffic sequence is useful to help determine the break between the computer startup and a user logon in a network trace. The system is now available for use. The system display will show the Ctrl-Alt-Delete screen.


User Logon

Overview

After the system startup is complete, the Ctrl-Alt-Delete screen appears on the console. A user will be able to make a domain logon from this system. Pressing Ctrl-Alt-Delete and entering a valid set of domain user credentials (user name and password) initiates the interactive client logon process that ends with the Windows NT shell being loaded and the user being able to interactively use the systems. It is important to note that the user logon process is essentially an abbreviated version of the computer startup process using a subset of the processes described previously. The following diagram shows this process.

W2KSRT10

Logon Flow

User Identification

Windows 2000 provides three ways for a user to enter account information at logon. The first method is to use the Security Accounts Manager (SAM) account name and select the domain. This is the default method for logon. The second method is to use the fully qualified name, which would appear as <user>@<domain-org- -com>. The third alternative is use the User Pr iple Name (UPN), which is described in the Windows 2000 Resource Kit as follows:

A user pr ipal name (UPN) is an e-mail-like name that uniquely represents a user. A UPN consists of two parts, a user identification portion and a domain portion. The two parts are separated by an "@" symbol, to form <user>@<DNS-domain-name>, for example, liz@noam.reskit.com. Every user is automatically assigned a default UPN, where the <user> portion of the name is the same as the user's logon name, and the <DNS-domain-name> portion of the name is the DNS name of the Active Directory domain where the user account is located. When logging on using a UPN, users no longer have to choose a domain from a list on the logon dialog box.

You can set UPNs to arbitrary values. For example, even if Liz's account is in the noam.reskit.com domain, her UPN could be set to liz@reskit.com. When the user logs on, the user account to be validated is discovered by searching the global catalog for a user account with a matching UPN value. By making UPN values independent from domain names, administrators can move user accounts between domains, leaving UPN values unchanged and making interdomain moves more transparent to users."

UPN names are resolved to a user and domain by performing a domain controller lookup of the Global Catalog (GC). UPN logon is only supported when the domain is in Native Mode.

Kerberos Authentication for User Logon

The user logon operation generates a Kerberos Authentication request to get its session ticket. Then logon process then requests a session key for a service from the KDC via the Ticket Granting Service.

Frame

Source

Destination

Protocol

Description

1

Client

Server

Kerberos

KRB_AS_REQ

2

Server

Client

Kerberos

KRB_AS_REP

3

Client

Server

Kerberos

KRB_TGS_REQ

4

Server

Client

Kerberos

KRB_TGS_REP

The logon process requests the following tickets during the user logon process:

                     Kerberos: Server Name = <clientname>$

                     Kerberos: Server Name = <dc name>$

                     Kerberos: Server Name = krbtgt.<dns domain name>

                     Kerberos: Server Name = ldap.<dc name>.<dns domain name>

As mentioned earlier, the size of the Kerberos packets depends on the number of groups a user is a member of.

Group Policy Load

The process of retrieving Group Policy information is the same as previously described in the computer startup section. The client uses the "DS API DSCrackNames" to perform a name translation and retrieves the information about the policies to load via LDAP.


If your browser does not support inline frames, click here to view on a separate page.

The client then establishes an SMB connection to the controller and downloads the necessary policy files.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

C negotiate, Dialect = NT LM 0.12

2

Server

Client

SMB

R negotiate, Dialect # = 5

3

Client

Server

SMB

C session setup & X

4

Server

Client

SMB

R session setup & X

5

Client

Server

SMB

C tree connect & X, Share = \\DCCLAB22.MAIN.LOCAL\SYSVOL

6

Server

Client

SMB

R tree connect & X, Type = _

7

Client

Server

SMB

C NT create & X, File = \main.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini

8

Server

Client

SMB

R NT create & X

9

Client

Server

SMB

C read & X, FID = 0x8005, Read 0x1a at 0x00000000

10

Server

Client

SMB

R read & X, Read 0x1a

This sequence shows the client connecting to the system volume and loading the user's policy. Information on the traffic generated by the loading of group policy information can be found in Chapter 5 of the Microsoft Press book Building Enterprise Active Directory Services, in the Notes from the Field series.

Completion

The client then closes its connection to the domain controller. This happens on Port 445. It is represented in the trace like the following table.

Frame

Source

Destination

Protocol

Description

1

Client

Server

SMB

SMB C tree disconnect

2

Server

Client

SMB

SMB R tree disconnect

3

Client

Server

SMB

SMB C logoff & X

4

Server

Client

SMB

SMB R logoff & X

The user has now logged on. The following table shows a summary of the network traffic for a user logon.

Protocol

Frames

Bytes Claimed

SMB

16

3070

ICMP

4

114

UDP

12

96

NBT

17

1164

TCP

86

6019

MSRPC

16

3872

LDAP

4

3226

Kerberos

12

14229

Note Please keep in mind that the traffic in the previous table represents a user who is just a member of the default groups and that no specific Group Policies were set.

Conclusion

We have now provided a detailed examination of the Windows 2000 computer startup and user logon process. As stated in the introduction, understanding this process will assist with both infrastructure design and systems administration in Windows 2000 networks.

This document covers a great deal of material and should probably be read multiple times to fully understand and kept handy as a reference.

To help cement your understanding of the concepts described in the paper, I would suggest setting up a test environment and using network monitor to make some traces of the process. Use this document as a reference when examining the traces to understand what is happening at each point.