One supplier; two consumers : how to enable replication of Account Lockout policy attributes?
by Jon Detert
I want the account lockout policy of all 3 servers to be the same, and the account lockout status of a given bind-dn to be the same across all 3.
I made the config shown below, but when I locked an account via purposely failed bind attempts to one of the consumers, neither the supplier nor the other consumer got informed that the account was locked. Any ideas?
Thanks
The config:
====================
I ran this on the supplier and both consumers:
ldapmodify -h localhost -cax -D "cn=directory manager" -y ~/pword <<BYE
dn: cn=config
changetype: modify
add: passwordLockout
passwordLockout: on
-
add: passwordUnlock
passwordUnlock: on
-
add: passwordMaxFailure
passwordMaxFailure: 20
-
add: passwordLockoutDuration
passwordLockoutDuration: 3600
-
add: passwordResetFailureCount
passwordResetFailureCount: 600
BYE
And this on each of the 2 consumers:
ldapmodify -h localhost -D cn="Directory Manager" -y ~/pword <<BYE
dn: cn=config
changetype: modify
replace: passwordIsGlobalPolicy
passwordIsGlobalPolicy: on
BYE
--
Jon Detert
Sr. Systems Administrator
Infinity Healthcare
Milwaukee, Wisconsin
9 years, 3 months
Problem with replication 1.2.5 to 1.2.11.25
by Tomasz Lesniewski
Hi.
I'm preparing to upgrade LDAP from 1.2.5 to 1.2.11.25 (both on CentOS)
and i have a weird problem. Firstly for tests i want to set replication
from my current master (1.2.5, single master) to new instance on
1.2.11.25 (dedicated consumer). So i made replication agreement and
everything works fine, unless i want to delete something from master. On
replica in error log appears:
entryrdn-index - _entryrdn_delete_key: Failed to remove ou=users; has
children
- database index operation failed BAD 1031, err=-1 Unknown error: -1
After a little investigation i know:
1. It's a problem when i'm trying to delete entry (dn:
uid=test,dc=foo,dc=pl,o=company) which contains subentry with
objectClass posixAccount (i don't know it even matter), ex:
dn: uid=test,dc=foo,dc=pl,o=company
dn: ou=users,uid=test,dc=foo,dc=pl,o=company
dn: uid=test__cms2,ou=users,uid=test,dc=foo,dc=pl,o=company
2. On master entry is successfully deleted, but not on replica (as error
log says it has children)
3. On replica there are left some entry which i cannot delete (with
error code 10 - Referral)
dn: uid=test,dc=foo,dc=pl,o=company
dn: ou=users,uid=test,dc=foo,dc=pl,o=company
or:
3: On replica there is only entry dn: uid=test,dc=foo,dc=pl,o=company,
but when i search entries wiht parentId set as entryId of uid=test i
found ou=users below that entry (which i can't see by ldapsearch or
ApacheDS).
So, my question am i doing something wrong or it's not possible to set
replication between this 389-ds versions (maybe it's to old/new). It's
really possible to upgrade LDAP accross this versions without any magic
or/and possibility of losing data? What i should check or change to make
this works? What other information should i provide? Any idea?
--
Pozdrawiam/Best regards
Tomasz Leśniewski
9 years, 3 months
replication stopped after server restart - problem to reenable
by Jan Kowalsky
Hi all,
this is my first post on the list. I'm using 389ds inside a kolab
environment. We are going to migrate to the new kolab version which runs
now 389ds. At the moment we are testing different scenarios for
replication. I don't have much experience with ldap and particular with
389ds.
I've got a single-master replication with one supplier (ldapmaster1) and
one consumer (ldapmaster2)
After server restart replication isn't working anymore. The error-log:
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - Found replication
agreement named "cn=test
replica,cn=replica,cn=dc\3Ddatenkollektiv\2Cdc\3Dnet,cn=mapping
tree,cn=config".
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - The replication
agreement named "cn=test
replica,cn=replica,cn=dc\3Ddatenkollektiv\2Cdc\3Dnet,cn=mapping
tree,cn=config" could not be correctly parsed. No replication will occur
with this replica.
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin -
agmtlist_config_init: found 0 replication agreements in DIT
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin - changelog program -
_cl5GetDBFile: found DB object 1d9bbf0 for database
/var/lib/dirsrv/slapd-ldapmaster
1/changelogdb/bbd31b03-93cd11e3-8fe4ea88-51d1475b_52fb486f000000070000.db4
[12/Feb/2014:12:04:51 +0100] - _csngen_adjust_local_time: gen state
before 52fb486f0001:1392199791:0:0
[12/Feb/2014:12:04:51 +0100] - _csngen_adjust_local_time: gen state
after 52fb55530000:1392203091:0:0
[12/Feb/2014:12:04:51 +0100] NSMMReplicationPlugin -
ruv_add_csn_inprogress: successfully inserted csn 52fb5553000000070000
into pending list
[12/Feb/2014:12:04:52 +0100] NSMMReplicationPlugin - Purged state
information from entry dc=datenkollektiv,dc=net up to CSN
52f2180c000000070000
[12/Feb/2014:12:04:52 +0100] NSMMReplicationPlugin -
csn=52fb5553000000070000 process postop: canceling operation csn
[12/Feb/2014:12:04:52 +0100] - slapd started. Listening on All
Interfaces port 389 for LDAP requests
[12/Feb/2014:12:04:53 +0100] NSMMReplicationPlugin -
_replica_update_state: failed to update state of csn generator for
replica dc=example,dc=org: LDAP error - 32
[12/Feb/2014:12:05:36 +0100] - _csngen_adjust_local_time: gen state
before 52fb55530001:1392203091:0:0
[12/Feb/2014:12:05:36 +0100] - _csngen_adjust_local_time: gen state
after 52fb55800000:1392203136:0:0
[12/Feb/2014:12:05:37 +0100] NSMMReplicationPlugin -
ruv_add_csn_inprogress: successfully inserted csn 52fb5580000000070000
into pending list
[12/Feb/2014:12:05:37 +0100] NSMMReplicationPlugin - Purged state
information from entry uid=kolab-service,ou=Special
Users,dc=datenkollektiv,dc=net up to CSN 52f2180c000000070000
[12/Feb/2014:12:05:37 +0100] - Error: ldbm_txn_ruv_modify_context failed
to retrieve and lock RUV entry
[12/Feb/2014:12:05:37 +0100] - ldbm_back_modify:
ldbm_txn_ruv_modify_context failed to construct RUV modify context
[12/Feb/2014:12:05:37 +0100] NSMMReplicationPlugin -
csn=52fb5580000000070000 process postop: canceling operation csn
[12/Feb/2014:12:05:37 +0100] - _csngen_adjust_local_time: gen state
before 52fb55800001:1392203136:0:0
[12/Feb/2014:12:05:37 +0100] - _csngen_adjust_local_time: gen state
after 52fb55810000:1392203137:0:0
[12/Feb/2014:12:05:37 +0100] NSMMReplicationPlugin -
ruv_add_csn_inprogress: successfully inserted csn 52fb5581000000070000
into pending list
[12/Feb/2014:12:05:37 +0100] NSMMReplicationPlugin - Purged state
information from entry uid=kolab-service,ou=Special
Users,dc=datenkollektiv,dc=net up to CSN 52f2180c000000070000
Also disable and reenable replication doesn't help.
dn: cn=test replica,cn=replica,cn=dc\=datenkollektiv\,dc\=net,cn=mapping
tree,cn=config
changetype: modify
add: nsds5ReplicaEnabled
nsds5ReplicaEnabled: on
dn: cn=test replica,cn=replica,cn=dc\=datenkollektiv\,dc\=net,cn=mapping
tree,cn=config
changetype: modify
replace:nsds5ReplicaUpdateSchedule
nsds5ReplicaUpdateSchedule: 0000-2359 0123456
dn: cn=test replica,cn=replica,cn=dc\=datenkollektiv\,dc\=net,cn=mapping
tree,cn=config
changetype: modify
replace: nsds5BeginReplicaRefresh
nsds5BeginReplicaRefresh: start
then I get the errors:
[12/Feb/2014:12:06:02 +0100] NSMMReplicationPlugin - Total update
aborted: Replication agreement for "agmt="cn=test replica"
(ldapmaster2:389)" can not be updated while the replica is disabled
[12/Feb/2014:12:06:02 +0100] NSMMReplicationPlugin - (If the suffix is
disabled you must enable it then restart the server for replication to
take place).
Is that the right procedure at all?
Any idea?
Thanks and best regards
Jan
9 years, 3 months
Setting up sub-suffix on 1.2.11.15-31 (CentOS 6.5)
by Brian Epstein
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello 389-users,
I recently setup two new 389-ds servers in a multi-master replicated
pair. I am only replicating the userRoot database at this time.
Everything is working well, SSL is setup, replication is working on
both nodes.
I'm using CentOS 6.5 with the EPEL packages, everything is up to date.
I would like this new multi-master pair to start being a read-only
consumer for a few other ldap servers in our environment. Here is the
tree breakdown.
dc=ias,dc=edu (multi-master pair)
dc=math,dc=ias,dc=edu (separate ldap server)
dc=sns,dc=ias,dc=edu (separate ldap server)
dc=itg,dc=ias,dc=edu (separate ldap server)
dc=net,dc=ias,dc=edu (separate ldap server)
If I'm reading things correctly, I need to have a separate database
for each of the sub domains in order to setup a new replication agreement.
So, I load up the Directory Server Console, navigate to Configuration
- -> Data and right click on the suffix dc=ias,dc=edu. I select "New
Sub Suffix" and fill it out. For example, I'll put in "dc=math" for
the New Suffix, and create an associate database automatically and
name it "math".
One thing to note, the suffix dc=ias,dc=edu displays as
"dc\3Dias\2Cdc\3Dedu". I'm guessing that the hex encoding isn't a big
deal, but just in case....
When I click "OK", I'm greeted with the following error.
Undefined resource: mappingtree-error-add-mapping-msg.
The suffix could not be created.
I must be missing something, although my Google-fu has been lacking
on finding the answer. Am I headed down the right path for what I
want to do?
Thanks for your help,
Brian
- --
Brian Epstein <bepstein(a)ias.edu> +1 609-734-8179
Manager, Network and Security Institute for Advanced Study
Key fingerprint = 128A 38F4 4CFA 5EDB 99CE 4734 6117 4C25 0371 C12A
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMD1i8ACgkQYRdMJQNxwSp+dgCgqFP23lZ9WQ9PXKzb/yFMFa2U
shkAn3k/AIVa7POu5MRbk9fQROS8Psu2
=B3yV
-----END PGP SIGNATURE-----
9 years, 3 months
How to specify number of hashing iterations for a password
by Richard Mixon
During the bind process is there anyway to tell 389 directory server to
hash a plaintext password n (multiple) times before trying to compare to
what is stored?
I am trying to implement something similar to what's described in this
article:
http://www.stormpath.com/blog/strong-password-hashing-apache-shiro
Our plan was to to use SSHA256 to hash the passwords around 200,000 times
before storing. This would at least slow down any cracking attempts should
someone get access to our directory.
I've read through the documentation on the Red Hat Directory Server site,
including the "Plug-in Guide". Under "5.8 Checking Passwords" it refers to
calling function "slapi_pw_find_sv()" - looking at the doc for this
function it does not look like hashing multiple times is supported.
Is there some means of doing this that is not obvious to me?
I can certainly do it by re-writing the security plugins for the various
servers (Tomcat, PHP Wordpress, etc) such that they hash the plaintext
password n minus 1 times before issuing the bind - but was hoping not to do
that.
I'm relatively new to 389 directory server, but so far quite happy to have
moved to it from another directory server.
Thank you - Richard
--
Richard Mixon
Custom Computer Creations, L.L.C.
mobile: (480) 577-6834 office: (480) 614-3442
email: rnmixon(a)CustCo.biz <mailto:rnmixon@CustCo.biz>
Microsoft Partner ID: 1263725
The messages and documents transmitted with this notice contain
confidential information belonging to the sender. If you are not the
intended recipient of this information, you are hereby notified that any
disclosure, copying, distribution or use of the information is strictly
prohibited. If you have received this transmission in error, please notify
the sender immediately.
9 years, 3 months
ACI to permit user create his own subentry?
by Jan Tomasek
Hello,
I need user to be able to add subentry bellow his own entry.
In this structure:
dc=cz
ou=People
uid=test1
dc=123 ??
uid=test2
How to write ACI that test1 could add only under his own entry? Sadly
(target = "ldap:///self") is not permited.
Any idea how to write ACI at level of ou=People?
--
-----------------------
Jan Tomasek aka Semik
http://www.tomasek.cz/
9 years, 3 months
paged results on large results sets and memory
by Michael Gettes
I did some searching to try and answer the following question and the answer is not apparent to me.
I have a directory with hundreds of thousands of entries. I have an app which, due to its behavior, needs to
be able to search for very large sets of users but I don’t want it to be able to get ALL users and therefore exhaust
all memory on the ldap server.
If the app performs a search on uid=* and the it’s a paged search, does this have a positive impact on how
memory is used to handle the results so it doesn’t exhaust all memory?
I’m trying to keep the scenario simple so I hope you appreciate the question I am getting at.
thanks!
/mrg
9 years, 3 months
Searches Hang - Apparently entryrdn index related
by Timothy Pollard
Hi,
After our LDAP instance has been running for a while large LDAP searches in
our userRoot start hanging. This appears to be caused by the entryrdn index
becoming corrupt since it can be fixed by regenerating the entryrdn index.
To give an example of a command that fails:
ldapsearch -x -b "dc=ourorg,dc=com" -h localhost -D "cn=directory manager" -w
removed objectclass=posixAccount > /dev/shm/ldap_search_output
This hangs after reading a large number of entries. The number of entries
change each time, but I believe it may be actually failing on the same specific
entry each time, and just reading them in a different order.
This can be fixed by stopping ns-slapdand
moving /var/lib/dirsrv/slapd-ldap-04/db/userRoot/entryrdn.db4 out of the way
before running `./db2index -n userRoot -t entryrdn`, but it will then reoccur
after a hour or two or so.
Our system:
$ cat /etc/redhat-release
CentOS release 6.5 (Final)
$ uname -r
2.6.32-431.3.1.el6.x86_64
$ rpm -q 389-ds
389-ds-1.2.2-1.el6.noarch
In case they're helpful I have stack traces from during both failed and
successful searches. I can send them through if they are useful.
Does anyone have any idea what might be causing this, or how we could go about
fixing it? Should we report it as a bug?
Thank you,
--
TimP
[http://blog.timp.com.au]
9 years, 3 months
replication error
by Elizabeth Jones
Hi - I have just encountered a replication error on our 389DS. We are
running Version 1.2.10.12 Build number 2012.180.1623. We had the
following error earlier today from our ldap1 server (running multimaster)
-
07/Feb/2014:13:06:52 -0600] NSMMReplicationPlugin - changelog program -
agmt="cn=ldap replication txdc2" (ldap2-prod:389): CSN
51001020000800030000 not found, we aren't as up to date, or we purged
[07/Feb/2014:13:06:52 -0600] NSMMReplicationPlugin - agmt="cn=ldap
replication ldap2" (ldap2-prod:389): Data required to update replica has
been purged. The replica must be reinitialized.
[07/Feb/2014:13:06:52 -0600] NSMMReplicationPlugin - agmt="cn=ldap
replication ldap2" (ldap2-prod:389): Incremental update failed and
requires administrator action
I tried deleting the sections that we are replicating in ldap2 but ldap2
would not delete everything, it throws this error "operation not allowed
on nonleaf".
Also tried exporting from the master and importing into ldap2 and it won't
let me import the database or import an ldif.
Anyone have any ideas on where to go from here?
thanks,
Elizabeth J
9 years, 4 months