Windows 2000 起動とログオンのトラフィック解析
公開日: 2000年8月1日 | 最終更新日: 2007年11月19日
トピック

はじめにはじめに
Windows 2000 コンポーネントの概要Windows 2000 コンポーネントの概要
Windows 2000 起動/ログオン プロセスの説明Windows 2000 起動/ログオン プロセスの説明
ユーザー ログオンユーザー ログオン
結論結論
付録 A: テスト環境付録 A: テスト環境
付録 B: 認証プロセスで使用される TCP/IP ポート付録 B: 認証プロセスで使用される TCP/IP ポート

はじめに

クライアントの起動/ログオン プロセスでは、Microsoft Windows オペレーティング システムが Windows ネットワーク環境のコンピュータまたはユーザーを検証します。 クライアント起動およびユーザー ログオンのプロセスを理解することは、Windows 2000 のネットワークについて理解するための基礎となります。 このホワイト ペーパーでは、このプロセスについて詳しく説明します。主な項目は次のとおりです。

  • Windows 2000 動的ホスト構成プロトコル (DHCP)、自動プライベート IP アドレス指定、および静的アドレス指定を使用したクライアントのネットワーク接続。

  • Windows 2000 クライアントが起動/ログオン プロセスに必要なドメイン コントローラおよびその他のサーバーを検索するときに使用される Windows 2000 のダイナミック ドメイン ネーム システム (DDNS) の働き。また、Windows 2000 クライアントがクライアント名を DDNS に登録するプロセスについても説明します。

  • 起動およびログオン プロセス中の Microsoft Active Directory(TM) での情報検索における LDAP (Lightweight Directory Access Protocol) の働き。

  • 認証における Kerberos セキュリティ プロトコルの働き。

  • MS リモート プロシージャ コール (MSRPC) の働き。

  • 起動およびログオン プロセスにおいてグループ ポリシー情報およびその他のデータを転送するために使用されるサーバー メッセージ ブロック (SMB) の働き。

このホワイトペーパーでは、起動/ログオン プロセスで使用される Windows 2000 コア コンポーネントについて説明するとともに、このプロセスの処理内容とそこで発生するネットワーク トラフィックの量についても説明します。まず、起動/ログオン プロセスに関わる Windows 2000 コンポーネントの概要説明から始めます。次に、クライアント起動プロセスとユーザー ログオン プロセスについて説明します。

このホワイトペーパーの全体を通して、各段階の処理内容を示すためにネットワーク モニタ トレースのサンプル情報を使用します。また、追加情報が得られる参考資料も随時紹介します。一般的な参考資料として次のようなものがあります。

  • インターネット技術標準化委員会 (IETF) の RFC (Requests for Comments)

  • Microsoft Windows 2000 リソース キット

  • Microsoft サポート技術情報 の文書

  • Microsoft『Notes from the Field』シリーズの書籍

  • 各種 Web サイト

システム設計者や管理者は、このホワイト ペーパーを読み、内容を把握することによって、Windows 2000 ネットワークの構築およびサポートの技術を向上させることができます。ネットワーク設計者にとっては、Windows 2000 ネットワークでの起動およびログオンの信頼性を保証するには主要なコンポーネントをどのように配置すればよいかを判断するのに役立ちます。 サポート スタッフは、本書に記載された基準と実際の環境を比較することによって問題の解決に役立てることができます。

対象読者

このホワイト ペーパーは、Windows 2000 ネットワークの計画策定、実装、管理に携わるシステム管理者およびネットワーク設計者を対象としています。また、以下の事項についての知識を備えていることが前提となります。

  • Microsoft Windows NT または 2000 のネットワークの概念

  • TCP/IP プロトコルについての基本的な知識

  • ネットワーク トレース解析の経験

Windows 2000 リソース キット、Microsoft TechNet、および『Notes from the Field』シリーズには、クライアント起動/ログオン プロセスの説明で取り上げる Windows 2000 のコア サービスに関する詳しい説明があります。本書を読むときには、これらの参考資料を補足情報として参照することをお勧めします。

Windows 2000 コンポーネントの概要

Windows 2000 クライアントの起動/ログオン プロセスを理解するためには、このプロセスで重要な役割を果たす最新のプロトコルやサービスについての知識が必要です。この節では、以下のプロトコルおよびサービスについて、概要を説明します。

  • 動的ホスト構成プロトコル (DHCP)

  • 自動プライベート IP アドレス指定

  • ドメイン ネーム システム (DNS)

  • Kerberos

  • LDAP (Lightweight Directory Access Protocol)

  • サーバー メッセージ ブロック (SMB)

  • Microsoft リモート プロシージャ コール (MSRPC)

  • タイム サービス

これらのプロトコルおよびサービスの詳細については、各節に挙げた参考資料を参照してください。

DHCP

動的ホスト構成プロトコルの当初の目的は、DHCP クライアントに有効な伝送制御プロトコル/インターネット プロトコル (TCP/IP) 構成を提供することでした。

そのプロセスは以下の 8 つのメッセージで構成されます。

  • DHCPDiscover - DHCP クライアントは、このメッセージを使って少なくとも 1 つの DHCP サーバーを検出します。

  • DHCPOffer - クライアントから要求を受け取った DHCP サーバーは、そのスコープ (適用範囲) をチェックして有効な構成セットを見つけ、それを DHCP クライアントに渡します。

  • DHCPRequest - DHCP クライアントは DHCP サーバーから受け取った最初の提示を要求します。

  • DHCPAcknowledge - 選択された DHCP サーバーは、このメッセージによって DHCP クライアントにリースされたことを確認します。

  • DHCPNack - DHCP サーバーは、このメッセージによって、要求された TCP/IP 構成が無効であることをクライアントに知らせます。

  • DHCPDecline - DHCP クライアントは、このメッセージによって、提供された TCP/IP 構成が無効であることをサーバーに知らせます。

  • DHCPRelease - DHCP クライアントは、このメッセージによって、割り当てられた構成がクライアント側で使用されなくなったことをサーバーに知らせます。

  • DHCPInform - RFC (Request for Comments) 2131 で新たに定義されたメッセージです。クライアントがインターネット プロトコル (IP) アドレスを既に取得している場合 (手動構成の場合など)、このメッセージを使用して、その IP アドレスに関連する追加の構成パラメータを DHCP サーバーから取得します。

この DHCP サーバーの役割は、動的 DNS の導入によって拡張されました。この場合、DHCP サーバーを使用して、クライアントの IP アドレスとホスト名を動的に登録することができます。既定の構成では、DHCP サーバーはクライアントの IP アドレスを DNS サーバーに登録します。登録された IP アドレスはポインタ レコード (PTR RR) ともいいます。

w2ksrt01

DHCP の詳細については、下記を参照してください。

  • RFC 1541

  • RFC 2131

  • 『Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 4 章 DHCP （動的ホスト構成プロトコル）」

自動プライベート IP アドレス指定
Windows 2000 には自動プライベート IP アドレス指定 (APIPA) が導入されており、DHCP サーバーが使用できなくても DHCP クライアントに IP アドレスを割り当てることができます。APIPA は、DHCP サーバーがない単一サブネット ネットワーク上のコンピュータを対象として設計されています。APIPA によって、169.254.0.01 ～ 169.254.255.254 の範囲で IP アドレスが自動的に割り当てられます。つまり、クライアントが起動時にローカル DHCP サーバーとの通信に失敗し、リースを更新できなかった場合、DHCP サーバーとの通信が可能になるまで、APIPA によって割り当てられたアドレスを使用します。これに対し、Windows NT 4.0 では、クライアントが DHCP サーバーにアクセスできない場合でも、期限切れとなっていないリースを使用し続けます。

APIPA を無効にするには、レジストリ エディタで次のようなレジストリ キーを作成します。

HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters \Interfaces<adapter name>

<adapter name> は、APIPA を無効にする動的ホスト構成プロトコル (DHCP) が構成されているアダプタの名前です。

このキーに次の値を追加します。

値名： IPAutoconfigurationEnabled

値の種類： REG_DWORD
16 進数： 0 (値 0 は、このアダプタの APIPA サポートを無効にします。)

メモ IPAutoconfigurationEnabled を指定しなければ、既定値の 1 が仮定されます。この値は APIPA が有効であることを示します。

この変更を反映させるには、コンピュータを再起動する必要があります。http://www.microsoft.com/japan/support/ から、文書 JP244268 を入手し参照してください。

DNS
Windows 2000 では、サービス検索および名前解決のメカニズムとしてドメイン ネーム システム (DNS) を採用しています。DNS システムは Windows 2000 と緊密に統合されており、Active Directory との統合と動的な更新のサポートを提供します。ただし、Windows 2000 では DNS が BIND 8.2.2 に準拠していることが必要です。Windows 2000 の DNS サポートは、NetBIOS に基づく Windows インターネット ネーム サービス (WINS) から標準に準拠したネーム サービスへの移行を目的として導入されたものです。WINS は、これまで Windows クライアントに動的サポートを提供していたサービスです。どちらのサービスもシステム名を動的に更新してデータベースに格納しますが、WINS はフラットな名前空間であり、DNS のような拡張性はありません。DNS に移行したことで、Windows 2000 はインターネット標準に準拠するだけでなく、大規模ネットワークの要求に応じた階層構造のネーム システムを提供することになります。

Windows 2000 の起動/ログオン プロセスでは、DNS を使用して LDAP や Kerberos などのサービスを検索し、1 つ以上のコントローラのアドレスを取得して、そのホスト名と IP アドレスを DNS ゾーン データベースに登録します。

