AD上のファイルサーバーをHomeマシンやNAPT越しのマシンから参照したい

すべての返信

• 

  

  0

  サインインして投票

  oooohです。

  AD側でkerberousを強制しているかNTLM系を無効にしているかのどちらかでは。

  ADはタヌキマル様が管理されているんでしょうか？

  管理されていないならAD管理者に相談すべきでは。

  • 回答の候補に設定 栗下 望Microsoft employee 2017年7月5日 1:58

  2017年7月4日 10:17
• 

  

  0

  サインインして投票

  チャブーンです。

  よくわからない点が多々ありますが、ひとまず、

  一方、同じサブネットBにあるSambaのNASやファイル共有している10Proドメイン端末に対してはアクセスできます。

  ということでしたら、ファイルサーバーのLM認証レベルが変更されたのではないでしょうか。SAMBAで通るというなら、Windows 10側(クライアント)のLM認証レベルを変更してください。Homeの場合はレジストリでしか変更できません。

  https://seous.info/jobs/network/491/

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  2017年7月5日 1:35
• 

  

  0

  サインインして投票

  タヌキマルです。コメントありがとうございます。

  グループポリシーを確認しましたが、「未定義」でした。明示的に禁止されてはいませんが、念のためにNTLMv2だけ許可してみました。結果、システムエラーが53から5になりました。相手を見つけることもできなかったのが拒否という回答をもらえるようになったので、前進です。ありがとうございます。

  ベンダーサポートに依頼する前に、壊さない程度にもう少し頑張ってみます。実はベンダーとはセキュリティロールアップの適用に何度やっても失敗する件でやりとりしているところなのです。

  2017年7月5日 3:56
• 

  

  0

  サインインして投票

  タヌキマルです。コメントありがとうございます。よく分からない書き方ですみません。質問には質問者のレベルが現れてしまうものですね。精進します。

  ooooh様にもご指摘いただいたLM認証については、NASのSambaはNTLMv2限定(LM拒否)にしています。ご教示いただいた資料を見ても10HomeはNTLMv2のみLM拒否になっているようです(当該キーはなかったので既定値の3)。NASにはこれまで通りアクセスできました。しかし、サーバー側のLMレベルをNTLMv2のみに変更しても、ドメインファイルサーバーは「システムエラー5」です。

  サブネットBの10Proにローカルユーザーでサインインすると、全く同じ症状になります。しかし、同じマシンにドメインサインインすると普通に利用できます。

  「ローカルユーザーはドメイン資源を利用できない仕様に変更された」とかだったらどうしようと思っていましたが、そうではないのであれば望みはあるものと思って頑張ってみます。かえすがえすも、IPアドレス配布の話が流れたのが恨めしいです。

  2017年7月5日 4:21
• 

  

  0

  サインインして投票

  oooohです。

  アクセス拒否される際はユーザー認証画面自体は出てくるんですか？

  出てくるならユーザー名を「%file server name%\%domain username%」で入れませんか？

  2017年7月5日 4:45
• 

  

  0

  サインインして投票

  タヌキマルです。

  ooooh様、アドバイスありがとうございます。サブネットBの10Pro端末で試しました。

  ローカルユーザーでサインインしたところ、net view \\(hostname)には間髪おかず「システムエラー5」が返りました。認証画面は全く出ません。

  ドメインユーザーでサインインした状態では、すぐに共有のリストが返りました。当然認証画面はありません。

  ユーザー名もパスワードもローカルとドメインとで同一のものを使っています。

  ドメインではNTLMv2はもとより許していますし、テストとして一時的にLMまで許してみてもだめでした。

  もう少し考えてみます。

  2017年7月6日 3:17
• 

  

  0

  サインインして投票

  oooohです。

  net viewではなくてエクスプローラーでアクセスしてみてください。

  2017年7月6日 4:44
