I think the bottom line of my argument boils down to "simple bind without
SSL is evil, but simple bind with SSL is acceptable". Secure bind is
generally acceptable, with or without SSL.
As such, I'd love to see an AD and ADAM option that would allow the DS to
reject simple bind operations on non-SSL ports. I think this would go a
long way towards helping enforce my mantra and would likely only have a
negative impact on non-MS apps using simple bind. The vast majority of code
from the MS world uses secure bind by default and actually requires the
developer to go out of their way to get a simple bind. For example, the
basic vbscript:
Set obj = GetObject("LDAP://DC=domain,DC=com")
results in a secure bind with GSS-SPNEGO (hopefully negotiating to Kerberos
:)). The same goes in .NET:
DirectoryEntry entry = new DirectoryEntry("LDAP://DC=domain,DC=com")
To get a simple bind, you must use OpenDSObject in script and pass in the
appropriate flags to NOT have Secure bind set, or set the appropriate
AuthenticationTypes. In general, ADSI does the right thing.
Another thing that would be helpful would be an unencrypted simple bind
audit event that could be configured, so that you could find the IP address
of any client issuing these operations and track them down.
I think one of the reasons why simple bind is used by many vendors is that
it is the only common denominator between other directories and a lot of
LDAP protocol libraries don't support Microsoft auth mechanisms. However,
the good news is that just about every LDAP library does have some sort of
support for SSL. Now, if it was only easy to force all DCs and ADAM
instances to have valid server certs, we'd be in business. :)
Regarding the evolution of authentication protocols with some of the stuff
in WS-*, I have to say that I like the vision. WS-Trust is the plumbing
under not only ADFS, but also CardSpace and the security framework for
Windows Communication Foundation (WCF). The vision is pretty appealing,
because the notion of how a user can be authenticated (via a security token
service) is more abstract and based on open and fairly simple web protocols
(HTTP, XML, PKI). The notion of a security token is now more abstract and
flexible than a Windows token too, in that a token describing an
authenticated user now just contains "claims", not just SIDs. Claims can be
anything (including their group SIDs), so this makes it easier to provide
all the information an app needs to authorize a user without having to
resort to post authentication lookups to go back and get their first name or
their email address. It also allows you to address privacy concerns, in
that each app can be configured to just get the info it needs and none that
it doesn't. Users can be given the right to control what information is
provided about them (which is very explicit in CardSpace, but is more of a
corporate policy thing with ADFS).
All in all, I'm digging the vision. I do think it has a long way to go
before it can become ubiquitous, but I do think it is a better model than
what we have now and the implementation is really simple and open enough
that everyone can play. Some would argue, probably rightly, that MS and IBM
have the keys to the kingdom and the stack is pretty complex with all the
layers of XML protocols. However, Kim Cameron has successfully demonstrated
CardSpace login to his blog running on the LAMP stack, so I'm convinced that
it is pretty doable.
When will we see the Security Token Service and WS-Trust displace the KDC
and SSPI in Windows? I think that will be a while. :)
And I love ADFS. It rocks. Bring on the Active Requester Profile (and a
better GUI)!
Joe K.
----- Original Message -----
From: "joe" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Sunday, September 24, 2006 10:10 AM
Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP
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
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
