web-dev-qa-db-ja.com

netbiosを使用しないDFS名前空間解決-なぜ機能するか

だから、私の問題は何かがうまくいかないということではありません。しかし、それは機能し、その理由はわかりません。

ショートバージョン：netbios/LLMNRがオフで、DNSエントリmydomain.mydomain.localeがオフになっている場合でも、\\ mydomain\MyDFSRootにアクセスできます存在します。理由がわからない。

詳細

  • AD-フォレスト/ドメイン：MyDomain.locale
  • DFS名前空間：MyDomain.locale/MyDFSRoot（v2）
  • フォレスト/ドメインレベル：2008R2

コンピューターのテスト：

  1. DC1（ドメインコントローラー-WS2019）
  2. SRV（DFS名前空間サーバー-WS2019）
  3. CLI（クライアント、Windows 10 1903）（このネットワークには他のコンピューターはありません）

構成：

  • LLMNR-GPO経由でオフ
  • Netbiosノード-GPO経由のタイプPノード
  • いいえWINS利用可能または構成済み
  • ネットワークアダプタで無効になっているTCP/IPを介したNetBIOS
  • SMBv1はGPO（コンピューターブラウザなし-サービスは実行されています）
  • DCとDFSn-Serverの両方でFQDNを使用するように設定されたDFS構成（ただし、重要ではないようです）
  • DNSサフィックス検索リストがデフォルトです（mydomain.locale）
  • CLIは独自のネットワーク（vswitchおよびDC/SRVにルーティング）で分離されています。これにより、ブロードキャストパケットが回避されます。
  • ネットワークからの外部トラフィックも外部DNS構成もありません

所見：

  • WORKS：すべてのDFSNパス（\ mydomain（sysvol | netlogon | mydfsroot）
  • 動作しません：DC\mydomain\dcsharedfolder上の共有フォルダー
  • 遅延：ネットワークから切断されたクライアントを起動し、ログオンし、ネットワークを有効にしてテストします。動作するまでに数秒/分かかる場合があります。
  • LLMNR/Netbios/BROWSERがオフ：すべてのトラフィックをキャプチャしましたが、これらのプロトコルの痕跡はありません
  • ipconfig/flushdns、dfsutil cache * flushなどは、効果がないように見えることなく頻繁に使用されます

更新：可能性のある回答ショートネームを機能させるトリガーとなるネットワークパケットを見つけたようです。ある時点で、タイプSMB2のパケットがRequest [FSCTL_DFS_GET_REFERRALS], FILE:に送信されます（ファイルパスが存在しないことに注意してください）（Wiresharkフィルターsmb2.ioctl.function == 0x00060194）。次に、ドメインコントローラーから次の応答が返されます。

            Referrals
                Referral
                    Version: 3
                    Size: 18
                    Server Type: Non-root targets returned (0)
                    Flags: 0x0002, NameListReferral
                    TTL: 600
                    Domain Offset: 36
                    Number of Expanded Names: 0
                    Expanded Names Offset: 0
                    Domain Name: \MYDOMAIN
                Referral
                    Version: 3
                    Size: 18
                    Server Type: Non-root targets returned (0)
                    Flags: 0x0002, NameListReferral
                    TTL: 600
                    Domain Offset: 34
                    Number of Expanded Names: 0
                    Expanded Names Offset: 0
                    Domain Name: \MYDOMAIN.LOCALE

現在、Microsoftの記事 "How DFS Works" には次の引用があります。

「クライアント上のすべてのUNC要求は、ネットワークリダイレクタの前に最初にDFSに送られます。DFSは、ドメインキャッシュをチェックして、名前がドメイン名かどうかを判断します

ただし、MUPキャッシュはパスを事前に知っている必要があるとも述べています。これは、最初は機能しない理由を説明しているかもしれませんが、「少し待つと」機能します。動作する前に、DFSドメインキャッシュを確認します。

[*][]
[*][MYDOMAIN]
[*][mydomain.locale]
[+][mydomain.locale]
        [+TESTDC.pertra.locale]

そしてそれが働き始めた後：

[*][TESTDC.mydomain.locale]
[*][MYDOMAIN]
[*][mydomain.locale]
[+][mydomain]
        [+TESTDC] AccessStatus: 0
[+][mydomain.locale]
        [+TESTDC.mydomain.locale]

[+]が前に付いているエントリは参照である必要があり、[*]は「ワークステーションサービスから受信」されます。このシナリオでは、パスの参照を取得したため、これが機能することを意味します。これは、おそらく他の何か（私が考えているGPO）がDFSルートにアクセスするためです。

EDIT2：クエリを送信したプロセスのPIDを確認しましたが、それはワークステーションサービスでした。

windowsactive-directorydfsnetbios
1
Zerqent

私はこれを理解したようです（長い答えについては質問を見てください）。基本的に：

  • DFSはNetbiosを使用せずに短い名前を使用します
  • DFSn名前空間にアクセスすると、そのエイリアスが提供されます（短いバージョンを含む）。
  • UNCは他のプロバイダーより前にDFSを試みます（通常の名前解決など）
0
Zerqent