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.
We have the following setup.
Active Directory Server in US.
389 DS Server in Italy.
We are able to access the Active Directory Server from 389 DS.
We installed the sync agreement. No body is touching the AD, the number of
objects that should copied is 21. But every time we are running the
replication agreement, the number of objects being copied is always
different. How can that be if there is no change happening at the AD
Is the replication done over UDP or TCP.
Also is it because of distance and delay that is causing the
If some can elaborate in this issue, it would be really helpful.
Specifically, I'm referring to the two incompatible schemas for rfc2307
vs rfc2307bis. In the past, it was possible to just delete 10rfc2307.ldif
from /etc/dirsrv/<instance>/schema and replace it with the file supplied
Now, with the new directory layout in 22.214.171.124, there is nothing to delete
in /etc/dirsrv/<instance>/schema. And since the two schemas are
incompatible, I can't load the other one by dropping it in there.
It seems the only thing I'm able to do is remove
/usr/share/dirsrv/schema/10rfc2307.ldif to get the other file to load.
That's global for all instances on the server, though. Is there any way to
make this change for just one instance?
Office of Information Technology
389 Directory Server 126.96.36.199
The 389 Directory Server team is proud to announce 389-ds-base version
Fedora packages are available on Fedora 30 and rawhide.
<https://koji.fedoraproject.org/koji/taskinfo?taskID=35621238> - Rawhide
<https://koji.fedoraproject.org/koji/taskinfo?taskID=35620824> - Fedora 30
The new packages and versions are:
Source tarballs are available for download at Download
Highlights in 188.8.131.52
* Bug fixes
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
There are no upgrade steps besides installing the new rpms
more information about the initial installation and setup
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
New UI Progress (Cockpit plugin)
The new UI is broken up into a series of configuration tabs. Here is a
table showing the current progress
Configuration Tab Finished Written in ReactJS
Server Tab Yes No
Security Tab No No
Database Tab Yes Yes
Replication Tab Yes No
Schema Tab Yes No
Plugin Tab Yes Yes
Monitor Tab Yes Yes
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
If you find a bug, or would like to see a new feature, file it in our
Pagure project: https://pagure.io/389-ds-base
* Bump version to 184.108.40.206
* Issue 49361 - Use IPv6 friendly network functions
* Issue 48851 - Investigate and port TET matching rules
* Issue 50446 - NameError: name ‘ds_is_older’ is not defined
* Issue 49602 - Revise replication status messages
* Issue 50439 - Update docker integration to work out of source directory
* Issue 50037 - revert path changes as it breaks prefix/rpm builds
* Issue 50431 - Fix regression from coverity fix
* Issue 50370 - CleanAllRUV task crashing during server shutdown
* Issue 48851 - investigate and port TET matching rules
* Issue 50417 - Fix missing quote in some legacy tools
* Issue 50431 - Fix covscan warnings
* Revert “Issue 49960 - Core schema contains strings instead of
* Issue 50426 - nsSSL3Ciphers is limited to 1024 characters
* Issue 50052 - Fix rpm.mk according to audit-ci change
* Issue 50365 - PIDFile= references path below legacy directory /var/run/
* Issue 50428 - Log the actual base DN when the search fails with
“invalid attribute request”
* Issue 50329 - (2nd) Possible Security Issue: DOS due to
ioblocktimeout not applying to TLS
* Issue 50417 - Revise legacy tool scripts to work with new
* Issue 48851 - Add more search filters to vfilter_simple test suite
* Issue 49761 - Fix CI test suite issues
* Issue 49875 - Move SystemD service config to a drop-in file
* Issue 50413 - ds-replcheck - Always display the Result Summary
* Issue 50052 - Add package-lock.json and use “npm ci”
* Issue 48851 - investigate and port TET matching rules filter
* Issue 50355 - NSS can change the requested SSL min and max versions
* Issue 48851 - investigate and port TET matching rules
* Issue 50390 - Add Managed Entries Plug-in Config Entry schema
* Issue 49730 - Remove unused Mozilla ldapsdk variables
At the moment we perform TCP health check via F5 on ports 389/636 (historical inheritance) – which isn’t sufficient for HA.
We are moving to an env where NSX and F5 may co-exist – and have an opportunity to re-work the LB health check for HA (on existing F5 and upcoming NSX).
If running NSX and/or F5 (or other load balancers) – how do you determine health on ldap node?
We have 2 read/write (1 active at given time) – replicating to N read-only nodes.
I'm still evaluating some options to securize dynamic nodes and I have some questions regarding certutil and nss databases:
Can I create NSS databases on any directory/server and then move files to "/etc/dirsrv/slapd-instance_name" ?
If cert8.db and key3.db files are found in that directory are they used automatically by slapd process on reboot?
If both answers are affirmative I'll try to script it and hook it within my node creation flow.
is there any other detail I should take care of with this approach?
I'm trying to upgrade my environment and I've reinstalled my CentOS
machines to CentOS 7 except for one. I've got my DNS for my LAN working
just fine. So now it's time for Directory Server.
What is a GOOD tutorial to follow? My environment includes 26 physical
and KVM virtual machines; 4 Windows 7 machines and 1 ArcaOS (OS/2)
machine. What is a DS configuration to go for?