『Windows 2000 リソース キット』および『Notes from the Field 』シリーズの『Building Enterprise Active Directory Services』に、Windows 2000 DNS システムとその要件に関する詳しい説明があります。

詳細については、下記を参照してください。

  • 『Windows 2000 リソース キット 3 分散システム ガイド 上』の「第 3 章 Active Directory での名前解決」

  • 『Windows 2000 リソース キット 6 TCP/IP ガイド』の「第 6 章 Windows 2000 DNS」

  • RFC: 1035, 1036

Kerberos
Kerberos V5 は Windows 2000 の既定の認証プロトコルです。Kerberos は 1980 年代後半に MIT の Athena プロジェクトにおいて開発されたもので、バージョン 5 は IETF RFC 1510 に記載されています。

Kerberos V5 は認証プロトコルです。コンピュータ間の相互認証を実現します。つまり、コンピュータどうしが互いを識別することができます。言うまでもなく、これはセキュリティ システムの基礎をなすものです。ユーザーが本人であるという確認がとれないと、サーバーはリソースへのアクセスを制御することができません。ユーザーの識別に成功すると、サーバーはそのユーザーがリソースへのアクセスを許可されているかどうか確認します。

Kerberos にはユーザーにリソースへのアクセスを許可する機能はありませんが、Microsoft が提供する Kerberos V5 には、ユーザー資格情報を安全に提供できる機能があります。(関連するフィールドの指定については、 http://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/maintain/rsvpker.mspx を参照してください。)

Kerberos には主要なメッセージが 6 つあります。6 つのメッセージは実際には 3 種類の操作であり、それぞれにクライアントからの要求とキー配布センター (KDC) からの応答があります。最初の操作は、クライアント側でパスワードが入力されたときに実行されます。ワークステーション上の Kerberos クライアントが KDC 上の認証サービスに対し、ユーザーが本人であることを証明するチケットの返送を求める "AS" 要求を送信します。認証サービスは、クライアントの資格情報を検証し、チケット保証チケット (TGT) を返送します。

2 番目の操作では、クライアントが KDC 上のチケット保証サービス (TGS) に TGS 要求を送信することによって、サービスまたはリソースへのアクセスを要求します。チケット保証サービスが要求されたサービスのチケットを返送すると、クライアントはそのチケットを必要なサービスまたはリソースがあるサーバーに提出します。

3 番目の操作では、Kerberos クライアントがサービス チケットをサーバーに提出し、サービスまたはリソースへのアクセスを要求します。これらは AP メッセージです。Microsoft 版では、アクセス セキュリティ識別子 (SID) がサーバーに送信されるチケットの一部である PAC に格納されます。クライアントが相互認証を要求した場合を除き、この 3 つ目の操作にサーバーからの応答は必要ありません。クライアントが相互認証を要求した場合は、サーバーがクライアントにユーザー認証システムのタイムスタンプが付いたメッセージを返送します。一般的なドメイン ログオンでは、これら 3 つの操作がすべて完了してから、ユーザーにワークステーションへのアクセスを許可します。

Windows 2000 に組み込まれた Kerberos の詳細については、http://www.microsoft.com/japan/technet/prodtechnol/windows2000serv/techinfo/howitworks/security/kerberos.mspx を参照してください。

Microsoft セキュリティ サービスの詳細については、http://www.microsoft.com/japan/windows2000/techinfo/howitworks/default.asp を参照してください。

LDAP
LDAP (Lightweight Directory Access Protocol) は、クライアントがディレクトリ内の情報の照会、作成、更新、削除を行うために策定されたディレクトリ アクセス プロトコル (DAP) です。当初、LDAP は X.500 ディレクトリのフロントエンドとして使用されていましたが、スタンドアロンのディレクトリ サーバーでも使用できます。Windows 2000 は LDAP のバージョン 3 とバージョン 2 の両方をサポートします。

LDAP プロセス
LDAP に採用された一般的なモデルは、クライアントがサーバーに対するプロトコル操作を実行するというものです。クライアントは操作の内容を示す要求をサーバーに送信します。この要求を受け取ったサーバーは、必要な操作をディレクトリ内で実行します。操作が完了すると、サーバーはクライアントへの応答として操作の結果またはエラーを返送します。

この LDAP 情報モデルは、何らかのオブジェクト (たとえば、"個人") に関する情報が格納されたエントリを基礎とします。エントリは属性で構成されます。属性は種類と 1 つ以上の値からなります。属性には構文があり、それによって設定できる値とディレクトリ操作における値の働きが決まります。属性構文の例としては、IA5 (ASCII) 文字列、URL、公開キーがあります。

LDAP の機能
Windows 2000 は、RFC 2251 に定義された LDAPv3 プロトコルをサポートします。このプロトコルには次のような特徴があります。

  • LDAPv2 (RFC 1777) のすべてのプロトコル要素がサポートされます。

  • TCP を介して直接伝送され、X.500 DAP のセッション/プレゼンテーション層での オーバーヘッドが大幅に軽減されます。

  • ほとんどのプロトコル データ要素 (識別名など) を文字列としてエンコードできます。

  • 他のサーバーへの照会が返されることがあります (次の節を参照)。

  • LDAP で SASL (Simple Authentication and Security Layer) メカニズムを使用し、アソシエーション セキュリティ サービスを提供することができます。

  • 属性値と識別名は、国際標準化機構 (ISO) 10646 文字セットの採用によって、多言語対応となっています。

  • 新しい操作のサポートを追加してプロトコルを拡張したり、コントロールを使って既存の操作を拡張することができます。

LDAP 照会
LDAP 照会は、ドメイン コントローラがクライアント アプリケーションに対し、要求されたオブジェクトのコピーが存在しないこと (正確には、オブジェクトが存在している場合に格納場所となるディレクトリ ツリー部分を持っていないこと) を知らせ、そのオブジェクトが存在する可能性の高い場所を示すための手段です。クライアントは、この情報に基づいて DNS でドメイン コントローラを検索します。どの照会も必ずオブジェクトが確実に存在するドメイン コントローラを参照するのが理想的です。ところが、参照先のドメイン コントローラが別の照会を生成することもあります。しかし通常は、オブジェクトが存在しないことを確認し、クライアントに通知するのに長い時間はかかりません。Active Directory は RFC 2251 に従って照会を返します。

RootDSE
rootDSE は論理名前空間の最上位、つまり LDAP 検索ツリーの最上位を表します。rootDSE の属性は、1 つのドメイン コントローラに固有のディレクトリ パーティション (ドメイン、スキーマ、および構成ディレクトリ パーティション) 、およびフォレスト ルート ドメイン ディレクトリ パーティションの両方を指定します。

rootDSE は LDAP サーバーに関する情報を公開します。この情報には、LDAP サーバーがサポートする LDAP バージョン、サポートされる SASL メカニズム、サポートされるコントロール、およびサブスキーマ サブエントリの識別名が含まれます。

クライアントは、LDAP 操作の開始時に rootDSE に接続します。

LDAP over TCP
LDAP メッセージ PDU (Protocol Data Unit) は直接 TCP バイト ストリームにマッピングされます。RFC 2251 は、サーバー インプリメンテーションがプロトコル リスナをポート 389 で提供することを推奨しています。Active Directory は、ドメイン コントローラの通信の既定ポートとしてポート 389 を使用します。さらに、Active Directory は LDAP Secure Sockets Layer (SSL) の通信用にポート 636 をサポートします。Windows 2000 ドメイン コントローラはグローバル カタログ (GC) サーバーであり、LDAP 通信ではポート 3268、LDAP SSL 通信ではポート 3269 でリッスンします。

起動 / ログオンプロセス中の LDAP
Windows 2000 の起動/ログオン プロセスでは、LDAP を広範囲に使用します。まず、クライアントはドメイン コントローラ ロケータ プロセスにおいて、使用するドメイン コントローラを検索するときに LDAP が使われます。コンピュータまたはユーザーに対応するグループ ポリシー オブジェクトの検索にも LDAP が使用されます。さらに、証明書の自動登録においても、クライアントの証明書を検索するために LDAP を使用します。

詳細については、下記を参照してください。

  • Windows 2000 リソース キット

  • Windows 2000 Active Directory テクニカル リファレンス

  • RFC 1777、1778、1779、1959、1960、1823

  • RFC 2251 ～ 2256

SMB
サーバー メッセージ ブロック (SMB) プロトコルは、MS-Net、LAN Manager、および Windows ネットワークで使用されるリソース共有プロトコルです。また、AT&T、HP、SCO、Samba 経由、その他 33 社以上のベンダが、OS/2、Netware、VMS、および Unix 用の SMB ソリューションを提供しています。SMB プロトコルは、クライアント/サーバー環境において、ファイル、プリンタ、メール スロット、名前付きパイプ、およびアプリケーション プログラミング インターフェイス (API) へのアクセスに使用されます。このプロトコルは、1980 年代半ばに、Microsoft、IBM、Intel の 3 社によって共同開発されました。次の表に示すように、SMB は複数のネットワーク プロトコル上で動作します。

w2ksrt02

SMB 通信では、クライアントがネゴシエートすることによってダイアレクト (dialect) を決定し、サーバーに接続します。接続が確立されると、クライアントはリソースにアクセスするためのコマンド (SMB) をサーバーに送信します。

SMB コマンドは次の 4 種類に大別できます。

  • セッション制御

  • ファイル コマンド

  • 印刷コマンド

  • メッセージ コマンド

SMB のセキュリティ機能は、SMB を使用するプラットフォームの発展に伴って拡張されています。基本となる SMB プロトコル モデルには次の 2 つのセキュリティ レベルが定義されています。

  • 共有レベル - サーバーの共有レベルで保護を適用します。共有ごとにパスワードを設定でき、クライアントはそのパスワードを入力するだけで共有内のすべてのファイルにアクセスできます。これは SMB の最初のセキュリティ モデルであり、Core および CorePlus プロトコルでは、このセキュリティ モデルしか使用できません。Windows for Workgroups vserver.exe では、Windows 95 と同様、共有レベルのセキュリティを既定で実装しています。

  • ユーザーレベル - ユーザーのアクセス権に基づいて各共有の個々のファイルに保護を適用します。各ユーザー (クライアント) がサーバーにログインし、認証を受けなければなりません。認証されると、クライアントにはユーザー ID が割り当てられます。それ以降、サーバーにアクセスするときには、必ずこのユーザー ID を入力します。このモデルは LAN Manager 1.0 以降で使用されています。

SMB プロトコルは、これまで何度も改訂されています。Windows 2000 に実装されている最新バージョンは CIFS (Common Internet File System) で、以前使用されていた NT LM 0.12 に小規模な変更を加えたものです。次の節では、この最新の SMB バージョンについて詳しく説明します。

Windows 2000 の CIFS による SMB のサポート
CIFS (Common Internet File System) は、Windows ネットワーク内のコンピュータ ユーザーがイントラネットおよびインターネット上の共有ファイルを使用するための標準の方法です。CIFS は SMB プロトコルの拡張バージョンです。SMB をオープンかつ異種混在プラットフォーム対応にしたもので、現在はインターネット標準の草案となっています。CIFS は Service Part 3 for Windows NT 4.0 に導入され、Windows 2000 ではネイティブ ファイル共有プロトコルとして採用されました。CIFS は NTLM 0.12 の一種です。

Windows 2000 の SMB/CIFS プロトコル実装
CIFS には、ネットワーク内のコンピュータ間で情報をやりとりするためのコマンドが定義されています。リダイレクタがリモート コンピュータへの要求を CIFS 構造にパッケージします。CIFS はネットワークを介してリモート デバイスに送信できます。リダイレクタは、ローカル コンピュータのプロトコル スタックに要求を送る場合にも CIFS を使用します。CIFS メッセージには大きく分けて次の 4 種類があります。

  • 接続確立メッセージ - サーバーの共有リソースへのリダイレクタ接続を開始/終了するコマンドからなります。

  • 名前空間およびファイル操作メッセージ - リダイレクタがサーバー上のファイルにアクセスし、読み書きするために使用します。

  • プリンタメッセージ - リダイレクタがサーバーの印刷キューにデータを送り、印刷キューの状態を取得するために使用します。

  • その他のメッセージ - リダイレクタがメール スロットおよび名前付きパイプに書き込むときに使用します。

Windows 2000 の CIFS は、分散複製仮想ボリューム (分散ファイル システム [DFS] など)、ファイルおよびレコードのロック、ファイル変更通知、先読み/後書き操作をサポートします。CIFS 通信は、標準 SMB セッションと名前解決メカニズムによって確立されます。

Windows 2000 の SMB/CIFS プロセス
共有ファイルを開くという要求がある場合、I/O はリダイレクタを呼び出し、適切なトランスポート プロトコルを選択するようリダイレクタに要求します。NetBIOS 要求の場合、NetBIOS は IP プロトコルにカプセル化され、ネットワーク上で適切なサーバーに転送されます。要求を受け取ったサーバーは、要求に適ったデータを返送します。

Windows NT 4.0、Windows インターネット ネーム サービス (WINS)、およびドメイン ネーム システム (DNS) では、TCP ポート 134 を使用して名前の解決が行われます。CIFS および NetBT の拡張機能によって、TCP ポート 445 を使用した TCP/IP 接続が可能になりました。Windows 2000 では、どちらの名前解決方法も使用できます。 これらのサービスの一方または両方をレジストリで無効にすることができます。

起動 / ログオンプロセス中の SMB の使用
Windows 2000 クライアントの起動/ログオン プロセスでは、SMB を使用して、そのワークステーションまたはユーザーに該当するグループ ポリシー オブジェクトをロードします。起動/ログオン プロセスで実行される基本的な SMB 操作は、SMB ダイアレクト ネゴシエーションです。これは、クライアントとサーバーがどの SMB ダイアレクトを使用するかを交渉によって決定することです。SMB は、アクセスする共有の DFS 照会を作成するときにも使用されます。クライアントによるグループ ポリシー オブジェクトのロードが、起動/ログオン プロセスの SMB トラフィックの大部分を占めます。

詳細については、下記を参照してください。

  • Windows 2000 TCP/IP プロトコル & サービス ガイド テクニカル リファレンス

MSRPC
RPC の最も簡単な定義は、あるコンピュータが別のコンピュータ上の処理リソースを使用するために作成する要求、となります。 RPC プロトコルでは、あるプロセスがネットワーク内の別のコンピュータにある別のプロセスに対して命令の実行を要求できます。

RPC プロセスは以下のコンポーネントで構成されます。

  • クライアントアプリケーション - リモート実行を要求します。

  • クライアントスタブ - コールと標準ネットワーク表現 (NDR) 形式の間で変換を行います。

  • クライアント RPC ランタイムライブラリ - NDR をネットワーク メッセージに変換します。

  • ネットワークトランスポート - ネットワーク通信を処理します。

  • サーバー RPC ランタイムライブラリ - NDR をネットワーク メッセージに変換します。

  • サーバースタブ - コールと標準ネットワーク表現 (NDR) 形式の間で変換を行います。

  • サーバーアプリケーション - 要求された命令を実行します。

RPC のプロシージャは、インターフェイス番号 (UUID)、オペレーション番号 (opnum)、およびバージョン番号で一意に識別されます。インターフェイス番号は関連するリモート プロシージャのグループを表します。たとえば、インターフェイスの 1 つである netlogon の UUID は 12345678-1234-ABCD-EF00-01234567CFFB です。

次に、RPC コールの例を示します。

MSRPC: 対象 - 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、Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX)、NetBIOS Enhanced User Interface (NetBEUI) などの 7 種類のトランスポート プロトコルの上位層として機能します。

