Re: slapd, SASL passthrough and changing passwords smashing userPassword

[Tim Watts <tw@dionic.net>]

Hi Howard,

Thanks for taking the time to reply to my stupid questions ;-o

On 25/02/13 15:37, Howard Chu wrote:
> Tim Watts wrote:
> > Hi folks,
> >
> > I hope this is a quick and easy one :)
> >
> > I have slapd 2.4.23 working with passthrough to MIT kerberos via
> > saslauthd. I use smbkrb5pwd (a hack on smbk5pwd) to pass password
> > changes through to kerberos (creating or modifying the target principle
> > as required)
>
> I haven't seen smbkrb5pwd but, as the author of smbk5pwd,

Ah ha :)

> it sounds like
> the hack is inadequate.

It's the one forked from smbk5pwd by opinsys.fi, tweaked slightly by me 
to add a default kerberos policy to principle creation requests.


> smbk5pwd provides the {K5KEY} password hash
> mechanism, so you can use the Kerberos password directly, and you don't
> need {SASL} at all.

Does smbk5pwd now support MIT? I bypassed it because I thought it only 
supported Heimdall.

> > To enable a particular user to bind to slapd with their kerberos
> > password, I'm setting:
> >
> > userPassword: {SASL}myuid@MY.KERBEROS.REALM.EXAMPLE.COM
> >
> > This works *very nicely*. Except one thing...
> >
> > Using passwd via pam_ldap or ldappasswd directly smashes userPassword:
> > and replaces the value with the password hash. Both machanisms are doing
> > EXOP password changes.
> >
> >
> > Is there any way to stop this happening when the mechanism in
> > userPassword is {SASL} ?

That causes a spurious error at the ldapasswd client end:
================
Result: Other (e.g., implementation specific) error (80)
Additional info: scheme provided no hash function
================

However, the kerberos principle does get updated - and userPassword is 
left alone.

Is that error message expected?

Cheers,

Tim



--
Tim Watts
Personal Blog: 
http://www.dionic.net/tim/

"It would be better to live under robber barons than under omnipotent
moral busybodies."