クライアントの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)
です。明示的に変更されていない限り、通常は次の形式になります。
通常のDN値に対するこれの利点は、ユーザーアカウントをAD内で移動でき、資格情報を使用するアプリケーションがその構成を更新する必要がないことです。
これは、次のようなレガシーNetBIOSフォームにすることもでき、クライアントが使用しているように見えます。
これには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