ほとんどの RPC インターフェイスは、ネットワーク通信に動的ポートを使用します。この場合、終了ポイント マッパー (End Point Mapper) というインターフェイスを使用する必要があります。終了ポイント マッパーは、常に TCP/IP 用のポート 135 でリッスンするインターフェイスで、その UUID は E1AF8308-5D1F-11C9-91A4- 08002B14A0FA です。

クライアントがプロシージャ コールを実行するためには、先にインターフェイスにバインドしなければなりません。バインド プロセスが完了していれば、終了ポイント マッパーに要求を送信することができます。この要求にはターゲット インターフェイスの UUID を指定します。終了ポイント マッパーは、クライアントが使用する通信ポートのポート番号を送り返します。

次の表は、このプロセスの通信シーケンスを示したものです。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

MSRPC

対象 - RPC バインド : UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA Ul

2

サーバー

クライアント

MSRPC

対象 - RPC バインド肯定応答 : call 0x1 assoc grp 0xC85D xmit 0x16D0 recvU

3

クライアント

サーバー

MSRPC

対象 - RPC 要求 : call 0x1 opnum 0x3 context 0x0 hint 0x84

4

サーバー

クライアント

MSRPC

対象 - RPC 応答 : call 0x1 context 0x0 hint 0x80 cancels 0x0

MSRPC を SMB にカプセル化することもできます。この場合、クライアントとサーバーは既に開いているファイルのハンドルを使ってデータを交換します。

Windows 2000 の起動/ログオン プロセスでは、インターフェイスとして Netlogon とディレクトリ複製サービス (DRS) を使用します。Netlogon インターフェイスは、ドメイン内のクライアントとドメイン コントローラ間のセキュリティで保護された通信チャネルを確立します。ディレクトリ複製サービス (DRS) は、主としてドメイン コントローラとグローバル カタログ サーバーの通信に使用されます。ただし、このサービスはログオン プロセスで使用されるインターフェイスを提供します。このサービスによって、名前が LDAP で使用可能な形式に変換されます。

詳細については、下記を参照してください。

  • 『Notes from the Field』シリーズ『Building Enterprise Active Directory Services』の「Active Directory Client Network Traffic」

  • TechNet の「Analyzing Exchange RPC Traffic Over TCP/IP」- [Q159298]

タイムサービス
Windows 2000 には、タイム サービス W32Time (Windows Time) が組み込まれています。このサービスは、ドメイン内の Windows 2000 クライアント間でシステム時間を同期させます。時間の同期は、コンピュータの起動プロセス中に行われます。

時間の同期では、ドメイン内の各システムにおいて次のような階層が使用されます。

  • すべてのクライアント デスクトップは、受信タイム パートナーとして認証ドメイン コントローラを指名します。

  • すべてのメンバ サーバーは、クライアント デスクトップと同じプロセスに従います。

  • すべてのドメイン コントローラは、受信タイム パートナーとしてプライマリ ドメイン コントローラ (PDC) 操作マスタを指名します。

  • PDC 操作マスタは、ドメインの階層に従って受信タイム パートナーを選択します。

注
操作マスタについては、『Windows 2000 Server リソース キット 分散システム ガイド』の第 7 章を参照してください。

詳細については、下記を参照してください。

  • Q216734 - 時間同期プロセスと権限を持つタイム ソースのセットアップ方法に関する説明があります。

  • RFC: 1769、2030

