Howard Chu a écrit :
Guillaume Rousse wrote:
> Hello list.
>
> Reading
http://www.openldap.org/doc/admin24/security.html#SASL password
> storage scheme, I understand autentication can be delegated to an
> external mechanisme. Such as, for instance, a kerberos server. In this
> case, it is advised to prevent changing passwords in the directory.
That part of the doc appears to be wrong. slapd will call SASL's setpass
function to change a SASL password, so there's no reason to prevent
changing passwords via LDAP.
I guess it is just a phrasing issue, and the doc means
'take care users
don't inadvertly rewrite their password attribute with a true password
instead of keeping this pointer'.
Also, the {KERBEROS} delegation scheme has been removed, only SASL
delegation is supported.
> What happens if the autentication provider is an heimdal server, using
> OpenLDAP as its backend, and smbkrb5 overlay to keep ldap, samba and
> kerberos password synced ? Does pass-through still work ?
When using the smbk5pwd overlay in such a configuration, there is no
pass-through. The Kerberos credentials reside in slapd and slapd
validates the authentication directly.
Only if you use the {SMBKRB5} redirection,
or even if you use a {SASL} one ?
[..]
> I know smbkrb5 has a special {smbkrb5} password storage scheme
for
> redirecting autentication against kerberos password internally, not
> relying on a external SASL process. But it's only usable if smbkrb5
> overlay is available (some of our slaves servers are centos-based, and
> don't have this overlay, but still need to autenticate users).
You can always obtain the source tree that was used to build your distro
and compile the overlay yourself.
Out of my control, unfortunatly (otherwise, those
servers wouldn't use
centOs at all :P). Anyway, it doesn't really hurt, it will just make
those servers from a specific department unable to autenticate users
from other department, not their own ones.
> And the
> trick of setting password-hash directive in slapd.conf to {smbkrb5} to
> prevent overwriting of userPassword attribute on PasswordChange
> operation with a normal value has the drawback than even pure ldap
> administrative accounts (syncrepl, for instance) get redirected to
> kerberos password for autentication, whereas only our users have
> principals currently.
The password_hash setting in slapd.conf is only a default. You can
explicitly set any hash type on any account.
Yes, if you use an normal attribute
change operation. I don't think
there is a way to use an extended password change operation, and bypass
this value. Anyway, it doesn't matter very much either, only sysadmins
are suposed to take care of administrative accounts.
Let's to summarize what's I'm understanding so far.
First, you have to use either password_hash or ACLs to prevent users to
rewrite password attribute with a standard password. Using password_hash
is only possible with smbkrb5 overlay, because it uses a fixed {SMBKRB5}
pattern, whereas {SASL} storage scheme change with any user
Second, {SMBKRB5} is an optimisation only possible with smbkrb5 overlay,
whereas {SASL} is more generical, but also more expensives, as external
calls are needed.
Am I correct ?
--
Guillaume Rousse
Moyens Informatiques - INRIA Futurs
Tel: 01 69 35 69 62