Forbidden account password reuse of the last 5 password

[Tian Zhiying]

Hi 

Is there a feature that OpenLDAP password policy can forbidden user password 
reuse of the last 5 password?

Thanks.

Re: help with mdb database recovery after crash

[Howard Chu]

Andrei Mikhailovsky wrote:
> Hi Howard,
> 
> 
>>
>> You could try using the preceding transaction and see if it's in any better
>> shape. The code
>> for this is not released in LMDB 0.9. You can compile the mdb.master branch 
>> in
>> git to obtain
>> it. Then use the "-v" option with mdb_copy and see if that copy of the 
>> database
>> is usable.
>>
> 
> I have compiled liblmdb using the mdb.master branch and used the mdb_copy as 
> you've suggested. It didn't produce any errors. However, when I copy the 
> data.mdb back to the Zimbra server it still produces the same error:
> 
> Feb 13 18:30:03 mail-archive slapd[8830]: mdb_entry_decode: attribute index 
> 560427631 not recognized

Then unfortunately you just have bogus attribute data in the DB. Seems unlikely 
that you'll be able
to sort this out, it may actually be a disk media failure.

> 
> and when I am trying to reindex I get:
> 
> zimbra@mail-archive:~/data/ldap/mdb/db$ /opt/zimbra/libexec/zmslapindex -vv
> indexing id=0001
> indexing id=0002
> indexing id=0003
> 5c64631c mdb_entry_decode: attribute index 560427631 not recognized
> /opt/zimbra/libexec/zmslapindex: line 67: 11205 Segmentation fault  (core 
> dumped) /opt/zimbra/common/sbin/slapindex -q -F /opt/zimbra/data/ldap/config 
> -b "" $KEY
> 
> 
> 
> My broken ldap data folder contains the following files:
> 
> zimbra@mail-archive:~/data/ldap/mdb/db$ ls -la 
> /opt/zimbra/RECOVERY/ldap-original/mdb/db/
> total 83886096
> drwxr-xr-x 1 zimbra zimbra  60 Feb  4 12:12 .
> drwxr-xr-x 1 zimbra zimbra   4 Sep  7 10:37 ..
> -rw--- 1 zimbra zimbra 85899345920 Feb  4 10:38 data.mdb
> -rw--- 1 zimbra zimbra8192 Feb  6 17:37 lock.mdb
> -rw-r- 1 root   root  10485759 Feb  4 12:12 log.01
> 
> 
> I can see there is the log file log.01. I don't know how do I check 
> or roll back data using this log file? I haven't managed to find anything 
> useful by googling. Any idea?

LMDB doesn't use log files. Apparently you've let some other software overwrite 
your database.

> Cheers
> 
> 
> 
>> --
>>  -- 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
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: help with mdb database recovery after crash

[Quanah Gibson-Mount]

--On Wednesday, February 13, 2019 6:37 PM + Andrei Mikhailovsky 
 wrote:



Hi Howard,




You could try using the preceding transaction and see if it's in any
better shape. The code
for this is not released in LMDB 0.9. You can compile the mdb.master
branch in git to obtain
it. Then use the "-v" option with mdb_copy and see if that copy of the
database is usable.



I have compiled liblmdb using the mdb.master branch and used the mdb_copy
as you've suggested. It didn't produce any errors. However, when I copy
the data.mdb back to the Zimbra server it still produces the same error:


Did you use mdb_copy with the -v flag as Howard noted?  It is helpful to be 
precise about exactly what steps you took.


--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:

Re: help with mdb database recovery after crash

[Andrei Mikhailovsky]

Hi Howard,


> 
> You could try using the preceding transaction and see if it's in any better
> shape. The code
> for this is not released in LMDB 0.9. You can compile the mdb.master branch in
> git to obtain
> it. Then use the "-v" option with mdb_copy and see if that copy of the 
> database
> is usable.
> 

I have compiled liblmdb using the mdb.master branch and used the mdb_copy as 
you've suggested. It didn't produce any errors. However, when I copy the 
data.mdb back to the Zimbra server it still produces the same error:

Feb 13 18:30:03 mail-archive slapd[8830]: mdb_entry_decode: attribute index 
560427631 not recognized

