AD 2008 has the same LDAP features as AD 2003, so migrating either AD or
Windows server should not matter here.
LDAP is primarily a directory access protocol. Kerberos is an
authentication protocol. They do different things. LDAP has a primitive
authentication mechanism called "simple bind" that applications can use to
verify credentials if they can't handle other authentication protocols.
It gets tricky because LDAP also includes an extensible authentication
framework called SASL that allows alternate authentication protocols to be
added. AD supports GSS-API (Kerberos), GSS-SPNEGO (Windows negotiate
authentication which selects between Kerberos and NTLM), Digest and External
(for client cert auth). Thus, if the client understands any of those SASL
mechanisms, it can actually use that for the authentication. As such,
Kerberos may be used by an application during an LDAP bind operation if the
client understands this.
In fact, scripts that use GetObject("LDAP://....") actually use GSS-SPNEGO
authentication using the current user's credentials to authenticate to the
directory and will use Kerberos when possible.
The bottom line here is that nothing important has really changed here, so
apps that required LDAP before should still be able to use LDAP. It is
probably worth understanding why an app would need LDAP for auth, especially
if other options are available. Another thing to consider is that if an app
uses LDAP simple bind, the password is passed in plaintext on the network
and is not secure without SSL which is not deployed on domain controllers by
Microsoft recommends against using LDAP for authentication purposes, however
there are cases where it is the only practical approach and it is supported.
Interactive login to the workstation or authentication peformed for RPC and
such NEVER uses LDAP. They always use negotiate authentication which
attempts to use Kerberos whenever possible.
Designed by sketchbooks.co.kr / sketchbook5 board skin