Windows管理者のためのネットワークコマンド実践テクニック

Command-2 Active Directoryドメインログオンに時間がかかる

Active DirectoryドメインにWindows XPクライアントがログオンするときには、DNSベースでドメインコントローラを検索してkerberos認証を行い、そのあとグループポリシーを適用します。ログオンに何分も時間がかかってしまう場合、この流れがうまくいっていないために起こることが普通です。ドメインコントローラ側に異常がない前提であれば、ログオンの流れに添って、切り分けを行う方法があります。

ドメインコントローラの確認

まず、現在ログオンしているドメインコントローラを確認します。ドメインコントローラを確認するには、echo %logonserver% コマンドを使いますが、Windows XPでは "高速ログオン機能" があるため "前回ログオンしたドメインコントローラ" が表示されることがあるので、注意が必要です。

図1 echo %logonserver%コマンド
C:\>echo %logonserver%
\\DOM1

C:\>

次に、ドメインコントローラに対して(FQDNではなく)コンピュータ名でpingを打ちます。このとき、ping の結果の可否はもちろんですが、どう表示されたのか確認します。ドメインコントローラの FQDN が dom1.example.com だったら "Pinging dom1.example.com [IP アドレス] with 32 bytes of data:" と表示されれば DNS ベースで名前解決しています図2が、"Pinging dom1 [IP アドレス] with 32 bytes of data:" であれば、NetBIOS over TCP/IP(NBT)での名前解決となり図3⁠、修正の必要があります。

図2 DNSベースで名前解決されているping
C:\>ping dom1

Pinging dom1.example.com[192.168.10.28]with 32 bytes of date:

Reply from 192.168.10.28: bytes=32 time=2ms TTL=128
Reply from 192.168.10.28: bytes=32 time<1ms TTL=128
Reply from 192.168.10.28: bytes=32 time<1ms TTL=128
Reply from 192.168.10.28: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.10.28:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 2ms, Average = 0ms
図3 NBTベースで名前解決されているping
C:\>ping dom1

Pinging dom1 [192.168.10.28] with 32 bytes of date:

Reply from 192.168.10.28: bytes=32 time=2ms TTL=128
Reply from 192.168.10.28: bytes=32 time=1ms TTL=128
Reply from 192.168.10.28: bytes=32 time=1ms TTL=128
Reply from 192.168.10.28: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.10.28:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 2ms, Average = 1ms

DNS設定の確認

ipconfig /allコマンドを表示し、"Primary Dns Suffix" と "DNS Suffix Search List" を確認します図4⁠。Active Directory DNS 名が入っていない場合、システムのプロパティの [コンピュータ名] タブにある "このコンピュータのプライマリDNSサフィックス" を修正します図5⁠。こちらが正しいのに "DNS Suffix Search List" に DNS 名がない場合、ネットワーク接続TCP/IPプロパティの詳細設定の [DNS] タブにある "以下のDNSサフィックスを順に追加する"を修正しますが、他のDNS名がいらない場合は "プライマリおよび接続専用のDNSサフィックスを追加する" を設定します図6⁠。

図4 ipconfig /allコマンド
C:\>ipconfig /all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : chabcl02
        Primary Dns Suffix  . . . . . . . : example.com
        Node Type . . . . . . . . . . . . : Hybrid
        TP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : example.com

Ethernet adapter ローカル エリア接続:

        Connestion-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Intel 21140-Based PCI Fast Ethernet Adapter (Generic)
        Physical Address. . . . . . . . . : 00-03-FF-0D-0D-96
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 192.168.10.30
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.268.10.1
        DNS Servers . . . . . . . . . . . : 192.168.10.28
図5 プライマリDNSサフィックスを設定
図5 プライマリDNSサフィックスを設定
図6 DNS サーチリストを追加する
図6 DNS サーチリストを追加する

つぎに、実際にDNSベースでドメインコントローラの検索ができているかを、nslookup -q=all _ldap._tcp.dc._msdcs.example.com コマンドの結果から、SRVレコードを検索します図7⁠。SRVレコードが引けない場合、図4のipconfigコマンドの"DNS Servers"を確認し、ドメインコントローラ(のDNS⁠⁠ 以外のDNSサーバが指定されていたら修正します。問題ないはずなのにSRVレコードが検索できないときには、udp/53やtcp/53のフィルタリングを疑います。

図7 nslookup -q=all _ldap._tcp.dc._msdcs.example.com コマンド
C:\>nslookup -q=all _ldap._tcp.dc._msdcs.example.com
Server:  dom1.example.com
Address:  192.168.10.28

_ldap._tcp.dc._msdcs.example.com        SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          srv hostname   = dom1.example.com
dom1.example.com        internet address = 192.168.10.28
※)
設計によりドメインコントローラ以外のDNSサーバに配置されていることもあります

フィルタリング設定の確認

ログオンが遅くなる原因に、ネットワーク間で不要なフィルタリングが行われていることがあります。たとえばMS-RPCと呼ばれる、動的なサービス(リソース)の生成などが、ログオン時には実行されますが、これは動的にポートが決まるため、ファイアウォールなどでフィルタされていると、動作できないことがあり、このためログオンが遅くなります。

図8 MS-RPCサーバとクライアント
図8 MS-RPCサーバとクライアント

ポートのフィルタリングは、netsh diag connect iphost dom1 [ポート番号] コマンドを使ってある程度確認できます。netsh diag connectコマンドは接続先のポートリスン状態を確認するものですが、リスンしているはずのものが確認できない場合、ネットワーク間でのフィルタリングを疑うことができます。

図9 相手先ポートへの接続が成功した場合
C:\>netsh diag connect iphost dom1 1025

IPHost (dom1)
    IPHost = dom1
    Port = 1025
    サーバーは次のポートで実行中と思われます [1025]


C:\>
図10 相手先ポートへの接続が失敗した場合
C:\>netsh diag connect iphost dom1 1025

IPHost (dom1)
    IPHost = dom1
    Port = 1025
    サーバーは次のポートで実行中と思われます [なし]


C:\>

確認するポート番号については、たとえば以下のようになります(影響の大きいものを挙げていますので、ファイアウォールで必要なポートとは一致しません⁠⁠。切り分けで問題ないことがわかっているもの ⁠ここではDNS⁠⁠ は省いてよいでしょう。ただし、netsh diag connect iphostコマンドではTCPポートのリスンしか確認できず、UDPはできません。あくまでも「当たりをつける」切り分けとなるので、注意してください。

DNS53
kerberos88
MSRPC エンドポイントマッパ135
LDAP389
CIFS445
MSRPC 1024-5000
(※小さい番号から任意に埋まっていくため、実際に調べるときには若い方から5~6個でよいでしょう)

これ以上の内容については、やはりパケットキャプチャを取るなどの方法で、ネットワークの細かいやりとりを調べる必要があります。

おすすめ記事

記事・ニュース一覧