TCP/IPノードの種類とクライアントログオン

複数のサブネット間でルーティングされるマルチサイトドメインを構築している場合、リモートサイトにバックアップドメインコントローラを配置すると、そのサイトのクライアントがローカルで検証されることが保証されると仮定することができます。 高価なリンクを介してLANの外に出るトラフィックを削減し、WAN接続の速度（またはその欠如）によってクライアントログオンが遅延しないようにする ローカルドメインコントローラのインストールは実際には機能するかもしれませんが、その成功は設計によるものか、偶然なのでしょうか？
残念ながら、特定のクライアントがWindows NT Server、Windows NT Workstation、またはWindows9xを実行しているかどうかを検証するドメインコントローラを指定する方法はありません。
この毎日のドリルダウンでは、関連するプロセスの概要を説明します。 また、低速モデムリンク上の別の国に配置されているドメインコントローラが、ログオン要求を処理するためにクライアントマシンによって選択されたものである可能性がある理由についても説明します。
背景
Windows NTドメインの概念に精通していない人のために、ここでは簡単な復習です：NTドメインは、共通のセキュリティとアカウント情報を共有す ドメインは、ユーザー、コンピュータ、およびネットワークの管理を一元化するために提供されます。 セキュリティ情報は、プライマリドメインコントローラ(PDC)として指定および構成されたサーバー上の中央データベースに保持され、バックアップドメインコントロー 一度にPDCにできるサーバは1つだけですが、必要に応じてこの特別なロールを任意のBDCに転送できます。 TCP/IPを実行しているクライアントがこのNTドメインにログオンしようとすると、ログオン要求は、同じドメインに属するネットワークのドメインコント
WINS
WINSサーバは、ネットワーク上のすべてのwins対応クライアントのリストを維持します。 WINSサーバーは、タイプ<1C>として識別されるドメインコントローラーの一覧も保持します。 彼らだけが知っている理由のために、WINSの設計者は、<1C>リストには25個のエントリの制限があることを決定しました。 クライアントは、ログオン要求にサービスを提供するドメインコントローラーを検索しようとすると、この一覧が表示されます。
ドメインコントローラーが一覧に表示される順序は、次のロジックに従います:

1. Winsサーバーに登録されているドメインコントローラーエントリ、最近更新された順から最近更新された順に
2. 他のWINSサーバーとのレプリケーションから取得されたドメインコントローラーエントリ
3. 最初のエントリは常にPDC

ノード
クライアントでTCP/IPを設定するときに表示されるオプションのいずれかです(クライアントによって異なります)。インストール）はノードタイプです。 ノードの種類は、クライアントがログオン要求にサービスを提供するドメインコントローラを検索する方法を参照します。
TCP/IPには四つのノードタイプがあります:

• B-node(ブロードキャストノード):クライアントがドメインコントローラを見つける必要がある場合、ブロードキャストを実行します。 応答する最初のドメインコントローラーには、ログオン要求のサービスのジョブが渡されます。
• P-node(point-to-point node):この環境では、名前クエリはWINSサーバーに直接送信されます。
• m-node(マルチホームノード):m-node環境では、最初にb-nodeを使用し、次に必要に応じてp-nodeを使用して名前を解決します。
• H-node(hybrid node):h-node環境では、ネームサービスが利用できない場合は最初にp-nodeを使用し、次にb-nodeを使用します。

各ノードタイプをより完全に調べてみましょう。
B-node
b-nodeモードでは、名前の登録と解決にブロードキャストメッセージを使用します。 たとえば、NT_PC1という名前のコンピュータがNT_PC2という名前のコンピュータと通信する場合、NT_PC1はNT_PC2を探しているというブロードキャストメッ その後、NT_PC2が応答するまで指定された時間待機します。
Bノードには二つの大きな問題があります:

• 大規模な環境では、ブロードキャストメッセージを使用してネットワークをロードします。
• 通常、ルータはブロードキャストメッセージを転送しないため、ルータの反対側のコンピュータは要求を聞くことはありません。