Windows 2000 のドメイン認証方法
Windows 2000 は、ドメイン ログオンの認証方法として、Kerberos と NTLM の 2 つをサポートしています。Windows 2000 の認証方法として Kerberos を使用すると、既定の Windows 認証プロトコルが NTLM からインターネット標準に基づくプロトコルに変わります。

Windows 2000 の既定の認証プロトコルは、RFC 1510 に定義された MIT の Kerberos バージョン 5 に基づいています。認証方法として Kerberos を使用すると、Windows ネットワーク内のクライアント、サーバー、ドメイン コントローラの間でセキュリティ情報を交換する方法が根本的に変わります。

Kerberos では、クライアントがいわゆるセッション チケットを KDC に要求します。セッション チケットには、サーバーがクライアントを認証するために必要な情報が含まれています。クライアントはセッション チケットを送信して、アクセスしようとしているリソースについて認証を受けます。Kerberos は、クライアントからリソースに認証情報を提供するだけです。リソースへのアクセス許可を与えるわけではなく、システムの使用許可を与えるにすぎません。

従来からのサポートを維持するために、Windows 2000 は NTLM 認証もサポートします。Windows 2000 が認証方法として NTLM を使用するのは、Windows 2000 ドメインではなく NT 4 ドメインまたはワークグループのメンバである場合と、認証に NTLM を使用しなければならない古いアプリケーションにアクセスする必要がある場合です。

ここでは、Kerberos 認証プロトコルとその起動/ログオン プロセスでの働きに焦点を当てます。NTLM プロトコルを使用した起動/ログオン プロセスは Windows NT 4.0 と同じであり、『Notes from the Field 』シリーズの『Building Enterprise Active Directory Services』に詳しい説明があります。

詳細については、下記を参照してください。

  • 『Windows 2000 リソース キット 3 分散システム ガイド 上』の「第 11 章 認証」

Windows 2000 起動/ログオン プロセスの説明

Windows 環境でのログオンというと、ユーザーが Ctrl + Alt + Del キーを押し、ユーザー名とパスワード (資格情報) を入力してシステムにアクセスするプロセスが思い浮かびます。この資格情報によって、ユーザーはローカル コンピュータ上のリソースへのアクセス権を得ることができます。また、コンピュータがネットワークに接続されている場合には、資格情報によって、アプリケーション、ファイル、プリンタなど、ユーザーがアクセスを許可されているネットワーク上のリソースへのアクセス権が得られます。

ユーザーにリソースへのアクセスを許可するプロセスは、ユーザーがシステムにログオンしたときではなく、それよりも前、システムを起動したときに開始されます。Windows 2000 ドメイン環境では、コンピュータがそれ自体をドメインの有効なメンバとして確立しなければ、ユーザーがシステムにログオンしてネットワーク上のリソースにアクセスすることはできません。

以下の節では、Windows 2000 の起動/ログオン プロセスで実行される処理の手順について説明します。Windows 2000 コンピュータのみの環境で発生するネットワーク トラフィックに着目するために、すべてのコンピュータで NetBIOS over TCP/IP 機能を無効にします。

ただし、各コンピュータを Windows NT および Windows 95/98 クライアントと相互稼働するように構成できます。Windows NT クライアントの起動/ログオン トラフィックの詳細については、『Notes from the Field』シリーズの『Building Enterprise Active Directory Services』の「Active Directory Client Network Traffic」を参照してください。次に、この構成を図で示します。

w2ksrt03

コンピュータ起動プロセス

Windows 2000 ドメインのメンバであるコンピュータは、起動プロセスによって、所属するドメインに接続します。この起動プロセスによって、コンピュータ上のサービスはネットワーク上のコンピュータと対話することができます。さらに重要なのは、起動プロセスはユーザーが対話形式でログオンするために必要であることです。次の図にコンピュータ起動プロセスの流れを示します。

w2ksrt04

ネットワークへの接続
コンピュータ起動プロセスは、コンピュータがネットワークに接続し、TCP/IP プロトコルをロードしたときに開始されます。TCP/IP の構成には、静的構成と動的構成があります。動的構成とは、DHCP を使用することを意味します。DHCP は、Windows Server オペレーティングシステムのコアコンポーネントであり、仕様が詳細に定義された技術です。静的アドレス指定とは、コンピュータ上で TCP/IP 構成情報を手動で設定することを意味します。通常、静的アドレスは、ルーターやサーバーなどの変更頻度があまり高くないリソースで使用されます。このホワイトペーパーの例では、静的アドレスを使用するシステムはサーバーだけです。

DHCP プロセスでは、クライアントがネットワークに接続すると、下の表に示すフレームが生成されます。最初の 4 フレームの「発見」、「提示」、「要求」、「肯定応答」が DHCP プロセスの処理順序を表します。これらのフレームでは 1,342 バイト (DHCP フレームあたり約 342 バイト) のネットワーク トラフィックが生成されますが、このトラフィック量は指定された DHCP オプションの数によって変わります。 フレーム 5 ～ 8 の Reverse ARP (RARP) は、取得したアドレスを使用しているコンピュータがほかにないことを確認するためにクライアントが実行するものです。各 RARP フレームのネットワーク トラフィックは約 60 バイトで、アドレス チェック シーケンス全体のネットワーク トラフィックは約 300 バイトとなります。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

*BROADCAST

DHCP

発見

2

サーバー

*BROADCAST

DHCP

提示

3

クライアント

*BROADCAST

DHCP

要求

4

サーバー

*BROADCAST

DHCP

肯定応答

5

クライアント

*BROADCAST

ARP_RARP

ARP : 要求、ターゲット IP: 10.0.0.100

6

クライアント

*BROADCAST

ARP_RARP

ARP : 要求、ターゲット IP: 10.0.0.100

7

クライアント

*BROADCAST

ARP_RARP

ARP : 要求、ターゲット IP: 10.0.0.100

8

サーバー

*BROADCAST

ARP_RARP

ARP : 応答、ターゲット IP : 10.0.0.100

ここで注意しなければならないのは、クライアントが既にリースを取得している場合は、再起動したときにリースを更新するだけで済むことです。更新プロセスでは、要求パケットと肯定応答パケット (下の表の最初の 2 フレーム) しか生成されません。ただし、この場合もクライアントは RARP プロセスを実行し、アドレスが使用されていないことを確認します。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

*BROADCAST

DHCP

要求

2

サーバー

*BROADCAST

DHCP

肯定応答

3

クライアント

*BROADCAST

ARP_RARP

ARP : 要求、ターゲット IP : 10.0.0.100

4

クライアント

*BROADCAST

ARP_RARP

ARP : 要求、ターゲット IP : 10.0.0.100

5

クライアント

*BROADCAST

ARP_RARP

ARP : 要求、ターゲット IP : 10.0.0.100

6

サーバー

*BROADCAST

ARP_RARP

ARP : 応答、ターゲット IP : 10.0.0.100

ドメインコントローラの検出
クライアント コンピュータは、起動時にそのつど最新の構成状態を取得する必要があります。そのため、所属するドメイン内で少なくとも 1 つのコントローラを見つけなければなりません。

Windows 2000 ドメインでは、コントローラは LDAP サーバーでもあります。使用可能なコントローラのリストを取得するには、DNS に対して _ldap._tcp.dc._msdcs.DnsDomanName という名前の SRV リソース レコードを問い合わせるクエリを実行します。

このクエリのフレームは次のようになります。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

DNS

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

2

サーバー

クライアント

DNS

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

Windows 2000 ドメインは管理の境界であり、ネットワーク構造に依存しません。ある特定の環境に属するコンピュータをサイトにグループ化することができます。Windows 2000 のサイトとは、信頼性の高い高速リンクで接続された IP サブネットの集まりを意味します。サイトの概念においては、目安として LAN 速度以上のネットワークを高速ネットワークと考えます。1 つのドメインが複数のサイトにまたがることができ、また複数のドメインが 1 つのサイトを包含することもできます。

w2ksrt05

クライアントのロケータ サービスは起動プロセスにおいて最も近いサイトを見つけようとし、そのサイト名をレジストリに保存します。クライアントは自分がどのサイトに属しているかわかっている場合は、そのサイト内のコントローラを検索するクエリを DNS サーバーに送信します。このようなクエリの形式は _ldap._tcp.Default-First-Site-Name._sites.dc._msdcs.DnsDomanName となります。

このクエリのフレームは次のようになります。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

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

サーバー

クライアント

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.

この DNS クエリでは、"Default-First-Site-Name" で LDAP サービスを検索しています。Default-First-Site-Name は、Windows 2000 ドメイン サイトの既定の名前です。

サイトに登録されたドメイン コントローラを表示するには、Microsoft 管理コンソールの DNS スナップインを使用します。次の図は、このスナップインの画面です。展開されたツリーに、サイトの Kerberos および LDAP サービスを登録したドメイン コントローラが表示されています。

w2ksrt06

要求された情報が見つかった場合、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.

クライアントは、それ以降の通信プロセスのために 1 つのコントローラを無作為に選択します。クライアントはサイトの各メンバを近い場所にあるコンピュータと見なすため、ローカル サブネットとリモート サブネットを区別しません。

前に説明したとおり、サイトという概念がコントローラの選択に影響を及ぼすことがあります。ドメイン コントローラを検索した後、クライアントはそのコントローラが最短距離にあるコントローラかどうかを LDAP クエリで確認します。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

LDAP

ProtocolOp : SearchRequest (3)

2

サーバー

クライアント

LDAP

