Auditing Tool for Directory Server
by Dhiraj Deshpande
Hi Guys,
Is there any auditing tool available for 389 directory server. For e.g to
fetch inactive users from last 8 days,user's last login..etc.
AdAudit does the same but works only with windows active directory which
fetches all these related information from AD.
Kindly let me know if there is any such tool which suffice this requirement.
--
Thanks & Regards
Dhiraj S. Deshpande
7 years, 10 months
Sync problems with AD 2012 R2
by Alberto Viana
I'm trying to setup a new scenario with 389 and AD 2012 R2 (So far I'm
using with AD 2008 R2 and everything works fine).
389-Directory/1.3.4.8 B2016.063.1654
Windows 2012 R2 64bits
After configure the AD replication and Initiate a full sync, it starts to
do some entries and I got the following error:
[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): windows_process_total_add:
Cannot replay add operation.
And after that:
[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Replica has no update vector.
It has never been initialized.
[16/May/2016:16:36:47 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Replica has no update vector.
It has never been initialized.
[16/May/2016:16:36:51 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - DF-GTI-DC01" (gti-df-dc01:636): Replica has no update vector.
It has never been initialized.
I found a really old ticket that seems to be related to same error:
https://fedorahosted.org/389/ticket/47589
but with win2008r2 and fixed.
According to this link ->
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10...
2012 R2 is supported, is that true?
Any clues?
7 years, 10 months
Latest version of 389 for Centos 7
by Richard Tearle
Hello
What is the latest version of 389 (-ds-base) available via RPMs for
Centos7? Yum is telling me it's 1.3.4.0-30.el7_2, which is from June
last year.
Is that correct, or have I messed up?
Thanks in advance.
--
Richard
--
This email is sent on behalf of Northgate Public Services (UK) Limited and
its associated companies including Rave Technologies (India) Pvt Limited
(together "Northgate Public Services") and is strictly confidential and
intended solely for the addressee(s).
If you are not the intended recipient of this email you must: (i) not
disclose, copy or distribute its contents to any other person nor use its
contents in any way or you may be acting unlawfully; (ii) contact
Northgate Public Services immediately on +44(0)1908 264500 quoting the name
of the sender and the addressee then delete it from your system.
Northgate Public Services has taken reasonable precautions to ensure that
no viruses are contained in this email, but does not accept any
responsibility once this email has been transmitted. You should scan
attachments (if any) for viruses.
Northgate Public Services (UK) Limited, registered in England and Wales
under number 00968498 with a registered address of Peoplebuilding 2,
Peoplebuilding Estate, Maylands Avenue, Hemel Hempstead, Hertfordshire, HP2
4NN. Rave Technologies (India) Pvt Limited, registered in India under
number 117068 with a registered address of 2nd Floor, Ballard House, Adi
Marzban Marg, Ballard Estate, Mumbai, Maharashtra, India, 400001.
7 years, 10 months
Is targetscope supported in 389ds ?
by giuseppesarno@fico.com
Hello,
I noticed that the aci filter "targetscope" is not listed under https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8....
despite I have seen it in examples for other Directory Services. I tried to use it in a ldapsearch command together with "target" but I get the following error:
MODIFY operation failed
Result Code: 21 (Invalid Attribute Syntax)
Additional Information: ACL Syntax Error(-5)
ACI example:
aci: (target="ldap:///cn=gsarno,dc=com")(targetscope="base")(version 3.0; acl "Self entry modification"; allow (read,search) userdn="........
Is targetscope supported in 389DS ? if not is there an alternative way to achieve the same functionality (apply aci to subtree or to the current node etc.) ?
Thanks,
Giuseppe.
7 years, 10 months
Solved? "LDAP Server will not perform" after DS upgrade/replica problems.
by Addison Laurent
Didn't see an answer to this problem we had, so for documentation
purposes, posting it here, in case someone else runs across it.
Configuration server was Centos 5.11, multi-master with 3 more replicas
and a Windows Sync agreement. (We're working on moving to RHDS, so this
was "frozen" in production while trying to get that project moving.)
From the yum.log when the upgrade was committed:
Apr 21 12:48:16 Updated: centos-ds-base-8.2.8-2.el5.centos.x86_64
Apr 21 12:48:18 Updated: centos-ds-admin-8.2.1-1.el5.centos.x86_64
Apr 21 12:48:18 Updated: centos-ds-console-8.2.0-4.el5.centos.noarch
Apr 21 12:48:19 Updated: centos-ds-8.2.0-2.el5.centos.x86_64
Apr 21 12:48:44 Updated: centos-ds-base-8.2.8-2.el5.centos.x86_64
Just prior to upgrade:
[21/Apr/2016:12:44:39 -0400] NSMMReplicationPlugin - Found replication
agreement named "cn=ds0 to ds1, cn=replica, cn="dc=cise, dc=ufl,
dc=edu", cn=mapping tree, cn=config".
[21/Apr/2016:12:44:39 -0400] NSMMReplicationPlugin - agmt="cn=ds0 to
ds1" (ds1:389): No linger to cancel on the connection
[21/Apr/2016:12:44:39 -0400] NSMMReplicationPlugin - agmt="cn=ds0 to
ds1" (ds1:389): Disconnected from the consumer
[21/Apr/2016:12:44:39 -0400] NSMMReplicationPlugin - agmt="cn=ds0 to
ds1" (ds1:389): State: start -> ready_to_acquire_replica
[21/Apr/2016:12:44:39 -0400] NSMMReplicationPlugin - agmt="cn=ds0 to
ds1" (ds1:389): State: ready_to_acquire_replica -> wait_for_changes
[21/Apr/2016:12:44:40 -0400] NSMMReplicationPlugin - supplier: {replica
...
And as the upgrade finished:
ds1" (ds1:389): repl5_inc_stop: protocol stopped after 1 seconds
[21/Apr/2016:12:48:44 -0400] NSMMReplicationPlugin - Found replication
agreement named "cn=ds0 to ds1,cn=replica,cn=dc\3Dcise\2C dc\3Dufl\2C dc
\3Dedu,cn=mapping tree,cn=config".
[21/Apr/2016:12:48:44 -0400] NSMMReplicationPlugin - The replication
agreement named "cn=ds0 to ds1,cn=replica,cn=dc\3Dcise\2C dc\3Dufl\2C dc
\3Dedu,cn=mapping tree,cn=config" could not be correctly parsed. No
replication will occur with this replica.
[21/Apr/2016:12:49:20 -0400] NSMMReplicationPlugin - Found replication
agreement named "cn=ds0 to ds1,cn=replica,cn=dc\3Dcise\2C dc\3Dufl\2C dc
\3Dedu,cn=mapping tree,cn=config".
[21/Apr/2016:12:49:20 -0400] NSMMReplicationPlugin - The replication
agreement named "cn=ds0 to ds1,cn=replica,cn=dc\3Dcise\2C dc\3Dufl\2C dc
\3Dedu,cn=mapping tree,cn=config" could not be correctly parsed. No
replication will occur with this replica.
[21/Apr/2016:12:50:09 -0400] NSMMReplicationPlugin - Replication
agreement for agmt="cn=ds0 to ds1" (ds1:389) could not be updated. For
replication to take place, please enable the suffix and restart the
server
[21/Apr/2016:12:50:09 -0400] NSMMReplicationPlugin - Replication
agreement for agmt="cn=ds0 to ds1" (ds1:389) could not be updated. For
replication to take place, please enable the suffix and restart the
server
What I saw in the logs that made me think this might be the problem:
[09/May/2016:16:52:10 -0400] NSMMReplicationPlugin -
replica_config_modify: replica does not exist for dc=cise,dc=ufl,dc=edu
The solution that worked was to remove the replica from all the servers,
and disable changelog on the partition.
Then renabled changelog, and re-set with multi-master (ds0/configuration
server first), I also changed the replica numbers ... just in case.
Re-initialized the replicas, and re-set up the Windows synchronization.
After that, the logs are looking normally, and replication is again
working.
Addison
7 years, 10 months
Secondary Group not listing
by warron.french
Hello all,
I am working with all CentOS-6.7 machines running 389-ds.
I had created to groups in my DIT:
1. non-XYusers, and
2. XY-auditors
I added 2 accounts to the DIT.
Account1, is a member of non-XYusers, and was manually added through the
389-console to the XY-auditors group as well.
The same is true of Account2; exact same configuration.
Anyway, when I run on a centOS-6.7 client the following commands:
*id -a Account1* (or Account2) all that I see listed is the primary Group
= non-XYusers.
*groups Account1*
Any ideas on how to correct this behavior, so that both groups are listed?
I am trying to do this so that I can enable these people to perform audit
functions.
Thanks in advance,
--------------------------
Warron French
7 years, 10 months
Announcing 389 Directory Server version 1.3.5.3
by Noriko Hosoi
389 Directory Server 1.3.5.3
The 389 Directory Server team is proud to announce 389-ds-base version
1.3.5.3.
Fedora packages are available from the Fedora 24 and Rawhide repositories.
The new packages and versions are:
* 389-ds-base-1.3.5.3-1
Source tarballs are available for download at Download 389-ds-base
Source <http://www.port389.org/binaries/389-ds-base-1.3.5.3.tar.bz2> and
Download nunc-stans Source
<http://www.port389.org/binaries/nunc-stans-0.1.8.tar.bz2>.
Highlights in 1.3.5.3
* Bug fixes and enhancements.
Installation and Upgrade
See Download <http://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* to set up your directory
server. setup-ds-admin.pl
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* to update your directory server/admin
server/console information. setup-ds-admin.pl -u
See Install_Guide
<http://www.port389.org/docs/389ds/legacy/install-guide.html> for more
information about the initial installation, setup, and upgrade
See Source <http://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
as well as
https://admin.fedoraproject.org/updates/389-ds-base-1.3.5.1-2.fc24
<https://admin.fedoraproject.org/updates/389-ds-base-1.3.5.1-2.fc24>.
If you find a bug, or would like to see a new feature, file it in our
Trac instance: https://fedorahosted.org/389
Detailed Changelog since 1.3.5.1
* Ticket 47536 - Allow usage of OpenLDAP libraries that don’t use NSS
for crypto
* Ticket 47536 - CI test: added test cases for ticket 47536
* Ticket 47840 - default instance scripts if undefined.
* Ticket 47888 - Add CI test
* Ticket 47888 - DES to AES password conversion fails if a backend
is empty
* Ticket 47951 - Fix startpid from altering dev/null
* Ticket 47968 - Disable journald logs by default
* Ticket 47982 - HR Log timers, regression fix for subsystem logging
* Ticket 48078 - CI test - paged_results - TET part
* Ticket 48144 - Add /usr/sbin/status-dirsrv script to get the status
of the directory server instance.
* Ticket 48269 - ns-accountstatus status message improvement
* Ticket 48342 - DNA: deadlock during DNA_EXTEND_EXOP_REQUEST_OID
* Ticket 48342 - DNA Deadlock test cases
* Ticket 48342 - Prevent transaction abort if a transaction has not begun
* Ticket 48350 - Integrate ASAN into our rpm build process
* Ticket 48374 - entry cache locks not released in error conditions
* Ticket 48410 - 389-ds-base - Unable to remove / unregister a DS
instance from admin server
* Ticket 48447 - with-initddir should accept no
* Ticket 48450 - Systemd password agent support
* Ticket 48492 - heap corruption at schema replication.
* Ticket 48597 - Deadlock when rebuilding the group of authorized
replication managers
* Ticket 48662 - db2index with no attribute args fail.
* Ticket 48710 - auto-dn-suffix unrecognized option
* Ticket 48769 - Fix white space in extendedop.c
* Ticket 48769 - RFE: Be_txn extended operation plugin type
* Ticket 48770 - Improve extended op plugin handling
* Ticket 48775 - If nsSSL3 is on, even if SSL v3 is not really
enabled, a confusing message is logged.
* Ticket 48779 - Remove startpidfile check in start-dirsrv
* Ticket 48781 - Vague error message: setup_ol_tls_conn - failed:
unable to create new TLS context
* Ticket 48782 - Make sure that when LDAP_OPT_X_TLS_NEWCTX is set, the
value is set to zero.
* Ticket 48783 - Fix ns-accountstatus.pl syntax error
* Ticket 48784 - CI test: added test cases for ticket 48784
* Ticket 48784 - Make the SSL version set to the client
library configurable.
* Ticket 48798 - Enable DS to offer weaker DH params in NSS
* Ticket 48799 - objectclass values could be dropped on the consumer
* Ticket 48800 - Cleaning up error buffers
* Ticket 48801 - ASAN errors during tests
* Ticket 48802 - Compilation warnings from clang
* Ticket 48808 - Add test case
* Ticket 48808 - Paged results search returns the blank list of entries
* Ticket 48813 - password history is not updated when an admin resets
the password
* Ticket 48815 - ns-accountstatus.sh does handle DN’s with single quotes
* Ticket 48818 - In docker, no one can hear your process hang.
* Ticket 48822 - (389-ds-base-1.3.5) Fixing coverity issues.
* Ticket 48824 - Cleanup rpm.mk and 389 specfile
7 years, 10 months