Search code examples
ldapdistinguishednameedirectory

Wildcards in LDAP connection


Possible Duplicate:
What's the difference in using distinguished name with cn or uid when logging into LDAP?

I'm trying to trick an application into logging in a user. I'm not trying to hack anything, we bought an application that tries to connect with some rigid settings. I'm trying to make it work.

Basically I have to define the Search Base:

  ou=employees,ou=Main,o=mycompany

And if I try to log in as johnsmith, it pre-prends the username as uid to the search base like this :

  uid=johnsmith,ou=employees,ou=Main,o=mycompany

Well it turns out that the Novell eDirectory uses cn as the distinguished name ( not uid ).

Is there any way I can trick the application using wildcards? I was hoping something like this might work :

  uid=*,cn=johnsmith,ou=employees,ou=Main,o=mycompany 

but this does not work. ^


Solution

  • The answer is no. A search request requires the following parameters:

    • base object
    • scope (subtree, one, or base)
    • filter
    • list of attributes to retrieve (optional)
    • time limit (optional)
    • size limit (optional)
    • controls (optional)
    • types only (optional)

    The server processes the request by creating a list of candidate entries starting at and including the base object. If the scope is subtree, all entries subordinate to the base object can be candidates, if the scope is one, only entries immediately subordinate to the base object are considered candidates, otherwise the scope is base and the candidate is the base object only. The filter is used to filter out candidates, that is, only candidates wherein the filter assertions evaluate to true are returned to the LDAP client. If the list of attributes is empty, all attributes except operational attributes are returned. If the list of attributes contains @objectClassName, then all attributes that are required or allowed in the named objectClass that are present in the entry are returned. If the list of attributes is "1.1" only the distinguished name of the entry is returned to the LDAP client ("1.1" is an OID that no attribute can match), if the list of attributes is "+", all operational attributes are returned to the client otherwise the attributes requested are returned to the LDAP client. LDAP-compliant servers return operational attributes only when explicitly requested by name. The time limit is an optional, client-requested limit on the amount of time the server should spend processing the request. The size limit is an optional, client-requested limit on the number of entries the server should spend return to the LDAP client. Client-requested parameters cannot override server settings. Controls are optional pieces of data included with a search request. For more information about search requests, see "Using ldapsearch".