none
ADに参加しているクライアントからファイルサーバへアクセスができない RRS feed

 > 

  • 質問

  • Question
    サインインして投票
    0
    サインインして投票
    ADサーバを Windows Server 2008 R2 から Windows Server 2012 R2 へ移行後、
    一部のアクセス権限がうまく動作しない状況です。
    移行前は下記事象は発生しておりません。

    ■ 環境
    ・DC2台 (Windows Server 2012 R2)
    ・クライアントは Windows 7, Windows 8.1, Wndows 10
    ・ファイルサーバは NetApp FAS2500シリーズ, CIFSサーバ

    ※クライアントのDNSはDCとは別のサーバを指定しています

    ■ 事象
    ファイルサーバ名をホスト名（netbios名）で指定した場合、
    ユーザのアクセス権で許可がある場合はアクセスができますが、
    セキュリティグループのアクセス権で許可がある場合はアクセス拒否されます。

    ファイルサーバ名をFQDNで指定した場合、
    セキュリティグループのアクセス権で許可がある場合もアクセスができます。

    クライアントのDNSをDC以外のサーバを指定した構成は非推奨ということで、
    DCを指定し直しましたが、事象は改善しませんでした。

    ■ 質問内容
    ファイルサーバ名をホスト名で指定した場合でも、
    セキュリティグループのアクセス権にて制御できるよう改善したいですが、
    原因の特定ができておりません。

    おそらくDNS周りに原因があるとみておりますが、原因をご教授頂ければと思います。


    よろしくお願い致します。


    • 編集済み ddvva 2017年6月2日 2:36
    2017年6月2日 2:31
    |

回答

