Thanks for your reply,
If compiling and installing from source, I don't see any information in the manual about how to auto-start the software and about process/file/directory permissions and ownership. I'm still searching the Faq-O-Matic (which is a little frustrating).
Taking a step back, I'd love to install from yum on RHEL/CentOS and let it be taken care of in a trusted manner. But we require better password hashing than SHA1, so we are required to compile by hand using the passwd/sha2 contributed module (little surprised this isn't accepted into the core project, but I'm sure there are reasons). Maybe I can find this in a third-party repo somewhere?
Not sure what you mean. the SHA2 contrib module is shipped with every OpenLDAP release. Thus, as best I can tell, it is indeed included.
My "surprised" comment is in reference to the fact that the default build of OpenLDAP only supports SHA1, which is widely regarded as deprecated. Why hasn't the sha2 module been migrated out of the contrib directory is what I am getting at (which commonly requires situations like this -- forcing people who wouldn't otherwise do so to install from source just to obtain this feature). One could argue that situations like this contribute to the lack of adoption of stronger password schemes in general. Something of an off-topic tangent.
If you are using RHEL or CentOS, you may be interested in http://ltb-project.org/wiki/download#openldap
Great. I will investigate.
Does anyone else know of any yum-compatible repos that have a sha2-enabled OpenLDAP build in them? Anyone know anything about the OpenLDAP packages in RepoForge?
I actually only assumed without testing that the OpenLDAP package in the CentOS base repo doesn't have the sha2 module compiled in. I should go back and check that assumption.
Also, reflecting on the installation of the sha2 module, it occurs to me that short of the CentOS repo package already having sha2 compiled in, the best course of action is probably to compile only the sha2 module and use it with the CentOS package --- including the module in the slapd configuration seems to be the extent of integration, so that should work, no? If so, I think this would be the best option.
After installation, what is commonly done in this regard? Create user/group "ldap" with no login shell and chown ldap:ldap on /usr/local/var/openldap-data? Is that all?
It depends on your needs. I have done anything from running slapd as root, to running it as a specific user.
I'd welcome pointers to somewhere this is discussed (don't see it in the docs, maybe in the FAQ?). I don't have needs that are much different than anyone else.
I naively assume slapd should generally not be run as root. In that case, is creating a ldap user/group and chowning the openldap-data directory the only things to do?
Then what do people use for auto-starting the software (presumably with -u ldap -g ldap) in a RedHat environment?
I wrote my own startup script that works with chkconfig. http://linuxcommand.org/man_pages/chkconfig8.html
I'm looking for anyone who wants to share such scripts.
Thanks kindly for your time, much appreciated.
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
My "surprised" comment is in reference to the fact that the default build of OpenLDAP only supports SHA1, which is widely regarded as deprecated. Why hasn't the sha2 module been migrated out of the contrib directory is what I am getting at (which commonly requires situations like this -- forcing people who wouldn't otherwise do so to install from source just to obtain this feature). One could argue that situations like this contribute to the lack of adoption of stronger password schemes in general. Something of an off-topic tangent.
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support. The "contrib" area is for modules that add non-RFC behavior to the stock behavior of OpenLDAP.
Does anyone else know of any yum-compatible repos that have a sha2-enabled OpenLDAP build in them? Anyone know anything about the OpenLDAP packages in RepoForge?
I always build OpenLDAP myself, so no idea.
I naively assume slapd should generally not be run as root. In that case, is creating a ldap user/group and chowning the openldap-data directory the only things to do?
For slapd, I think it is generally an administrator preference. You are certainly more secure from any sort of potential root exploit by not running it as root.
As for chkconfig scripts, you can simply google for it... One example of many:
http://www.faqs.org/docs/securing/chap26sec214.html This one is clearly a bit old since it looks for slapd.conf and slurpd, but the basic concepts are there.
or you could just look at the one that ships with RHEL/CentOS...
--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
Quanah Gibson-Mount wrote:
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
Why hasn't the sha2 module been migrated out of the contrib directory
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support.
Sorry, this is an artificial argument which is simply not valid!
Can you tell me which RFC specifies how to handle LANMAN hashes (--enable-lmpasswd)? There are plenty similar examples...
I'd also like to see sha2 module pulled into mainstream source (with patch in ITS#7490).
Ciao, Michael.
--On Wednesday, January 16, 2013 7:39 AM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
Why hasn't the sha2 module been migrated out of the contrib directory
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support.
Sorry, this is an artificial argument which is simply not valid!
Can you tell me which RFC specifies how to handle LANMAN hashes (--enable-lmpasswd)? There are plenty similar examples...
OpenLDAP, like many software projects that have existed for numerous years, has grown in its development practices. Just because something was done incorrectly in the past is not a reason to continue doing so. Feel free to port lanman hashes to a contrib module.
--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 Wednesday, January 16, 2013 7:39 AM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
Why hasn't the sha2 module been migrated out of the contrib directory
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support.
Sorry, this is an artificial argument which is simply not valid!
Can you tell me which RFC specifies how to handle LANMAN hashes (--enable-lmpasswd)? There are plenty similar examples...
OpenLDAP, like many software projects that have existed for numerous years, has grown in its development practices. Just because something was done incorrectly in the past is not a reason to continue doing so. Feel free to port lanman hashes to a contrib module.
I'm not an expert in security, so this is just my 2c. In general, as far as I recall, we tend to be pragmatic when appropriate. So asking a fancy useless feature to become mainstream because other fancy useless features made it long ago is pointless. But when it comes to security, I think it may be wise to break the rule every now and then.
I leave judgement to security experts, but in case I'd favour moving SHA-2 support to mainstream (or whatever other means makes it easier for packagers to include it without requiring users to compile it separately).
As I said, my 2c.
p.
On Wed, Jan 16, 2013 at 11:18 AM, Pierangelo Masarati masarati@aero.polimi.it wrote:
--On Wednesday, January 16, 2013 7:39 AM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
Why hasn't the sha2 module been migrated out of the contrib directory
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support.
Sorry, this is an artificial argument which is simply not valid!
Can you tell me which RFC specifies how to handle LANMAN hashes (--enable-lmpasswd)? There are plenty similar examples...
OpenLDAP, like many software projects that have existed for numerous years, has grown in its development practices. Just because something was done incorrectly in the past is not a reason to continue doing so. Feel free to port lanman hashes to a contrib module.
I'm not an expert in security, so this is just my 2c. In general, as far as I recall, we tend to be pragmatic when appropriate. So asking a fancy useless feature to become mainstream because other fancy useless features made it long ago is pointless. But when it comes to security, I think it may be wise to break the rule every now and then.
I'd add that things like sha2 aren't "fancy" and frivolous at all, but commonly recommended. As I mentioned, the more adoption it gets, the more the RFC authors will be encouraged to update, but even if not, deferring to the (outdated, if it in fact mentions SHA1 and nothing better) RFC on an issue like this may not be the best approach.
On Jan 16, 2013, at 1:05 PM, Ori Bani oribani@gmail.com wrote:
On Wed, Jan 16, 2013 at 11:18 AM, Pierangelo Masarati masarati@aero.polimi.it wrote:
--On Wednesday, January 16, 2013 7:39 AM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
Why hasn't the sha2 module been migrated out of the contrib directory
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support.
Sorry, this is an artificial argument which is simply not valid!
Can you tell me which RFC specifies how to handle LANMAN hashes (--enable-lmpasswd)? There are plenty similar examples...
OpenLDAP, like many software projects that have existed for numerous years, has grown in its development practices. Just because something was done incorrectly in the past is not a reason to continue doing so. Feel free to port lanman hashes to a contrib module.
I'm not an expert in security, so this is just my 2c. In general, as far as I recall, we tend to be pragmatic when appropriate. So asking a fancy useless feature to become mainstream because other fancy useless features made it long ago is pointless. But when it comes to security, I think it may be wise to break the rule every now and then.
I'd add that things like sha2 aren't "fancy" and frivolous at all, but commonly recommended.
I think Ando was simply pointing out that the arguing that SHA-2 password schemes should be included because LANMAN hash schemes are currently included is lame. I have to agree with him there.
As I mentioned, the more adoption it gets, the more the RFC authors will be encouraged to update, but even if not, deferring to the (outdated, if it in fact mentions SHA1 and nothing better) RFC on an issue like this may not be the best approach.
SHA-2 is not significantly better here! It's not about bits of hash, it's about compute cost of dictionary and brute force attacks. SHA-2 is only marginally more expensive than SHA-1 or even MD-5.
Any effort to induce new password hash schemes should make dictionary and brute force attacks many orders of magnitude more expensive, as this is by far the most feasible attack we face. There are a few other areas of concern... including the continued reliance on human generated passwords, but I digress.
Anyways, the interop argument Michael made is valid.
Also, at times, one just has to hold their nose. IMO, if you going to do password authentication, you should be using SCRAM-SHA-1-PLUS authentication and using the compatible hashed storage format (SHA-1 based, of course) or, the more practical, clear-text.
Odd that, SCRAM using SHA-1 not SHA-2. :-)
-- Kurt
Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2013 7:39 AM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
Why hasn't the sha2 module been migrated out of the contrib directory
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support.
Sorry, this is an artificial argument which is simply not valid!
Can you tell me which RFC specifies how to handle LANMAN hashes (--enable-lmpasswd)? There are plenty similar examples...
OpenLDAP, like many software projects that have existed for numerous years, has grown in its development practices. Just because something was done incorrectly in the past is not a reason to continue doing so.
I expected this answer but not that SHA-2 userPassword hashes are mainstream in other LDAP server and client implementations for quite a while now.
Feel free to port lanman hashes to a contrib module.
That's not my goal and you know that.
Ciao, Michael.
Quanah Gibson-Mount wrote:
--On Wednesday, January 16, 2013 7:39 AM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
--On Tuesday, January 15, 2013 2:35 PM -0800 Ori Bani oribani@gmail.com wrote:
Why hasn't the sha2 module been migrated out of the contrib directory
The "core" of OpenLDAP tries to be as RFC compliant as possible. There is no RFC that I'm aware of that adds SHA2 support.
Sorry, this is an artificial argument which is simply not valid!
Can you tell me which RFC specifies how to handle LANMAN hashes (--enable-lmpasswd)? There are plenty similar examples...
OpenLDAP, like many software projects that have existed for numerous years, has grown in its development practices. Just because something was done incorrectly in the past is not a reason to continue doing so. Feel free to port lanman hashes to a contrib module.
http://www.ietf.org/id/draft-stroeder-hashed-userpassword-values-00.txt
Ciao, Michael.
Also, reflecting on the installation of the sha2 module, it occurs to me that short of the CentOS repo package already having sha2 compiled in, the best course of action is probably to compile only the sha2 module and use it with the CentOS package --- including the module in the slapd configuration seems to be the extent of integration, so that should work, no? If so, I think this would be the best option.
This has been tested and works. It requires compilation of the full OpenLDAP source in order to compile and install the sha2 module, but that's easy and of course you skip the "make install" step. After that, install the hand-built sha2 module, add it to your configuration and it works fine.
openldap-technical@openldap.org
-
Kurt Zeilenga -
Michael Ströder -
Ori Bani -
Pierangelo Masarati -
Quanah Gibson-Mount