ProtocolOp : SearchResponse (4)

3

クライアント

サーバー

LDAP

ProtocolOp : SearchRequest (3)

4

サーバー

クライアント

LDAP

ProtocolOp : SearchResponse (4)

このクエリでは、以下の属性が一致するかどうかを確認します。

  • DNS ドメイン名

  • ホスト名

  • ドメイン グローバル一意識別子 (GUID)

  • ドメイン セキュリティ ID (SID)

これとまったく同じ情報がコントローラの Active Directory データベースにある場合は、コントローラに関する以下の情報が返送されます。

  • DomainControllerName

  • DomainControllerAddress

  • DomainControllerAddressType

  • DomainGUID

  • DomainName

  • DNSForestName

  • DCSiteName

  • ClientSiteName

クライアントにとって最も重要な情報はサイト名です。クライアントがこのコントローラのサイトに属している場合は、次に示すサーバーからの応答の 16 進ダンプにはサイト名が 1 つしか含まれません。

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 ...U...À[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„...U..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 .HD‚ˆNyUG¨Ê..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„.........

クライアントが別のサイトにあるコントローラに接続している場合は、サーバーからの応答にクライアントのサイト名も含まれています。 

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 ...U...µÈ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 .HD‚ˆNyUG¨Ê..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 サーバーにもう 1 つクエリを送り、自分のサイト内のコントローラのリストを要求します。このクエリのフレームは次のようになります。クライアントは、Site2 でドメイン コントローラを検索し、LDAP の後に Site1 に切り替えています。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

DNS

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

2

サーバー

クライアント

DNS

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

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 _ldap._tcp.Site1._sites.dc._msdcs.dcclab.local.

8

クライアント

サーバー

DNS

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

各サイトにドメイン コントローラが必要なわけではありません。ドメイン コントローラはフォレスト内のすべてのサイトと複製コストをチェックします。ドメイン コントローラがなく、接続コストが最低であるサイトに、ドメイン コントローラが自己登録します。このプロセスを自動サイト カバレッジともいいます。したがって、クライアントは接続コストが最も安い近接するドメイン コントローラを使用することになります。

最短距離のドメイン コントローラを見つける既定のプロセスは 10 個のネットワーク パケットからなり、約 2,000 バイトのトラフィックを生成します。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

ARP_RARP

ARP : 要求

2

サーバー

クライアント

ARP_RARP

ARP : 応答

3

クライアント

サーバー

DNS

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

4

クライアント

サーバー

DNS

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

5

サーバー

クライアント

DNS

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

6

サーバー

クライアント

DNS

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

7

クライアント

サーバー

LDAP

ProtocolOp : SearchRequest (3)

8

サーバー

クライアント

LDAP

ProtocolOp : SearchResponse (4)

9

クライアント

サーバー

LDAP

ProtocolOp : SearchRequest (3)

10

サーバー

クライアント

LDAP

ProtocolOp : SearchResponse (4)

11

クライアント

サーバー

ARP_RARP

ARP : 要求

12

サーバー

クライアント

ARP_RARP

ARP : 応答

ドメイン検索プロセスの詳細については、『Windows 2000 リソース キット 3 分散システム ガイド 上』の「第 3 章 Active Directory での名前解決」を参照してください。

ドメインコントローラとのセキュリティで保護されたチャネルの確立
クライアントは、サイトとドメイン コントローラを確認したら、次にドメイン コントローラに対してセキュリティで保護されたチャネルを作成します。セキュリティ保護されたチャネルとは、ドメイン メンバとドメイン コントローラの間に確立された接続のことで、ドメイン情報の取得、Active Directory 内のコンピュータ情報 (コンピュータ パスワードなど) の更新、ドメイン メンバシップの検証には、このチャネルを使用します。

このプロセスは、ドメイン メンバとドメイン コントローラが使用する SMB ダイアレクトのネゴシエーションから始まります。SMB プロトコルは、1984 年に発表されて以来、多くの改訂と拡張を繰り返してきました。そのため、クライアントとサーバーが必ずしも同じ SMB ダイアレクトを使用しているとは限りません。ここでは、クライアントとサーバーがどちらも Windows 2000 であり、ダイアレクトは NTLM 0.12 です。このダイアレクトでは、エクスチェンジで Unicode を使用できます。それ以前のダイアレクトでは、エクスチェンジが ASCII で行われていました。Unicode 文字列には、ファイル名、リソース名、およびユーザー名を含めることができるという利点があります。

次に、クライアントはターゲットの netlogon インターフェイスに接続します。このプロセスでは、クライアントをサーバーの正しいポートに接続するために終了ポイント マッパーが必要となります。最後に、クライアントはこのインターフェイスに 3 つのコール (NetrServerReqChallenge、NetrServerAuthenticate3、NetrLogonGetdomainInfo) を送信します。このプロセスのトラフィックは約 4,600 バイトです。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

SMB

C negotiate, Dialect = NT LM 0.12

2

サーバー

クライアント

SMB

R negotiate, Dialect # = 5

3

クライアント

サーバー

MSRPC

対象 - RPC バインド : UUID E1AF8308-5D1F-11C9-91A

4

サーバー

サーバー

MSRPC

対象 - RPC バインド肯定応答 : call 0x1 assoc grp 0xD52C

5

クライアント

サーバー

MSRPC

対象 - RPC 要求 : call 0x1 opnum 0x3 contex

6

サーバー

クライアント

MSRPC

対象 - RPC 応答 : call 0x1 context

7

クライアント

サーバー

MSRPC

対象 - RPC バインド : UUID 12345678-1234-ABCD-EF0

8

サーバー

クライアント

MSRPC

対象 - RPC バインド肯定応答 : call 0x1 assoc grp 0x1C04B

9

クライアント

サーバー

R_LOGON

RPC クライアント コール logon : NetrServerReqChallenge(..)

10

サーバー

クライアント

R_LOGON

RPC サーバー応答 logon : NetrServerReqChallenge()

11

クライアント

サーバー

R_LOGON

エラー : Bad Opcode (機能が存在しない)

12

サーバー

サーバー

R_LOGON

エラー : Bad Opcode (機能が存在しない)

13

クライアント

クライアント

MSRPC

対象 - RPC バインド : UUID 12345678-1234-ABCD-EF0

14

サーバー

クライアント

MSRPC

対象 - RPC バインド肯定応答 : call 0x3 assoc grp 0x1C04B

15

クライアント

クライアント

R_LOGON

エラー : Bad Opcode (機能が存在しない)

16

サーバー

クライアント

R_LOGON

エラー : Bad Opcode (機能が存在しない)

注
Netmon の現バージョンは、 NetrServerAuthenticate3 と NetrLogonGetdomainInfo の 2 つのコールを正しく解決できません。上の表では、これらのコールが Bad Opcode というエラーとして示されています。

重要 Windows NT ドメインを Windows 2000 にアップグレードした後の混在環境では、次のような状況に注意が必要です。Windows 2000 クライアントが認証を受けるドメイン コントローラとして使用できるのが Windows NT 4.0 バックアップ ドメイン コントローラだけである場合、セキュリティで保護されたチャネルを確立することはできません。これはセキュリティを高めるために意図的に行われています。Windows 2000 クライアントは、属しているドメインのタイプを把握しており、セキュリティで保護されたチャネルを確立するときに認証方法を下位のレベルに合わせることはしません。以下のトレース シーケンスは、このシナリオを示したものです。このトレース シーケンスは、一見すると Windows 2000 クライアントが Windows NT 4.0 ドメイン内にある場合と同じです。重要な部分はその後です。クライアントがセキュリティで保護されたチャネルを確立できなかったため、ドメインの認証が失敗しています。

Kerberos 認証とセッションの作成
セキュリティで保護されたチャネルが確立されると、クライアントはコントローラとの IPC$ セッションを確立するために必要なすべてのチケットを取得します。Windows 2000 ドメイン コントローラはすべて Kerberos キー配布センター (KDC) であるため、クライアントは LDAP サービスの場合と同じように最短距離にある KDC を検出しようとします。

クライアントが実行しなければならない最初の操作は、AS チケットの交換による認証です。認証に成功すると、クライアントはコントローラ (コンピュータ名 $) とコントローラ上の Kerberos サービス (krbtgt) のチケットを要求します。このパケット交換では、約 8KB のトラフィックが生成されます。 実際のサイズは、クライアントが属するグローバル グループおよびユニバーサル グループの数によって変わります。グループが 1 つ増えるごとにトラフィックが約 28 バイト増加します。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

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

サーバー

クライアント

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

クライアント

サーバー

LDAP

LDAP ProtocolOp : SearchRequest (3)

4

サーバー

サーバー

LDAP

LDAP ProtocolOp : SearchResponse (4)

5

クライアント

サーバー

Kerberos

Kerberos KRB_AS_REQ (TGT の要求)

6

サーバー

クライアント

Kerberos

Kerberos KRB_AS_REP

7

クライアント

サーバー

Kerberos

Kerberos KRB_TGS_REQ (DC$ の要求)

8

サーバー

クライアント

Kerberos

Kerberos KRB_TGS_REP

9

クライアント

サーバー

R_LOGON

Kerberos KRB_TGS_REQ (Kerberos サービスの要求)

10

サーバー

クライアント

R_LOGON

Kerberos KRB_TGS_REP

w2ksrt07

クライアントが取得したチケットは、Microsoft リソース キットの Kerbtray ユーティリティを使って表示できます。 最後に、クライアントはコントローラの IPC$ 共有に接続します。このプロセスのトラフィックは約 3,600 バイトです。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

SMB

SMB C session setup & X

2

サーバー

クライアント

SMB

SMB R session setup & X

3

クライアント

サーバー

SMB

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

4

サーバー

クライアント

SMB

SMB R tree connect & X, Type = IPC$

DFS 照会
次に、クライアントは分散ファイル システム (DFS) 照会を実行します。DFS 照会は、クライアントがサーバーから DFS に関する情報を取得するための DFS クライアント/サーバー プロトコルです。DFS 照会は必要に応じて実行されます。一般的な照会プロセスは、クライアントが SMB パケットを DFS 照会として送信することによって開始されます。サーバーがこの要求を DFS ドライバに渡すことで、要求の処理が完了します。これ以降、ネットワーク共有にアクセスするときに、クライアントがその共有に関する情報を取得していなければ、DFS 照会要求が発生します。Windows 2000 は DFS バージョン 5.0 クライアントです。このバージョンでは、DFS ルートまたはリンクへの照会を一定時間 (管理者が設定可能) キャッシュに保持しておくことができます。

クライアントが起動すると、クライアント コンピュータが属するドメイン内の 1 つのドメイン コントローラにいくつかの DFS 照会要求が送られます。このプロセスは、クライアントがドメイン ベースの DFS 共有に対する要求を処理するために必要です。

最初の 2 つの要求は DFS クライアントを初期化するためのものです。1 つ目の要求によって、クライアントがアクセスできる信頼された Windows 2000 ドメインすべての名前を確認します。 2 つ目の要求では、ドメイン内のドメイン コントローラをローカル サイトから順に配列したリストを取得します。返された名前のリストには、ドメインの Netbios 名と DNS 名の両方が含まれています。

3 つ目の要求は、sysvol 共有に接続する実際のサーバー パスを取得するのが目的です。

DFS 照会プロセスでは、最低 394 バイトのトラフィックが生成されます。実際のトラフィック量は、応答として返される信頼されたドメインとローカル ドメイン内の DC の数によって変わります。

既定では、ドメイン構成を調べる DFS 照会は 15 分間隔で繰り返されます。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

SMB

C transact2 NT Get DFS Referral

2

サーバー

クライアント

SMB

R transact2 NT Get DFS Referral (フレーム 105 への応答)

次に、クライアントは ping を実行し、LDAP 要求を送信して、もう一度ドメイン コントローラを取得します。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

ICMP

エコー : 10.00.00.100 → 10.00.00.22

2

サーバー

クライアント

ICMP

エコー応答 : 10.00.00.100 ← 10.00.00.22

3

クライアント

サーバー

UDP

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

4

サーバー

クライアント

UDP

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

名前の変換
Active Directory 内のオブジェクトには、それぞれに名前が付いています。ユーザー プリンシパル名、識別名、Windows NT の "ドメイン \ ユーザー名" など、さまざまな形式の名前があります。名前は文字列でなくてもかまいません。オブジェクトを一意に識別するものは、すべて名前と見なすことができます。パラメータとして名前を必要とするサービスによっては、名前の形式を変換しなければならない場合があります。

名前の形式を変換するには、DsCrackNames という API を使用します。この API については、Microsoft Developers Network (MSDN) で詳しい情報を入手できます。クライアントがこの関数を呼び出すためには、まず DSBind でハンドルをディレクトリ サービスにバインドし、操作の終了後に DSUnbind でディレクトリとのバインドを解除する必要があります。

以下のフレームは、名前変換プロセスに伴うネットワーク トラフィックを示しています。このプロセス全体のトラフィックは約 6,600 バイトです。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

MSRPC

対象 - RPC バインド : UUID E1AF8308-5D1F-11C9-91A4-08002B14A0FA call 0

2

サーバー

クライアント

MSRPC

対象 - RPC バインド肯定応答 : call 0x1 assoc grp 0xD52D xmit 0x16D0 recv 0x1

3

クライアント

サーバー

MSRPC

対象 - RPC 要求 : call 0x1 opnum 0x3 context 0x0 hint 0x84

4

サーバー

クライアント

MSRPC

対象 - RPC 応答 : call 0x1 context 0x0 hint 0x80 cancels 0x0

5

クライアント

サーバー

MSRPC

対象 - RPC バインド : UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2 call 0

6

サーバー

クライアント

MSRPC

対象 - RPC バインド肯定応答 : call 0x1 assoc grp 0x1C04C xmit 0x16D0 recv 0x

7

クライアント

サーバー

MSRPC

対象 - RPC Alt-Cont : UUID E3514235-4B06-11D1-AB04-00C04FC2DCD2 call 0

8

サーバー

クライアント

MSRPC

対象 - RPC Alt-Cont Rsp : call 0x1 assoc grp 0x1C04C xmit 0x16D0 recv 0x

9

クライアント

サーバー

MSRPC

対象 - RPC 要求 : call 0x1 opnum 0x0 context 0x0 hint 0x38

10

サーバー

クライアント

MSRPC

対象 - RPC 応答 : call 0x1 context 0x0 hint 0x3C cancels 0x0

11

クライアント

サーバー

MSRPC

対象 - RPC 応答 : call 0x2 opnum 0xC context 0x0 hint 0x6E

12

サーバー

クライアント

MSRPC

対象 - RPC 応答 : call 0x2 context 0x0 hint 0xB4 cancels 0x0

13

クライアント

サーバー

MSRPC

対象 - RPC 応答 : call 0x3 opnum 0xC context 0x0 hint 0x6E

14

サーバー

クライアント

MSRPC

対象 - RPC 応答 : call 0x3 context 0x0 hint 0xAC cancels 0x0

15

クライアント

サーバー

MSRPC

対象 - RPC 要求 : call 0x4 opnum 0x1 context 0x0 hint 0x14

16

サーバー

クライアント

MSRPC

対象 - RPC 応答 : call 0x4 context 0x0 hint 0x18 cancels 0x0

LDAP RootDSE
次に、クライアントは LDAP RootDSE からの情報を要求します。RootDSE は LDAP 3.0 の仕様に定義された標準属性です。RootDSE には、ディレクトリ サーバーに関する機能や構成などの情報が収められています。この要求に対する応答として、RFC 2251 に定義された標準セットの情報が返されます。この情報の項目の 1 つに、サポートされる SASL (Simple Authentication and Security Layer) メカニズムがあります。この例では、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) によってロードします。

