none
WIN7でADに参加しているユーザーのパスワード変更に時間がかかる RRS feed

  • 質問

  • はじめて投稿します。よろしくお願いします。

    Windows7 professional 64bitの端末から、Windows 2008 R2 Enterpriseサーバーにドメイン参加していますが、

    ユーザーのパスワード変更に3分くらいかかります。

    ログインはすぐに行われます。サーバーの設定が悪いのか、win7の環境設定が悪いのかわかりません。

    ちなみに、win xpの端末からはすぐにパスワード変更ができます。

    現象が起きる端末ですが、WINDOWS 7のみです、

    複数の端末(WIN7)でやってみても現象は同じでパスワード変更に

    数分をようします。

    何かインストールしたものが、影響しているかと思い、

    OSからのリカバリーを行い、初期状態に戻してから

    ドメイン参加して、パスワード変更しましたが、結果は同じでした。

    構成のまったく違うWIN7端末でもパスワード変更に多くの時間をようします。

    また、ネットワークに何か問題があるかと思い、ハブを別メーカーにしたり、

    セグメントを違うものにして、IPアドレスを変えたりしましたが、結果は同じでした。

    ただ、WIN XP端末からは、一瞬で変更できるので、原因がわかりません。

    今回はじめてWIN7端末を使い始めたので、とまどっています。

    また、Windows 2003のサーバーに対してもパスワード変更に数分かかることがわかりました。

    サーバーはともに、WINDOWS 2008 R2 のHYPER-V上で稼働しています。

    もしかして、何か関係ありますでしょうか?

    以上、よろしくお願いします。

    2013年6月17日 4:42

