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 have two servers running with multi master replication. The servers are
running RHEL 7.4 with 389-ds installed via yum using the rhel-7-server-rpms
repository. The hosts are behind a load balancer and all client access is through
the load balancer.
I would like to upgrade to the latest release available in rhel-7-server-rpms. I
have the following packages installed related to 389ds:
Only two of those packages appear to have updates available; 389-ds-base and 389-ds-base-libs.
Is this the correct procedure?
1. remove server1 from the load balancer config to halt client requests
2. stop the dirsrv and dirsrv-admin services on server1
3. run "yum upgrade 389-ds-base 389-ds-base-libs" on server1
4. run "setup-ds-admin.pl -u" on server1
5. restart dirsrv and dirsrv-admin on server1
6. verify replication is still working
7. add server1 back to load balancer config
8. repeat steps 1-7 on server2
I presume that replication will continue to work after upgrading server1 but before
upgrading server2. I believe that at step 4, I don't *also* have to run "setup-ds.pl".
Is that correct?
University of Louisiana at Lafayette
is there a way to access documentation for upcoming 1.4 release?
I would like to see specifically changes in ACIs as stated in this thread:
thanks in advance,
-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent.
-- Abans d'imprimir aquest missatge, pensau si es realment necessari.
Is any chance to import all from openldap ?
I install 389 Directory Server - from faq in webside + 389-console
Now I wanted to import db from openldap - I get root.ldif
My openldap have a "weird" root in tree
I was looking in documentation 389 for how to add/import schema but I
can someone help me with import db and qmail.schema ?
Is it okay to allow a master to accept changes while a replica is being initialized?
In the past when we have had to do this we've shut down changes but want to know if this was still recommended for 1.3.x and 1.4.x code levels.
Deborah Crocker, PhD
Systems Engineer III
Office of Information Technology
The University of Alabama
Tuscaloosa, AL 36587
Office 205-348-3758 | Fax 205-348-9393
I have an Active Directory Setup With the users and groups.
I am interested in getting groups information from a subtree in AD called
But I get the following error
*The consumer Initialization has unsuccessfully completedThe error received
by the replica is " 1 Connection error: operation failure - Total update
But when I see the destination subtree on the *Directory Server*. I see the
users and groups have been successfully copied with the even posix info.
First question is why am I still getting data if there is connection issue.
When I change the Active Directory source subtree from
*ou=ABC,dc=example,dc=com* to *cn=Users,dc=example,dc=com*. The above error
does not show up.
Please can someone advise me on this issue?
Is it possible to log the negotiated ciphers used between a client and
our 389ds server? I've played around with different logging levels and
none seem to show the agreed upon set of ciphers used for each
connection. The reason we would like to log this, if possible, is
because we would like to prevent the use of some ciphers, but would like
to know which clients might be using those ciphers.
Our 389ds version is 1.2.2.
I'm preparing migration from 389 DS 1.2.5. I'm using single master and 4
replicas all on RedHat which I would like to abandon in favor Debian
which is my main platform.
My idea was to use 389-ds 1.4.x line on Debian/Buster, but there is
completely missing 389-admin package . They ship cockpit-389-ds
184.108.40.206-1 which completely doesn't work on Debian. It declares that
389-ds-base isn't installed. It is installed and configured.
I tried Fedora 29, there is 220.127.116.11-1.fc29 and it works... somehow.
Schema editation is possible. But database management is broken, it
shows two suffixes dc=example,dc=com and o=ipaca.com which are not
present in 389-ds configuration dse.ldif file. And it is unable to
detect defined suffix. It looks nice, but it seems that many things
might not be working even on Fedora.
Is it possible to manage 389-ds 1.4.x with 389-admin 1.1.46 and
389-admin-console 1.1.12-5.fc29? This is combination Fedora 29 come with.
Or is it safer to stick with 389-ds 1.3.x which is shipped with RHEL 7 &
Debian/Stretch? And use 389-admin & 389-console for managing them?
Thanks for responses
Jan Tomasek aka Semik
389 Directory Server 18.104.22.168
The 389 Directory Server team is proud to announce 389-ds-base version
Fedora packages are available on Fedora 28, and 29
The new packages and versions are:
Source tarballs are available for download at Download 389-ds-base
Highlights in 22.214.171.124
Installation and Upgrade
See Download <https://markdownlivepreview.com/download.html> for
information about setting up your yum repositories.
To install, use *dnf install 389-ds-base*, then run *dscreate*. To
install the Cockput UI plugin use "dnf install cockpit-389-ds"
<https://markdownlivepreview.com/howto/howto-install-389.html> for more
information about the initial installation, setup, and upgrade
See Source <https://markdownlivepreview.com/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*
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 126.96.36.199
* Ticket 50308 - Revise memory leak fix
* Ticket 50308 - Fix memory leaks for repeat binds and replication
* Ticket 49873 - (cont 3rd) cleanup debug log
* Ticket 49873 - (cont 2nd) Contention on virtual attribute lookup
* Ticket 50292 - Fix Plugin CLI and UI issues
* Ticket 50289 - Fix various database UI issues
* Ticket 50300 - Fix memory leak in automember plugin
* Ticket 50265 - the warning about skew time could last forever
* Ticket 50260 - Invalid cache flushing improvements
* Ticket 49561 - MEP plugin, upon direct op failure, will delete twice
the same managed entry
* Ticket 50077 - Do not automatically turn automember postop modifies on
* Ticket 50282 - OPERATIONS ERROR when trying to delete a group with
* Ticket 49873 - (cont) Contention on virtual attribute lookup
* Ticket 50260 - backend txn plugins can corrupt entry cache
* Ticket 50041 - Add CLI functionality for special plugins
* Ticket 50273 - reduce default replication agmt timeout
* Ticket 50234 - one level search returns not matching entry
* Ticket 50232 - export creates not importable ldif file
* Ticket 50215 - UI - implement Database Tab in reachJS
* Ticket 50238 - Failed modrdn can corrupt entry cache
* Ticket 50236 - memberOf should be more robust
* Ticket 50151 - lib389 support cli add/replace/delete on objects
* Ticket 50155 - password history check has no way to just check the
* Ticket 49873 - Contention on virtual attribute lookup
* Ticket 49658 - In replicated topology a single-valued attribute can
* Ticket 50177 - import task should not be deleted too rapidely after
import finishes to be able to query the status
* Ticket 50165 - Fix issues with dscreate