• 

  

  0

  サインインして投票

  どうやら解決したようです。ooooh様、チャブーン様、ありがとうございます。

  サーバー(2012R2)・クライアント(ローカルサインインの10Pro)ともに明示的にNTLMv2(LM/NTLM拒否)を設定した上で、エクスプローラーでアクセスしてみると、無事ファイルサーバーにたどり着けました。

  コマンドラインではnet use \\(servername)\ipc$ /user:(username) (password)とやってもシステムエラー1326になるなど行き詰まっていましたが、エクスプローラーを使うと「ユーザー名またはパスワードが正しくありません」と下に赤字で表示された認証画面が現れ、改めてユーザー名とパスワードを入力するとアクセスできました。

  その後10Homeのマシンでもアクセスできることを確認しました。あとはNAPT越えのテストです。

  システムエラー53の頃はエクスプローラーは失敗時のタイムアウトがうっとうしくて使っていませんでしたが、こんなこともあるのですね。奥が深い。もしかしたらサーバーをNTLMv2だけに明示的に設定した時点（システムエラー5)でエクスプローラーを使っていたら解決していたのかも知れません。

  どうもありがとうございました。

  2017年7月6日 8:30
• 

  

  0

  サインインして投票

  チャブーンです。

  ひとまず問題解決してよかったです。水を差すようで申し訳ないですが、NAT越えの件は、結構障壁が高い(場合によっては解決できない)と思います。

  端的にいうと、SMBダイレクト(CIFS以降)ではNATによる接続は1接続のみで、複数同時接続はそもそも無理ということです。NBTでの接続はこの限りではありませんが、クライアントからの接続要求でSMBダイレクトを無効にしたり、サーバ側でNBT接続を有効に設定しておく等、相当敷居が高いうえ、レガシープロトコルを使い続けるということで、接続性やセキュリティ観点でも、問題がありそうです。

  https://support.microsoft.com/ja-jp/help/301673

  個人的にはこのような構成を「是とする」ことはお奨めしません。仮にうまくいったからと言って、ご自身や会社組織としての利益が得られた、と考えないほうがよいと、思います。

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  2017年7月7日 2:13
• 

  

  0

  サインインして投票

  oooohです。

  NAPTの件ですが現状どういう状況なのか再度お知らせください。

  私見ですが、セグメントAルータに戻りの経路を記載しないといけない気がします。

  私としては今回の話はイントラ内で完結する事ですし、L3でやっても技術的には同じことですし、

  セキュリティに問題があるとは思いませんし技術的に無理があるとも思いません。

  タヌキマル様の親会社の情シスはお怒りかもしれませんが。

  ちなみにNAPT越えを諦めるならセグメントB用にファイルサーバの足を延ばすのが手っ取り早いですよ。

  物理的にできるのか知りませんが。

  2017年7月7日 5:07
• 

  

  0

  サインインして投票

  チャブーンです。

  最近一部で流行っている? 回答者同士でのコメントはおそらく避けたい、とおもわれているでしょうから、こちらの見識を述べるにとどめておきます。

  この件ですが、SMBの仕様上の問題(サービス側から見て同一クライアントでは1セッションしか管理できない)で、NATで複数同時セッションを張った場合、サーバ側が新しい(NAT的には別のクライアント)セッション情報で上書かれて、不整合が発生する、という問題があるという理解です。USのフォーラムで同じような質問があり、MSFTな人が、CIFSはあきらめてNBTにしろ、とはっきり言っていますね。

  https://social.technet.microsoft.com/Forums/windowsserver/en-US/afacec9f-fb10-46cc-884e-1cd7877ef1da/accessing-file-shares-over-nat?forum=winserverfiles

  私がなぜNBTを採用するべきではない、といったかというと、社内運用云々もありますが、それ以上に、今後NBTを前提とした標的型攻撃等「どんなセキュリティインシデントが発生するか、わかったものではない」という想いがあるからです。

  最近のWindowsは、WannaCry等レガシープロトコル(SMB1.0)が悪い意味で使われるケースもありますし、MS的にレガシープロトコル(のサポート)にはかかわりたくない、という傾向は高いと思っています。費用対効果が最悪だから、というのがその根拠です。

  今のWindowsでは、サーバOSもクライアントOSもすべて445ベースのSMBをなるべく使うように実装されています。基本的にNBTは互換性の問題で「万やむを得ない」シチュエーションのみで使ってくれ、とMSがメッセージしているようにも、私には思えます。できるだけ使わないでくれ、といっているレガシープロトコルで、手厚いサポートやセキュリティ対応をMSが行ってくれるか、私にはわからないのです。

  サポートやセキュリティ問題が起こる可能性がある(かもしれない)ソリューションを、個人的にはお奨めすることは行っていません。

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  
  

  • 編集済み チャブーンMVP 2017年7月7日 9:48

  2017年7月7日 9:23
