locked
Best 'AuthenticationType' for Active Directory RRS feed

  • Question

  • User43200643 posted

    Hi,

    I have recently started a project to convert authentication for an application from NDS to AD. The current system connects on the secure port (636 I belive) which you can do by using AuthenticationTypes.SecureSocketsLayer when binding. I've been looking at these forums a fair bit over the past couple of weeks, and I've noticed that all of the AD binding seems to use AuthenticationTypes.Secure (and so does the code I've written).

    The sys admins seem to think that we may need to use SSL for the queries, but I was wondering if anyone can tell me what the best authentication type to use for AD actually is (and why).

    Thanks

    - Steve

    Monday, July 17, 2006 3:11 AM

Answers

  • User1354132231 posted
    Well, there really is no 'best' per se.  The reason you see .Secure instead of .SecureSocketsLayer in many cases is because no one bothers to setup SSL with AD LDAP directories.  The whole point of SSL was to encrypt the traffic and protect any secrets in transit (like username and password mostly).  Active Directory does not need SSL to secure the channel.

    .Secure tells ADSI to use SSPI (SPNEGO) to negotiate authentication.  This will protect the username and password in transit by using either NTLM or Kerberos tickets instead of the plaintext credentials you see most LDAP directories use (and what SSL was introduced to protect) in what are called 'simple' binds.  With AD, you can then layer on both confidentiality (.Sealing) as well as non-repudiation/data integrity (.Signing).  With the 3 types together, it is generally considered more 'secure' than SSL (however, not necessarily for cryptographic reasons).  The signing in particular is what SSL cannot do by itself.

    There is some overhead for signing and encrypting the entire channel, so unless the data itself is very confidential, I generally just use .Secure to protect the credentials.

    If you have an SSL certificate installed with AD, it only really comes in handy in a couple situations: if you happen to want to use fast concurrent binding or are setting and changing passwords a lot.  However, if you are using ADAM with ADAM security principals (as compared to Windows users with pass-through authenticaiton) it is also the only way to secure the channel as 'simple' binds are the only type of binds allowed by ADAM (I am ignoring Digest here on purpose because ADSI does not currently support it).

    Make sense?  If you have an SSL cert installed, it might be handy.  However, you don't need it with AD at all.  It is a great idea for ADAM however.
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 17, 2006 10:26 AM

All replies

  • User1354132231 posted
    Well, there really is no 'best' per se.  The reason you see .Secure instead of .SecureSocketsLayer in many cases is because no one bothers to setup SSL with AD LDAP directories.  The whole point of SSL was to encrypt the traffic and protect any secrets in transit (like username and password mostly).  Active Directory does not need SSL to secure the channel.

    .Secure tells ADSI to use SSPI (SPNEGO) to negotiate authentication.  This will protect the username and password in transit by using either NTLM or Kerberos tickets instead of the plaintext credentials you see most LDAP directories use (and what SSL was introduced to protect) in what are called 'simple' binds.  With AD, you can then layer on both confidentiality (.Sealing) as well as non-repudiation/data integrity (.Signing).  With the 3 types together, it is generally considered more 'secure' than SSL (however, not necessarily for cryptographic reasons).  The signing in particular is what SSL cannot do by itself.

    There is some overhead for signing and encrypting the entire channel, so unless the data itself is very confidential, I generally just use .Secure to protect the credentials.

    If you have an SSL certificate installed with AD, it only really comes in handy in a couple situations: if you happen to want to use fast concurrent binding or are setting and changing passwords a lot.  However, if you are using ADAM with ADAM security principals (as compared to Windows users with pass-through authenticaiton) it is also the only way to secure the channel as 'simple' binds are the only type of binds allowed by ADAM (I am ignoring Digest here on purpose because ADSI does not currently support it).

    Make sense?  If you have an SSL cert installed, it might be handy.  However, you don't need it with AD at all.  It is a great idea for ADAM however.
    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 17, 2006 10:26 AM
  • User43200643 posted

    Yep makes sense, thanks mate.

    Monday, July 17, 2006 11:46 PM