https://bugzilla.redhat.com/show_bug.cgi?id=469261
Resolves: bug 469261
Bug Description: Support server-to-server SASL
Reviewed by: ???
Files: see diff
Branch: HEAD
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).
Platforms tested: Fedora 9, Fedora 8
Flag Day: yes
Doc impact: oh yes
https://bugzilla.redhat.com/attachment.cgi?id=322014&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=322015
--
Fedora-directory-devel mailing list
Fedora-directory-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-directory-devel
