RE: rewrite a login into a dn in simple bind

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Francois Beretti

This thread appears to be a moving target. I believe the project requirements
have not been specified correctly, or not researched thoroughly enough.

> Francois Beretti wrote:
>For technical reasons, I would like to bind to my openldap server using
>a login, not a dn, and I can't use other method than simple bind (with
>or without ssl/tls)

Simple Bind requires a DN. If you only get a login name, your client must
tack on an attributeType at least, putting it in proper
AttributeValueAssertion (AVA) form, and search for it. The attributeType that
you choose, the LDAP server that you query, and the subtree to search under
must all be configured into the client.

>Ok, but if the access control rules of the server don't allow any
>anonymous bind, or don't give search access on uid attribute, or read
>access on users' entries, I can't use this method, because I think some
>LDAP administrators won't let me set such access rules on their openldap
>server for my application to work on their network.

>> Then ask them to create an application account.  We do this all the time.

>I can't do this :)

>my application is intended to be installed on every workstation in a
>company, and administrators will have to enter the application account
>credentials on each computer :-/
>I understand your idea, but I will have to enter the dn and password
>when installing the application, dont'you agree ?

The administrators already have to provide several items of information on
every client. (See above.) What's one or two more?

>My application is not written for me or my company, it is intended to
>customers, and must adapt itself to their directory server (iplanet,
>openldap, active directory, ...)

This was first posed as an OpenLDAP question. If you also need to solve this
for iPlanet, ActiveDirectory, and whatever else, then it's pointless to ask
about a custom feature in OpenLDAP. You have rejected other suggested
solutions because they won't work in 100% of the deployments. Why accept a
solution here, that also will not work in 100% of your deployments? This
logic is flawed.

>> Use sasl bind (the ldap server will map login id to dn).

>Yes, I thought of it about a second after my boss asked it to me, but...
>it's hard to say... I _must_ use Microsoft's ADSI API to talk with the
>server, and this poor thing can't use SASL (AFAIK) :(

You need to learn more about ADSI and how Microsoft implemented their LDAP
client.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/adsi/
adsopenobject.asp

SASL is the best possibility - it is standards-based and actively supported
by most directory vendors.

This link lists the SASL mechanisms supported by various Windows releases:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/ldap/
using_ldap_init.asp

>I haven't other choice than using simple bind (over ssl if I want to be
>more secured)

Using SSL will also require additional configuration effort on each client,
since you must install the proper CA certs on each client. With SASL/GSSAPI
the Windows machine is pre-configured, so there's no extra effort required.
With SASL/DIGEST-MD5 there's also no configuration effort required, but the
client must be Windows XP to support it.

Several approaches have been suggested here; all of them are in common use.
SASL is your best bet. If you want something else, it will be a custom
solution, tailored to each directory server vendor, version, and deployment.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support