Yeah I understand, lots of vendors use LDAP for auth, but it doesn't make it good/right. Just like lots of vendors requiring admin access or always passing NULL for LPSECURITY_ATTRIBUTES when working with securable objects.
ADAM is another story, if you need to use ADAM principals you are stuck with using LDAP for the auth. I still don't like it though. :) Of course you are correct on the using SSL can help beef up the security but that seems to be done in the minority of the cases. Far too many times that I have looked at LDAP traces I see passwords and IDs just flowing across the wire like there was no tomorrow. The thing is most of the users I expect have no clue that they are being exposed in such a way because they trust that the Administrators and vendors actually know what they are doing. Course this is the case with many web based apps as well, but folks have started to learn to mistrust these automatically as time goes by. The little "key" on the browser helps a little but it tells you nothing about the backend and how insecure it is. I guess a possible configuration to help with this would be to configure IPSEC to only allow port 389/3268 to be used by replication partners. This would probably just break a ton of other stuff including anything using say kerberos/ntlm LDAP packet encryption or TSL as well as all of the non-secured stuff. As for the WS-* stuff, this is obviously more prevalent than just Web related techs. I admit to being completely uninformed on those protocols. Is your thought that those protocols are headed in the direction to be more universal and used even when Web access isn't even involved? joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Saturday, September 23, 2006 12:15 AM To: [email protected] Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP 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: <[email protected]> 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 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
