title: How Do Microsoft's Active Directory Security Requirements Affect My C# Application
body: <p>I'm trying to get some clarity on the guidelines/requirements that Microsoft released this month regarding AD and LDAP.  My company produces software that queries AD for groups and users.  We use several .NET classes within the System.DirectoryServices.AccountManagement namespace for pretty much all of this.  We use the PrincipalContext class with the default options (Negotiate, Signing, Sealing) to perform the binding.</p>
  
  <p>We have a customer who is requiring that we support LDAPS because they believe this is being mandated by Microsoft.  From what I have been able to gather, the requirement is only that bindings be done in a secure manor, not necessarily that they be done using one particular approach.  However, I'm still not entirely certain that my interpretation is correct.  If I could get answers to the following questions, I should be in a better position to know what we need to do for this customer.  Please keep in mind that we're only concerned with Active Directory.</p>
  
  <ol>
  <li>By my reading, signing and sealing is secure, and is actually how
  most Microsoft client/server applications bind.  Is this correct?</li>
  <li>LDAPS is probably only necessary to support clients that cannot use
  signing/sealing (possibly because the client doesn't support NTLM or
  Kerberos).  Is this correct?</li>
  <li>A domain with LDAPS support must still support LDAP (with
  signing/sealing support).  You can't somehow remove support for
  regular LDAP as that would break many clients, correct?</li>
  <li>If the first three assertions are correct, is there any real reason
  why a client application that already supports signing/sealing
  should want to support LDAPS?</li>
  </ol>
  
  <p>If the answer to the last question is 'No', but you still needed to provide support for LDAPS so the customer is happy, you could implement that support in one of two ways.  The first would require that the user explicitly choose LDAPS for AD where we configure other such settings.  The second approach would be to attempt an LDAPS binding first, and if that fails, fallback to an LDAP binding with the default options (Negotiate, Signing, Sealing).  The second approach seems simpler on the surface, but I think there a few problems with it.   So, here are a few more questions, specifically about this latter implementation.</p>
  
  <ol>
  <li>For domains that have both LDAPS and LDAP support, do we want to
  bind with SSL if we could have done the binding with
  signing/sealing?  Are we actually favoring the wrong binding
  approach just so we bind the way one customer is requesting?</li>
  <li>I have experimented with attempting an SSL bind when LDAPS is not
  configured to test the fallback logic.  With either the
  PrincipalContext class or the LdapConnection class's Bind method, it
  takes about 30 seconds before it times out and gives up.  I
  have not found a way to control this timeout.  If I were going to go
  this route, I'd like it to fail faster (say in 3 to 5 seconds), so I
  could fall back to a regular binding and get on with things.  Is
  there a way to set the actual bind operation timeout with either of
  these .NET classes?</li>
  </ol>
  
  <p>Thanks in advance to anyone who can provide answers to any or all of these questions.</p>