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?
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?
Best regards, Thierry
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.
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.
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? Do you recommend using {K5KEY} as the userPassword?
Best regards, Thierry
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.)
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.
Sorry my question was not very clear. I wan't LDAP Simple Binds and Kerberos with the same password. I find smbk5pwd and OpenLDAP as a Heimdal backend very appealing but maybe there are good reasons to use another Kerberos implementation and/or store passwords in the Kerberos native backend (adding e.g. SASL in the mix to make LDAP Simple Binds use pass-through authentication), obviously ruling out smbk5pwd.
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.
AFAICS with smbk5pwd I have two ways to have LDAP Simple Binds and Kerberos with the same password. 1) force use of ldappasswd to make smbk5pwd synchronize all passwords; 2) assign {K5KEY} to the userPassword and use kpasswd to change a password.
If I understood correctly, the second method makes the passwords identical by construction while the first allow passwords to desynchronize if changed without ldappasswd.
Best regards, Thierry
Thierry Lacoste wrote:
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.
Sorry my question was not very clear. I wan't LDAP Simple Binds and Kerberos with the same password. I find smbk5pwd and OpenLDAP as a Heimdal backend very appealing but maybe there are good reasons to use another Kerberos implementation and/or store passwords in the Kerberos native backend (adding e.g. SASL in the mix to make LDAP Simple Binds use pass-through authentication), obviously ruling out smbk5pwd.
If all of your clients can use SASL Binds, then that is the best choice, and you can ignore smbk5pwd.
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.
AFAICS with smbk5pwd I have two ways to have LDAP Simple Binds and Kerberos with the same password.
- force use of ldappasswd to make smbk5pwd synchronize all passwords;
- assign {K5KEY} to the userPassword and use kpasswd to change a
password.
If I understood correctly, the second method makes the passwords identical by construction while the first allow passwords to desynchronize if changed without ldappasswd.
The point of smbk5pwd is to fully synchronize, that means it works in both directions. When configured correctly and {K5KEY} is used, it doesn't matter whether kpasswd or ldappasswd is used, everything stays in sync.
There is no either-or as you outline with your two choices above. You must use {K5KEY} if you want any of the synchronization to work.
On 10 déc. 10, at 20:57, Howard Chu wrote:
Thierry Lacoste wrote:
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.
Sorry my question was not very clear. I wan't LDAP Simple Binds and Kerberos with the same password. I find smbk5pwd and OpenLDAP as a Heimdal backend very appealing but maybe there are good reasons to use another Kerberos implementation and/or store passwords in the Kerberos native backend (adding e.g. SASL in the mix to make LDAP Simple Binds use pass-through authentication), obviously ruling out smbk5pwd.
If all of your clients can use SASL Binds, then that is the best choice, and you can ignore smbk5pwd.
Unfortunately I have no control over the clients so I need something transparent for them. What I had in mind was setting {SASL}login@MY.REALM in the userPassword. The realm would be on a KDC hosted on the same box as the LDAP server to minimize network traffic. It seems much less elegant than the Heimdal/OpenLDAP integration with smbk5pwd but (maybe) has some benefits: I can use another KDC (e.g. MIT) and use the native kerberos backend. My first tests are OK but as of now I have no idea about replication.
Any recommandation for the best way to have LDAP Simple Binds and Kerberos with the same password are much appreciated.
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.
AFAICS with smbk5pwd I have two ways to have LDAP Simple Binds and Kerberos with the same password.
- force use of ldappasswd to make smbk5pwd synchronize all
passwords; 2) assign {K5KEY} to the userPassword and use kpasswd to change a password.
If I understood correctly, the second method makes the passwords identical by construction while the first allow passwords to desynchronize if changed without ldappasswd.
The point of smbk5pwd is to fully synchronize, that means it works in both directions. When configured correctly and {K5KEY} is used, it doesn't matter whether kpasswd or ldappasswd is used, everything stays in sync.
I noticed some differences. In particular ldappasswd updates sambaLMPassword while kpasswd does not.
With ldappasswd, here is an excerpt of my auditlog:
replace: userPassword replace: sambaPwdLastSet replace: sambaLMPassword replace: sambaNTPassword replace: krb5KeyVersionNumber replace: krb5Key
With kpasswd, I have :
replace: krb5KeyVersionNumber replace: krb5PasswordEnd replace: sambaPwdMustChange delete: krb5Key add: krb5Key replace: sambaNTPassword
There is no either-or as you outline with your two choices above. You must use {K5KEY} if you want any of the synchronization to work.
Here I'm confused. I tested smbk5pwd with SSHA password hashes. ldappasswd correctly updates passwords and kerberos keys such that LDAP simple binds and kerberos authentication both work with the same password.
Best Regards, Thierry
Thierry Lacoste wrote:
On 10 déc. 10, at 20:57, Howard Chu wrote:
Thierry Lacoste wrote:
> > 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.
Sorry my question was not very clear. I wan't LDAP Simple Binds and Kerberos with the same password. I find smbk5pwd and OpenLDAP as a Heimdal backend very appealing but maybe there are good reasons to use another Kerberos implementation and/or store passwords in the Kerberos native backend (adding e.g. SASL in the mix to make LDAP Simple Binds use pass-through authentication), obviously ruling out smbk5pwd.
If all of your clients can use SASL Binds, then that is the best choice, and you can ignore smbk5pwd.
Unfortunately I have no control over the clients so I need something transparent for them. What I had in mind was setting {SASL}login@MY.REALM in the userPassword. The realm would be on a KDC hosted on the same box as the LDAP server to minimize network traffic. It seems much less elegant than the Heimdal/OpenLDAP integration with smbk5pwd but (maybe) has some benefits: I can use another KDC (e.g. MIT) and use the native kerberos backend. My first tests are OK but as of now I have no idea about replication.
Any recommandation for the best way to have LDAP Simple Binds and Kerberos with the same password are much appreciated.
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.
AFAICS with smbk5pwd I have two ways to have LDAP Simple Binds and Kerberos with the same password.
- force use of ldappasswd to make smbk5pwd synchronize all
passwords; 2) assign {K5KEY} to the userPassword and use kpasswd to change a password.
If I understood correctly, the second method makes the passwords identical by construction while the first allow passwords to desynchronize if changed without ldappasswd.
The point of smbk5pwd is to fully synchronize, that means it works in both directions. When configured correctly and {K5KEY} is used, it doesn't matter whether kpasswd or ldappasswd is used, everything stays in sync.
I noticed some differences. In particular ldappasswd updates sambaLMPassword while kpasswd does not.
I suppose we can delete sambaLMPassword support by now, certainly no one should be using it any more.
With ldappasswd, here is an excerpt of my auditlog:
replace: userPassword replace: sambaPwdLastSet replace: sambaLMPassword replace: sambaNTPassword replace: krb5KeyVersionNumber replace: krb5Key
With kpasswd, I have :
replace: krb5KeyVersionNumber replace: krb5PasswordEnd replace: sambaPwdMustChange delete: krb5Key add: krb5Key replace: sambaNTPassword
There is no either-or as you outline with your two choices above. You must use {K5KEY} if you want any of the synchronization to work.
Here I'm confused. I tested smbk5pwd with SSHA password hashes. ldappasswd correctly updates passwords and kerberos keys such that LDAP simple binds and kerberos authentication both work with the same password.
In that case there's both an SSHA hashed copy and a KDC hashed copy of the password. With {K5KEY} there is only the KDC hash.
On 12/15/2010 07:19 PM, Howard Chu wrote:
Thierry Lacoste wrote:
On 10 déc. 10, at 20:57, Howard Chu wrote:
Thierry Lacoste wrote:
>> >> 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.
Sorry my question was not very clear. I wan't LDAP Simple Binds and Kerberos with the same password. I find smbk5pwd and OpenLDAP as a Heimdal backend very appealing but maybe there are good reasons to use another Kerberos implementation and/or store passwords in the Kerberos native backend (adding e.g. SASL in the mix to make LDAP Simple Binds use pass-through authentication), obviously ruling out smbk5pwd.
If all of your clients can use SASL Binds, then that is the best choice, and you can ignore smbk5pwd.
Unfortunately I have no control over the clients so I need something transparent for them. What I had in mind was setting {SASL}login@MY.REALM in the userPassword. The realm would be on a KDC hosted on the same box as the LDAP server to minimize network traffic. It seems much less elegant than the Heimdal/OpenLDAP integration with smbk5pwd but (maybe) has some benefits: I can use another KDC (e.g. MIT) and use the native kerberos backend. My first tests are OK but as of now I have no idea about replication.
Any recommandation for the best way to have LDAP Simple Binds and Kerberos with the same password are much appreciated.
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.
AFAICS with smbk5pwd I have two ways to have LDAP Simple Binds and Kerberos with the same password.
- force use of ldappasswd to make smbk5pwd synchronize all
passwords; 2) assign {K5KEY} to the userPassword and use kpasswd to change a password.
If I understood correctly, the second method makes the passwords identical by construction while the first allow passwords to desynchronize if changed without ldappasswd.
The point of smbk5pwd is to fully synchronize, that means it works in both directions. When configured correctly and {K5KEY} is used, it doesn't matter whether kpasswd or ldappasswd is used, everything stays in sync.
I noticed some differences. In particular ldappasswd updates sambaLMPassword while kpasswd does not.
I suppose we can delete sambaLMPassword support by now, certainly no one should be using it any more.
I'm sorry but did i understand correctly that sambaLMPassword will no longer be updated while using the smbk5pwd overlay? Also, i would like to know why do you state that "no one should be using it any more". Besides Samba itself, it can (as is) used by freeradius while using PEAP and MsCHAPv2 for wireless clients authentication.
With ldappasswd, here is an excerpt of my auditlog:
replace: userPassword replace: sambaPwdLastSet replace: sambaLMPassword replace: sambaNTPassword replace: krb5KeyVersionNumber replace: krb5Key
With kpasswd, I have :
replace: krb5KeyVersionNumber replace: krb5PasswordEnd replace: sambaPwdMustChange delete: krb5Key add: krb5Key replace: sambaNTPassword
There is no either-or as you outline with your two choices above. You must use {K5KEY} if you want any of the synchronization to work.
Here I'm confused. I tested smbk5pwd with SSHA password hashes. ldappasswd correctly updates passwords and kerberos keys such that LDAP simple binds and kerberos authentication both work with the same password.
In that case there's both an SSHA hashed copy and a KDC hashed copy of the password. With {K5KEY} there is only the KDC hash.
Regards,
Hugo Monteiro.
Hugo Monteiro wrote:
On 12/15/2010 07:19 PM, Howard Chu wrote:
Thierry Lacoste wrote:
I noticed some differences. In particular ldappasswd updates sambaLMPassword while kpasswd does not.
I suppose we can delete sambaLMPassword support by now, certainly no one should be using it any more.
I'm sorry but did i understand correctly that sambaLMPassword will no longer be updated while using the smbk5pwd overlay? Also, i would like to know why do you state that "no one should be using it any more". Besides Samba itself, it can (as is) used by freeradius while using PEAP and MsCHAPv2 for wireless clients authentication.
That's interesting, especially since the KDC itself doesn't maintain sambaLMPassword. The LANMAN hash mechanism has been obsolete for years, it is intrinsically weak and is not a good security mechanism.
I think you're mistaken, anyway; according to RFC2759 which defines MSCHAPv2, it uses an NT hash, not a LANMAN hash. The LANMAN hash was used for MSCHAPv1 which is also obsolete.
On 12/15/2010 11:47 PM, Howard Chu wrote:
Hugo Monteiro wrote:
On 12/15/2010 07:19 PM, Howard Chu wrote:
Thierry Lacoste wrote:
I noticed some differences. In particular ldappasswd updates sambaLMPassword while kpasswd does not.
I suppose we can delete sambaLMPassword support by now, certainly no one should be using it any more.
I'm sorry but did i understand correctly that sambaLMPassword will no longer be updated while using the smbk5pwd overlay? Also, i would like to know why do you state that "no one should be using it any more". Besides Samba itself, it can (as is) used by freeradius while using PEAP and MsCHAPv2 for wireless clients authentication.
That's interesting, especially since the KDC itself doesn't maintain sambaLMPassword. The LANMAN hash mechanism has been obsolete for years, it is intrinsically weak and is not a good security mechanism.
I think you're mistaken, anyway; according to RFC2759 which defines MSCHAPv2, it uses an NT hash, not a LANMAN hash. The LANMAN hash was used for MSCHAPv1 which is also obsolete.
Hello Howard,
Thanks for clarifying that for me, i was under the impression that MSCHAPv2 used the LANMAN password . I should have consulted the RFC first.
Best Regards,
Hugo Monteiro.
On Thursday, 9 December 2010 21:42:46 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.
In Mandriva, the Kerberos implementation in the "main" repository is MIT Kerberos, while Heimdal is in contrib. As OpenLDAP is in main, it cannot depend on Heimdal, so by default we build smbk5pwd as smbpwd.so without Heimdal support, while we have a separate openldap-smbk5pwd package (providing smbk5pwd.so) in contrib which is built with Heimdal support.
However, I have had problems with this package on CentOS with my Heimdal packages (slapd would hang or crash on a password change on a Heimdal account with the module enabled), and due to problems in conjunction with ppolicy (krb5PasswordEnd not being updated), I don't use it myself on my CentOS deployment, but rather use the "use Samba passwords" feature.
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?
Untested (besides "it installs, it loads, slapd still runs), but built from the Mandriva openldap-smbk5pwd src.rpm:
http://staff.telkomsa.net/packages/rhel5/openldap2.4- smbk5pwd-2.4.21-4.el5.i386.rpm
1)Install ('rpm -Uvh http://staff.telkomsa.net/packages/rhel5/openldap2.4- smbk5pwd-2.4.21-4.el5.i386.rpm' or similar) 2)Change 'moduleload smbpwd.so' to 'moduleload smbk5pwd.so' 3)Restart slapd
Please let me know if this package works for you. If not, it might be time to update the heimdal packages (which I didn't do earlier due to regressions in the "use samba passwords" feature which I recently fixed in the Mandriva packages).
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 ?
IMHO, Heimdal provides some advantages over MIT.
If Heimdal, is it better to use OpenLDAP as a backend for Kerberos or let Kerberos use its native backend?
There are some minor complications using hdb_ldap, but I feel the benefits outweigh them.
If OpenLDAP as a backend, is it better to use {K5KEY} as the userPassword or let smbk5pwd synchronize everything?
Depends on if you have any non-GSSAPI or simple-bind-to-LDAP-server-with- master-key authentication (e.g. MSCHAPv2).
Regards, Buchan
openldap-technical@openldap.org