I've been looking through the archives for information, but I haven't stumbled on a solution to my problem.
I'm running ds-389 (389-ds-base-18.104.22.168) on a centos 7 box (CentOS Linux release 7.2.1511). I have a centos OS client configured using SSL/TLS
which queries the LDAP server. Per a previous thread, I configured the memeberOf plugin and all seems to be working properly.
I have a php script that will run on the client and change the LDAP password for the user. The problem is, the script looks for the SSHA has
of the password when an ldapsearch is issued.
However, when I issue a general ldapsearch (anonymously) I don't get the userpassword field. I read in your archives that I might have
to be the "directory manager" user in order to see the hashed password. I've been playing around with the ldapsearch syntax, but I can't
quite get it right.
Anyway, my question is, can I set a flag in 389-ds that will display the hashed userpassword? I think that will solve my problem with the php script returning an error that it can't retrieve the old password.
I'll admit up front that comparatively speaking, this is a tiny, tiny, tiny little environment, only a few hundred users in the directory service.
We have a 60 day password expiration requirement. Users range from nerdy infrastructure types to Windows developers to business users.
Is anybody using an httpd (Apache2) based self-service password reset tool?
I've been looking at the LTB self-service password reset application(http://ltb-project.org/wiki/documentation/self-service-passwo.... I can probably get it to work for me, but I'm also looking at some fairly non-trivial modifications, I suspect.
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
does anyone have an idea what would be the best way to retroactivaley
generate performance metrics using the logfiles?
I would like to be able to check for example if in a certain time range
there were binds or searches that took longer than usual.
389 Directory Server 22.214.171.124
The 389 Directory Server team is proud to announce 389-ds-base
Fedora packages are available from the Fedora 24, 25 and
The new packages and versions are:
Source tarballs are available for download at Download 389-ds-base
and Download nunc-stans Source
Highlights in 126.96.36.199
* A security bug fix and lots of 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
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
<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.
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
as well as
If you find a bug, or would like to see a new feature, file it in our
Trac instance: https://fedorahosted.org/389
- Ticket 48992 - Total init may fail if the pushed schema is rejected
- Ticket 48832 - Fix CI test suite for password min age
- Ticket 48983 - Configure and Makefile.in from new default paths work.
- Ticket 48983 - Configure and Makefile.in from new default paths work.
- Ticket 48983 - generate install path info from autotools scripts -
Ticket 48944 - on a read only replica invalid state info can accumulate
- Ticket 48766 - use a consumer maxcsn only as anchor if supplier is
- Ticket 48921 - CI Replication stress tests have limits set too low
- Ticket 48969 - nsslapd-auditfaillog always has an explicit path
- Ticket 48957 - Update repl-monitor to handle new status messages
- Ticket 48832 - Fix CI tests
- Ticket 48975 - Disabling CLEAR password storage scheme will crash
server when setting a password
- Ticket 48369 - Add CI test suite
- Ticket 48970 - Serverside sorting crashes the server
- Ticket 48972 - remove old pwp code that adds/removes ACIs
- Ticket 48957 - set proper update status to replication agreement in
case of failure
- Ticket 48950 - Add systemd warning to the LD_PRELOAD example
- provide backend dir in suffix template
- Ticket 48953 - Skip labelling and unlabelling ports during the test
- Ticket 48967 - Add CI test and refactor test suite
- Ticket 48967 - passwordMinAge attribute doesn’t limit the minimum age
of the password
- Fix jenkins warnings about unused vars
- Ticket 48402 - v3 allow plugins to detect a restore or import
- Ticket #48969 - nsslapd-auditfaillog always has an explicit path
- Ticket 48964 - cleanAllRUV changelog purging incorrectly processes
- Ticket 48965 - Fix building rpms using rpm.mk
- Ticket 48965 - Fix generation of the pre-release version
- Bugzilla 1368956 - man page of ns-accountstatus.pl shows redundant
entries for -p port option
- Ticket 48960 - Crash in import_wait_for_space_in_fifo().
- Ticket 48832 - Fix more CI test failures
- Ticket 48958 - Audit fail log doesn’t work if audit log disabled.
- Ticket 48956 - ns-accountstatus.pl showing “activated” user even if it
- Ticket 48954 - replication fails because anchorcsn cannot be found
- Ticket 48832 - Fix CI tests failures from jenkins server
- Ticket 48950 - Change example in /etc/sysconfig/dirsrv to use tcmalloc
I'm trying to implement password expiration policy with no sucess, I've
changed my config:
But after that I'm still able to bind with my(or any) user in 389.
Am I missing something? Also, what attribute 389 uses to control that? I
could not see any attribute in my user related to that.
All changes were based on this doc:
Could anyone knowledgeable be so kind as to inform me of the current status of 389's REST API?
1. Is it functional, stable ?
2. What can be done with it currently?
3. To what extent does the 389 server need to be configured before the REST API can be utilized?
Im looking for ways to pull a number of audit events from 389. Such as:
-User authentication success and failures.
-Group additions, removals and changes.
-User additions, removals and possibly changes.
Details in each of these would include items such as:
timestamp of event
Sending these out via syslog formatted messages is the preferred route.
I have not been able to find anything definitive in how to do this. Debug
logs seem to lack much of this or contain far too much information making
the prohibitive to use. They are also formatted in such a way making it
extremely difficult to process in any practical way. For example, you would
probably need a full LDIF interpreter to reformat them on the fly. I assume
I either have not dug far enough or simply digging in the wrong direction.
Is anyone out there doing something similar and pulling the above data into
a SIEM? If so would you be willing to share your experience on the topic or
point me in the right direction?
Thank you for reply! The Sysadmin here was able to build and compile the 389-DS 188.8.131.52 on rhel6-scientific linux 6, we have 3 other hosts with same cfg running fine, I am seeing this issues after we had to re-image this host , re-install the 389-ds packages from puppet we have , I am unable to rebuild the 389-DS now , any tips were to look for ?