LDAP / ActiveDirectory BindDN構文

クライアントのLinuxベースのハードウェアファイアウォールのトラブルシューティングを行っています。このハードウェアファイアウォールは、シングルサインオン認証のためにActiveDirectoryに接続します。

ActiveDirectoryは、私の知る限りではLDAPの変なバージョンに過ぎず、同じBindDN構文を使用しています-私が間違っている場合は修正してください。

クライアントはこれをBindDNとして構成しました-プライバシー上の理由から実際の文字列は置き換えられましたが、特殊文字と空白は残っています。「somerandomplace \ fubar fubaz」

これは私にとって有効なBindDN構文ではないようで、以前にLDAPを使用したことがありますが、[テスト]ボタンをクリックしてこのBindDNをテストすると、テストは成功します。BindDNの文字を1つだけ変更してテストを再度実行すると、テストが失敗します。

私はここで問題が何であるかを理解しようとしています：

A）BindNDのニュアンスと関連する構文を完全に理解していないこと

または

B）アプライアンスが入力を適切に検証できず、テストを成功と誤って識別している

LDAPは単なるプロトコルです。そして、グレッグが言ったように、Active DirectoryでのMicrosoftの実装は、それを定義するさまざまなRFCに準拠しています。（彼に+1）

ダグの答えは、有効なバインドDNの一例を示しているという点で部分的に正しいです。ただし、Active Directoryでは特に、バインドDN値を他のフォームとして送信することもできます。私の意見で使用するのに最適なフォームは、UserPrincipalName (UPN)明示的に変更されていない限り、通常は次のフォームです。

• <sAMAccountName> @ <ドメインFQDN>（例：user1@contoso.com）

通常のDN値に対するこれの利点は、ユーザーアカウントをAD内で移動でき、資格情報を使用するアプリケーションがその構成を更新する必要がないことです。

これは、次のようなレガシーNetBIOSフォームにすることもでき、クライアントが使用しているように見えます。

• <ドメインNetBIOS名> \ <sAMAccountName>（例：CONTOSO \ user1）

これにはUPN値と同じ利点がありますが、これもレガシと見なされます。NetBIOS名はずっと前に消滅していたはずですが、それは別のスレッドの怒りです。

ユーザーコンテナにあるユーザーのバインドDNは、CN = username、CN = Users、DC = yourdomain、DC = comになります。

Active Directory対応の場合、おそらくsAMAccountnameプロパティを検索するため、ユーザー名を入力しただけでも機能する可能性があります。ユーザー名の前にドメインを付けないでください。

MicrosoftのLDAP実装は準拠しています。DNでは任意の文字が有効です。特殊文字がある場合は、エスケープする必要があります。先頭または末尾にない限り、空白をエスケープする必要はありません。文字は、円記号または同等の16進数の\ nnでエスケープできます。

識別名
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366101%28v=vs.85%29.aspx

space or # character at the beginning of a string    0x20
space character at the end of a string    0x20
,    comma    0x2C
+    plus sign    0x2B
"    double quote    0x22
\    backslash    0x5C
<    left angle bracket    0x3C
>    right angle bracket    0x3E
;    semicolon    0x3B
LF   line feed    0x0A
CR   carriage return    0x0D
=    equals sign    0x3D
/    forwards slash    0x2F