bノードのクライアントである可能性のあるネットワーク上のコンピュータの例には、WINSクライアントソフトウェアがインストールされていないMS-DOS、Windows3.1、またはWindows for Workgroupsを実行しているコンピュータが含まれます。 サーバーには、IBM LAN Server、DEC PATHWORKS、AT&T StarLAN、OS/2またはUNIXシステム用LAN Managerなどのサーバーメッセージブロック(SMB)ベースのネットワークサーバーがあります。
P-node
p-nodeモードは、b-nodeが解決しない問題に対処します。 Pノード環境では、コンピューターはブロードキャストメッセージを作成したり応答したりしません。 WINSサーバーは、コンピューターの名前とアドレスを把握し、ネットワーク上に重複する名前が存在しないようにする役割を果たします。
この環境では、NT_PC1がNT_PC2と通信しようとすると、WINSサーバーにNT_PC2のアドレスを照会します。 アドレスを受信すると、NT_PC1はブロードキャストせずにNT_PC2に直接移動します。 名前クエリはWINSサーバーに直接送信されるため、p-nodeはブロードキャストメッセージを含むネットワークのロードを回避します。 ブロードキャストメッセージは使用されず、アドレスが直接受信されるため、コンピュータはルータの反対側にある可能性があります。

p-nodeの最も重要な問題は次のとおりです:

• すべてのコンピュータは、WINSサーバーのアドレスを知るように構成する必要があります。
• WINSサーバーがダウンしている場合、アドレスを解決するためにwinsサーバーに依存しているコンピュータは、ネットワーク上の他のシステムに到達できません。

M-node
m-nodeモードは、主にb-nodeとp-nodeに関連する問題を解決するために作成されました。 Mノード環境では、コンピュータは最初にbノードで登録と解決を試みます。 それが失敗した場合、p-nodeに切り替わります。 利点は次のとおりです:

• Mノードはルータを横断できます
• bノードは常に最初に試行されるため、winsサーバーがダウンしている場合、ルータの同じ側のコンピュータは通常どおり動作し続けます
• 理論的には、mノードを使用するとLANパフォーマンスが向上するはずです

H-node
h-nodeモードは、ブロードキャストメッセージとルーティング環境操作に関連する最も重要な問題を解決します。 このモードは、ブロードキャストメッセージを最後の手段として使用するbノードとpノードの組み合わせです。 Hノードモードは、bノードとpノードを使用する順序を変更するだけでなく、winsサーバーがダウンしている場合、ブロードキャストメッセージが必要になる場合、コンピ WINSサーバに再び到達できると、システムはpノードに戻ります。 Hノードは、ブロードキャスト名解決が失敗した後にLMHOSTSファイルを使用するように設定することもできます。
最初にpノードを使用するため、WINSサーバーが稼働している場合はブロードキャストメッセージは生成されず、コンピュータはルーターの反対側に配置できます。 WINSサーバーがダウンしている場合は、bノードが使用されるため、ルーターの同じ側のコンピューターは通常どおり動作し続けます。
その他の組み合わせ
変更されたbノードとして知られている別のバリエーションは、メッセージがルータを越えて行くことができるように、Microsoftネットワー 変更されたbノードは、pノードモードまたはwinsサーバを使用しません。 このモードでは、bノードは、LMHOSTSファイルに格納されているコンピューターとアドレスの一覧を使用します。 Bノードの試行が失敗した場合、システムはLMHOSTSを検索して名前を検索し、関連するアドレスを使用してルータを通過します。 ただし、各コンピューターにはこのリストが必要であり、リストを維持して配布する必要があるため、管理上の負担が発生します。 Windows for Workgroups3.11とLAN Manager2の両方。xはこのような修正されたbノードシステムを使用しました。 Winsサーバーがネットワーク上で使用されていない場合、Windows NTはこの方法を使用します。 Windows NTでは、管理を容易にするためにこのファイルにいくつかの拡張機能が追加されていますが、変更されたb-nodeは理想的な解決策ではありません。
一部のサイトでは、bノードとpノードの両方のモードが必要になる場合があります。 この構成は機能しますが、管理者は細心の注意を払い、移行状況にのみ使用する必要があります。 Pノードホストはブロードキャストメッセージを無視し、bノードホストは名前解決のためにブロードキャストメッセージに依存するため、二つのホストは同じNetBIOS名で構成することができ、予測不可能な結果につながる可能性があります。 また、bノードを使用するように構成されたコンピューターがwinsデータベースに静的マッピングを持っている場合、pノードを使用するように構成されたコンピ
Windows NTを実行しているコンピューターをWINSプロキシエージェントとして構成して、WINSの使用への移行を支援できます。 Windowsベースのネットワーククライアント(WINS対応のWindows NT、Windows95、またはWindows for Workgroups3.11コンピューター)は、WINSを直接使用できます。 Bノードと互換性のあるWINS以外のコンピューター(Rfc1001および1002で説明)は、プロキシを介してwinsにアクセスできます。 WINSプロキシは、名前クエリのブロードキャストメッセージをリッスンし、ローカルサブネットにない名前に対して応答するWINSが有効なコンピュータです。 プロキシはpノードコンピュータです。
TCPを設定すると、ノードタイプを設定する方法が見つかりません。 ノードタイプは、TCP構成時にデフォルトに設定されます。 デフォルトのWindows95TCP/IPノードの種類は次のとおりです:DHCP=True、WINSが手動で設定されている場合、ノード・タイプh-node(0x08)
DHCP=True、WINSが手動で設定されている場合、ノード・タイプh-node(0x08)
DHCP=True、WINSが手動で設定されている場合、ノード・タイプh-node(0x08)
DHCP=True、WINSが手動で設定されている場合、ノード・タイプH-node(0x08)
DHCP=True、WINSが手動で設定されている場合、ノード・タイプH-node(0x08)
WINSサーバオプションがDHCP経由で提供されている場合は、DHCPオプション46を使用してノードタイプを設定する必要があります。; ただし、ローカルで定義されたWINSサーバーは自動的にノードの種類をh-nodeに設定するため、クライアントでwinsサーバーをローカルで定義すると、これらの2つのオプ
ノードの種類は、Windows95レジストリを編集することで手動で変更できます。 この場所は、サブキー
SYSTEM\CURRENTCONTROLSET\SERVICES\VXD\MSTCP\Node Type

