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

つぎに、実際に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と呼ばれる、動的なサービス（リソース）の生成などが、ログオン時には実行されますが、これは動的にポートが決まるため、ファイアウォールなどでフィルタされていると、動作できないことがあり、このためログオンが遅くなります。

ポートのフィルタリングは、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はできません。あくまでも「当たりをつける」切り分けとなるので、注意してください。

DNS	53
kerberos	88
MSRPC エンドポイントマッパ	135
LDAP	389
CIFS	445
MSRPC	1024-5000 （※小さい番号から任意に埋まっていくため、実際に調べるときには若い方から5～6個でよいでしょう）

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