> Using password policy overlay, pwdMinLength is not checked when pwdInHistory ==
I tried to reproduce this with my local OpenLDAP 2.4.41 installation.
In one case I thought to see this but I could not reproduce all the time.
Maybe there's another condition for this to happen.
Could you please also test with release 2.4.41?
And please also post the entry with the password (and relevant pwd* attrs) and
the pwdPolicy entry used, both as LDIF (minus sensitive data).
> When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name
> doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the
> reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by
> kerberos then kerberos will fail.
Did you already try with -N?
$ ldapsearch -h
-N do not use reverse DNS to canonicalize SASL host name
Full_Name: Ian Bishop
Submission from: (NULL) (2001:388:e001:ce00:f2de:f1ff:fea7:d755)
Using password policy overlay, pwdMinLength is not checked when pwdInHistory ==
I tested this by setting pwdMinLength=6 and pwdInHistory=0. I was then able to
set a 3 character password. When I changed pwdInHistory > 0 and tried to set a 3
charactepapassword, the attempt was denied. I repeated this several times, and
also restarted slapd just in case - same result.
Running Openldap 2.4.39 on Centos7, installed from Centos RPM repo.
Full_Name: Calvin Winkowski
Submission from: (NULL) (2001:468:c80:a202:3b1d:f567:f43c:7b3a)
When using ldapsearch GSSAPI mechanism with a server whose reverse DNS name
doesn't match its DNS name, ldapsearch will do the DNS lookups and hand the
reverse DNS entry to GSSAPI. If the reverse DNS entry is not what is used by
kerberos then kerberos will fail. There are settings in /etc/krb5.conf to
disable canonicalizing the hostname provided.
I have a server with a record example.ad.example.com whose PTR record is
example.example.com, but the realm is ad.example.com and it's entry in the
kerberos database is example.ad.example.com, not example.example.com.
If I execute the command ``ldapsearch -b "" -s base -Y GSSAPI -D "dn" -H
ldap://example.ad.example.com'' GSSAPI will submit a ticket request for
example.example.com instead and result in a failure. All other services I've
tested with this setup (disabling reverse dns in kerberos) do not give the PTR
record, but the user provided hostname. These include mbsync, msmtp, and another
ldap utility. I believe that the correct behaviour should be to provide the
hostname provided to the utility to GSSAPI. I can provide packet captures
illustrating the incorrect lookup if needed.
Full_Name: Sergio Gelato
Submission from: (NULL) (22.214.171.124)
As currently implemented (since ITS#7027,
5de85b922aaa5bfa6eb53db6000adf01ebdb0736) the algorithm to shuffle DNS SRV
records of a given priority according to their weights is flawed: if all records
have the same weight, the implementation is biased towards the first record and
against the last. In the most extreme case of two records of weight 1, the
current implementation will never swap them (whereas one would have hoped for a
swap 50% of the time). The problem can be cured by changing (r <= 0) to (r < 0).
(The wording of the RFC may have contributed to this error; I suspect it was
written with real random deviates in mind, not integer ones. In any event, the
principle that records of equal weight should have the same probability of being
picked trumps the RFC since the latter only says what algorithm SHOULD be
I've written and tested a patch for this and found it to solve the above
problem. My patch also addresses another (operationally minor, which is why I'm
not reporting it separately) issue in the same piece of code: what if at least
two, but not all, of the records of a given priority have weight zero? One
should be prepared to switch to a Fisher-Yates shuffle if "total" becomes zero
during the iteration.
(Yet another potential issue is overflow of "total" on platforms where
INT_MAX==32767 if the sum of the weights exceeds that value. Consider declaring
it uint32_t or u_long.)
Full_Name: Howard Chu
Submission from: (NULL) (126.96.36.199)
Submitted by: hyc
The fix in ITS#8036 only corrects the situation for candidate-based searches,
not for scope-based searches. In scope-based searches the "fix" treats the
scopes array incorrectly and can overwrite the heap. A new fix is coming
On 22. juli 2015 17:54, Howard Chu wrote:
> h.b.furuseth(a)usit.uio.no wrote:
>> If we require C99 library features like this, then I
>> think we should add a configure test for them. Strange
>> breakage at runtime is rather worse than a failed build.
>> (That's not the same as testing for a C99 compiler, since
>> one can have a C99 compiler like gcc with a C90 library.)
> The fewer configure tests we need, the better. Happy to replace %zu with %llu
> and forget about it. It's not worth a fuss.
Right. Looks like it should be %ld and (long) though,
we don't use long long either except inside HAVE_LONG_LONG etc
> If we require C99 library features like this, then I
> think we should add a configure test for them. Strange
> breakage at runtime is rather worse than a failed build.
> (That's not the same as testing for a C99 compiler, since
> one can have a C99 compiler like gcc with a C90 library.)
The fewer configure tests we need, the better. Happy to replace %zu with %llu
and forget about it. It's not worth a fuss.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Yes I'm well aware of the state of Solaris 9 support and we support key components
of the OS ourselves. However that doesn't mean
that people don't still run it, like we do on some systems yet to be upgraded.
(yes we have Sun systems purchased over 15 years ago that are still happily running;
the hardware is very reliable; many are well overdue for upgrade though; its a resource/priority thing
just look at how many people are running WinXP still)
However this issue is a portability of openldap issue, not a OS support/patch thing (the C library in this case is not
broken; its doing as the man page says, which doesn't mention %z), and the %z support is only
a recent thing in the lifetime of unix (well last ~15 years it started to appear... C99 I think)
There will be other legacy OS's that don't support %z too; no idea what ones though.
Anyway I've got an (ugly) patch for me to use now and it passes 'make check' on Solaris 9;
it was hard to find the cause of the problem though.
On 07/22/15 04:01, Howard Chu wrote:
> Howard Chu wrote:
>> iand(a)ekit-inc.com wrote:
>>> Full_Name: Ian Donaldson
>>> Version: 2.4.41
>>> OS: Solaris 9
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (188.8.131.52)
>>> Built 2.4.41 on Solaris 9; ran 'make check' which failed to start slapd with
>>> the following errors:
>> Thanks for the report. Not sure that it's worth our taking any action though.
>> The last release of Solaris 9 was 10 years ago, and it has been end-of-life'd
>> by Oracle.
> For reference: Solaris 9 EOL
> In short it means Solaris 9 is no longer eligible for any Oracle updates including security updates, fixes, patches or any other changes. Solaris 9 went into sustaining support in October 2014.
> Since Oracle is no longer providing any patches for this OS, I don't see much reason for us to either. Fortunately you are free to patch and build OpenLDAP for yourself for as long as you wish.