Wildcards in LDAP connection

Question

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. ^

Answer 1

Your statement that 'Well it turns out that the Novell eDirectory uses cn as the distinguished name ( not uid ).' is not per se correct.

By default it uses the attribute CN as the naming attribute. You can make objects whose naming attribute is uid= in eDirectory but it is not the default.

You could rename everybody via LDIF with a modrdn to uid= their current CN value.

I initially was going to suggest you remap the uid attribute to be the CN value in the LDAP Server attribute mapping. But on second thought I am not sure if that will help.

Because your app is not searching for a user whose uid= some value, rather it is building a DN based on an assumption.

But you could try and see if it helps:

In your LDAP Server object, (you should use iManager to make this change, the ConsoleOne snapins are no longer updated and supported) there is an option to specify LDAP Attribute mappings.

Just map eDirectory CN to LDAP uid.

Also, do you know how to use DStrace on the eDirectory server side to watch events as they come in via LDAP queries?

(eDir serverIP:8008 for Netware, :8028 if on Linux or Windows/nds and then trace config, clear all, enable LDAP).

Answer 2

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".