ポリシーの検索

以下のフレームは、クライアントによる LDAP ディレクトリへのバインド操作を示しています。 LDAP クエリで情報を検索するためには、クライアントがディレクトリ サービスにバインドする必要があります。ログオン プロセスのこの段階では、クライアントが Active Directory にバインドして、適用されるグループ ポリシーを検索します。この表には、適用されるグループ ポリシーを調べる LDAP 要求も示されています。1 回のバインド操作で発生するトラフィックは約 1,675 バイトです。この例では、ポリシーの検索で約 3,527 バイトのトラフィックが発生します。

フレーム

送信側

受信側

プロトコル

説明

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

適用されるポリシーを確認した後、クライアントはもう 1 つ DFS 照会を実行します。Windows 2000 のクライアントによる共有ポイントへの接続試行のほとんどは、この操作の後に行われます。

SMB を使用したポリシーのロード
ポリシーのロードは、クライアントが SYSVOL (ドメイン コントローラ上の標準共有ポイント) に接続し、ポリシーをダウンロードすることで完了します。このプロセスのトラフィックは 1,018 バイトです。

w2ksrt08

この例の構成はきわめて単純であるため、トラフィックはさほど多くありませんが、グループ ポリシーが複雑になれば、それにつれてトラフィックも増大します。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

SMB

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

2

サーバー

クライアント

SMB

R tree connect & X, Type = ÿ_

3

クライアント

サーバー

SMB

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

4

サーバー

クライアント

SMB

R NT create & X, FID = 0x4000

5

クライアント

サーバー

SMB

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

6

サーバー

クライアント

SMB

R read & X, Read 0x1a

クライアント証明書の自動登録
グループ ポリシー オブジェクトが適用されるたびに、クライアント側で自動登録イベントが発生します。自動登録イベントでは以下の操作が実行されます。

  • コンピュータの証明書の状態をチェックし、OK でない場合はクライアントがクライアントを自動登録する。

  • Active Directory のエンタープライズ ルート ストア (= PKI 信頼アンカー) から企業の証明機関 (CA) 証明書をダウンロードする。

  • スマート カード証明書を発行できる CA の証明書を Active Directory からダウンロードする。

クライアントは LDAP RootDSE (上記のフレームを参照) の情報を取得するための要求を実行し、LDAP を使用して自動登録を完了します。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

DNS

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

2

サーバー

クライアント

DNS

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

3

クライアント

サーバー

DNS

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

4

サーバー

クライアント

DNS

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

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)

上記のフレーム 3 をよく見ると、ドメイン内の公開キー サービスの構成情報を取得するための要求であることがわかります。このフレームの詳細は以下のとおりです。

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 Port : Unknown (1051); Dst Port : Network Time Protocol (123); Length = 76 (0x4C)

2

サーバー

クライアント

NTP

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

ダイナミックドメインネームシステムの更新
起動プロセスの最後の段階では、クライアントが DNS データベースでクライアント名を更新します。Windows 2000 の動的な DNS 更新は RFC 2136 に基づいています。このプロセスは RFC 2136 に基づいています。

まず、クライアントは DNS サーバーがクライアントのゾーンに対する権限を持っているかどうか確認します。このプロセスで発生するトラフィックは 225 バイトです。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

DNS

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

2

サーバー

