Full_Name: SATOH Fumiyasu Version: master OS: URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch Submission from: (NULL) (220.100.28.128) This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes to slapd-sha2 module. This patch depends on ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch (http://www.openldap.org/its/index.cgi?findid=7269).
fumiyas@osstech.co.jp wrote: > Full_Name: SATOH Fumiyasu > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch > Submission from: (NULL) (220.100.28.128) > > > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes > to slapd-sha2 module. > > This patch depends on > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > (http://www.openldap.org/its/index.cgi?findid=7269). I've not tested the patch yet. But I'd appreciate if SHA-2 support would be available in the main source and not only under contrib/. Any objections against extending libraries/liblutil/passwd.c? Ciao, Michael.
At Thu, 24 May 2012 01:32:33 GMT, fumiyas@OSSTech wrote: > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. Sorry. > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes > to slapd-sha2 module. > > This patch depends on > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > (http://www.openldap.org/its/index.cgi?findid=7269). -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/
At Tue, 29 May 2012 05:49:52 GMT, fumiyas@OSSTech wrote: > > URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch > > In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. > Sorry. FYI. [PATCH] slappasswd: Read slapd.conf to load dynamic password hash modules https://gist.github.com/2632560 It is a problem that a slappasswd user must have read privilage on slapd.conf (or slapd.d) by this patch... > > This patch adds support {SSHA256}, {SSHA384} and {SSHA512} hash schemes > > to slapd-sha2 module. > > > > This patch depends on > > ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-multithread.patch > > (http://www.openldap.org/its/index.cgi?findid=7269). -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/
fumiyas@osstech.co.jp wrote: > At Tue, 29 May 2012 05:49:52 GMT, > fumiyas@OSSTech wrote: >>> URL: ftp://ftp.openldap.org/incoming/openldap-2.4.31-sha2-salted-hash.patch >> >> In patched slapd-sha2.c, "#define SLAPD_SHA2_DEBUG" must be removed. >> Sorry. > > FYI. > > [PATCH] slappasswd: Read slapd.conf to load dynamic password hash modules > https://gist.github.com/2632560 > > It is a problem that a slappasswd user must have read privilage > on slapd.conf (or slapd.d) by this patch... slappasswd is an administrative command; if you don't have administrator access already you have no business running it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Tuesday, May 29, 2012 4:08 PM +0000 hyc@symas.com wrote: >> It is a problem that a slappasswd user must have read privilage >> on slapd.conf (or slapd.d) by this patch... > > slappasswd is an administrative command; if you don't have administrator > access already you have no business running it. What in any way makes it administrative? You simply give it a password to convert into whatever scheme for you. Where is the administrative requirement? Why shouldn't X user with some particular permissions into the database, but not the configuration, be able to run it to generate a value? --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@zimbra.com wrote: > --On Tuesday, May 29, 2012 4:08 PM +0000 hyc@symas.com wrote: > >>> It is a problem that a slappasswd user must have read privilage >>> on slapd.conf (or slapd.d) by this patch... >> >> slappasswd is an administrative command; if you don't have administrator >> access already you have no business running it. > > What in any way makes it administrative? You simply give it a password to > convert into whatever scheme for you. Where is the administrative > requirement? Why shouldn't X user with some particular permissions into > the database, but not the configuration, be able to run it to generate a > value? I concur with Quanah: I know many operational procedures where slappasswd is just used to generate pre-hashed userPassword values. This usage is supported by DESCRIPTION in slappasswd(8). I also don't see a requirement for administrative access to slapd's config at all. Doesn't this ask for fully integrating SHA-2 password support into libraries/liblutil/passwd.c? Ciao, Michael.
I'd argue that slappassword shouldn't read the configuration and hence not support 'contributed' hash mechanisms. But if you are going to make slappassword read the configuration, then it needs to be restricted to only users who have read access to the configuration. I have no real opinion about whether SHA-2 should or shouldn't be in the core set of hashes... but personally I rather push folks towards SCRAM compatible hashes than the same poor usages of newer hash algorithms. -- Kurt
Kurt@OpenLDAP.org wrote: > I'd argue that slappassword shouldn't read the configuration and hence not > support 'contributed' hash mechanisms. Which means if SHA-2 stays in a separate overlay contrib/ there won't be practically usable SHA-2 support in OpenLDAP. I consider it falling behind other LDAP server implementations. > But if you are going to make slappassword read the configuration, then it > needs to be restricted to only users who have read access to the > configuration. Yes. > I have no real opinion about whether SHA-2 should or shouldn't be in the > core set of hashes... but personally I rather push folks towards SCRAM > compatible hashes than the same poor usages of newer hash algorithms. I concur that SCRAM would be the best choice. But IMO adding SHA-2 support to the core does not hold anybody back from developing/deploying SCRAM. In reality getting completely rid of simple bind in favour of SASL bind no matter which SASL mech is nothing done so easily with all the applications out in the wild. And last time I checked SCRAM support in cyrus-sasl required clear-text password in userPassword. So this is outside the OpenLDAP project, isn't it? Ciao, Michael.
michael@stroeder.com wrote: > Doesn't this ask for fully integrating SHA-2 password support into > libraries/liblutil/passwd.c? Clearly you haven't thought this through. No, because that doesn't solve the problem of how to use other contrib passwd modules. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Quanah Gibson-Mount wrote: > --On Tuesday, May 29, 2012 4:08 PM +0000 hyc@symas.com wrote: > >>> It is a problem that a slappasswd user must have read privilage >>> on slapd.conf (or slapd.d) by this patch... >> >> slappasswd is an administrative command; if you don't have administrator >> access already you have no business running it. > > What in any way makes it administrative? You simply give it a password to > convert into whatever scheme for you. Where is the administrative > requirement? Why shouldn't X user with some particular permissions into > the database, but not the configuration, be able to run it to generate a > value? slap*(8) are all administrative tools, by definition. You should already know that. Why should X user ever need to run this tool to generate a value? slapd generates users' password values automatically. The only time anyone ever *needs* this tool is for setting a rootpw in the slapd config. That's the only reason this tool exists and it is the only valid use case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > michael@stroeder.com wrote: >> Doesn't this ask for fully integrating SHA-2 password support into >> libraries/liblutil/passwd.c? > > Clearly you haven't thought this through. Maybe. But one question: Why is SHA-1 in the core and SHA-2 isn't? IMO that's just an arbitrary choice. > No, because that doesn't solve the problem of how to use other contrib passwd > modules. If you come up with another overall solution to avoid reading the config when using slappasswd I'm of course fine with that too. Ciao, Michael.
hyc@symas.com wrote: > Why should X user ever need to run this tool to generate a value? From slappasswd(8): DESCRIPTION Slappasswd is used to generate an userPassword value suitable for use with ldapmodify(1), slapd.conf(5) rootpw configuration directive or the slapd-config(5) olcRootPW configuration directive. Do you want to restrict this text regarding ldapmodify(1) only for the cases that the slappasswd user has also write access to back-config? Of course your are the OpenLDAP boss. You can change everything to make it work for you. But it breaks existing operational procedures for other people. Ciao, Michael.
--On Tuesday, May 29, 2012 5:49 PM +0000 michael@stroeder.com wrote: > hyc@symas.com wrote: >> Why should X user ever need to run this tool to generate a value? > > From slappasswd(8): > > DESCRIPTION > Slappasswd is used to generate an userPassword value suitable > for use with ldapmodify(1), slapd.conf(5) rootpw configuration > directive or the slapd-config(5) olcRootPW configuration directive. > > Do you want to restrict this text regarding ldapmodify(1) only for the > cases that the slappasswd user has also write access to back-config? The tool has allowed the ability to generate password values for years. It is not uncommon to use it to do just that. I've often used it to generate base-64 encoded SSHA values to push into LDIF I will be writing to the server via ldapmodify. That should not require access to cn=config/slapd.conf. --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
Michael Ströder wrote: > hyc@symas.com wrote: >> Why should X user ever need to run this tool to generate a value? > >>From slappasswd(8): > > DESCRIPTION > Slappasswd is used to generate an userPassword value suitable > for use with ldapmodify(1), slapd.conf(5) rootpw configuration > directive or the slapd-config(5) olcRootPW configuration directive. > > Do you want to restrict this text regarding ldapmodify(1) only for the cases > that the slappasswd user has also write access to back-config? We could probably delete that ldapmodify(1) reference. Technically it has always been wrong, since there's never been any guarantee that an LDAP user's password was ever stored in any user-accessible attribute. > Of course your are the OpenLDAP boss. You can change everything to make it > work for you. But it breaks existing operational procedures for other people. The text also states The practice of storing hashed passwords in userPassword violates Standard Track (RFC 4519) schema specifications and may hinder interoperability. Anyone building operational procedures on something that violates the specs was asking for trouble. Users should be using ldappasswd, that's what it's for. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Howard Chu wrote: > The text also states > The practice of storing hashed passwords in userPassword violates > Standard Track (RFC 4519) schema specifications and may hinder > interoperability. In practice we all live very well with this for years. That's least of a problem today. > Anyone building operational procedures on something that violates the specs > was asking for trouble. Users should be using ldappasswd, that's what it's for. ??? ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. I cannot see how this is different from using ldapadd/ldapmodify. So what are you really trying to say? Ciao, Michael.
Michael Ströder wrote: > Howard Chu wrote: >> The text also states >> The practice of storing hashed passwords in userPassword violates >> Standard Track (RFC 4519) schema specifications and may hinder >> interoperability. > > In practice we all live very well with this for years. That's least of a > problem today. > >> Anyone building operational procedures on something that violates the specs >> was asking for trouble. Users should be using ldappasswd, that's what it's for. > > ??? > > ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. > I cannot see how this is different from using ldapadd/ldapmodify. Wrong, ldappasswd sends a PasswordModify exop to a server. The server may implement that exop in any implementation-specific manner, and there is no guarantee that the password a server uses is ever instantiated in any LDAP entry. There is no guarantee that setting a userPassword attribute using ldapadd/ldapmodify will ever do anything useful for any given LDAP user. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc@symas.com wrote: > Michael Ströder wrote: >> Howard Chu wrote: >>> The text also states >>> The practice of storing hashed passwords in userPassword violates >>> Standard Track (RFC 4519) schema specifications and may hinder >>> interoperability. >> >> In practice we all live very well with this for years. That's least of a >> problem today. >> >>> Anyone building operational procedures on something that violates the specs >>> was asking for trouble. Users should be using ldappasswd, that's what it's for. >> >> ??? >> >> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >> I cannot see how this is different from using ldapadd/ldapmodify. > > Wrong, ldappasswd sends a PasswordModify exop to a server. The server may > implement that exop in any implementation-specific manner, and there is no > guarantee that the password a server uses is ever instantiated in any LDAP > entry. There is no guarantee that setting a userPassword attribute using > ldapadd/ldapmodify will ever do anything useful for any given LDAP user. You're arguing based on what a LDAP server could do. I'm arguing based on what OpenLDAP and other server implementations are doing for years. None of what you said in this thread is a real argument against adding SHA-2 hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out. Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you want. (But you shouldn't wonder why there's no active OpenLDAP community.) Ciao, Michael.
Michael Ströder wrote: > hyc@symas.com wrote: >> Michael Ströder wrote: >>> Howard Chu wrote: >>>> The text also states >>>> The practice of storing hashed passwords in userPassword violates >>>> Standard Track (RFC 4519) schema specifications and may hinder >>>> interoperability. >>> >>> In practice we all live very well with this for years. That's least of a >>> problem today. >>> >>>> Anyone building operational procedures on something that violates the specs >>>> was asking for trouble. Users should be using ldappasswd, that's what it's for. >>> >>> ??? >>> >>> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >>> I cannot see how this is different from using ldapadd/ldapmodify. >> >> Wrong, ldappasswd sends a PasswordModify exop to a server. The server may >> implement that exop in any implementation-specific manner, and there is no >> guarantee that the password a server uses is ever instantiated in any LDAP >> entry. There is no guarantee that setting a userPassword attribute using >> ldapadd/ldapmodify will ever do anything useful for any given LDAP user. > > You're arguing based on what a LDAP server could do. I'm arguing based on what > OpenLDAP and other server implementations are doing for years. ActiveDirectory is an obvious example invalidating your argument. > None of what you said in this thread is a real argument against adding SHA-2 > hash algos to the core. Still you did not answer why SHA-1 is in and SHA-2 is out. At present there is no need to change anything in the core since SHA-2 support can be dynamically loaded. Don't fix what isn't broken. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Tuesday, May 29, 2012 8:38 PM +0000 michael@stroeder.com wrote: > Well, you're the OpenLDAP god. So you can arbitrarly decide whatever you > want. (But you shouldn't wonder why there's no active OpenLDAP community.) Comments like this weaken any point you are trying to make, serve no purpose, and are obnoxious. Your emails would be better served without them. --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
Howard Chu wrote: > Michael Ströder wrote: >> hyc@symas.com wrote: >>> Michael Ströder wrote: >>>> Howard Chu wrote: >>>>> The text also states >>>>> The practice of storing hashed passwords in userPassword violates >>>>> Standard Track (RFC 4519) schema specifications and may hinder >>>>> interoperability. >>>> >>>> In practice we all live very well with this for years. That's least of a >>>> problem today. >>>> >>>>> Anyone building operational procedures on something that violates the specs >>>>> was asking for trouble. Users should be using ldappasswd, that's what >>>>> it's for. >>>> >>>> ??? >>>> >>>> ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. >>>> I cannot see how this is different from using ldapadd/ldapmodify. >>> >>> Wrong, ldappasswd sends a PasswordModify exop to a server. The server may >>> implement that exop in any implementation-specific manner, and there is no >>> guarantee that the password a server uses is ever instantiated in any LDAP >>> entry. There is no guarantee that setting a userPassword attribute using >>> ldapadd/ldapmodify will ever do anything useful for any given LDAP user. >> >> You're arguing based on what a LDAP server could do. I'm arguing based on what >> OpenLDAP and other server implementations are doing for years. > > ActiveDirectory is an obvious example invalidating your argument. Does MS AD support RFC 3062? AFAIK W2K3 doesn't. I don't currently have the possibility to check with most recent W2K8R2 though. Anyway that's not relevant here either. We're talking about how OpenLDAP stores and checks the passwords since over a decade. Violating Standard Track (RFC 4519) schema specifications could be avoided by implementing RFC 3112. But this also never happened. > Don't fix what isn't broken. With this argument you can immediately stop any progress. Maybe also a valuable statement by the OpenLDAP chief architect. Ciao, Michael.
changed notes changed state Open to Test moved from Incoming to Contrib
On May 29, 2012, at 1:38 PM, michael@stroeder.com wrote: > Still you did not answer why SHA-1 is in and SHA-2 is out. Well, the general rule is simply all new hash schemes should go in contrib first. What you ask is for an exception to this general rule for SHA-2. I don't see the arguments for the exception being all that strong. Arguing it should be "in" because SHA-1 is "in" is a really poor argument. SHA-1 is "in" because it was grandfathered in. SHA-2, like any new hash scheme, is "out" because of the current practice to put new schemes in contrib. It's as simple as that, I think. I do note that there's many issues bring hashes into core. One key one is that core schemes ought to work with minimal 3rd party libraries, and that means without OpenSSL. So bringing these schemes also means, if we hold to this, bring in a SHA2 implementation into core... and that's gets, well, more involved. And that's one of reasons we have the core/contrib split. Anyways, I personally think no exception should be granted, these schemes should go into contrib like any other new hash scheme would. I've thought a bit about whether slappasswd should or should not load modules. I stand against slapppasswd reading slapd configuration by default. I would not object to reading slapd configuration when specifically requested by the user (by a command line argument). I generally run slappasswd (for setup purposes) as a user which has no access to slapd configuration. This not only for convenience, but for security reasons (limit programs which can read the configuration, as the configuration contains sensitive information). While if I needed some scheme only in contrib I might resort to other means to generate the hash (such as a little perl), I don't object to slappasswd, when requested by option, reading the configuration, loading the modules, and generating the hash. I would only object if slappasswd did this by default, as that would cause me to have to use other means even for core schemes. -- Kurt
Hi, I wish the following command-line option for slappasswd to load dynamically loadable password hash modules: $ slappasswd -o module-load=slapd-sha2.la -h '{SSHA512}' ... $ slappasswd -o module-path=/path/to/lib/openldap \ -o module-load=slapd-sha2.la -h '{SSHA512}' ... At Wed, 30 May 2012 13:45:48 GMT, Kurt@OpenLDAP.org wrote: > While if I needed some scheme only in contrib I might resort to other means to generate the hash (such as a little perl), I don't object to slappasswd, when requested by option, reading the configuration, loading the modules, and generating the hash. I would only object if slappasswd did this by default, as that would cause me to have to use other means even for core schemes. I've revised the patch: https://gist.github.com/2632560 With this patch: $ slappasswd Same as the original behavior (do not read any config) $ slappasswd -f /path/to/slapd.conf Read the specified slapd.conf $ slappasswd -f - Read the default slapd.conf -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/
On May 30, 2012, at 10:06 AM, fumiyas@osstech.co.jp wrote: > I wish the following command-line option for slappasswd to > load dynamically loadable password hash modules: > > $ slappasswd -o module-load=slapd-sha2.la -h '{SSHA512}' > ... > > $ slappasswd -o module-path=/path/to/lib/openldap \ > -o module-load=slapd-sha2.la -h '{SSHA512}' This seems more appropriate approach to me than reading slapd.conf files. Users who use a particular module frequently can use an alias to reduce the typing overhead. -- Kurt
changed notes changed state Test to Release
At Wed, 30 May 2012 17:11:23 GMT, Kurt@OpenLDAP.org wrote: > > I wish the following command-line option for slappasswd to > > load dynamically loadable password hash modules: > > > > $ slappasswd -o module-load=slapd-sha2.la -h '{SSHA512}' > > ... > > > > $ slappasswd -o module-path=/path/to/lib/openldap \ > > -o module-load=slapd-sha2.la -h '{SSHA512}' > > This seems more appropriate approach to me than reading slapd.conf files. Users who use a particular module frequently can use an alias to reduce the typing overhead. I've created a patch. http://www.openldap.org/its/index.cgi?findid=7284 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/
I'm trying to build this module (make distclean before) from recent RE24 git 0cfc487a70f2de40d9827b67949569653ee0e28a but it fails: $ make cc -I../../../../include -Wall -g -c slapd-sha2.c cc -I../../../../include -Wall -g -c sha2.c cc -I../../../../include -shared -Wall -g slapd-sha2.o sha2.o -o slapd-sha2.so /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: slapd-sha2.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC slapd-sha2.o: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [slapd-sha2.so] Error 1 Do I have to tweak the Makefile? Ciao, Michael.
At Thu, 31 May 2012 08:43:30 +0200, Michael Ströder wrote: > I'm trying to build this module (make distclean before) from recent RE24 git > 0cfc487a70f2de40d9827b67949569653ee0e28a but it fails: > > $ make > cc -I../../../../include -Wall -g -c slapd-sha2.c > cc -I../../../../include -Wall -g -c sha2.c > cc -I../../../../include -shared -Wall -g slapd-sha2.o sha2.o -o slapd-sha2.so > /usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: > slapd-sha2.o: relocation R_X86_64_32 against `.text' can not be used when > making a shared object; recompile with -fPIC See the above message. :-) > slapd-sha2.o: could not read symbols: Bad value > collect2: ld returned 1 exit status > make: *** [slapd-sha2.so] Error 1 > > Do I have to tweak the Makefile? Add -fPIC to $CCFLAGS in Makefile if you are using GCC. -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/
SATOH Fumiyasu wrote: > Michael Ströder wrote: >> Do I have to tweak the Makefile? > > Add -fPIC to $CCFLAGS in Makefile if you are using GCC. I hoped that this would not be necessary and the module work include something detected via autoconf before. Anyway it does not work for me. If I set password-hash {SSHA512} such a userPassword value is added to the entry but the bind does not work. Also if I generate a salted SHA-2 userPassword with my web2ldap it does not work. (I did interop-tests web2ldap<->OpenDJ before with salted SHA-2 hashes.) SHA-2 hashes without salt seem to work. Ciao, Michael.
At Mon, 11 Jun 2012 21:30:18 +0200, Michael Ströder wrote: > >> Do I have to tweak the Makefile? > > > > Add -fPIC to $CCFLAGS in Makefile if you are using GCC. > > I hoped that this would not be necessary and the module work include something > detected via autoconf before. Can you try the following Makefile? https://gist.github.com/2915450 > Anyway it does not work for me. If I set password-hash {SSHA512} such a > userPassword value is added to the entry but the bind does not work. > > Also if I generate a salted SHA-2 userPassword with my web2ldap it does not > work. (I did interop-tests web2ldap<->OpenDJ before with salted SHA-2 hashes.) > > SHA-2 hashes without salt seem to work. I've confirmed that slapd-sha2 works on Debian GNU/Linux unstable (x86-64), Solaris 10 (SPARC) and AIX 6.1 (POWER). Can you try the following command line with the latest master source or http://www.openldap.org/its/index.cgi?findid=7284 patch? $ slappasswd -o module-load=slapd-sha2 -h '{SSHA512}' -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/
fumiyas@osstech.jp wrote: > At Mon, 11 Jun 2012 21:30:18 +0200, > Michael Ströder wrote: >>>> Do I have to tweak the Makefile? >>> >>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. >> >> I hoped that this would not be necessary and the module work include something >> detected via autoconf before. > > Can you try the following Makefile? > > https://gist.github.com/2915450 This works much better. And now the bind after Password Modify ext. op. also works! ??? Could you please submit a patch with your recent Makefile? Ciao, Michael.
Michael Ströder wrote: > fumiyas@osstech.jp wrote: >> At Mon, 11 Jun 2012 21:30:18 +0200, >> Michael Ströder wrote: >>>>> Do I have to tweak the Makefile? >>>> >>>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. >>> >>> I hoped that this would not be necessary and the module work include something >>> detected via autoconf before. >> >> Can you try the following Makefile? >> >> https://gist.github.com/2915450 > > This works much better. > > And now the bind after Password Modify ext. op. also works! > ??? And now client-hashed password generated by web2ldap also works. Strange it did not before. Ciao, Michael.
At Wed, 13 Jun 2012 09:30:03 +0200, Michael Ströder wrote: > >>> Add -fPIC to $CCFLAGS in Makefile if you are using GCC. > >> > >> I hoped that this would not be necessary and the module work include something > >> detected via autoconf before. > > > > Can you try the following Makefile? > > > > https://gist.github.com/2915450 > Could you please submit a patch with your recent Makefile? I've filed a patch to ITS: http://www.openldap.org/its/index.cgi?findid=7309 and another one: http://www.openldap.org/its/index.cgi?findid=7308 -- -- Name: SATOH Fumiyasu (fumiyas @ osstech co jp) -- Business Home: http://www.OSSTech.co.jp/ -- GitHub Home: https://GitHub.com/fumiyas/
changed notes changed state Release to Closed
added in master added in RE24