ほとんどの組織はユーザーアイデンティティをLDAPまたはADディレクトリ上で管理しています。新しいアプリケーションが導入されるたびに同じ問いが繰り返されます：このアプリケーションはどのようにディレクトリに接続するか、どのようにユーザーを検証するか、どのグループ情報を読むか、どこでアクセス判断を行うか。この接続を各アプリケーションで個別に行うと、アイデンティティアーキテクチャは急速に分散します。
アプリケーションごとのLDAP統合は運用上の負債を生みます。各アプリケーションが独自のサービスアカウント、接続アドレス、検索フィルター、タイムアウト値、証明書検証設定を抱えます。ディレクトリスキーマが変わったとき、OU構造が移動したとき、サービスアカウントのパスワードがローテーションされたとき、またはドメイン移行を行ったとき、この変更が多数のアプリケーションに波及します。
セキュリティ面でもリスクが大きくなります。暗号化されていないLDAPの使用は、パスワードがネットワーク上で保護されずに運ばれることにつながりえます。サービスアカウントのパスワードがアプリケーション構成に保存されます。グループベースの認可はアプリケーション自身のコードに分散します；認証とアクセスポリシーが異なるシステムで異なるルールで適用されます。
監査と可視性も断片化します。どのアプリケーションがどのサービスアカウントでディレクトリに接続したか、どのユーザーが検証されたか、どのグループがクエリされたか、どのアクセスが拒否されたか、という情報はしばしばアプリケーションログに埋もれたまま残ります。SOCと監査チームは、中央集権的なアイデンティティフローの代わりに、散在したログを集約せざるを得ません。
TR7 LDAP / AD Bindはこの問題をアクセスプラットフォームで解決します：direct-bindおよびsearch-bind方式、LDAPSセキュアトランスポート、グループメンバーシップのクエリ、bind restrictionフィルター、複数サーバーのフェイルオーバー、AAM条件付きアクセスポリシーが単一アーキテクチャに統合されます。
TR7 AAMは、LDAP/AD接続を単なるパスワード検証としてではなく、ユーザー検索、グループクエリ、セキュアトランスポート、アクセスポリシー生成のフローとして扱います。
direct-bindは、ユーザー名をUPN、NetBIOS、UID、CN、またはカスタムパターンでbind principal値に変換します。search-bindは、サービスアカウントでユーザーのDN情報を検索し、その後ユーザー自身のパスワードでbind検証を行います。
search-bindモードではグループ検索を有効化でき、ユーザーのグループメンバーシップがAAMセッションに追加されます。このグループ情報は、アプリケーションアクセス、MFAの必須化、またはbackendベースの権限判断に利用できます。
TR7はLDAPS経由でTLS保護された接続を確立できます。証明書検証とself-signed証明書ポリシーを構成することで、ディレクトリ接続のセキュリティレベルを組織の標準に応じて決定します。
複数のLDAP/ADサーバーを単一の構成内で定義できます。roundrobin、weighted、またはfailover方式で接続が分散されます；プライマリディレクトリサーバーがアクセス不能になったとき、代替サーバーが投入できます。
LDAP / AD Bindは、エンタープライズディレクトリ検証を、bindテンプレート、検索フィルター、グループメンバーシップ、セキュアトランスポート、複数サーバー管理とともにAAMフローに接続します。
direct-bindモードでは、ユーザー名がUPN、NetBIOS、UID、CN、またはcustomテンプレートのいずれかでbind principal値に変換されます。AD環境ではUPNとNetBIOS形式が一般的です；OpenLDAPやPOSIXディレクトリではUIDとCNパターンがより適切な場合があります。customパターンでは、uid={{username}},ou=people,dc=company,dc=comのような組織固有の構造を構築できます。この柔軟性により、異なるディレクトリスキーマを単一のAAM検証フローに接続することが容易になります。
search-bindモードでは、TR7はまずサービスアカウントでディレクトリに接続し、ユーザーのDN情報を検索します。ユーザーが見つかると、第二段階でユーザー自身のDNとパスワードでbind操作が行われます。このモデルは、ユーザーが異なるOUに存在する場合、DN情報がユーザー名から直接生成できない場合、またはより制御された検索フィルターが必要な環境で有用です。サービスアカウントと検索base DN情報は中央集権的に管理されます。
search-bindフィルターは自動モードでuserPrincipalName、sAMAccountName、cnフィールドを一緒に評価できます。customモードではオペレーターが独自のLDAPフィルターを定義します；例えば(sAMAccountName={{username}})のようにより狭い検索が可能です。このアプローチは異なるディレクトリスキーマとユーザー名形式に適応します。誤ったユーザーマッチを減らすため、フィルターはできる限り明確に定義すべきです。
ユーザーのパスワードが正しくても、すべてのディレクトリユーザーがすべてのアプリケーションにアクセスすることは望ましくない場合があります。bind restriction filterにより、特定のOU、グループ、または属性条件を満たすユーザーのみが検証フローを通過するようにします。例えば、VPN Usersグループのユーザーのみが特定のbackendへ受け入れられます。このフィルターは、認証をアクセス範囲とともに評価します。
ldapEnableGroupSearchが有効なとき、TR7はユーザーDN値を使ってグループメンバーシップをクエリできます。ldapGroupSearchBaseとldapGroupFilterで、どのディレクトリ領域でどのフィルターでグループを検索するかが決まります。返されたグループリストはAAMセッションに追加されます。条件付きアクセスフローは、このグループ情報に応じて、異なるアプリケーション、MFA、許可、または拒否の判断を下せます。
LDAPSが使用されると、LDAP接続はTLSで保護され、通常636ポート上で動作します。サーバー証明書の検証挙動はsslValidateCertificateとsslAllowSelfSignedといった設定で構成できます。本番環境では暗号化されていないLDAPは推奨されません。ディレクトリ接続のセキュリティは、ユーザーパスワードやサービスアカウントといった機微なデータを保護するための基本要件です。
LDAPの接続および操作タイムアウト値は構成できます。接続が確立できない場合、またはディレクトリサーバーの応答が遅い場合、AAMフローは無限に待機しません。ピーク時の遅いドメインコントローラーの挙動やネットワークセグメントの遅延は、これらの値で制御できます。タイムアウト設定は、ユーザー体験とフェイルオーバー挙動とともに計画すべきです。
TR7は、特定のsearch base配下のユーザーを取得し、メールや電話のような属性値をAAMローカルユーザープロファイルへ移すことができます。queryMailFieldやqueryPhoneFieldのようなフィールドは組織スキーマに応じて設定できます。この機能はユーザーリストと連絡先情報の管理を助けます。クラスタ環境では、ユーザーリスト取得はprimary nodeのみで動作するよう制限されます。
hosts配列に複数のLDAP/ADサーバーを定義できます。lbMethodはroundrobin、weighted、またはfailoverとして選択できます。failoverモードでは、プライマリサーバーがアクセス不能になると代替サーバーへ切り替わります。接続プールとサーキットブレーカーのアプローチが、継続的に失敗するサーバーがフローを乱すことを減らします。
LDAPサーバーへどのネットワークネームスペース経由で到達するかを構成できます。これは、別セグメントのドメインコントローラーやテナント固有のディレクトリ構造にとって重要です。アクセス管理のトラフィックは正しいルートテーブルとネットワーク隔離を経由して運ばれます。マルチテナントまたは分離されたデータセンターのアーキテクチャでより明確なネットワーク制御を提供します。
LDAP / AD Bindは、接続ライフサイクル、フィルターセキュリティ、接続クリーンアップ、search-bind挙動、クラスタ制約、属性選択とともに運用されます。
LDAP設定が更新されると、接続情報が再準備され、検証フローが新しい設定で動作します。接続情報はprotocol、host、port、TLS、timeoutパラメータから生成されます。設定変更を中央集権的なライフサイクル内で適用することが構成の一貫性を提供します。
ユーザー入力はLDAPフィルターに配置される前に特殊文字がエスケープされます。バックスラッシュ、アスタリスク、括弧、null文字のような値は、LDAPインジェクションのリスクを減らすためにエスケープされます。この挙動は特にカスタムフィルターを使う構成で重要です。
LDAP接続は使用後にクライアントがクリーンアップされ、listenerが削除されます。このアプローチはゾンビ接続と不要なメモリ使用を減らします。長期のkeep-alive挙動は、ユーザーリスト取得のような特定のモードでのみ使用すべきです。
自動search-bindフィルターはuserPrincipalName、sAMAccountName、cnフィールドを一緒に評価できます。カスタムフィルターモードではオペレーターが独自のLDAPフィルターを定義します。カスタムフィルターは強力です；ただし、誤って広いフィルターは予期しないユーザーマッチにつながりうるため、慎重に設計すべきです。
新世代のLDAP backendプール構造は、LDAPクライアント接続をプールロジックで管理できます。LDAPSが選択されると、TLSオプションが接続確立に追加されます。専用のDNSルックアップ時間と接続タイムアウト値は、遅いまたはセグメント化されたネットワークで重要になります。
ユーザーリスト取得は、クラスタ環境ではprimary nodeのみで動作するよう制限されます。この挙動は、同じユーザーリストが複数のノードによって同時に取得され不要な負荷を生むことを防ぎます。認証bindフローは、定義された接続モデルに従って動作し続けます。
ldapAttributes配列で、ディレクトリからどのフィールドを返すかが決まります。デフォルトのフィールドはdn、cn、userPrincipalName、displayName、mail、電話のような値を含みえます。department、employeeID、またはカスタム属性のような追加フィールドは、組織のニーズに応じてリストに追加できます。
大規模組織で従業員が既存のADユーザー名とパスワードでAAM経由でアプリケーションにアクセスします。グループメンバーシップがAAMポリシーへ運ばれます；財務、人事、ITのグループは異なるアプリケーションやMFAフローへルーティングできます。ADパスワードポリシーが変わってもアプリケーションを一つずつ更新しません。
2つのデータセンターに2つのドメインコントローラーがある構成で、TR7はfailover方式で接続を確立できます。プライマリディレクトリサーバーがアクセス不能になると代替サーバーへ切り替わります。ユーザー検証フローは単一DCの障害に縛られません。
特定のbackendがVPN Usersグループのユーザーのみに開放できます。bindが成功してもbindRestrictionFilter条件を通過しないユーザーは拒否されます。これにより、パスワード検証とアプリケーションアクセス権限が同じものとは見なされません。
ADの代わりにOpenLDAPを使う組織は、UIDまたはCN bindテンプレートでユーザー検証を行えます。posixAccountベースのディレクトリでは、メール、電話、カスタム属性のマッピングをAAMプロファイルへ運べます。LDAPSでセキュアな接続を確立することで、クラシックなLDAPディレクトリがモダンなアクセスフローに取り込まれます。
LDAP/AD接続、グループベースのポリシー、LDAPSセキュアトランスポート、中央集権的な監査が単一プラットフォームに。あなた自身の環境のライブセットアップでご案内します。