and when I am trying to reindex I get:

zimbra@mail-archive:~/data/ldap/mdb/db$ /opt/zimbra/libexec/zmslapindex -vv
indexing id=0001
indexing id=0002
indexing id=0003
5c64631c mdb_entry_decode: attribute index 560427631 not recognized
/opt/zimbra/libexec/zmslapindex: line 67: 11205 Segmentation fault  (core 
dumped) /opt/zimbra/common/sbin/slapindex -q -F /opt/zimbra/data/ldap/config -b 
"" $KEY



My broken ldap data folder contains the following files:

zimbra@mail-archive:~/data/ldap/mdb/db$ ls -la 
/opt/zimbra/RECOVERY/ldap-original/mdb/db/
total 83886096
drwxr-xr-x 1 zimbra zimbra  60 Feb  4 12:12 .
drwxr-xr-x 1 zimbra zimbra   4 Sep  7 10:37 ..
-rw--- 1 zimbra zimbra 85899345920 Feb  4 10:38 data.mdb
-rw--- 1 zimbra zimbra8192 Feb  6 17:37 lock.mdb
-rw-r- 1 root   root  10485759 Feb  4 12:12 log.01


I can see there is the log file log.01. I don't know how do I check or 
roll back data using this log file? I haven't managed to find anything useful 
by googling. Any idea?

Cheers



> --
>  -- Howard Chu
>  CTO, Symas Corp.   http://www.symas.com
>  Director, Highland Sun http://highlandsun.com/hyc/
>   Chief Architect, OpenLDAP  http://www.openldap.org/project/

help needed for further investigation

[Thomas.Meller]

Hello together. I am the heir of a setup based on RHEL 6.10 and Openldap 2.4.45 
(ltb)
A master syncrepls to a slave in type=refreshOnly using bindmethod=sasl, 
saslmech=external.

The mapped techuser resides in ou=ServiceUser. All Clients also use user 
objects in the same ou to bind to the servers.

I need to set new acls and decided to include a dedicated acl- and 
limits-configfile. The ACLs checked via slapacl look fine and run without 
problems on the test environment. (Which is based on the same 2.4.45 rpms, but 
the replica runs on RHEL 7.5)

All slapd configuration make use of database mdb and an explicitly set maxsize. 
(which is sized sufficiently: 12 GB, 49 MB used)

When implementing the configuration on a running system, the replica deletes 
the ou (that one with all the service user objects).
Which is not what I want 
8-/

How can I find out more about the reason for this peculiar result?
I set the loglevel to 'stats sync' on the replica and 'sync' on the master. (fs 
size is limited for logs)
The access limits are in place for this replication account and read access is 
granted as well. (might be I need to set something extra for operational 
attributes?)
limits dn.subtree="ou=ServiceUser,..."
size=unlimited
(this is the replica)
sizelimit unlimited
timelimit 10
and
limits dn.subtree="ou=ServiceUser,..."
size=unlimited
time=120
(in this order, this is the master)
What do I need to look at to find what's missing? I am no openldap crack, but 
no newbie as well. Yet my openldap knowledge ist not very extended.

Which further infos do I need to supply to maybe get help?

The include statements for limits and acls are defined before the database 
configuration.
I avoid using dynamic configuration to keep it all simple.

Overlays in use:
chain
dynlist
valsort
memberof
ppolicy
(replica)

syncprov
ppolicy
unique
dynlist
memberof
refint
valsort
(master)

Thank you,
Thomas

Re: slapd memory usage

[Howard Chu]

Zev Weiss wrote:
> On Tue, Feb 12, 2019 at 06:09:36AM CST, Howard Chu wrote:
>> It's not tying up a bunch of memory. It's using up some address space, but 
>> if it is indeed
>> unused, the OS will not dedicate any actual RAM to that address space.
>>
> 
> Andreas's initial message showed a pretty large difference in top's RES 
> column -- wouldn't that indicate that that virtual address space is in fact 
> backed by
> actual allocated physical pages?

It also showed that there was still 140MB free RAM out of a total of 390MB.
There was no memory pressure to cause the OS to reclaim those pages.

Look at the big picture, not just a single detail.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/