> I'd love to see an AD and ADAM option that would allow the DS to
> reject simple bind operations on non-SSL ports
We agree. That's why we built it in to the product. :) Well, in to ADAM
that is.
See object CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,CN={<GUID>}. Check out the attribute
msds-other-settings, value named RequireSecureSimpleBind=0. Change that
0 to a 1, then you have enabled the protection.
I would point out, this does not prevent a client from *presenting* a
password via simple bind w/o connection security, only from the
operation succeeding. So you could still present a password (thereby
showing it to an attacker), it's just that it won't work. This is
training with the stick, not the carrot.
It's akin to saying, I can protect your SSN from working when you scream
it to me in a room full of people (ie, require you write it on a piece
of paper and pass it over), but I can't stop you from screaming, only
punish you when you make this bad choice.
> 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.
This is a good idea. Can you file a bug for this? I have thought of
doing this before but never thought anyone would appreciate things like
this. :)
> Now, if it was only easy to force all DCs and ADAM
> instances to have valid server certs, we'd be in business. :)
I think it goes w/o saying, but this is impossible. The definition of
"valid" is in the eye of the beholder. For example, to some a
self-signed cert, trusted by no one, is invalid for the DS. However, to
the person that explicitly trusted that cert on their LDAP clients, it's
perfectly fine. That's just one example, the same could be said for
nearly every wonky cert config you think of, especially when you
consider ADAM in the mix.
~Eric
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan
Sent: Sunday, September 24, 2006 9:16 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP
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
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
