none
ActiveDirectory環境でユーザのログインに時間が掛かる RRS feed

 > 

  • 質問

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

    【環境】
    　＜サーバ環境＞
    　・FSMO
    　　OS：Windows Server 2008
    　　ドメイン機能レベル：2008
    　　※2枚のLANカードを使用し、マルチホスト環境として使用。
    　　　IPアドレスはそれぞれ以下を固定で使用。
    　　　　192.168.11.XXX/22
    　　　　192.168.100.XXX/24

    　　▼補足▼
    　　　・LANカードでネットワークを分けており、それぞれ別ネットワークの
    　　　　端末から接続を行う運用です。

    　　　・以下の役割をインストール中。
    　　　------- ここから -------
    　　　　ActiveDirectory ドメインサービス
    　　　　ActiveDirectory 証明書サービス
    　　　　DHCPサーバー
    　　　　DNSサーバー
    　　　　Webサーバー
    　　　　ネットワークポリシーとアクセスサービス
    　　　　ファイルサービス
    　　　　印刷とドキュメントサービス
    　　　------- ここまで -------

    　・DC1(切り分けのために現在はAD機能等を全て削除しており、
    　　　　今は単なるドメインユーザ)
    　　OS：Windows Server 2012 Standard
    　　※2枚のLANカードを使用し、マルチホスト環境として使用。
    　　　IPアドレスはそれぞれ以下を固定で使用。
    　　　　192.168.11.XXX/22
    　　　　192.168.100.XXX/24

    　＜端末＞
    　　・Windows 7(Pro、Ultimate、Enterprise） 約100台
    　　・Windows 8.1 Pro 約5台

    　　▼補足▼X
    　　　・FSMOのDHCPサーバ機能を使用し、192.168.8.0/22のネットワークに所属させる
    　　　　端末には192.168.8.2/22 ～ 192.168.8.252/22を、192.168.100.0/24の
    　　　　ネットワークに所属させる端末には192.168.100.2/24 ～ 192.168.100.254/24を
    　　　　配布しています。

    　　　・192.168.8.0/22のネットワーク端末が約90台で、192.168.100.0/24の
    　　　　ネットワーク端末が約15台です。

    　＜DHCP設定＞
    　　スコープオプションでは以下の3つを設定しています。
    　　　・003 ルータ 192.168.11.1
    　　　・006 DNSサーバ 192.168.11.XXX(FSMOサーバのIP)
    　　　・015 DNSドメイン名 ドメイン名を記載済み。

    　＜その他＞
    　　・FSMOのDNSサーバ機能において、ラウンドロビンは無効に設定済み。
    　　・FSMOはDHCPサーバ、ファイルサーバ、RASサーバの役割も行っております。

    【現象】
    　192.168.8.0/22のネットワーク端末においてログイン時、「ようこそ」画面での
    　読み込みに数分間の時間を要する場合が多発します。
    　発生時にはイベントID:6005とイベントID:6006がクライアントのイベントログに
    　記録されます。そのため、クライアントOSとしては正常にログイン処理は完了していると
    　考えられます。しかし、元々は30秒以下でログインが行えていた環境である為に
    　ログイン時間が長い事に不満が出ております。

    【再現性】
    　毎日複数端末(192.168.8.0/22の端末の6割～7割程度)で発生します。
    　192.168.100.0/24の端末では発生しません。

    【現象補足】
    　元々はFSMOのみの環境で運用を行っておりましたが、DCの追加を行いました。
    　また、DC追加に伴い元々192.168.11.0/24のネットワーク環境を拡張し、
    　192.168.8.0/22に変更を行いました。

    　作業完了の数日後からログインに時間が掛かるという問い合わせが増えたために
    　以下の確認を行いましたが現象の改善が見られませんでした。

    　　・グループポリシーの削除
    　　　サーバからのログインスクリプト等の影響かを確認するためにテスト的に
    　　　グループポリシーが一切適用されていない端末・ユーザでテストを行いましたが
    　　　現象が再現しました。

    　　・端末を固定IPアドレスにしてのテスト
    　　　DHCPサーバからの配信で今は使用していない 192.168.8.XXX/22 を端末の
    　　　固定IPとして設定して動作テストを行いましたが、現象が再現しました。

    　　・DCをFSMOのみにしてのテスト
    　　　DC追加が影響であるかを確認するためにWindows Server 2012のAD機能、
    　　　DNS機能等を全て削除しましたが、現象が再現しました。

    　なお、PINGコマンドやTRACERTコマンドでドメイン名やFSMO名との疎通テストを
    　行うと、192.168.100.0/24側のIPアドレスに送信されてタイムアウトになって
    　しまいます。
    　※DNSには「192.168.11.XXX」と「192.168.100.XXX」が記載されています。
    　　それぞれのネットワークからの検索で使用するために2つのレコードが登録されて
    　　いる事は正常です。また、元々のネットワーク拡張前からもレコードは2つ
    　　登録されており、正常に動作しておりました。

    【その他】
    　端末でhostsファイルにドメイン名とFSMO名を記載した端末では今のところ現象が
    　発生していない様に見受けられています。
    　そのため、ドメイン名やFSMOを探すために時間を要している可能性が高いのではないかと
    　考えています。


    現状では調査や確認に行き詰っております。

    よろしくお願いします。

    2014年6月4日 2:24
    |

すべての返信

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

    マルチホーム運用は難易度が高いかと。

    とりあえず、 route の設定とかでしょうか。

    アクティブ ディレクトリ通信マルチホーム ドメイン コント ローラーに障害が発生しました。

    マルチホーム コンピュータのデフォルト ゲートウェイ設定

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

    oooohです。

    そもそもMSとしてはADDCのマルチネットワーク運用というのは非推奨でして・・・。

    ドメイン コントローラのネットワーク要件

    私がMIZUNO.1234様の環境で試すなら

    ・FSMOはDC1と同期をさせないといけないのでそのままで、

    ・DC1はIPセグメントを192.168.11.XXXだけにしてDCに昇格・DNSサーバを立てる。

    　(FSMOとの同期は11系アドレスで行うことになります。名前解決ができないならhostsにFSMOを記載。)

    ・DHCPｻｰﾊﾞで192.168.8系クライアントのプライマリDNSをDC1にしてみる。

    とかでしょうか。

    できるだけセグメント内にDNSサーバと認証サーバが存在するようにすると

    セグメントを跨ぐことによるルーティングロスが防げます。

    ：補足

    できるだけセグメント内にDNSサーバと認証サーバが存在するようにすると～

    と書いたのは、現状ではクライアントから見ると別セグメント（100系）のADサーバに

    認証しに行っていると見えるためです。

    • 編集済み ooooh 2014年6月5日 3:01 補足を追加
    2014年6月5日 2:49
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    この件ですが、根本原因はマルチホームネットワークでドメインコントローラを運用していることです。おそらくDNSサーバの「ネットマスクの順序を有効にする」機能を使えばクライアント(が提示する)ネットワークアドレスに対して適切なIPアドレスがドメインコントローラから提示されるはず、と思われているのでしょうが、実際はそうは動きません。

    このシステムでは22ビットのネットワークアドレスがあるようですが、「ネットマスクの順序を有効にする」が正常に機能するのは24ビットのネットワークアドレスに対してであり、それ以外のネットワークアドレスに対して正常動作させるためには、この設定を変更させる必要があります。そういったくだりを含めて、過去にお答えしたことがあるので、したの過去ログをご覧になってみてください。

    http://social.technet.microsoft.com/Forums/ja-JP/18bddee2-b89e-4341-8247-a3507bdd82aa/adnic?forum=activedirectoryja


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

    ご返信ありがとうございます。

    皆様からの情報を参照した上で別のネットワークアドレスに接続しているかをネットワークトレースで確認しました。

    結果、やはり認証時に別のネットワークアドレスに送信しているパケットが多数確認出来ました。

    そのため、DNSに登録されているレコードを192.168.11.XXXのみとし、192.168.100.XXX側の端末には

    hostsファイルを使用して対処を行う運用を対処として行いたいと考えています。

     

    しかし、KB272294を参照しながら設定を行っても、20分ほど時間が経つと自動的に192.168.100.XXXの

    レコードが作成されてしまいました。

    再起動時に登録されてしまうというKB275554の情報はありましたが、ActiveDirectory環境の場合には

    そもそも片方のNICのみをDNSに登録する事もできないのでしょうか？

    　▼補足▼

    　　ネットワーク環境については、今後の社内構成変更時などに別途対処を行う方向で進める予定です。

    2014年6月6日 10:08
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    クライアントのhostsファイルにドメインコントローラのIPアドレスを書く、ということですが、残念ながらこの方法では問題が発生します。ドメイン認証には「SRVレコード」による名前解決が必要で、hostsファイルにSRVレコードを書き込むことはできないので、認証に失敗します。

    修正:ドメインコントローラの片側NICだけを登録する方法について、先に書いた投稿より、簡単な方法でできることがわかりましたので書いておきます。簡単に検証したところうまくいったようです。

    1. 削除したいNIC側の「この接続のアドレスをDNSに登録する」をOFFにする
    2. DNSサーバプロパティのインターフェースで、削除したいNICのIPアドレスをOFFにする
    3. ドメインコントローラを再起動する(できない場合は「DNS Server」と「Netlogon」サービスを再起動する)
    4. DNSゾーンのNSレコードのうち、削除したいIPアドレスのものを手動削除する
    5. _msdcs DNSゾーンの「gc」内のAレコードのうち、削除したいIPアドレスのものを手動削除する

    したのMSのページに情報が書いてありますね。

    http://support.microsoft.com/kb/2023004



    2014年6月6日 10:38
    |
    モデレータ
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンさん、返信ありがとうございます。

    「hostsファイルにSRVレコードを書き込むことはできないので、認証に失敗します」との事ですが、

    この認証に失敗するという点について教えていただけませんか。

    　1)100.XXXのネットワーク端末について影響が出るという事で、DNSサーバが動作している11.XXXの

    　　ネットワーク端末については正常にログインできるという認識で正しいでしょうか。　　

    　2)ドメインに一度も接続した事がない端末については、100.XXXのネットワークからはドメインへの参加が

    　　行えないという認識で正しいでしょうか。

    　3)既に100.XXXのネットワークでログイン済みの端末、かつログイン済みのドメインユーザの場合、端末内部の

    　　キャッシュでドメインにログインなどを行う事は出来るのでしょうか。

    ご存知でしたらご教授をお願いします。

    2014年6月9日 2:34
    |
  • Question
    サインインして投票
    0
    サインインして投票

    チャブーンです。

    この件ですが、ちょっと問題を整理したほうがいいかなと思います。私がお答えしたことはしたのような流れに添っています。

    • クライアントにhostsファイルでドメインコントローラから認証をさせることはできない
    • 質問者さんは(192.168.100.0/24からのログオンについてはあきらめ)192.168.11.0/22からだけ認証をさせたい、と思われている
    • うえをふまえ、私から192.168.100.0/24側NICを無効化する方法をお教えした

    うえの話しは、192.168.100.0/24のクライアントが(他機器によるルーティング等での迂回で)ドメインコントローラの192.168.11.0/22NICと通信ができることが必須です。

    もし話が全然違って、(両者の通信経路は全然ないので)192.168.100.0/24と192.168.11.0/22の両方から直接ログオンさせないと意味がない、ということでしたら、結論として私の最初の投稿にある「ネットマスクの順序を有効にする」機能を22ビットで使えるようにするしかありません。方法は先の投稿のリンク先をご覧になってください。

    hostsの話しは192.168.100.0/24のクライアントに置くわけですから、192.168.11.0/22側クライアントの認証については無関係です。繰り返しますが、ドメインコントローラ認証にはSRVレコードの参照が必要で、hostsファイルには「SRVレコードの代わり」を記述するしくみは一切ないので、hostsファイルでクライアントの認証を行うことはできません。

    あとWindowsには「資格情報のキャッシュ」という機能で、ドメインコントローラと接続していなくても、アカウントとパスワードを入力するとデスクトップを表示させる(ログオン後の画面が表示される)ことはできます。ですが、ドメインコントローラとの認証をしていないので、そのあとの操作(ファイルサーバ等他のリソースへのアクセス)はすべて失敗します。結論としてキャッシュのみで「ドメインにログオン済み」の状態にすることはできません。

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

    Windows 7 または Windows Server 2008 R2 ベースのドメイン メンバーコンピューター上で、ドメイン コント ローラーが利用できない場合のスタートアップまたはログオン時間

    根本的な解決ではないでしょうけど。

    2014年6月10日 9:09
    |