On 25/02/13 15:17, Dan White wrote:

On 02/25/13 14:53 +0000, Tim Watts wrote:

...

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)

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} ?

Or maybe there is another way to enable global SASL password passthroughs?

Hi Dan,

What is the reason for keeping SASL pass-through after a password change? Why not allow the exop operation to proceed normally, which should write the correct password hash into your userPassword attribute (by way of your olcPasswordHash config)?

Do you expect to make kerberos password changes outside of an ldap exop operation?

Possibly - and for password handling I prefer kerberos to remain authoritative and running on it's own backend. I've had good milage with MIT kerberos before (10 years of happiness) and I feel I understand it.

For my users, LDAP will be a read only directory of basic posix account data. We're not needing anything very clever.

I *could* tell them to use kpasswd (and switch PAM so passwd goes direct to kerberos) when the switch is made, but it would make the transition a little easier if LDAP EXOPS could be routed through. Well, they can - it's just that the password change breaks the passthrough directive in userPassword.

Cheers,

Tim

...

======

I'm in a transition phase. I need to import the slapcat output from the old LDAP server to my new one. At this point, all authentication should be done with the existing userPassword hash. Password changes should update this hash and create/modify principles on the kerberos server.

3 months later, I want to switch the auth mechanism on all accounts to passthrough to kerberos, at which point, ldappasswd should still work but via smbkrb5pwd updating kerberos.

Perhaps a better approach would be to place your kerberos store within LDAP, and handle password changes with smbk5pwd.

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