すべての返信

  • チャブーンです。

    その動作ですが、何かの原因でPDCエミュレータの通信に問題があるのかもしれません。またその前提条件である、SRVレコードの名前解決に問題があるのかもしれません。まずはしたのコマンドを7クライアントで実行した場合、情報が返ってくるでしょうか?

    nslookup -type=srv _ldap._tcp.pdc._msdcs.<DNSドメイン名>

    最終行に(<サーバのFQDN> internet address = <IP アドレス>)という情報が返ってくるはずなので、その<サーバのFQDN>pingを実行し、通信が可能であることを確認してください。

    また、[システムのプロパティ]-[コンピューター名]画面の[ドメイン]欄に<DNSドメイン名>が入っていること、同じ画面の[変更]-[詳細]ボタンで参照できる「このコンピューターのプライマリDNSサフィックス」に<DNSドメイン名>が入っていることを確認してください。

    あわせて、7クライアントのネットワーク設定の「参照先DNSサーバ」が<ドメインコントローラのIPアドレス「のみ」>を設定していることを確認してください。社内の他DNSサーバやISPのDNSサーバをリストに含めないようにしてください。仮にXPがそのような状態になっていたとしても、この条件は守るようにしてください。理由については、したをご覧ください。

    http://social.technet.microsoft.com/Forums/ja-JP/activedirectoryja/thread/6809f680-28c2-4ff1-93cd-0b6db60e4828



    2013年6月18日 6:05
    モデレータ
  • チャブーンさん、返信ありがとうございます。

    早速nslookupコマンドを実行してみました。

    結果はサーバーのFQDNが帰ってきて、IPアドレスも帰ってきました。

    帰ってきたPINGも正常にとおります。

    ネットワーク設定の参照先DNSサーバーは、一つに変更し、

    [システムのプロパティ]-[コンピューター名]画面の[ドメイン]欄に<DNSドメイン名>が入っていること、同じ画面の[変更]-[詳細]ボタンで参照できる「このコンピューターのプライマリDNSサフィックス」に<DNSドメイン名>が入っていることも確認しました。

    これらを確認し、再度パスワード変更しましたが、結果は同じで、パスワード変更に数分を要します。

    この他にまだ対策はありませんでしょうか?

    よろしくお願いします。

    2013年6月18日 7:58
  • すみません。

    ひとつ補足するのを忘れました。

    nslookupを実行すると、

    サーバー: unknownとなります。

    何か関係あるでしょうか。

    最終行にはFQDNとIPアドレスは帰ってきます。

    2013年6月18日 8:04
  • チャブーンです。

    なるほど。DNS名前解決自体には問題はなさそうですね。

    ちなみにnslookupでの"unknown"は、参照先DNSサーバ自身の逆引きができない、ことを指していますが、直接の影響はありません。

    Windows 7がドメインに参加するとFirewallのプロファイルが「ドメイン」に変わっているはずですが、きちんと変わっていますか?[ネットワークと共有センター]の[アクティブなネットワークの表示]で確認ができます。別のプロファイルになっていた場合も含め、切り分けのため各プロファイルのファイアウォールをいったん無効にしてみてください。

    あわせて、Windows 7のイベントログで警告やエラーメッセージがでていないか、確認していただくといいかもしれません。システムログとアプリケーションログを確認してみてください。

    解決しない場合ですが、構成自体の確認から必要かなと思います。ドメインコントローラはOSごとに何台あるか、PDCエミュレータはどのドメインコントーラになるか、また、Hyper-Vマシン上で動かしているとのことですが、物理マシンはドメインに参加しているか、ワークグループなのか、あたりがわかるといいのかもしれません(この情報だけでは解決は難しいですけれど)。


    2013年6月19日 5:17
    モデレータ
  • おそらく、XP の場合は IPv6 を利用していないと思いますので、Windows7 の IPv6 を無効にしてから一度試してみては?


    2013年6月19日 7:16
  • ドメインの設定ですが、問題なくネットワークは「ドメイン」になっています。

    ファイアウォールをすべて無効にしましたが、結果は同じでした。

    ネットワーク上に複数のサーバーがあり、参照できる他の

    サーバーに対してもパスワード変更に時間がかかることがわかりました。

    たぶん、サーバー側に問題はないと考えています。

    ネットーワーク上にドメインコントローラーが複数あることが要因か、ネットワーク上の

    セキュリティーの問題かなと少し思います。

    2013年6月20日 4:22
  • 返信ありがとうございます。

    IPVP6を無効にしていますが、これは影響していないようです。

    2013年6月20日 4:23
  • Windows7、2008 R2 限定ですと、 MTUの調整、SMB2.1 辺りかもしれませんね。

    先に TCP のリセットを行って効果が無いようであれば、TCPウインドウサイズの自動調整を無効にしてみたり、とかでしょうか。

    インターネット プロトコル (TCP/IP) をリセットする方法 http://support.microsoft.com/kb/299357/ja

    TCP ウィンドウ スケーリングの Windows Vista、Windows Server 2008、Windows 7 または Windows Server 2008 R2 の修正プログラムの向上します。

    http://support.microsoft.com/kb/2780879/ja

    Windows Vista ベースのコンピューターとそれ以前のオペレーティング システムの間で、サイズの大きいファイルをコピーすると、予想よりもコピー操作に時間がかかることがある http://support.microsoft.com/kb/932170/ja

    あとは、EnableWsd、DisableLargeMtu 辺りのキーとか

    Windows Server 2008 R2 のパフォーマンス チューニング

    http://msdn.microsoft.com/ja-jp/library/windows/hardware/gg463392.aspx

    2013年6月20日 5:54
  • 端末はWIN7のみでしか発生しませんが、サーバーは、2003,2008とあります。同一ビル内のサーバーだけではなく、遠隔地のセンターにあるサーバーに対しても、パスワード変更に時間がかかる現象が発生します。しかも、その他の業務(ファイルサーバー、認証、アプリ実行)等、パスワード変更作業以外は、全く問題ありません。こうなると、サーバー側の問題は少ないかと。ネットワークに起因する問題ではないかと思いますが、みなさんのアドバイスも含めて、自力での解決は難しいのではないかと思いました。ネットワークはIP-SECを用いた構成で、各拠点をいくつも結んでいます。ダウンロード等も細かく規制されています。ファイアーウォールも厳重で、通信会社が細かく設定しています。
    2013年6月20日 6:45
  • チャブーンです。

    状況は何となくですが理解できました。セグメントごとにスイッチやファイアウォールがあり、通信ポートをきちんと制御しているのですね。SOHOや部門レベルの小さなシステムではない、ということですから、きちんとした有償アドバイス(MS有償サポート)を受けられた方がいいと思います。

    簡単なアドバイスを、2つほどします。

    • エフェメラルポート(一時ポート)の扱いについて、FWやスイッチの通過設定を確認する
      Windowsが使う一時ポートですが、XPとVista以降ではポートが変わっています。RPCと呼ばれる特殊な通信(パスワードの変更時にはこの通信が使われます)や、通信時のローカルポートに一時ポートが割り当てられますが、XPで使っていた1024~5000等は7では使われず49152~65535を使用するため、ファイアウォールでこのポートの通信を遮断していた場合、通信ができません。ファイアウォールやスイッチの設定を確かめてみると、何かわかるかもしれません。
    • XPクライアントと7クライアントのネットワークトレースを取ってみる
      専用ソフトを使って、実際のIP通信情報を取ることを「ネットワークトレース」といいます。XPと7でパスワード変更時の状況をネットワークトレースで取得し、比べることで状況の違いが分かります。有名なソフトとしてWireSharkがあるので、これをクライアントにインストールすれば、クライアント=サーバ間の全情報が取れます。ただし、内容の判読には相応の知識が必要ですので、ネット検索等でどのように使うのか事前に調べていただくことをお奨めします。


    2013年6月20日 7:55
    モデレータ
  • チャブーンです。

    もうひとつだけ、追加のアドバイスを。(RPCが利用する)一時ポートをWindows XP相当に変更することができます。Windows 7上で、したのコマンドを使ってポートを変更し、問題がなくなればこれが原因、とめどがつくのではないでしょうか。

    • netsh int ipv4 set dynamicport tcp start=1025 num=3976
    • netsh int ipv4 set dynamicport udp start=1025 num=3976

    このコマンドの説明や背景については、したの資料を見てみてください。

    http://support.microsoft.com/kb/929851/ja

    2013年6月20日 9:11
    モデレータ
  • チャブーンさん、いつもありがとうございます。

    早速試してみましたが、結果は同じでした。

    また、ネットーワーク会社にも現象を説明し、調査依頼をしました。

    ポートに関しては、これに該当するようなことはしていないとのことですが、

    調査してくれることになりました。

    2013年6月21日 4:59
  • チャブーンです。

    そういうことであれば、質問者さん側でできそうな話としては、「XPと7でネットワークトレースを取り、内容を比較する」という以外の方法は難しいと思います。

    ネットワークトレースの内容を読むには経験と知識が必要ですので、ご自身での対応は難しいかもしれませんが、ネットワーク会社の方から情報として求められる可能性がありますので、可能であれば取っておかれるといいと思います。

    そのあたりも含め、ネットワーク会社の方と相談されるのがいいと思います。

    • 回答の候補に設定 佐伯玲 2013年6月28日 6:15
    2013年6月24日 7:44
    モデレータ