• 

  

  0

  サインインして投票

  ooooh様

  タヌキマルです。NAPT越えの件については、結局諦めることになりました。

  セグメント間には大昔はルーターがありましたが、今は親会社の設置したL3SW上のVLANでそれを再現しています。L3SWは技術上(機器のACLが既に上限)いじれません。そのため「セグメントAルーター」自体がありませんし、その役を担うL3SWに経路を設定するのも現実的ではありません。親会社のSEに聞いたわけではありませんが(組織の承認なく勝手に聞くことはできないのです)。

  1000台を超える固定IPアドレスのホストが存在するので、アドレスの振り直しは内部的にも抵抗が大きく問題の発生も予想され、VLANの切り直しは現実問題としてできません。現状ではNAPTルーターでIPアドレスを水増しすることによるデメリットを誰も感じていないので、笛を吹いても無反応でした。正確にはセキュリティ担当者が「NAPTルーターの下から評判の悪いサイトにアクセスがあった」という場合に感じていますが、我慢の範囲だそうです。要するに今あるネットワークをいじることはできません。SMBを諦めたことにより、今回初めてNAPTルーターによる弊害が発生することになります。とはいえ全く使えないのはさすがによくないので、WebDAVか何か代替手段を提供します。

  ところで、「ファイルサーバーの足を延ばす」とはどういう意味なのでしょうか？「その程度も知らずにサーバーを扱うな」と言われてしまうようなことなのかも知れませんが、見当がつきません。後学のため、教えていただければ有り難いです。

  タヌキマル

  2017年7月11日 23:40
• 

  

  0

  サインインして投票

  チャブーン様

  タヌキマルです。詳細な解説をいただき、ありがとうございます。ファイル共有については自分なりに勉強したつもりでしたがどうもふわふわしたところがあり、それがだいぶ解消されました。

  ooooh様への返信にも書きましたが、NAPTルーターの下については通常のファイル共有は諦め、他の方法でサービスを提供します。組織内でWindows8.1以上についてはSMBv1の無効化を推奨していたこともあり、レガシーには戻りません。

  私が理解したつもりになっている内容は、こんな感じです：

  ・SMBv1とそれ以前はNBT (NetBIOS over TCP/IP, 137/TCP, UDP, 138/UDP, 139/TCP)を使用

  ・SMBv1は無効化が可能(Windows8.1以降、７ではできない)

  ・SMBv2以降はMicrosoft-DS (445/TCP)を使用（CIFSと呼ぶ資料もあればDirect Hosting SMBと呼ぶ資料も）

  ・SMBv2以降ではNBTは使えない、ただしWindows8.1に限りレジストリをいじれば使えないこともない、10はだめ

  ・SMBv2以降 (≒Microsoft-DS)ではサーバーとクライアントが１：１接続となる

  最後の点は、何だかNetBEUIの昔に戻ったような気もします。かつて管理していたブロードキャストセグメント内専用の2000Serverにはいくつかつながっていました。NAPTなどイントラでは邪道ですね。間違っているのはうちのネットワークでした。

  それにしても、マイクロソフトはもう少し技術情報を分かりやすく出してほしいものです。もちろんNT4の時代とは比ぶべくもないのはよく分かっていますが、プロトコルの名前がはっきりしないというのはちょっと。たとえばドメインコントローラーが使用するポート一覧くらい、公式なものがあってもよさそうなものですが見つけることができませんでした。

  プロトコル名やOSごとのバージョンなどを確認するのに下記の記事を参照しました。情報源としてこの著者をかなり厚く信頼しています。もちろんチャブーン様も。

  http://www.atmarkit.co.jp/ait/articles/1501/19/news092.html

  ありがとうございました。

  2017年7月12日 0:35
• 

  

  0

  サインインして投票

  チャブーンです。

  すみません。ちょっとうまく伝わっていない点があるようなので。

  ・SMBv1とそれ以前はNBT (NetBIOS over TCP/IP, 137/TCP, UDP, 138/UDP, 139/TCP)を使用

  これですが、私の書き方がいけないのかもしれませんが、NBTとSMB1.0は違うものです。で、SMB1.0とCIFSが事実上同じものです。つまり、SMB1.0は445ポートを使いますが139ポートは使いません。

  「レガシープロトコル」とひとくくりに書いてしまったのがいけなかったと思いますが、趣旨としてレガシーにあたるSMB1.0を媒介した問題が実際に起こったので、(仕様は違うが)立ち位置としてかなり似ているポジションにいるNBTについても、未知のセキュリティ問題が発生する可能性は考えておくべきと考えている、というところです。

  ---

  フォーラムは有償サポートとは異なる「コミュニティ」です。フォーラムでご質問頂くにあたっての注意点 をご一読のうえ、お楽しみください。

  2017年7月12日 5:56
