When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
I'm new to 389-ds and last week downloaded and installed the software.
I have a running instance of the server, and I've added TLS/SSL. I've configured a CentOS 7 client to be able to query
the server using TLS/SSL, and all appears working.
I've created users and groups on the 389-ds server successfully. For each user and group, I've enabled posix attributes and my client
can see the unix users and groups using the "getent password" or "getent group" commands.
Now, here's where I'm getting tripped up..........
I need to limit which users have access to which systems. I've been trying to do this via memberOf group limitations.
I found the following online resource (https://thornelabs.net/2013/01/28/aix-restrict-server-login-via-ldap-grou...)
which is close enough to CentOS that the initial commands worked.
I enabled the MemberOf plugin and changed the attributes per the link, and restarted the system.
I created a test group (that I didn't enable a posix GID) and tried to add a single user via:
Right click on group -- > click Properties --> then Members --> click Add --> Search for user --> click Add.
When I try to go this route (which worked before enabling the memberOf plugin) it worked. Now it seems I get the error:
"Cannot save to directory server.
netscape.ldap.LDAPException: error resiult(65): Object class violation"
And the messages file throws the error (/var/log/dirsrv/slapd-<instancename>/errors:
"Entry "uid=test,ou=People,dc=int,dc=com" -- attribute "memberOf" not allowed
[17/Feb/2016:11:22:58 -0700] memberof-plugin - memberof_postop_modify: failed to add dn (cn=testgroup,ou=Groups,dc=int,dc=com) to target. Error (65)"
So it seems my server isn't quite using the memberOf plugin properly, but I'm not sure what else to enable. I'll have to solve this issue before
I even try to filter login access via groups on my client system.
I should mention that if I go under the advanced tab for one of the groups I created, I can add the the attribute "uniquemember", but I'm not sure what I
should set the "value" to be.
I've tried creating new users to see if I could set their "uniquemember" attributes, but no luck. It seems that I don't have the ability to set this attribute
on individual users, only groups.
This might not be the right road to head down when trying to restrict access to servers via groups, so I'm open to any suggestions.
Any suggestions would be appreciated.
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-188.8.131.52) 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 184.108.40.206
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 220.127.116.11
* 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?