LDAP（Lightweight Directory Access Protocol）は、階層的なディレクトリデータを効率的に照会・更新するための標準プロトコルであり、Active DirectoryやOpenLDAPなどの認証・情報管理基盤で広く利用されています。Wiresharkはこのプロトコルをネイティブにサポートしており、暗号化されていないトラフィック（ポート389）およびTLSで保護されたLDAPS（ポート636）の両方を正確にデコード・表示できます。

プロトコル解析の内部構造

WiresharkのLDAPディセクタはepan/dissectors/packet-ldap.cに実装され、BER（Basic Encoding Rules）形式のASN.1メッセージを逐次パースします。各LDAP PDU（Protocol Data Unit）はMessageIDで関連付けられ、操作タイプ（Bind、Search、Modifyなど）に応じて異なるTLV（Tag-Length-Value）構造を持ちます。定数定義はpacket-ldap.hで管理され、たとえばLDAP_RES_SEARCH_ENTRY（値4）やLDAP_RES_SEARCH_RESULT（値5）といったマクロが、WiresharkのGUI上で「Operation」フィールドとして表示される根拠となっています。

効果的なトラフィック収集手法

ネットワークインターフェースを選択後、以下のキャプチャフィルタを適用すると、LDAP関連のTCPセッションのみを対象にできます：

tcp port 389 or tcp port 636

収集後の分析では、表示フィルタを活用して特定の動作に焦点を当てられます：

• ldap.opcode == 3：すべての検索要求（SearchRequest）を抽出
• ldap.search_filter matches "(uid=.*admin.*)"：管理者系アカウントを含むフィルタ条件を含むリクエストを特定
• ldap.result_code != 0：失敗した操作（エラー応答）のみを一覧表示

主要なメッセージ要素の解釈

典型的なSearchRequestには以下の必須コンポーネントがあります：

• baseObject：検索起点となるDN（例：ou=People,dc=corp,dc=local）
• scope：検索範囲（0＝base、1＝onelevel、2＝subtree）
• filter：RFC 4515準拠の検索式（例：(&(objectClass=inetOrgPerson)(mail=*))）
• attributes：取得対象属性リスト（空リスト＝全属性）

実際のパケット例（再構成済み）

以下は、Wiresharkで展開されたSearchRequestの構造を簡潔に再現したものです（変数名・レイアウトを変更し、論理は維持）：

LDAP Protocol: Search Request (ID=7)
├─ Message Identifier: 7
├─ Operation Type: Search (opcode=3)
├─ Base DN: ou=Engineering,dc=acme,dc=org
├─ Search Scope: Subtree (2)
├─ Filter Expression: (&(objectClass=posixAccount)(uidNumber>=1000))
├─ Attribute List: uid, gidNumber, homeDirectory, loginShell
└─ Controls: [none]

対応するレスポンスでは、複数のSearchResultEntryが連続して送信され、最後にSearchResultDoneが返されます。成功時のresultCodeは0（success）、認証失敗時は49（invalidCredentials）となります。

運用上の課題診断への応用

Wiresharkを用いたトラブルシューティングでは、次のポイントが特に有効です：

• 遅延要因の特定：「Statistics → Conversations → TCP」でRTT（Round-Trip Time）を確認し、サーバ側処理時間とネットワーク遅延を分離
• 不適切なフィルタの検出：ワイルドカードを多用した(cn=*)や(objectClass=*)は大量の結果を生成し、サーバ負荷を高める
• 権限エラーのトレース：BindRequest後に続くSearchRequestが48（insufficientAccessRights）で終了している場合、ACL設定の見直しが必要