クライアント

DNS

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

次に、クライアントは DNS サーバーでクライアント名の動的な更新を実行します。 A RR と PTR RR の両方を更新しなければならない場合、このプロセスのトラフィックは約 1,800 バイトとなります。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

DNS

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

2

サーバー

クライアント

DNS

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

3

クライアント

サーバー

DNS

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

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

6

サーバー

クライアント

DNS

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

動的な更新の実際のパケット サイズは、さまざまな条件によって変化します。まず第一に、クライアントが登録済みかどうかが関係します。また、登録済みのエントリとの競合があるかどうかもパケット サイズに影響します。クライアント トラフィックの面では DHCP が使用中かどうかによっても変わります。このシナリオでは、既定の構成でクライアントが A RR を更新し、PTR RR の更新は DHCP サーバーが担当します。

最後に、DNS サーバーの構成とセキュリティで保護された動的な更新の動作設定もトラフィックに影響します。

注 DDNS を使用していない環境では、クライアントの動的な更新機能を無効にすることを検討してください。これによって、この機能をサポートしていない環境でクライアントが動的な更新を実行することによる不要なネットワーク トラフィックを発生させずにすみます。この機能を無効にするには、個々のネットワーク接続の TCP/IP 詳細設定の中で変更します。TCP/IP 詳細設定の変更は、次に示す画面で行います。

w2ksrt09

プロセスの完了
コンピュータ起動プロセスは、クライアントがドメイン コントローラとの接続を次の表に示すような順序で切断することで完了します。このプロセスで発生するトラフィックは 473 バイトです。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

SMB

C tree disconnect

2

サーバー

クライアント

SMB

R tree disconnect

3

クライアント

サーバー

SMB

C tree disconnect

4

サーバー

クライアント

SMB

R tree disconnect

5

クライアント

サーバー

SMB

C logoff & X

6

サーバー

クライアント

SMB

R logoff & X

このトラフィック シーケンスは、ネットワーク トレースでコンピュータ起動とユーザー ログオンの区切りを見つけるのに役立ちます。これでシステムは使用可能な状態になり、Ctrl +Alt +Del キーを押すように促すダイアログ ボックスが表示されます。

ユーザー ログオン

概要
システムの起動プロセスが完了すると、Ctrl +Alt +Del キーを押すように要求するダイアログ ボックスが表示されます。ユーザーは、このシステムからドメイン ログオンを実行できます。Ctrl +Alt +Del キーを押し、有効なドメイン ユーザー資格情報 (ユーザー名とパスワード) を入力すると、対話形式のクライアント ログオン プロセスが開始されます。Windows NT シェルがロードされると、このプロセスが完了し、ユーザーは対話形式でシステムを使用できるようになります。重要な点は、ユーザー ログオン プロセスは本質的にコンピュータ起動プロセスを簡略化したもので、これまで説明してきたプロセスのサブセットを使用するということです。このプロセスを図で示すと次のようになります。

w2ksrt10

ログオン プロセスの流れ

ユーザーの識別
Windows 2000 には、ログオン時にアカウント情報を入力する 3 通りの方法があります。1 つ目は、セキュリティ アカウント マネージャ (SAM) アカウント名を使用し、ドメインを選択するという方法です。これが既定のログオン方法です。2 つ目は、<user>@<domain-org-company-com> という形式の完全修飾名を使用する方法です。 3 つ目の方法では、ユーザー プリンシパル名 (UPN) を使用します。UPN については、Windows 2000 リソース キットで次のように説明されています。

ユーザー プリンシパル名 (UPN) は、個々のユーザーを一意に表すメール アドレスに似た形式の名前です。UPN は、ユーザー識別部とドメイン部という 2 つの部分で構成されます。この 2 つの部分を "@" で区切るため、形式は <ユーザー>@<DNSドメイン名> となります (例： liz@noam.reskit.com)。各ユーザーには既定の UPN が自動的に割り当てられます。<ユーザー> の部分はログオン名と同じで、<DNS ドメイン名> の部分にはユーザー アカウントが属する Active Directory ドメインの DNS 名が入ります。UPN を使ってログオンした場合は、ログオン ダイアログ ボックスでドメインを選択する必要はありません。

UPN は任意の値に設定できます。たとえば、Liz というユーザーのアカウントが noam.reskit.com ドメインにあっても、このユーザーの UPN を liz@reskit.com とすることができます。ユーザーがログオンすると、検証するユーザー アカウントを見つけるために、UPN が一致するユーザー アカウントがグローバル カタログで検索されます。UPN をドメイン名と関係のない値にすると、ユーザー アカウントを別のドメインに移動するときに、UPN を変更せずにすみ、ドメイン間の移動をユーザーが意識することなく行うことができます。

グローバル カタログ (GC) のドメイン コントローラ検索を通して、UPN 名はユーザーとドメインに解決して変換されます。UPN を使ったログオンは、ドメインがネイティブ モードである場合のみ可能です。

ユーザー ログオンでの Kerberos 認証
ユーザー ログオンでは、セッション チケットを取得するための Kerberos 認証要求を生成します。次に、チケット保証サービス (TGS) を使用して KDC にサービスのセッション キーを要求します。

フレーム

送信側

受信側

プロトコル

説明

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 = <DC の名前 >$

  • Kerberos: Server Name = krbtgt.<DNS ドメイン名 >

  • Kerberos: Server Name = ldap.<DC の名前 >.<DNS ドメイン名 >

既に説明したように、Kerberos パケットのサイズはユーザーが属するグループの数によって変わります。

グループ ポリシーのロード
グループ ポリシー情報を取得するプロセスは、コンピュータ起動プロセスの場合と同じです。クライアントは "DS API DSCrackNames" を使用して名前を変換し、ロードするポリシーの情報を LDAP を通して取得します。

w2ksrt11

次に、クライアントはコントローラとの SMB 接続を確立し、必要なポリシー ファイルをダウンロードします。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

SMB

C negotiate, Dialect = NT LM 0.12

2

サーバー

クライアント

SMB

R negotiate, Dialect # = 5

3

クライアント

サーバー

SMB

C session setup & X

4

サーバー

クライアント

SMB

R session setup & X

5

クライアント

サーバー

SMB

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

6

サーバー

クライアント

SMB

R tree connect & X, Type = _

7

クライアント

サーバー

SMB

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

8

サーバー

クライアント

SMB

R NT create & X

9

クライアント

サーバー

SMB

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

10

サーバー

クライアント

SMB

R read & X, Read 0x1a

このシーケンスは、クライアントがシステム ボリュームに接続し、ユーザーのポリシーをロードするまでを示しています。グループ ポリシー情報のロードに伴うトラフィックについては、『Notes from the Field』シリーズ『Building Enterprise Active Directory Services』(Microsoft Press) の第 5 章を参照してください。

プロセスの完了
クライアントはドメイン コントローラとの接続を切断します。この操作はポート 445 で実行されます。トレースでは次の表のように表されます。

フレーム

送信側

受信側

プロトコル

説明

1

クライアント

サーバー

SMB

SMB C tree disconnect

2

サーバー

クライアント

SMB

SMB R tree disconnect

3

クライアント

サーバー

SMB

SMB C logoff & X

4

サーバー

クライアント

SMB

SMB R logoff & 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

ドメイン Main.Local の Windows 2000 ドメイン コントローラ ： 1 台、以下のサービスを搭載
DNS
DHCP
WINS

Windows 2000 Professional デスクトップ ： 1 台
Windows 2000 Professional ノートブック ： 1 台

NT 4

NT 4 SP6a ドメイン コントローラ ： 1 台、以下のサービスを搭載
DHCP
WINS

Windows 2000 Professional デスクトップ ： 1 台

混在環境

アップグレードした Windows 2000 ドメイン コントローラ ： 1 台、以下のサービスを搭載
DNS
DHCP
WINS
NT 4.0 SP6a BDC ： 1 台

Windows 2000 Professional デスクトップ ： 1 台

フォレスト

ドメイン Corp.Main.Local の Windows 2000 Server ドメイン コントローラ ： 1 台、以下のサービスを搭載
DNS
DHCP
RRAS ルーターとして構成された Windows 2000 Server ： 2 台 (ヌル モデム ケーブルを使用して低速リンクをシミュレート)
ドメイン Field.Main.Local の Windows 2000 ドメイン コントローラ ： 1 台
ドメイン Field.Main.Local の Windows 2000 ドメイン コントローラ ： 1 台、以下のサービスを搭載
DNS (セカンダリ)
DHCP

ドメイン Corp.Main.Local の Windows 2000 Professional デスクトップ ： 1 台
ドメイン Field.Main.Local の Windows 2000 Professional デスクトップ ： 1 台

すべてのコンピュータ (別途明記されたものを除く) を 10/100 Ethernet ハブで相互接続しました。クライアントには各種 Ethernet カードを使用しています。すべてのクライアントを 100 MB でネットワークに接続しました。

ネットワーク トレースは、すべてネットワーク モニタ v5.00.646 を使用して作成しました。ネットワーク モニタに Kerberos トラフィック用のパーサーを追加しました。

本書に記載されたネットワーク テストおよび構成では、TCP/IP トランスポート プロトコルを使用しています。TCP/IP は Windows 2000 の既定のネットワーク プロトコルで、ログオン/起動プロセスで使用するサービスの多くが TCP/IP を必要とします。

付録 B: 認証プロセスで使用される TCP/IP ポート

次の表は Windows で使用されるポートの一覧です。

ポート

TCP/UDP

機能説明

20

TCP

FTP

21

TCP

