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.
We recently upgraded from Centos 5.4 389-ds Version 1.1.2 to Centos 6.7
389-ds version 1.2.11
The setup has a single master, hub and 5 replicas. For some reason we are
experiencing replication delays of upto 40 secs between hub and replicas.
This did not occur in the old setup. At the time access logs showed an
average of 1000 MOD operations per minute.
Some of our configured parameters:
The systems resources on the Hub (CPU/memory/disk) look fine, so it must be
389-ds resources either on the hub or the replicas that must be causing the
delay. Where should I be looking?
Our build system detects syntax error in
String found where operator expected at
/usr/src/tmp/389-ds-base-buildroot/usr/sbin/ns-accountstatus.pl line 34,
near "STDERR " [-i] [-g seconds]\n\n""
(Do you need to predeclare STDERR?)
syntax error at
/usr/src/tmp/389-ds-base-buildroot/usr/sbin/ns-accountstatus.pl line 34,
See attached patch to fix it.
Small note: ldap/admin/src/scripts/db2index.in use Bash4 syntax
construction (|&), but use interpreter /bin/sh
Not all Linux distributives have /bin/sh as symlink to /bin/bash4
A question about how to best go about doing access control on db-linked directories. Given the below 2-directory setup (Dir1 has a db link set up to Dir2, and vice versa), is the shown ACI setup possible/advisable? If not, what’s the best way to make it work?:
aci:(targetattr ="*")(version 3.0;acl “Admins Group";allow (all) (groupdn = "ldap:///cn=admins,dc=example,dc=com");)
I ask because section 2.3.6. Database Links and Access Control Evaluation, of the RHDS Admin Guide says:
"ACIs must be located with any groups they use. If the groups are dynamic, all users in the group must be located with the ACI and the group. If the group is static, it may refer to remote users."
I’m afraid the phrasing is a little opaque to my understanding. Does it mean that “Admin Groups” act on Dir2 is not allowed to refer to cn=admins,dc=example,dc=com on Dir1?
If so, then what is the best way of maintaining groups centrally but allowing them to be used on remote directories?
Say Alice only has access to Dir1, she can issue a search to ou=projects because of the DB link from Dir1 —> Dir2. When the aci on ou=projects is processed, which user is used? uid=alice or the proxy user of the db link? Will the aci work at all in this case?
Thanks a lot,
Senior Programmer Analyst
Information Technology | Engage. Envision. Enable.
The University of British Columbia
trevor.fong(a)ubc.ca<mailto:firstname.lastname@example.org> | 1-604-827-5247<tel:604-827-5247> | it.ubc.ca<http://it.ubc.ca>
I am new to 389-console and have the following questions:
If 389-console connects the first time to an admin server or
a directory server the appropriate JARs will be downloaded
to the console locally. On the server they are stored under
These JARs are included in both packages 389-admin-console
and 389-ds-console, respectively.
Under RHEL 6 and CentOS 6 these packages can be downloaded
from the EPEL channel, but under RHEL 7 and CentOS 7
from the EPEL-TEST channel only.
Are there any plans to make the RHEL 7 packages available
in the EPEL channel soon? My customer restricts use of
I appreciate your help!
Thanks and best regards,
I have tried to set up a replication agreement on a 389ds master to send updates to a 389ds slave. The master is configure to use client certs for authentication.
The 389ds master fails each time it attempts to contact the slave with the following message, and tcpdump shows no traffic flowing over the wire:
[30/Mar/2016:17:19:19 +0000] setup_ol_tls_conn - failed: unable to create new TLS context
[30/Mar/2016:17:19:19 +0000] slapi_ldap_bind - Error: could not configure the server for cert auth - error -1 - make sure the server is correctly configured for SSL/TLS
[30/Mar/2016:17:19:19 +0000] NSMMReplicationPlugin - agmt="cn=Agreement ldap.example.com" (ldap:636): Replication bind with EXTERNAL auth failed: LDAP error 0 (Success) ()
The server is correctly configured for SSL/TLS, and I am able to bind to both the master and the slave over SSL port 636.
The replication agreement looks as follows:
dn: cn=Agreement ldap.example.com,cn=replica,cn=dc\3Dexample\,dc\3Dcom,cn=mapping tree,cn=config
cn: Agreement ldap.example.com
description: Replication agreement to ldap.example.com
nsDS5ReplicaBindDN: cn=Replication Manager,cn=config
nsds5replicaLastInitStatus: 255 Replication error acquiring replica: unknown
nsds5replicaLastUpdateStatus: 255 Replication error acquiring replica: unkno
wn error - Unable to acquire replica
Is there anything I can do to coax a useful error message out of the master server? "LDAP error 0 (Success)” tells me this is a bug of some kind, as why would it fail saying success?
This is 389ds on Ubuntu 14.04:
ii 389-ds-base 184.108.40.206-0ubuntu1 amd64 389 Directory Server suite - server
I have an old directory server running Sun One Java System Directory Service. Yesterday I created top dcobject - dc=christianbook,dc=com, however, I don't know what the best way is to import data from my old Sun Directory Server to 389 Directory Server. It appears the object structure is different. Below is an example of my old dcobject:
aci: (target ="ldap:///dc=christianbook,dc=com")(targetattr !="userPassword")(version 3.0;acl "Anonymous read-search access";allow (read, search, compare)(userdn = "ldap:///anyone");)
aci: (target="ldap:///dc=christianbook,dc=com") (targetattr = "*")(version 3.0; acl "allow all Admin group"; allow(all) groupdn = "ldap:///cn=Directory Administrators,ou=Groups,dc=christianbook,dc=com";)
aci: (targetattr = "cn||uid||uidNumber||gidNumber||homeDirectory||shadowLastChange||shadowMin||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag||memberUid")(version 3.0; acl LDAP_Naming_Services_deny_write_access; deny (write) userdn = "ldap:///self";)
aci: (target="ldap:///dc=christianbook,dc=com")(targetattr="userPassword")(version 3.0; acl LDAP_Naming_Services_proxy_password_read; allow (compare,search) userdn = "ldap:///cn=proxyagent,ou=profile,dc=christianbook,dc=com";)
This is another object in my old Sun Directory Server:
What is the best way to convert or import from my old Sun Directory Server to new one?
I installed a new version of 389:
And I'm getting these warnings:
[30/Mar/2016:10:47:39 -0300] - SSL alert: Found unsecure configuration:
nsSSL3: on; We strongly recommend to disable nsSSL3 in
[30/Mar/2016:10:47:39 -0300] - SSL alert: Configured range: min: TLS1.0,
max: TLS1.2; but both nsSSL3 and nsTLS1 are on. Respect the supported range.
I already disabled nsSSL2 and nsSSL3:
and confirmed that my server is only accepting TLS connections
Also tried to delete nsssl3ciphers:
But it comes back.
Why I'm still getting these warnings even after to disable nsSSL2 and