[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
client.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/adsi/
adsopenobject.asp
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:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/ldap/
using_ldap_init.asp
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