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.