バインドDNとは何ですか？

バインド DN（Bind Distinguished Name）とは、LDAP クライアントがバインド操作（クライアントがディレクトリ内でユーザーやグループを検索する前に、クライアントの認証を行う手順）中にディレクトリサーバーに対して提示する、サービスアカウントの識別名です。

主なポイント

• Bind DN は、LDAP クライアントが認証を行う際のサービスアカウントを識別します。
• これはバインドパスワードと組み合わせて、LDAPのバインド操作を完了させます。
• 匿名性、シンプルさ、そしてSASLバインドは、それぞれ異なる方法で身元を証明します。
• Versa バインド DN を使用して、Active Directory からユーザーやグループを検索します。
• Bind DN アカウントが侵害されると、ディレクトリツリー全体が公開される恐れがあります。

このページの内容： その重要性 ・ 仕組み ・ 種類 · DNのバインドとVersa · よくある質問

バインドDNはなぜ重要なのでしょうか？

ディレクトリサーバーには、下流のシステムがアクセス許可の判断を行う際に使用する識別データが格納されています。そのデータを読み取る前に、クエリを送信するシステムは自身の身元を証明する必要があります。これが Bind DN の役割です。Bind DN は、接続が認証されるサービスアカウントを指定するものであり、その後そのシステムが閲覧を許可されるすべての情報は、そのアカウントの権限の範囲内に限定されます。

間違えると認証は即座に失敗しますが、うっかり正しく入力してしまった場合は、それほど目立ちません。ドメイン管理者権限を持つバインドDNは、ゲートウェイがユーザーの認証を行うために必要な範囲をはるかに超えてディレクトリを読み取り、場合によっては書き込みも行うことができるため、これらの認証情報を取得した攻撃者は、そのアクセス権限を引き継ぐことになります。最小権限のサービスアカウントを使用し、平文のバインドではなくSSL/TLSを組み合わせることで、日常的な認証操作がディレクトリ全体への情報漏洩につながるのを防ぐことができます。

バインドDNとは何ですか？

「識別名（DN）」とは、LDAPディレクトリツリー内のエントリへの完全なパスを指し、共通名（CN）、組織単位（OU）、ドメインコンポーネント（DC）などの構成要素から、ドメインのルートに向かって外側に向かって読み進める形で構成されます。「バインドDN」とは、認証済みのLDAPセッションを開くために使用されるアカウントのDNのことです： cn=Administrator,cn=Users,dc=versa,dc=com 「Users」コンテナ内の「Administrator」アカウントを特定します。

バインド操作は LDAP プロトコルの動詞の一つです。クライアントはバインド DN とパスワードを送信し、サーバーは認証を行った上で接続を許可します。その接続で行われるすべての検索は、そのアカウントの権限に基づいて実行され、その範囲はベース DN で定義された範囲に限定されます。バインド DN は、検索を実行するユーザーではなく検索の開始点を示すベース DN や、DN 内に含まれる要素の一つであるコモンネームとは区別されます。

LDAPバインドの種類

LDAPでは、バインドを完了するための3つの方法が定義されており、これらは身元の証明の厳格さが異なります。匿名バインドは認証情報を送信しないため、本番環境のディレクトリでは通常、この機能が無効にされています。シンプルバインド（ほとんどの認証プロファイルで使用されるモード）は、バインドDNとパスワードを平文で送信するため、LDAPSまたはSTARTTLSを介して実行する必要があります。SASLバインドは、Kerberos（GSSAPI）やDIGEST-MD5などのメカニズムに認証を委譲し、パスワードそのものを送信することなく身元を証明します。

ほとんどのエンタープライズ向け統合では、SSLを有効にしたシンプルバインドが使用されています。設定が容易であるうえ、TLSによって、暗号化されていないシンプルバインドでは生じてしまう平文の認証情報のセキュリティ上の脆弱性が解消されるからです。

DN をバインドし、Versa

Versa SSEゲートウェイのLDAPおよびActive Directory認証プロファイルでは、ベースDNやドメイン名に加え、Bind DNおよびBind Passwordが必須フィールドとして指定する必要があります。ゲートウェイは、プロファイルのBind DNを使用してADサーバーへの認証済みセッションを開き、その後、ベースDNの下で検索を行ってユーザーを検証し、グループメンバーシップを取得します。プロファイルパラメータの完全な一覧については、「SSEゲートウェイでの認証プロファイルの設定」を参照してください。

ADサービスアカウントに適したバインドDNを特定することは、よくある設定手順の一つです。その 設定の手順：SSEゲートウェイの認証プロファイル このガイドの付録では、「Active Directory ユーザーとコンピューター」または dsquery user コマンド。

よくある質問

バインド DN とベース DN の違いは何ですか？

Bind DN は、ディレクトリに対して認証を行うサービスアカウントを識別するものであり、Base DN はそのアカウントの検索がツリー内のどこから始まるかを指定するものです。Bind DN には、次のようなものがあります。 cn=Administrator,cn=Users,dc=versa,dc=com, 一方、次のようなベースDNは dc=versa,dc=com すべての検索をドメイン全体を対象に行います。

Bind DN には管理者権限が必要ですか？

いいえ。必要なのは、認証プロファイルが照会するユーザーやグループに対する十分な読み取りアクセス権だけであり、ディレクトリに対する完全な管理者権限は必要ありません。ドメイン管理者ではなく、最小権限のサービスアカウントを使用することで、万が一 Bind DN のパスワードが漏洩した場合でも、攻撃者が得られる権限を制限することができます。

バインドDNやパスワードが間違っていた場合はどうなりますか？

バインド操作は完全に失敗し、ディレクトリサーバーが接続を拒否するため、検索は一切実行できません。つまり、設定ミスのあったアカウントが本来見つけることができなかった特定のユーザーだけでなく、そのプロファイルを通じて認証を行うすべてのユーザーに対してアクセスが拒否されます。

BindのDN認証は、暗号化なしで実行できますか？

技術的には、プレーンテキストのLDAPで単純なバインドを行う場合は可能です。しかし、その場合、バインドDNのパスワードが暗号化されずにネットワーク上を送信されてしまいます。本番環境での導入では、代わりにSSL/TLS（LDAPSまたはSTARTTLS）を有効にし、その後のディレクトリクエリだけでなく、バインド時の認証情報も転送中に保護されるようにする必要があります。

Active Directory サービス アカウントのバインド DN を調べるにはどうすればよいですか？

実行 dsquery user -name <account> ADサーバー上で、アカウントの完全な識別名（DN）を返す――例えば cn=admin,cn=Users,dc=versanetworks,dc=com。「Active Directory のユーザーとコンピューター」では、同じパスが視覚的に表示されるため、アカウントのコンテナまで移動して、そのDNを直接コピーすることができます。

Bind DNに関する詳細

さらに詳しく知りたい場合は、私たちが信頼している情報源を以下にご紹介します。

関連用語

Bind DNについてお読みの方は、次にこれらもぜひチェックしてみてください。