Thierry Lacoste wrote:
On 9 déc. 10, at 22:03, Howard Chu wrote:
Thierry Lacoste wrote:
Hello,
I'm experimenting with integrating Kerberos and OpenLDAP following roughly http://wiki.mandriva.com/en/Projects/OpenLDAP_DIT
I'm using CentOS and Buchan Milne's repository (http://staff.telkomsa.net/packages/rhel5/ ) both for OpenLDAP and Heimdal.
I've almost succeeded except for password integration. It seems that the smbk5pwd module provided by openldap2.4- servers-2.4.22-1.el5 in /usr/lib/openldap2.4/smbpwd.so is built without kerberos support.
With "smbk5pwd-enable krb5" I have the following error: /etc/openldap2.4/slapd.conf: line 154: smbk5pwd:<smbk5pwd-enable> module "smbk5pwd-enable" only allowed when compiled with -DDO_KRB5.
What is the easiest option to get a kerberos supporting smbk5pwd?
I have no comment on other people's builds.
Sorry for the noise. I found it here http://staff.telkomsa.net/packages/rhel5/openldap2.4-smbk5pwd-2.4.21-4.el5.i...
BTW I'd appreciate any recommandations about providing kerberos and LDAP authentication (with the same password) in a production setting. Should I use Heimdal or MIT kerberos ? If Heimdal, is it better to use OpenLDAP as a backend for Kerberos or let Kerberos use its native backend? If OpenLDAP as a backend, is it better to use {K5KEY} as the userPassword or let smbk5pwd synchronize everything?
Read the smbk5pwd README.
I'v read it. Your answer seems to imply that I should use Heimdal and then OpenLDAP as it's backend. Am I right?
It's more than just implied. The README says the code was written for Heimdal. If you want to use smbk5pwd at all, then you must use Heimdal.
Do you recommend using {K5KEY} as the userPassword?
If you want LDAP Simple Binds to use the same password as Kerberos, then yes. If not, then no.
There are security implications to using it; without strong protections on the LDAP sessions you're exposing the Kerberos password on the network and it ordinarily never should be exposed. (Also, just because you think you have strong protections in place, it's still less secure than keeping it completely off the wire. Particularly when somebody screws up (e.g. Debian) and their TLS software is doing something stupid like generating predictable sequences of "random" keys, etc.)