[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: openldap and kerberos integration



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.
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.

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.

--
fct.unl.pt:~# cat .signature

Hugo Monteiro
Email	 : hugo.monteiro@fct.unl.pt
Telefone : +351 212948300 Ext.15307
Web      : http://hmonteiro.net

Divisão de Informática
Faculdade de Ciências e Tecnologia da
		   Universidade Nova de Lisboa
Quinta da Torre   2829-516 Caparica   Portugal
Telefone: +351 212948596   Fax: +351 212948548
www.fct.unl.pt                apoio@fct.unl.pt

fct.unl.pt:~# _