Hello,
We've been using OpenLDAP for all major services (mainly mail, Shibboleth, web service authentication etc.) based on authentication over the standard userPassword attribute (and uid as the username) of the person objectClass.
Now, for particular authentication needs (because particular applications - like SQUID - do not support the standard PLAIN auth over TLS/SSL which we usually use), we consider installing Kerberos using our LDAP server as backend.
Such a setup is meant to continue to allow the standard PLAIN auth over TLS/SSL (directly by LDAP) in some applications and provide Kerberos authentication in others, based on the same user/password database (stored and maintained in LDAP). [I know that in many environments, userPassword and krbPrincipalKey are deliberately different.]
Generally, the Kerberos installation and user administration process involves creating Principals (krbPrincipalName) and Principal Keys (krbPrincipalKey).
My question:
Is there a way to automatically populate (either internally, via LDAP configuration, or externally, by running - for example - an external script) the values of krbPrincipalName and krbPrincipalKey attributes, so that these values can be produced by the values of the currently used attributes (uid, userPassword, including possibly others.)? This would allow initial creation of values for the above attributes using the same password value.
Here: https://help.ubuntu.com/10.04/serverguide/C/kerberos-ldap.html I have found a quite descriptive tutorial, which, unfortunately, does not cover the above issues.
Any feedback and system design advice will be appreciated.
Thanks in advance, Nick
On 21/07/11 00:39 +0300, Nick Milas wrote:
Such a setup is meant to continue to allow the standard PLAIN auth over TLS/SSL (directly by LDAP) in some applications and provide Kerberos authentication in others, based on the same user/password database (stored and maintained in LDAP). [I know that in many environments, userPassword and krbPrincipalKey are deliberately different.]
Is there a way to automatically populate (either internally, via LDAP configuration, or externally, by running - for example - an external script) the values of krbPrincipalName and krbPrincipalKey attributes, so that these values can be produced by the values of the currently used attributes (uid, userPassword, including possibly others.)? This would allow initial creation of values for the above attributes using the same password value.
See:
contrib/slapd-modules/smbk5pwd/
within the source.
Dan White wrote:
On 21/07/11 00:39 +0300, Nick Milas wrote:
Such a setup is meant to continue to allow the standard PLAIN auth over TLS/SSL (directly by LDAP) in some applications and provide Kerberos authentication in others, based on the same user/password database (stored and maintained in LDAP). [I know that in many environments, userPassword and krbPrincipalKey are deliberately different.]
Is there a way to automatically populate (either internally, via LDAP configuration, or externally, by running - for example - an external script) the values of krbPrincipalName and krbPrincipalKey attributes, so that these values can be produced by the values of the currently used attributes (uid, userPassword, including possibly others.)? This would allow initial creation of values for the above attributes using the same password value.
See:
contrib/slapd-modules/smbk5pwd/
Note that this overlay only works when using heimdal software for the KDC which uses a different LDAP schema.
Since the orginal poster mentioned attributes krbPrincipalName and krbPrincipalKey he seems to use MIT Kerberos.
Ciao, Michael.
On 21/7/2011 8:50 πμ, Michael Ströder wrote:
Dan White wrote:
See:
contrib/slapd-modules/smbk5pwd/
Note that this overlay only works when using heimdal software for the KDC which uses a different LDAP schema.
Since the orginal poster mentioned attributes krbPrincipalName and krbPrincipalKey he seems to use MIT Kerberos.
Thank you all for your feedback.
Yes, it's the MIT Kerberos. And, after looking into smbk5pwd, it does the opposite (of what I want): it automatically gets value for userPassword based on the Principal key (krb5Key) attribute (using the krb5-kdc.schema).
I am looking if it is possible to automatically populate/produce krbPrincipalKey attribute values (kerberos.schema) based on current userPassword attribute values (person objectClass in core.schema), without knowing the stored password (encoded mainly as MD5).
Any ideas?
Thanks, Nick
Nick Milas wrote:
On 21/7/2011 8:50 πμ, Michael Ströder wrote:
Dan White wrote:
See:
contrib/slapd-modules/smbk5pwd/
Note that this overlay only works when using heimdal software for the KDC which uses a different LDAP schema.
Since the orginal poster mentioned attributes krbPrincipalName and krbPrincipalKey he seems to use MIT Kerberos.
Thank you all for your feedback.
Yes, it's the MIT Kerberos. And, after looking into smbk5pwd, it does the opposite (of what I want): it automatically gets value for userPassword based on the Principal key (krb5Key) attribute (using the krb5-kdc.schema).
I am looking if it is possible to automatically populate/produce krbPrincipalKey attribute values (kerberos.schema) based on current userPassword attribute values (person objectClass in core.schema), without knowing the stored password (encoded mainly as MD5).
Obviously Not.
Any ideas?
Generating a Kerberos key requires knowing the original plaintext that will be used to derive the key. A hashed password cannot be simply reversed into its original plaintext; that's the point of hashing it.
Nick Milas wrote:
Yes, it's the MIT Kerberos. And, after looking into smbk5pwd, it does the opposite (of what I want): it automatically gets value for userPassword based on the Principal key (krb5Key) attribute (using the krb5-kdc.schema).
No, it can do two things:
1. Intercept a Password Modify Extended Request and populate krb5Key based on the new clear-text password.
2. Intercept a simple Bind Request and check the user's password against krb5Key if userPassword is set to the value {K5KEY}.
From what I understood in your original posting you want 1. But you have to use heimdal as KDC for that.
I am looking if it is possible to automatically populate/produce krbPrincipalKey attribute values (kerberos.schema) based on current userPassword attribute values (person objectClass in core.schema), without knowing the stored password (encoded mainly as MD5).
Maybe you can extend smbk5pwd to do that or derive your own overlay from that code.
Ciao, Michael.
On 21/07/11 10:59 +0300, Nick Milas wrote:
On 21/7/2011 8:50 πμ, Michael Ströder wrote:
Dan White wrote:
See:
contrib/slapd-modules/smbk5pwd/
Note that this overlay only works when using heimdal software for the KDC which uses a different LDAP schema.
Since the orginal poster mentioned attributes krbPrincipalName and krbPrincipalKey he seems to use MIT Kerberos.
Thank you all for your feedback.
Yes, it's the MIT Kerberos. And, after looking into smbk5pwd, it does the opposite (of what I want): it automatically gets value for userPassword based on the Principal key (krb5Key) attribute (using the krb5-kdc.schema).
I am looking if it is possible to automatically populate/produce krbPrincipalKey attribute values (kerberos.schema) based on current userPassword attribute values (person objectClass in core.schema), without knowing the stored password (encoded mainly as MD5).
It's unclear from your original post if your are using SASL binds - you said you are doing "PLAIN auth over TLS/SSL".
If you are using SASL binds, or can force SASL binds, then you could use the autotransition feature of Cyrus SASL to transition from a hashed password store to a cleartext password store.
An approach would be to configure /usr/lib/sasl2/slapd.conf with:
pwcheck_method: saslauthd mech_list: plain login gssapi external auto_transition: yes auxprop_plugin: slapd
You could run saslauthd with the ldap backend (with a non-sasl configuration), or run it with the pam backend, and configure an nss plugin to, in turn, retrieve the hashed passwords from ldap.
That would get you a step closer, at which point you could generate your kerberos keys from the clear text passwords you've just stored in userPassword.
A simpler approach, and one that works with non-SASL binds, would be to configure pass-through authentication and perform saslauthd/kerberos5 authentication. As users change their passwords (against your kerberos server, via some unspecified process), you could replace their userPassword entries with {SASL}user@realm (as described in the Admin guide) and do away with hashed password entries altogether.
On 21/7/2011 10:23 μμ, Dan White wrote:
It's unclear from your original post if your are using SASL binds - you said you are doing "PLAIN auth over TLS/SSL".
No, I am not using SASL on LDAP. I mistakenly used the term "PLAIN" (which implies SASL). In fact I am using the "simple" method (usually noted: SSL + User + Password).
If you are using SASL binds, or can force SASL binds, then you could use the autotransition feature of Cyrus SASL...
...
A simpler approach, and one that works with non-SASL binds, would be to configure pass-through authentication and perform saslauthd/kerberos5 authentication. As users change their passwords (against your kerberos server, via some unspecified process), you could replace their userPassword entries with {SASL}user@realm (as described in the Admin guide) and do away with hashed password entries altogether.
Thank you for the detailed info; both approaches seem interesting and I'll have to investigate further (it will take some time I am afraid).
If I understand it correctly, the second approach seems more attractive to me. Running Kerberos with LDAP backend still stores passwords in the DIT so we can still have a single data store. Additionally, it provides a smooth transition as users can:
1. Continue to use their hashed passwords until they change them (and automatically migrate to the pass-through scheme). 2. Continue to use simple (non-SASL) binds directly to LDAP Server. 3. Use kerberos authentication directly (using Kerberos LDAP backend transparently).
Thanks again, Nick
On 21/7/2011 10:23 μμ, Dan White wrote:
A simpler approach, and one that works with non-SASL binds, would be to configure pass-through authentication and perform saslauthd/kerberos5 authentication. As users change their passwords (against your kerberos server, via some unspecified process), you could replace their userPassword entries with {SASL}user@realm (as described in the Admin guide) and do away with hashed password entries altogether.
If I follow this model, according to the documentation:
"Where an entry has a "{SASL}" password value, OpenLDAP delegates the whole process of validating that entry's password to Cyrus SASL."
Supposing that we configure SASL to use Kerberos5 authentication, will our current standard applications (Postfix, Dovecot, Shibboleth, Apache etc.) need to be configured to include GSSAPI SASL method?
As an example, Postfix uses Dovecot SASL to authenticate clients (PLAIN method), and is configured to check their identity/password against LDAP (User+Password - No SSL here because it's running on the local box). I guess Postfix will need to include GSSAPI to SASL methods ?
In effect: Authentication for a user (hosted in LDAP) will fail in an application which (uses LDAP for user/password backend and) is not SASL-enabled or it is SASL-enabled but does not include/support the GSSAPI method, if the user has a "{SASL}user@realm" userPassword attribute value?
Thanks, Nick
--On Friday, July 22, 2011 9:03 PM +0300 Nick Milas nick@eurobjects.com wrote:
On 21/7/2011 10:23 μμ, Dan White wrote:
A simpler approach, and one that works with non-SASL binds, would be to configure pass-through authentication and perform saslauthd/kerberos5 authentication. As users change their passwords (against your kerberos server, via some unspecified process), you could replace their userPassword entries with {SASL}user@realm (as described in the Admin guide) and do away with hashed password entries altogether.
If I follow this model, according to the documentation:
"Where an entry has a "{SASL}" password value, OpenLDAP delegates the whole process of validating that entry's password to Cyrus SASL."Supposing that we configure SASL to use Kerberos5 authentication, will our current standard applications (Postfix, Dovecot, Shibboleth, Apache etc.) need to be configured to include GSSAPI SASL method?
No. If you use pass-through authentication like this, then your LDAP server is specifically NOT using SASL/GSSAPI, but passing the credentials THROUGH. I.e., you still bind with a username and password to LDAP, which then authenticates that against the KDC.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
On 22/07/11 21:03 +0300, Nick Milas wrote:
On 21/7/2011 10:23 μμ, Dan White wrote:
A simpler approach, and one that works with non-SASL binds, would be to configure pass-through authentication and perform saslauthd/kerberos5 authentication. As users change their passwords (against your kerberos server, via some unspecified process), you could replace their userPassword entries with {SASL}user@realm (as described in the Admin guide) and do away with hashed password entries altogether.
If I follow this model, according to the documentation:
"Where an entry has a "{SASL}" password value, OpenLDAP delegates the whole process of validating that entry's password to Cyrus SASL."
Supposing that we configure SASL to use Kerberos5 authentication, will our current standard applications (Postfix, Dovecot, Shibboleth, Apache etc.) need to be configured to include GSSAPI SASL method?
No. However if Postfix, or other daemons which link against cyrus sasl, happens to be using saslauthd to authenticate users, then changing saslauthd to use the kerberos5 backend will affect how those daemons authenticate users as well. If that's the case, you could run two saslauthd daemons, each with their own backend, which will require a custom saslauthd_path configuration in one of your sasl .conf files.
If your intention is to eventually authenticate directly to slapd/postfix using SASL GSSAPI binds (rather than simple pass-through binds), then you can 'turn on' GSSAPI piecemeal wise in each of your daemons (with your mech_list config).
As an example, Postfix uses Dovecot SASL to authenticate clients (PLAIN method), and is configured to check their identity/password against LDAP (User+Password - No SSL here because it's running on the local box). I guess Postfix will need to include GSSAPI to SASL methods ?
Since your Postfix is compiled again Dovecot, any changes made to saslauthd should not affect Postfix. The fact that Postfix uses Dovecot to authenticate, against OpenLDAP, which in turn potentially authenticates against saslauthd/kerbero5 should all be transparent to Postfix and Dovecot.
In effect: Authentication for a user (hosted in LDAP) will fail in an application which (uses LDAP for user/password backend and) is not SASL-enabled or it is SASL-enabled but does not include/support the GSSAPI method, if the user has a "{SASL}user@realm" userPassword attribute value?
pass-through authentication only works with non-sasl binds. Any process which authenticates to your slapd server via this method should be ignorant of the fact that sasl is ultimately being used on the backend, and does not need to support SASL itself.
If you have a client authenticating against slapd/postfix using SASL GSSAPI binds, the userPassword entry is ignored.
openldap-technical@openldap.org
-
Dan White -
Howard Chu -
Michael Ströder -
Nick Milas -
Quanah Gibson-Mount