Hi :)
My LDAP skillz are (very) slowly coming along - thanks to good folk here, I think I have figured out ACLs and I have managed to get rwm/relay to emulate an old tree structure (well enough) whilst being able to design a better structure for our department.
My next question is just a request for a pointer.
My understanding of LDAP authentication is very limited. What I would like to do is a 2 phase transition to kerberos (which I do understand):
1) Rig OpenLDAP so all password changes get sent to the kerberos server but do not use it for authentication. In the meantime we will continue authenticate with the SSHA1 hashes in the user's LDAP entry.
2) After some time (months) when everyone has eventually done a password change, the Kerberos server will be well enough in sync. Now I would like to switch OpenLDAP to using kerberos on the backend (ie for binds etc) and I will purge the SSHA1 hashes.
================== I most interested in some pointers for stage 1) is someone could be kind enough to help me out - is there a particular name for this mechanism, or a module that handles this kind of stuff? ==================
2) I think I can probably google for myslef (keywords SASL and/or GSSAPI and/or LDAP+Kerberos. I've had a skim but did not notice an obvious way to handle 1) without 2)
I apologise if it's a dumb question :-o
Many thanks in advance :)
Cheers
Tim
Hey,
On 05/28/2012 10:25 PM, Tim Watts wrote:
- Rig OpenLDAP so all password changes get sent to the kerberos
server but do not use it for authentication. In the meantime we will continue authenticate with the SSHA1 hashes in the user's LDAP entry.
The usual way to do this on most *nix systems is to actually 'rig' the PAM. In debian for example you setup your /etc/pam.d/common-password to contain something like:
password sufficient pam_krb5.so ignore_root password required pam_unix.so nullok obscure min=4 max=8 sha256 use_first_pass
this sets up most of your tools to use the right modules when changing the password, e.g. 'passwd'.
I do not know if you could do something like 'referring' a password change request from the OpenLDAP server to the kerberos server but since this would be an invitation von mitm attacks I doubt it.
- After some time (months) when everyone has eventually done a
password change, the Kerberos server will be well enough in sync. Now I would like to switch OpenLDAP to using kerberos on the backend (ie for binds etc) and I will purge the SSHA1 hashes.
We successfully auth against kerberos with our LDAP, you might be interested in reading the SASL section of man slapd-config. Make sure you ahve compiled your OpenLDAP with SASL support and have successfully kerberized your server.
happy configuration party :)
On 29/05/12 00:00, Bernd May wrote:
Hey,
On 05/28/2012 10:25 PM, Tim Watts wrote:
- Rig OpenLDAP so all password changes get sent to the kerberos
server but do not use it for authentication. In the meantime we will continue authenticate with the SSHA1 hashes in the user's LDAP entry.
The usual way to do this on most *nix systems is to actually 'rig' the PAM. In debian for example you setup your /etc/pam.d/common-password to contain something like:
password sufficient pam_krb5.so ignore_root password required pam_unix.so nullok obscure min=4 max=8 sha256 use_first_pass
this sets up most of your tools to use the right modules when changing the password, e.g. 'passwd'.
Hi Brend,
Thanks for the reply.
Unfortunately there's a problem with that - the user would need their old kerberos password before they could initiate a change and in this case, their old kerberos password is unknown because Kerberos has only just existed.
I do not know if you could do something like 'referring' a password change request from the OpenLDAP server to the kerberos server but since this would be an invitation von mitm attacks I doubt it.
It will be a bit of a pity in this case if it's not possible :(
When using password hashes in the user entry, does slapd receive the plaintext password or does the client generate the hash?
If slapd does not have a mechanism specifically for forcing (priming) kerberos servers, does it have a password change hook?
Otherwise, I am going to have to provide a special password change service somewhere - probably web based or something.
Or crack all the LANMan hashes I found in the original LDAP server! (Just joking).
- After some time (months) when everyone has eventually done a
password change, the Kerberos server will be well enough in sync. Now I would like to switch OpenLDAP to using kerberos on the backend (ie for binds etc) and I will purge the SSHA1 hashes.
We successfully auth against kerberos with our LDAP, you might be interested in reading the SASL section of man slapd-config. Make sure you ahve compiled your OpenLDAP with SASL support and have successfully kerberized your server.
Thanks! That sounds good :)
happy configuration party :)
All the best,
Tim
On 29/05/12 07:46, Tim Watts wrote:
On 29/05/12 00:00, Bernd May wrote:
Hey,
On 05/28/2012 10:25 PM, Tim Watts wrote:
- Rig OpenLDAP so all password changes get sent to the kerberos
server but do not use it for authentication. In the meantime we will continue authenticate with the SSHA1 hashes in the user's LDAP entry.
The usual way to do this on most *nix systems is to actually 'rig' the PAM. In debian for example you setup your /etc/pam.d/common-password to contain something like:
password sufficient pam_krb5.so ignore_root password required pam_unix.so nullok obscure min=4 max=8 sha256 use_first_pass
this sets up most of your tools to use the right modules when changing the password, e.g. 'passwd'.
Hi Brend,
Sorry - Bernd (typo),
Thanks for the reply.
Unfortunately there's a problem with that - the user would need their old kerberos password before they could initiate a change and in this case, their old kerberos password is unknown because Kerberos has only just existed.
I do not know if you could do something like 'referring' a password change request from the OpenLDAP server to the kerberos server but since this would be an invitation von mitm attacks I doubt it.
It will be a bit of a pity in this case if it's not possible :(
When using password hashes in the user entry, does slapd receive the plaintext password or does the client generate the hash?
Sorry also - that was ambiguous. Add "when changing a password" to the above sentence -
<coffee not yet worked>
On 29.05.2012 08:46, Tim Watts wrote:
On 29/05/12 00:00, Bernd May wrote:
Hey,
On 05/28/2012 10:25 PM, Tim Watts wrote:
- Rig OpenLDAP so all password changes get sent to the kerberos
server but do not use it for authentication. In the meantime we will continue authenticate with the SSHA1 hashes in the user's LDAP entry.
The usual way to do this on most *nix systems is to actually 'rig' the PAM. In debian for example you setup your /etc/pam.d/common-password to contain something like:
password sufficient pam_krb5.so ignore_root password required pam_unix.so nullok obscure min=4 max=8 sha256 use_first_pass
this sets up most of your tools to use the right modules when changing the password, e.g. 'passwd'.
Hi Brend,
Thanks for the reply.
Unfortunately there's a problem with that - the user would need their old kerberos password before they could initiate a change and in this case, their old kerberos password is unknown because Kerberos has only just existed.
I do not know if you could do something like 'referring' a password change request from the OpenLDAP server to the kerberos server but since this would be an invitation von mitm attacks I doubt it.
It will be a bit of a pity in this case if it's not possible :(
When using password hashes in the user entry, does slapd receive the plaintext password or does the client generate the hash?
If slapd does not have a mechanism specifically for forcing (priming) kerberos servers, does it have a password change hook?
Otherwise, I am going to have to provide a special password change service somewhere - probably web based or something.
Or crack all the LANMan hashes I found in the original LDAP server! (Just joking).
Hi,
what Kerberos implementation are you using? If it's Heimdal and if it uses your OpenLDAP server as its storage backend, you can use the smbk5pwd overlay to set the Kerberos password along with a regular password change.
If your distro doesn't ship it with OpenLDAP or as a seperate package, you can build it from source. It's in the tarball under
contrib/slapd-modules/smbk5pwd/
Regards, Christian Manal
On 29/05/12 08:18, Christian Manal wrote:
Hi,
what Kerberos implementation are you using? If it's Heimdal and if it uses your OpenLDAP server as its storage backend, you can use the smbk5pwd overlay to set the Kerberos password along with a regular password change.
If your distro doesn't ship it with OpenLDAP or as a seperate package, you can build it from source. It's in the tarball under
contrib/slapd-modules/smbk5pwd/
Hi Christian,
I'm going to use MIT kerberos as that is what I am used to and I trust it and my abilities to fix it :)
But what you've said about smbk5pwd is interesting.
So Overlays are the plug-ins that can hook into parts of the process, including a password change? That is very useful knowledge - I can have a hunt for some others if smbk5pwd does not support MIT password changes - and I am aware that beyond ticket granting the wire protocols do differ.
If I'm desperate enough, I feel reasonably confident I could copy and modify that overlay - even if it is just to fork/exec to kadmind.
Many thanks for your time - very useful stuff!
All the best,
Tim
On 29/05/12 10:27, Tim Watts wrote:
On 29/05/12 08:18, Christian Manal wrote:
Hi,
what Kerberos implementation are you using? If it's Heimdal and if it uses your OpenLDAP server as its storage backend, you can use the smbk5pwd overlay to set the Kerberos password along with a regular password change.
If your distro doesn't ship it with OpenLDAP or as a seperate package, you can build it from source. It's in the tarball under
contrib/slapd-modules/smbk5pwd/
Hi Christian,
I'm going to use MIT kerberos as that is what I am used to and I trust it and my abilities to fix it :)
But what you've said about smbk5pwd is interesting.
So Overlays are the plug-ins that can hook into parts of the process, including a password change? That is very useful knowledge - I can have a hunt for some others if smbk5pwd does not support MIT password changes
- and I am aware that beyond ticket granting the wire protocols do differ.
If I'm desperate enough, I feel reasonably confident I could copy and modify that overlay - even if it is just to fork/exec to kadmind.
Many thanks for your time - very useful stuff!
All the best,
Tim
Ah-ha!
http://www.opinsys.fi/en/smbkrb5pwd-password-syncing-for-openldap-mit-kerber...
(Line wrap warning) - some nice person has already done the job for MIT Kerberos :->>>
On the face of it - that looks absolutely perfect!
Cheers
Tim
Tim Watts wrote:
http://www.opinsys.fi/en/smbkrb5pwd-password-syncing-for-openldap-mit-kerber... (Line wrap warning) - some nice person has already done the job for MIT Kerberos :->>>
The system described above is a bit fragile. Because if one of the systems fail the password might only be changed in LDAP or Kerberos.
On the face of it - that looks absolutely perfect!
Hmm...
A better approach is taken in the FreeIPA project: There's a SLAPI plugin for 389 DS which supports MIT Kerberos. A C programmer might be able to adapt this as an OpenLDAP overlay (similar to OpenLDAP's slapo-smbk5pwd).
Ciao, Michael.
On 29/5/2012 7:42 μμ, Michael Ströder wrote:
There's a SLAPI plugin for 389 DS which supports MIT Kerberos. A C programmer might be able to adapt this as an OpenLDAP overlay (similar to OpenLDAP's slapo-smbk5pwd).
Sorry, couldn't one use the SLAPI plugin as is in OpenLDAP, since SLAPI support is available (SLAPI plugins are supposed to be able to work without modifications on all LDAP servers)?
(For example, Symas and LTB packages are SLAPI-enabled; I had tested such a SLAPI plugin and it worked fine.)
Nick
Nick Milas wrote:
On 29/5/2012 7:42 μμ, Michael Ströder wrote:
There's a SLAPI plugin for 389 DS which supports MIT Kerberos. A C programmer might be able to adapt this as an OpenLDAP overlay (similar to OpenLDAP's slapo-smbk5pwd).
Sorry, couldn't one use the SLAPI plugin as is in OpenLDAP, since SLAPI support is available (SLAPI plugins are supposed to be able to work without modifications on all LDAP servers)?
"supposed to" and "actual" tend to be quite different, since the inventors of SLAPI diverged from each other (Sun/Netscape/RedHat...), and OpenLDAP's implementation is rather sparse, and only fleshed out on an as-needed basis.
(For example, Symas and LTB packages are SLAPI-enabled; I had tested such a SLAPI plugin and it worked fine.)
It would be better to simply extend slapo-smbk5pwd with MIT support.
On 29/05/12 17:42, Michael Ströder wrote:
Tim Watts wrote:
http://www.opinsys.fi/en/smbkrb5pwd-password-syncing-for-openldap-mit-kerber... (Line wrap warning) - some nice person has already done the job for MIT Kerberos :->>>
The system described above is a bit fragile. Because if one of the systems fail the password might only be changed in LDAP or Kerberos.
True.
In this case, the correct scenario for my environment is to fail the password change completely if the backends are not all contactable.
One of the points of using kerberos is not to have cleartext (or decryptable) passwords lying around (the other being very secure methods of challenging the password), which you'd have to do to put the password change in a queue for delayed changing - and I cannot see[1] any other way to safely queue a Kerberos hash in a documented way - unlike an LDAP userPassword where you could possibly precompute a SSHA1 hash and queue that.
[1] Which does not mean it is impossible, but I would be very interested in how it would be possible.
On the face of it - that looks absolutely perfect!
Hmm...
A better approach is taken in the FreeIPA project: There's a SLAPI plugin for 389 DS which supports MIT Kerberos. A C programmer might be able to adapt this as an OpenLDAP overlay (similar to OpenLDAP's slapo-smbk5pwd).
Ciao, Michael.
slapi? Not heard of those - I shall go Google.
Many thanks for all that - interesting stuff :)
Cheers
Tim
Tim Watts wrote:
On 29/05/12 17:42, Michael Ströder wrote:
Tim Watts wrote:
http://www.opinsys.fi/en/smbkrb5pwd-password-syncing-for-openldap-mit-kerber...
(Line wrap warning) - some nice person has already done the job for MIT Kerberos :->>>
The system described above is a bit fragile. Because if one of the systems fail the password might only be changed in LDAP or Kerberos.
True.
In this case, the correct scenario for my environment is to fail the password change completely if the backends are not all contactable.
So if the password change succeeded one system you would have to roll-back in case it fails on the second system. This can get tricky even if you have the old password at hand (e.g. because of pwdHistory).
One of the points of using kerberos is not to have cleartext (or decryptable) passwords lying around (the other being very secure methods of challenging the password), which you'd have to do to put the password change in a queue for delayed changing - and I cannot see[1] any other way to safely queue a Kerberos hash in a documented way - unlike an LDAP userPassword where you could possibly precompute a SSHA1 hash and queue that.
Well, you can first make the non-queueable password change and if that succeeds send the queueable password change. But I'd consider queueing a rather bad user experience which causes work in the first level support.
Ciao, Michael.
openldap-technical@openldap.org
-
Bernd May -
Christian Manal -
Howard Chu -
Michael Ströder -
Nick Milas -
Tim Watts