アプリケーションをだましてユーザーをログインさせようとしています。私は何かをハッキングしようとしているわけではありません。厳格な設定に接続しようとするアプリケーションを購入しました。私はそれを機能させようとしています。
基本的に、検索ベースを定義する必要があります。
ou=employees,ou=Main,o=mycompany
そして、johnsmith としてログインしようとすると、次のようにユーザー名が uid として検索ベースに事前に追加されます。
uid=johnsmith,ou=employees,ou=Main,o=mycompany
Novell eDirectory は識別名として ( uid ではなく) cn を使用していることがわかりました。
ワイルドカードを使用してアプリケーションをだます方法はありますか? 私はこのようなものがうまくいくことを望んでいました:
uid=*,cn=johnsmith,ou=employees,ou=Main,o=mycompany
しかし、これは機能しません。^
「Novell eDirectory は cn を識別名 ( uid ではなく) として使用していることが判明しました。」というあなたの声明。それ自体は正しくありません。
デフォルトでは、ネーミング属性として属性 CN を使用します。ネーミング属性が uid= であるオブジェクトを eDirectory で作成できますが、これはデフォルトではありません。
modrdn を使用して LDIF を介して全員の名前を uid= 現在の CN 値に変更できます。
最初は、uid 属性を LDAP サーバー属性マッピングの CN 値に再マップすることを提案するつもりでした。しかし、考え直して、それが役立つかどうかはわかりません。
あなたのアプリは uid= 何らかの値を持つユーザーを検索しているのではなく、仮定に基づいて DN を構築しているためです。
しかし、それが役立つかどうか試してみることができます：
LDAP サーバ オブジェクト (この変更を行うには iManager を使用する必要があります。ConsoleOne スナップインは更新およびサポートされなくなりました) には、LDAP 属性マッピングを指定するオプションがあります。
eDirectory CN を LDAP uid にマップするだけです。
また、eDirectory サーバー側で DStrace を使用して、LDAP クエリ経由で受信するイベントを監視する方法を知っていますか?
(eDir serverIP:Netware の場合は 8008、Linux または Windows/nds の場合は :8028、次に設定をトレースし、すべてクリアし、LDAP を有効にします)。
答えはノーだ。検索リクエストには、次のパラメーターが必要です。
サーバーは、base object. が である場合、 の下位にscopeあるsubtreeすべてのエントリbase objectが候補になり、 が である場合、 のscopeすぐone下位にあるエントリのみが候補base objectと見なされます。フィルターは、候補を除外するために使用されます。つまり、アサーションが評価された候補のみが LDAP クライアントに返されます。属性のリストが空の場合、操作属性を除くすべての属性が返されます。属性のリストに含まれる場合scopebasebase objectfiltertrue@objectClassNameの場合、エントリに存在する指定された objectClass で必須または許可されているすべての属性が返されます。属性のリストが"1.1"LDAP クライアントに返されるエントリの識別名のみの場合 ("1.1"は属性が一致しない OID です)、属性のリストが の場合"+"、すべての操作属性がクライアントに返されます。それ以外の場合、要求された属性はLDAP クライアントに返されます。LDAP 準拠のサーバーは、名前で明示的に要求された場合にのみ操作属性を返します。これtime limitは、サーバーが要求の処理に費やす必要のある、クライアントが要求するオプションの制限です。のsize limitサーバーが LDAP クライアントに返すエントリの数について、クライアントが要求するオプションの制限です。クライアントが要求したパラメーターは、サーバーの設定をオーバーライドできません。Controls検索リクエストに含まれるオプションのデータです。検索リクエストの詳細については、「ldapsearch の使用」を参照してください。