FTP

23

TCP

Telnet

25

TCP

IIS SMTP

31

TCP

Netmeeting

42

TCP

WINS 複製

47

TCP

PPTP の GRE

52

TCP

Netmeeting

53

UDP

DNS 名前解決
SQL TCP 検索

53

TCP

DNS
SQL TCP 検索

67

UDP

DHCP リース (BOOTP)

68

UDP

DHCP リース

80

TCP

IIS HTTP

88

UDP

Kerberos

88

TCP

Kerberos

110

TCP

POP3

119

TCP

NNTP

135

TCP

ロケーション サービス
RPC
RPC EP マッパー
SQL RPC セッション マッパー
WINS マネージャ
DHCP マネージャ
MS DTC

137

UDP

NetBIOS ネームサービス
SQL RPC 検索
ログオン シーケンス
NT 4.0 信頼関係
NT 4.0 セキュリティで保護されたチャネル
パス スルー検証
参照
印刷
SQL 名前付きパイプ検索

137

TCP

WINS 登録

138

UDP

NetBIOS データグラム サービス
ログオン シーケンス
NT 4.0 信頼関係
NT 4.0 ディレクトリ複製
NT 4.0 セキュリティで保護されたチャネル
パス スルー検証
NetLogon
参照
印刷

139

TCP

NetBIOS セッション サービス
NBT
SMB
ファイル共有
印刷
SQL 名前付きパイプ セッション
ログオン シーケンス
NT 4.0 信頼関係
NT 4.0 ディレクトリ複製
NT 4.0 セキュリティで保護されたチャネル
パス スルー検証
NT 4.0 管理ツール (サーバー マネージャ、イベント ビューア、レジストリ エディタ、診断、パフォーマンス モニタ、DNS マネージャ)

161

UDP

SNMP

162

UDP

SNMP トラップ

215

TCP

Netmeeting

389

TCP

LDAP

443

TCP

HTTP SSL

445

TCP

SMB または CIFS

464

UDP

Kerberos kpasswd

500

UDP

IPSEC isakmp IKE

531

TCP

IRC

560

TCP

コンテンツ複製サービス - Site Server

636

LDAP over SSL

731

TCP

Netmeeting

動的

UDP

Netmeeting

888

TCP

ログインと環境の受け渡し

動的

TCP

ディレクトリの複製

1109

TCP

Kerberos による POP

1433

TCP

SQL TCP セッション

1645

UDP

RADIUS 認証

1646

UDP

RADIUS アカウンティング

1723

TCP

PPTP 制御チャネル (IP プロトコル 47 - GRE)

1755

TCP

Netshow

動的

UDP

Netshow

1812

UDP

RADIUS 認証

1813

UDP

RADIUS アカウンティング

1863

TCP

MSN Messenger

2053

TCP

Kerberos デマルチプレクサ

2105

TCP

Kerberos 暗号化 rlogin

3268

グローバル カタログ LDAP

3269

グローバル カタログ LDAP over SSL

3389

RDP

ターミナル サービス

8000

TCP

CyberCash (クレジット ゲートウェイ)

8001

TCP

CyberCash (admin)

8002

TCP

CyberCash (コイン ゲートウェイ)

10140-10179

TCP

DCOM ポート範囲

Windows NT のポート一覧は、ローカル コンピュータの次に示すファイルを参照してください。

%winnt%/system32/drivers/etc/services

次の表に一般的なポートを示します。

認証 認証サービスは、リソースへのアクセスを要求するユーザーまたはデバイスの ID を検証します。

サービス

種類

AFS/Kerberos 認証サービス

TCP ポート 7004 - afs3-kaserver

AFS/Kerberos 認証サービス

UDP ポート 7004 - afs3-kaserver

認証サービス

TCP ポート 113 - ident

認証サービス

UDP ポート 113 - ident

証明書配布センター

TCP ポート 223 - cdc

証明書配布センター

UDP ポート 223 - cdc

Funk Software Inc.

TCP ポート 1505 - funkproxy

Funk Software Inc.

UDP ポート 1505 - funkproxy

Login Host Protocol (TACACS)

TCP ポート 49 - bbn-login

Login Host Protocol (TACACS)

UDP ポート 49 - bbn-login

TACACS-Database Service

TCP ポート 65 - tacacs-ds

TACACS-Database Service

UDP ポート 65 - tacacs-ds

ディレクトリ サービス/名前の解決 ディレクトリ サービスは名前の解決および検索の機能を提供し、ユーザーやデバイスがネットワーク上のリソースを誰にでもわかる名前で検索できるようにします。

サービス

種類

AppleTalk Name Binding

TCP ポート 202 - at-nbp

AppleTalk Name Binding

UDP ポート 202 - at-nbp

ディレクトリ検索サービス

TCP ポート 197 - dls

ディレクトリ検索サービス

UDP ポート 197 - dls

ディレクトリ検索サービス モニタ

TCP ポート 198 - dls-mon

ディレクトリ検索サービス モニタ

UDP ポート 198 - dls-mon

Lightweight Directory Access Protocol

TCP ポート 389 - ldap

Lightweight Directory Access Protocol

UDP ポート 389 - ldap

Microsoft-DS

TCP ポート 445 - microsoft-ds

Microsoft-DS

UDP ポート 445 - microsoft-ds

Microsoft の Windows インターネット ネーム サービス

TCP ポート 1512 - wins

Microsoft の Windows インターネット ネーム サービス

UDP ポート 1512 - wins

NETBIOS ネーム サービス

TCP ポート 137 - netbios-ns

NETBIOS ネーム サービス

UDP ポート 137 - netbios-ns

NIC Host Name Server

TCP ポート 101 - hostnames

NIC Host Name Server

UDP ポート 101 - hostnames

Prospero ディレクトリ サービス non-priv

TCP ポート 1525 - prospero-np

Prospero ディレクトリ サービス non-priv

UDP ポート 1525 - prospero-np

ドメイン ネーム サーバー

TCP ポート 53 - domain

ドメイン ネーム サーバー

UDP ポート 53 - domain

Host Name Server

TCP ポート 42 - nameserver

Host Name Server

UDP ポート 42 - nameserver

HOSTS2 ネーム サーバー

TCP ポート 81 - hosts2-ns

HOSTS2 ネーム サーバー

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

Kerberos 管理

TCP ポート 749 - kerberos-adm

Kerberos 管理

UDP ポート 749 - kerberos-adm

Kerberos キー配布センター

Windows NT サービス - Kerberos キー配布センター

kerberos-master

TCP ポート 751 - kerberos-master

リモート アクセス/VPN リモート アクセス サービスと VPN サービスによって、ユーザーまたはデバイスはローカル接続の場合と同じようにリモート ネットワークにアクセスできます。このサービスは、ユーザーがリモート ネットワーク ホストの制御を取得するリモート コントロール ソフトウェアとは異なります。

サービス

種類

プライベート ダイヤル アウト サービス

TCP ポート 75 -

プライベート ダイヤル アウト サービス

UDP ポート 75 -

Apple Remote Access Protocol

TCP ポート 3454 - mira

IPSEC ドライバ

Windows NT サービス - IPSEC ドライバ

pptp

TCP ポート 1723 - PPTP

ルーティングとリモート アクセス

Windows NT サービス - ルーティングとリモート アクセス

Shiva

TCP ポート 1502 - shivadiscovery

Shiva

UDP ポート 1502 - shivadiscovery

TIA/EIA/IS-99 モデム サーバー

TCP ポート 380 - is99s

TIA/EIA/IS-99 モデム サーバー

UDP ポート 380 - is99s

ルーティング ルーティング プロトコルは、ネットワーク間の情報伝達を実現します。TCP/IP プロトコルはネットワークの全ホストで実行されていることを想定しているため、このリストには入っていません。TCP/IP 以外のプロトコルに着目することが重要なのは、そうしたプロトコルが各種クライアント オペレーティング システムやネットワーク構成のエクストラネット サポートを示すことがあるからです。

サービス

種類

AppleTalk プロトコル

Windows NT サービス - AppleTalk プロトコル

AppleTalk Routing Maintenance

TCP ポート 201 - at-rtmp

AppleTalk Routing Maintenance

UDP ポート 201 - at-rtmp

Appletalk Update-Based Routing Protocol

TCP ポート 387 - aurp

Appletalk Update-Based Routing Protocol

UDP ポート 387 - aurp

AppleTalk Zone Information

TCP ポート 206 - at-zis

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

ローカル ルーティング プロセス (オンサイト)

UDP ポート 520 - router

© 2000 Microsoft Corporation. All rights reserved.

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。

本書に記載されている情報は、発行時点で議論されている問題点に関する Microsoft Corporation の最新の見解を示しています。Microsoft は変化する市場状況に対処しなければならないため、本書の内容を Microsoft の確約事項として解釈してはならず、Microsoft は発行日以降に提示された情報の精度についてはいかなるものであれ保証致しません。本書は、情報の通知のみを目的としており、Microsoft は本書に記載されている情報について明示的にも暗黙的にも一切の保証をいたしません。この文書で例として挙げられている企業、その他の組織、製品、職業、イベントは、仮想のものです。それらが、いずれかの実際の企業、組織、製品、人物、またはイベントを指していることはなく、そのように解釈されるべきではありません。

Microsoft、BackOffice、MS-DOS、Outlook、PivotTable、PowerPoint、Microsoft Press、Visual Basic、Windows、Windows NT、Office ロゴは、米国 Microsoft Corporation の米国およびその他の国における登録商標または商標です。


タグ :


Page view tracker