Yes, we should file a bug for AD. I'll take this offline with you. On the SSL front, it's interesting that you see this as a strength of ADFS. I would argue the opposite. Cert infrastructures are non-trivial to configure or maintain, I always saw it as a downside to ADFS that it requires one to get a PhD is certology and make this work not only for you but across organizations, assuming you use it in this way. Of course, the real solution to all of this is making a cert infrastructure as easy to run as, say, the key infrastructure that makes Kerberos "just work" for you.
~Eric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Kaplan Sent: Sunday, September 24, 2006 10:49 AM To: [email protected] Subject: Re: [ActiveDir]SUBDOMAIN AND LDAP That's very cool, Eric. I had no idea that setting existed in ADAM. Any change of sneaking that into the AD stack? I agree that it only solves half the problem, but at least by preventing this from working at all, it keeps people from setting up apps that will do unsecure simple binds thousands of times per day for years. There is only so much you can do. I also agree that SSL just isn't that easy and can't be, just because of the way it works. That doesn't stop me from wishing it was. :) One thing I like about ADFS is that you have to use SSL to play, so you can't even get yourself in trouble. I'll definitely file a bug on the audit thing. I think that would be nice, even with ADAM in the mode to reject insecure simple binds, because you could find out which clients are attempting it. Joe K. ----- Original Message ----- From: "Eric Fleischman" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Sunday, September 24, 2006 11:48 AM Subject: RE: [ActiveDir]SUBDOMAIN AND LDAP > 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 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
