Although a do tend to agree that LDAP does not define a good authentication
protocol at all, it is definitely the case that LDAP is used as an
authentication mechanism all over the place. I also don't thing there is
really anything wrong with using it for that per say, as long as it is used
correctly.
Specifically, it is the LDAP bind operation that is typically used for
authentication. The only real problem with using LDAP bind to authenticate
a user is that the only binding mechanism defined directly by the LDAP V3
spec is the simple bind. Simple bind is not secure by itself because it
passes the user's plaintext credentials over the wire. That is ultra bad,
as any snooper can easily recover the user's password. However, when LDAP
simple bind is combined with channel level encryption such as SSL, it really
isn't that bad. :) Sure, I'd rather use Kerberos, but that isn't always an
option.
I've heard a few security experts suggest that you are actually safer using
HTTP basic authentication with SSL over using NTLM auth over HTTP with no
SSL. NTLM is actually that easy to hack. And NTLM actually IS an
authentication protocol (albeit a dated, deprecated protocol that we still
can't seem to get rid of in Windows over 6 years after it fell out of favor
over Kerberos).
When using ADAM as an identity store, the primary means you have available
to you to authenticate your ADAM users is LDAP simple bind (although digest
auth is available if the client knows how to speak it; most don't). If you
want to use the fast concurrent bind feature of ADAM or AD, simple bind is
the only supported authentication mechanism.
The real key is to ensure that simple bind is always combined with SSL (or
some other transport layer security like IPSEC). I'd actually love to see
an option in AD and ADAM that would only allow simple bind on a secure
channel. I think that would be a good product feature, although it would
probably have to be off by default.
I don't expect to see lots of third party apps moving away from LDAP bind as
an authentication mechanism until something else more universal rises up to
replace it. I'm hoping that's WS-Federation/WS-Trust, but somehow I doubt
we'll see that very soon. :)
Joe K.
----- Original Message -----
From: "joe" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Friday, September 22, 2006 8:07 PM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
The first thing I would say and I am shocked Al didn't say is
LDAP IS NOT AN AUTHENTICATION PROTOCOL!!!!
For the the managers and vendors let me repeat ;o)
LDAP
IS
NOT
AN
AUTHENTICATION
PROTOCOL
!!!!
LDAP has to authenticate as a part of giving secure access to data but
that
doesn't make it an authentication protocol. A file server has to
authenticate you in some way shape or form for you to safely access files
too; I don't see people stumbling over themselves to use that as an
authentication protocol. The only reason this comes in from the *NIX world
like this is because Kerberos can be a serious pain in the ass there.
Tough,
use a real authentication protocol.
If the vendor is using it to authenticate and that is all they are doing
my
comment to them is get off your ass and use a real auth protocol and with
Windows the proper auth protocol is Kerberos. Most Windows folks don't
even
have a clue to the technical depth and complexity of Kerberos because
Microsoft did such a bang up job of burying the details for most things
Windows. So if someone doesn't use it, that is their issue, not
Microsoft's.
Following up of course with the things JoeK said which I fully concur
with.
If using LDAP to authenticate though, where in the tree you poke doesn't
matter, as long as the user is a member of that forest, if you specify
their
ID and their password, it will authenticate them by passing the traffic to
whatever DC is required. However, the app should be smart enough to ask
the
proper DC out of the box.
And when you specify the ID, specify either UPN or Domain\UserID, do not
use
DN. Why? Because DN's change and if you allow the apps to say, you have to
stick with a certain DN then you have lost a bunch of flexibility of AD.
Finally, if they don't do basic things like this right, I wonder what your
chances are that they do harder things like attribute ranging and paging
right.
AD is an extremely robust directory service and have tons of failover and
location services built into it. It has been out for 6 years in production
now, much longer in beta phases, etc and if apps still don't know what
they
are doing with it I would greatly question the programmers and the vendor.
It is outright stupid to make your robust directory lower itself to the
standards of a poorly written app. If the app requires and of the
following:
1. Fixed DNs
2. All users under a single base
3. someone to change the ranging values
4. someone to change the paging values
5. a fixed hostname
6. Non-nested groups
7. etc etc etc
Then really investigate that app because it is a pain in the ass. The only
time you should be talking fixed hostnames versus auto service location is
in the case of syncronization. That is the one case where it is a bit
difficult to bounce between DCs but I have seen apps that can pull this
off,
though they are less efficient because they have to regather their
bearings
every time they jump DCs. Most applications do not have this issue.
Especially apps doing basic auth/authz/data lookup.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