• 

  

  0

  サインインして投票

  oooohです。

  >ファイルサーバーの足を延ばす」とはどういう意味なのでしょうか？

  配線工事まで関わるとよく耳にするのですが、SEのみだと耳にしないですかね？

  ファイルサーバにNICを増設して（今回の場合だとセグメントBの）IPを振ることです。

  これによりNAPTする必要がなくなります。

  物理的な問題というのはNICの増設スロットがないとか、LANの取り回しの距離とかです。

  • 回答の候補に設定 チャブーンMVP 2017年7月14日 7:19
  • 回答としてマーク 栗下 望Microsoft employee 2017年7月20日 1:44

  2017年7月13日 0:39
• 

  

  0

  サインインして投票

  チャブーン様

  理解不足を正していただき、ありがとうございます(正しく受け取れたかどうかはまた別ですが)。

  「ファイル共有サービス」というアプリケーション層の機能を実現するのが、歴代挙げると大昔のLAN Managerで使われた無印SMB, Windows95/NT4のCIFS, Windows2000/XPのSMB1.0, Windows Vista/7のSMB2.0/2.1, Windows8/8.1/10のSMBv3.0/3.02/3.11、ということかと思います。細かいバージョンはさして重要ではありませんが、いずれもレイヤー5-7の上位プロトコルですね。そのうちSMB1.0とそれ以前が「レガシー」であると。

  # Common Internet File System (CIFS)だなんて力み返るあたり、SUNを倒しMSNでInternetに勝つとか吹いていた当時の元気なマイクロソフト(今も元気ですが大人になりました)が思い出されます。

  レイヤー2-4については、95マシンではLLC/NetBEUIを使っていたこともあります。それらに代わってTCP/IPを導入し、その上でファイル共有サービスを実現するために、最初に導入されたのがNBT (NetBIOS over TCP/IP)ですね。ポート137-9を利用する、1987年のRFC1001/2で標準化された方の。そして、Windows2000でSMB1.0とともに導入されたのがポート445を使うMicrosoft-DS。NetBEUIやNBIPXはもちろん、NBT(137-9)ももう「レガシー」であり、Microsoft-DS(445)を使うべきなのですね。

  2000では当然NBTも使えましたから、何らかの仕掛けがあったのでしょう。「SMB1.0とCIFSが事実上同じもの」ということの正確な意味は私には理解できていないと思いますが、何となく分かるような気がします。

  モダンなネットワークでは、下のレイヤーについてはダイレクトホスティングSMB(ポート445)を使い、上のレイヤーについてはSMB2以降を使うというのが、適切なのだと納得いったところです。ファイアウォールに開けた137-9の穴は塞ぐとしましょう。

  以前LANやサーバーの管理をしていたのが9xがまだいくらか現役という時代だったもので、常識がずいぶん変わっており、ずいぶん勉強したつもりでしたが、思い込みや抜けている点がありました。詳しく教えて下さり、ありがとうございました。この記事を後から見る方のためにかなりくどくどと書いてしまいましたが、ご容赦いただければ幸いです。

  2017年7月14日 5:35
• 

  

  0

  サインインして投票

  ooooh様

  タヌキマルです。なるほどそういう意味でしたか。

  ビルも自社所有ではないことから、物理配線はインフラ更新の時くらいしか触ることがなく、思いつきませんでした。

  残念ながら、一番必要なセグメントは距離の問題で光ファイバーが必要になりますので、ちょっと難しいです。また、NAPTするのは絶対的なIPアドレス不足のせいなので、セグメントBに直結してもそれだけでは不足です。そこの中にいくつもある独立したNAPTルーターの配下の空間に直接つながなければなりません。それぞれのアドレス空間の一意性を確保するなどすれば1:1通信ができそうですが、業務を乗せる自信はちょっとありません。できたとしても、きっとNAPTルーターとプライベートLANの管理までする羽目になるのでしょう。

  でも、可能性としては検討してみたいと思います。テストマシンを使って模擬的にNAPTルーターの下に「足を伸ばす」というのをやってみたいと思います。自力では思いつかなかった可能性を教えて下さり、誠にありがとうございました。

  2017年7月14日 5:50