Resolves: bug 469261

Bug Description: Support server-to-server SASL - part 1
Reviewed by: nkinder, nhosoi, ssorce (Thanks!)
Fix Description: I've created two new functions to handle the client side of LDAP in the server - slapi_ldap_init_ext and slapi_ldap_bind.  These two functions are designed to work with any connection type (ldap, ldaps, ldap+starttls, and eventually ldapi) and bind type (plain, sasl, client cert).  The secure flag has been extended to use a value of 2 to mean use startTLS.  One tricky part is that there is no place to store the startTLS flag in init to pass to bind, so we store that in the clientcontrols field which is currently unused.  We do that because the semantics of ldap_init are not to do any network traffic, but defer that until the bind operation (or whatever the first actual operation is e.g. start_tls).  I plan to replace all of the places in the code that do ldap init and bind with these functions.
I started with replication.  I extended the transport to add tls for startTLS and the bind method to add sasl/gssapi and sasl/digest-md5.  I removed a lot of code from repl5_connection that is now done with just slapi_ldap_init_ext and slapi_ldap_bind.  One tricky part of the replication code is that it polls the connection for write available, using some ldap sdk internals.  I had to fix that code to work within the public ldap api since nspr and sasl muck with the internals in different incompatible ways.
Finally, there is a lot of new kerberos code in the server.  The way the server does sasl/gssapi auth with its keytab is similar to the way it does client cert auth with its ssl server cert.  One big difference is that the server cannot pass the kerberos identity and credentials through the ldap/sasl/gssapi layers directly.  Instead, we have to create a memory credentials cache and set the environment variable to point to it.  This allows the sasl/gssapi layer to grab the credentials for use with kerberos.  The way the code is written, it should also allow "external" kerberos auth e.g. if someone really wants to do some script which does a periodic kinit to refresh the file based cache, that should also work.
I added some kerberos configure options.  configure tries to first use krb5-config to get the compiler and linker information.  If that fails, it just looks for some standard system libraries.  Note that Solaris does not allow direct use of the kerberos api until Solaris 11, so most likely Solaris builds will have to use --without-kerberos (--with-kerberos is on by default).
Fixed a bug in kerberos.m4 found by nkinder.
ssorce has pointed out a few problems with my kerberos usage that will be addressed in the next patch.
Changed the log level in ldap_sasl_get_val - pointed out by nkinder
Platforms tested: Fedora 9, Fedora 8
Flag Day: yes
Doc impact: oh yes

1 files changed, 3 insertions, 2 deletions

diff --git a/Makefile.am b/Makefile.am
index 57e54313..9bea4bfa 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -47,6 +47,7 @@ SVRCORE_LINK = @svrcore_lib@ -lsvrcore
 ICU_LINK = @icu_lib@ -licui18n -licuuc -licudata
 NETSNMP_LINK = @netsnmp_lib@ @netsnmp_link@
 PAM_LINK = -lpam
+KERBEROS_LINK = $(kerberos_lib)
 
 LIBSOCKET=@LIBSOCKET@
 LIBNSL=@LIBNSL@
@@ -534,12 +535,12 @@ libslapd_la_SOURCES = ldap/servers/slapd/add.c \
 	ldap/servers/slapd/vattr.c \
 	$(libavl_a_SOURCES)
 
+libslapd_la_CPPFLAGS = $(PLUGIN_CPPFLAGS) @sasl_inc@ @db_inc@ @svrcore_inc@ @kerberos_inc@
 if SOLARIS
 libslapd_la_SOURCES += ldap/servers/slapd/slapi_counter_sunos_sparcv9.S
 endif
 
-libslapd_la_CPPFLAGS = $(PLUGIN_CPPFLAGS) @db_inc@ @svrcore_inc@
-libslapd_la_LIBADD = $(LDAPSDK_LINK) $(SASL_LINK) $(SVRCORE_LINK) $(NSS_LINK) $(NSPR_LINK)
+libslapd_la_LIBADD = $(LDAPSDK_LINK) $(SASL_LINK) $(SVRCORE_LINK) $(NSS_LINK) $(NSPR_LINK) $(KERBEROS_LINK)
 
 
 #////////////////////////////////////////////////////////////////