すべての返信

  • Question
    サインインして投票
    0
    サインインして投票

    所属グループはログオン・ログオフしないと変化しないので、実施していない場合はご確認ください。

    TCP/IP詳細設定のDNSタブにある、「この接続のDNSサフィックス」を明示的に指定してみた場合、改善するでしょうか。


    2017年6月2日 4:16
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    この件ですが、私もクライアントまたはメンバーサーバ(共有フォルダのサーバ)のDNSサフィックスが適切に認識されていない、可能性が高いと思います。

    その際確認事項ですが、まずは「プライマリDNSサフィックス」が適切かどうか、を最初に確認するとよりよい、ようにも思います(クライアントとサーバの両方を確認してください)。確認方法はしたのページを参考にしてください。

    http://www.atmarkit.co.jp/ait/articles/0403/06/news016.html

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

    2017年6月2日 8:22
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    ご回答ありがとうございます。

    ログオン・ログオフ後に確認致しましたが、状況に変化はありませんでした。

    DNSサフィックスにつきましては確認させて頂きます。


    2017年6月5日 0:14
    |
  • Question
    サインインして投票
    0
    サインインして投票

    ご回答ありがとうございます。

    プライマリDNSサフィックスが適切に設定されていない場合、ユーザーのアクセス権に影響はないのでしょうか。

    DNSサフィックスが適切に設定されていない場合、そもそも通信ができず、ユーザーのアクセス権も適切に動作しないような気がしております。


    2017年6月5日 0:37
    |
  • Question
    サインインして投票
    0
    サインインして投票

    やきです。プライマリDNSサフィックスや私がお伝えした設定は、ホスト名→ホスト名+DNSサフィックス(通常はドメイン名) = FQDN となるように補完します。

    例えば単なるコンピュータ名を指定したとき「コンピューター名 + DNSサフィックス」のように補完します。最初から正しいFQDNを指定すれば、それを使用します。

    よって、コンピューター名のみの時「コンピュータ名.間違ったDNSサフィックス」で失敗となりますが、(正しいDNSサフィックスを使った手打ちの)FQDNのときはうまくいく、ということになります。


    2017年6月5日 1:39
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    正しくないDNSサフィックス設定の場合も、WindowsのNBT(NetBIOS over TCP/IP)の名前解決機能により、通信自体はできてしまうことがあります。

    この通信ができた場合、pingやファイル共有アクセス等、一部の機能はそつなく動作しますが、それ以外の動作(とくにLDAPへの直接アクセス等)についてはうまくいかない、ように思えます。アクセス許可設定がグループの場合、ユーザのメンバーシップ確認がいりますので、そこで問題が出ているようにも思えます。

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

    2017年6月5日 1:48
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    やきです。

    あと、IPアドレス直打ちも同じような動きだったりしないでしょうか？
    NTLM認証固有のトラブルの可能性もあるので、失敗させたタイミングでクライアント・ファイルサーバー・ドメインコントローラーのセキュリティログに拒否されたログが記録されていないか確認してみてください。

    2017年6月5日 4:20
    |
  • Question
    サインインして投票
    0
    サインインして投票

    やき 様

    IPアドレス直打ちの場合は、セキュリティグループのアクセス権が問題なく動作しました。

    ログにつきましても確認致しましたが、各クライアント、サーバともに拒否のログは記録されておりません。

    通常、ADに参加しているクライアントのDNSはADサーバへ向けると思いますが、今回の構成では別のDNSサーバへ向けているため、DNSサフィックスの設定がうまく動作していないのかもしれません。

    2017年6月6日 0:43
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーン 様

    どこまでの機能が正常に動作するかの切り分けが難しそうですね。

    ご指摘頂いた通り、メンバーシップの確認のところで問題が出ていることが原因だと、納得はできます。

    本事象の解決策としては、やはりDNSサフィックスを明示的に指定することだと思いますが、いかがでしょうか。

    この場合、クライアント台数が多いため、グループポリシーにてDNSサフィックスを展開することを想定しております。

    2017年6月6日 0:49
    |
  • Question
    サインインして投票
    0
    サインインして投票

    やきです。

    試しに1台でもいいので、DNSサフィックスを明示指定した状態で試してみることをお勧めします。

    ■　その他のアプローチ

    アクセス拒否のログが残っていないので違うとは思いますが、クライアントに保存された資格情報に誤りがあり、ホスト名の時だけ違う資格情報で自動的に接続を試みている可能性があります。もしそのユーザー名を直接ACLに指定している場合、逆に許可を取り消したらアクセスできないような状態になりますでしょうか(意図したアカウントと接続を試みているアカウントが異なる可能性)。

    またこのような奇妙な現象について、クライアント側のキャッシュが原因で起きたという投稿を見つけたので共有します。

    Windows 7 failing to access network shares by netbios name / fqdn (Folder Redirection Failure with Error 502 Access Denied)

    https://social.technet.microsoft.com/Forums/windows/en-US/51721012-2b3d-4479-8c93-02354e80ce13/windows-7-failing-to-access-network-shares-by-netbios-name-fqdn-folder-redirection-failure-with?forum=w7itpronetworking

    2017年6月6日 1:36
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    私のほうで見落としていましたが、根本原因はおそらく

    ※クライアントのDNSはDCとは別のサーバを指定しています

    だと思います。クライアントの参照先DNSサーバ(NetApp付随機能でしょうか？)にSRVレコードを展開できていれば別ですが、そうでない場合、正しくドメインコントローラーの認識(サービスレベルでの名前解決)ができていない可能性が高いです。

    またNetAppはアプライアンスなので、Windowsでいうところの「プライマリDNSサフィックス」設定がないでしょうから、クライアント側も含めた、ひとまずのNICレベルのDNSサフィックス設定は、有効ではあるでしょう。

    ですが、それを持って「問題が解決した」と考えると、今後ほかの問題が出る可能性がありますので、「DNSによる名前解決を正しく構成する」ことは、継続して考えられたほうがいいですね。

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

    2017年6月6日 2:27
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    やきです。

    チャブーンさんのコメント見て私も気が付きましたが、

    > クライアントのDNSをDC以外のサーバを指定した構成は非推奨ということで、
    > DCを指定し直しましたが、事象は改善しませんでした。

    こちら、ファイルサーバーのほうもDNSもDCを指定し、ipconfig /flushdns 相当の処理を行ってみてください。
    FQDNでない場合NTLMの認証時に「クライアント→ファイルサーバー→ドメインコントローラーに転送」となるのですが、ファイルサーバーが非DCのDNSを見に行ってしまっていてうまく機能しない可能性が残ります。

    2017年6月6日 4:50
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーン 様

    やき 様

    クライアントの参照先は bind にて構築したDNSサーバとなります。

    やき様のご指摘にありました通り、ファイルサーバのDNSについてはDCを指定して試しておりませんでした。

    （ここが原因のような気がしてきました）

    確認が取れ次第、報告させて頂きます。

    構成につきましては非推奨の構成ということで承知しておりましたが、AD移行前はたまたまかもしれませんが、特に問題なく動作しておりましたので、移行後もそのまま稼働できると思っておりました。

    お二人がご指摘の通り、根本原因は非DCのDNSを参照していることにあると思いますので、まずは構成の再検討を致します。

    2017年6月6日 6:50
    |
  • Question
    サインインして投票
    0
    サインインして投票

    やきです。

    参考まで、BINDとの連携についてはこちらです。

    Active Directory サポートのための BIND (Berkeley Internet Name Domain) の構成
    https://technet.microsoft.com/ja-jp/library/cc985025.aspx?f=255&MSPPError=-2147217396

    チェックリスト: DNS サーバーを移行する
    https://technet.microsoft.com/ja-jp/library/cc755303(v=ws.11).aspx

    2017年6月7日 4:59
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    BINDを参照されている、ということですが、BINDは「DNS動的更新」と「SRVレコードの登録」をサポートしているはずですので、それ自体は問題ないです。

    BINDにゾーンを展開する際、上記の機能を無効にして「ドメインコントローラのDNSサーバとレコード構成がまったく違う」ような場合に問題が起きます。レコード内容をチェックしたいなら、したのKB情報を試されるといいでしょう。

    https://support.microsoft.com/en-us/help/816587/how-to-verify-that-srv-dns-records-have-been-created-for-a-domain-controller

    ファイルサーバが(他のクライアントが見ている)DNSサーバを見ていない、ということならそれが原因の可能性は高いです。

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

    2017年6月7日 5:06
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    ファイルサーバのDNSにつきましては、運用中のシステムのため、すぐに変更することができませんでした。

    BINDとの連携も含めて、時期を見て確認致します。

    一度、ここまでの内容を整理して確認致しますので、ペンディングとさせて頂きたいと思います。

    いろいろとアドバイスありがとうございました。

    2017年6月9日 10:01
    |