NodeTypeの下にあるHKEY_LOCAL_MACHINEサブツリーの下に存在しますが、まだ存在しない場合は、Mstcpの下に文字列値として追加できます。
ログオン要求
ここで、クライアントがユーザー名、パスワード、およびドメイン情報を入力し、ログオンプロンプトウィンドウでOKをクリックした後(ログオ Windows9xとWINDOWS NTの動作は少し異なるので、それらについては別々に説明します。
Windows9xクライアント
クライアントは、構成されているノードの種類によって定義された方法でドメインコントローラを検索しようとします。 以下は非常に単純化された一連のイベントです:

1. bノードのクライアントが要求をブロードキャストします。 サーバーが応答しない場合、ログオンは失敗します。
2. pノードクライアントは、WINSサーバーから<1C>リストを要求します。 次に、<1C>リスト内の各サーバーに、最初の(PDC)から順に要求をブロードキャストします。
3. m-nodeクライアントとh-nodeクライアントは、上記の順序でこれらの両方を行いますが、クライアントのワークグループ名がログオンが試行されているアカウ WINSサーバーがアクティブで到達可能である場合、応答する<1C>リストの最初のドメインコントローラーが常にログオン要求を処理することを意味します。

前述したように、クライアントがローカルドメインコントローラによって検証されるようにするには、ワークグループ名をそのドメインコントローラで表されるドメインと同じにする必要があります。 ただし、office環境内でワークグループを使用する場合は、ローカル検証を確実にするこの方法は受け入れられない場合があります。 この場合、ローカルドメインコントローラーが最初に応答する可能性が高くなるように、クライアントが最初にローカルサブネットでブロードキャストするよ それは難しくて速いルールではないことに注意してください。 これは、管理者がリモートサイトに単一のドメインコントローラーを配置するのが通常であるため、リモートサイトサーバーが頻繁に使用され、より応答性の高い
または、WINSをローカルドメインコントローラーにインストールし、クライアントがプライマリWINSサーバーとして使用することもできます。 この方法は、ユーザーがローカルブランチの外部のリソースにほとんどアクセスしない場合には良い考えですが、ファイルサービスと印刷サービス、DHCP、SQL、Exchange、およ
ワークグループ名がアカウントドメインと異なる場合、m-nodeを使用すると、ログオン要求がローカルでサービスされる可能性が高くなります。
Windows NTクライアント
Windows NTログオンは、Windows9xログオンとは多少異なります—NTワークステーションは、ドメイン内のマシンIDを持っています。 そのため、クライアントはログオン検証のために四つのステップを経ます。 まず、NT Workstation clientは、リソースドメインのドメインコントローラでマシンIDを検証し、パススルー検証のためにユーザーログオン情報を送信します。 リソースドメインのドメインコントローラは、ログオン情報をアカウントドメインのドメインコントローラに渡します。 次に、リソースドメインドメインコントローラは、(アカウントドメインドメインコントローラから受信した)ユーザー認証情報をユーザーに渡します。
ユーザーがログオンしているかどうかにかかわらず、NT Workstationクライアントは、初期化中および後で必要に応じてID検証を行います(リソースドメインコントロー
まず、ドメインコントローラの名前解決が行われます。 NT Workstationクライアントは、リソースドメイン-ドメインコントローラを検索する必要があります。 NT Workstationクライアントがリソースドメインコントローラを検索するために使用する検出プロセスは、リソースドメインドメインコントローラがアカウントドメインドメインコントローラとの信頼された接続を確立するために使用する検出プロセスと同じです。
次に、NTマシンIDが検証されます。 NT Workstation clientは、WINSから取得されたリソースドメインドメインコントローラにユニキャストログオン要求を送信する前に、常にローカルログオンブロードキャストをResource-Domain<1C>に送信します。
クライアントは、ログオン要求に応答するために、リソースドメインからの最初のドメインコントローラでNT Workstation machine IDを検証します。
NT Workstation clientは、信頼されたドメインリストを列挙するようにリソースドメインドメインコントローラに要求します。 取得したドメイン名は、ログオンウィンドウのドメインドロップダウンボックスに表示されます。
NT Workstation clientは、ユーザーログオン資格情報をリソースドメインドメインコントローラに渡し、パススルー認証を要求します。
リソースドメインドメインコントローラは、信頼された接続を確立したアカウントドメインドメインコントローラにユーザーログオン資格情報を渡し、ユー その後、検証情報をNT Workstationクライアントに返します。
NT Workstation clientは、構成されている場合、接続してログオンスクリプト/プロファイルを実行するために、リソースdomain-domain controllerからアカウントdomain-domain controllerの名前を取得します。
これで、NTユーザーはアカウントドメインにログオンし、ログオンスクリプトを実行し、ホームディレクトリに適切なネットワーク接続を確立しました。
もちろん、マシンIDがローカルサブネット外のドメインに登録されている場合、またはユーザーがローカルサブネット上にドメインコントローラを持たないド 低速リンクの場合は、ログオンプロセスが拡張されます。
結論
Windows9xクライアントでは、ワークグループ名をログオンまたはアカウント、ドメインと同じにするか、bモードまたはmノードを使用してログオン要求が 明らかに、bノードはあまり汎用性がなく、ローカルドメインコントローラが迅速に応答しない場合、ログオンに失敗します。
Windows NTクライアントでは、リソースドメインコントローラとアカウントドメインコントローラがローカルセグメントに存在する必要があります。 (リソースドメインとアカウントドメインが同じ場合は、単一のサーバーになる可能性があります。)
複数のWINSサーバーを持ち、<1C>リストにローカルまたは最も近いドメインコントローラーを登録するWINSサーバーをクライアントにポイントすることで、プロセスを

Richard Charringtonのコンピュータキャリアは、マイクロコンピュータとして知られていたPcバックでの作業を開始したときに始まりました。 プログラマとして始めて、彼はWindows NTシステム管理者の高尚な高さまで彼の方法を働いた、と彼はちょうど約すべての間に行っています。 Richardは、適切なGUIを持つ前からWindowsで作業しており、Lanmanager以来Windows NTで作業していました。 今請負業者、彼はWindows NT用のスクリプト執筆に滑っているし、いくつかの非常に便利な自動管理ユーティリティを構築しています。

著者および編集者は、ここに記載されているコンテンツの準備に注意を払っていますが、いかなる種類の明示的または黙示的な保証を行わず、誤 いかなる損害についても責任を負いません。 変更を加える前に、必ず確認済みのバックアップを作成してください。