[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: rewrite a login into a dn in simple bind

Hi Howard,

Howard Chu wrote:

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

My application, which replaces the logon window of MS Windows (all versions from NT4 to XP and 9x), is installed on every workstation of the customer. This application uses the MS ADSI API to bind to an LDAP server using the credentials provided by the user.

In fact the configuration effort is not the main problem
The main problem is that I don't want to store a password somewhere on each computer.

Even if it is encrypted, it is not secure, because by retro-engineering the application someone can retrieve this password (as I have been said)

The application is intended for very large organisations, where you can't trust the users, who are very various.

sorry for talking about configuration problems, it is mainly a security problem

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.

That is in the case where the application search the directory for the dn of the entry having the login as an attribute

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

As I said, it is not the main problem of this method.

So my constraint is : no credentials stored in the application files

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


in this page I don't see any ability to use SASL mechanism

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:

This page is talking about the MS ldap api (Wldap32)
The ADSI API is above the LDAP api, and it doesn't let the developper use all the features of the LDAP api.
I use ADSI :(
and I really think that ADSI can't let me use SASL mechanisms like DIGEST-MD5

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.

For GSSAPI I need a kerberos architecture, and the customer may want not to use the microsoft's one to store its security data (Do I need to say that some people don't like MS very much ? :) )

As you said, DIGEST-MD5 is only supported by windows XP, so I can't use it, as many companies use W2k.
And as I said, DIGEST-MD5 doesn't seem to be supported by ADSI api

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.

yes, for me SASL is the perfect method, but I seem not to be able to use it, since I must (for the moment) use ADSI api.

I think I am seriously going to study a translation of all our applications and libraries into ldap api. But it will cost a lot of time (and a lot of money)

My last hope is a module of openldap that could let me modify the dn used in the bind, to translate a login name into a well formed dn

here is a sample of what I saw in the slapd-meta manpage :

       # Then we need to detect DN made up of a single email,
       # e.g. `mail=someone@example.com'; note that the rule
       # in case of match stops rewriting; in case of error,
       # it is ignored.  In case we are mapping virtual
       # to real naming contexts, we also need to rewrite
       # regular DNs, because the definition of a bindDn
       # rewrite context overrides the default definition.
       rewriteContext bindDn
       rewriteRule "^mail=[^,]+@[^,]+$" "%{attr2dn(%0)}" "@I"

can this module help me ?

thank you very much

Francois Beretti

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