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サフィックスを設定
図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
フィルタリング設定の確認
ログオンが遅くなる原因に、ネットワーク間で不要なフィルタリングが行われていることがあります。たとえば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はできません。あくまでも「当たりをつける」切り分けとなるので、注意してください。
DNS 53
kerberos 88
MSRPC エンドポイントマッパ 135
LDAP 389
CIFS 445
MSRPC 1024-5000(※小さい番号から任意に埋まっていくため、実際に調べるときには若い方から5~6個でよいでしょう)
これ以上の内容については、やはりパケットキャプチャを取るなどの方法で、ネットワークの細かいやりとりを調べる必要があります。