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-184.108.40.206) 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 am using 389DS on Centos7 x64
[root@idm01 ~]# rpm -qa | grep 389
A week ago I started having a weird problem using the 389DS's java
management console remotely.
If I connect locally with the console, I get the two entries of the
directory server under server group :
- Administration server
- Directory server
But when I use the console from another machine, a Windows machine with the
management console installed on it, I get only the "Administration server"
So I cannot access the directory server to modify entries.
I am using the 'Directoy Manager' to login to the console.
I didn't find anything special on the error and access logs from neither
the admin server no from the directory server.
any idea where to search.
Today I just found when I click "Manage Certificate" in administration console, I got an error. Below is the error message:
An error has occured.
Could not open file (null). File does not exist or filename is invalid. A filename that exists in the server security directory must be specified. Absolute or relative paths should not be specified.
Does anybody know what's going on?
I'm fairly new to 389-ds and I ran into an issue when trying to update a
user's password via the command line.
I was able to change a password "as" the user via the command line using
the following syntax without issue:
ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D
"uid=jdoe,ou=People,dc=domain,dc=edu" -w current_user_passwd -s
However, when I tried doing the same thing as the Directory Manager, it
changes the password hash, but it doesn't update the password. In fact,
issuing the following command (see below), both the old and new
passwords don't work:
ldappasswd -h my389dsserver.domain.edu -p 389 -ZZ -D "cn=Directory
Manager" -w directorymanager_passwd -s new_user_passwd
I found the following page,
but being fairly
new to 389-ds I wasn't sure how to create/define/add the ability to be a
password administrator to an account.
Any suggestions would be appreciated.
I have a setup with 3 Servers running on rhel7, 1 master and 2 slaves,
as described in the documentation chapter 11.2.1. Once or twice a week
the master gets killed by the OS because the system is out of memory. I
could just throw more ram at it, but the system already has 16GB of ram
and i would like to try to fix the problem without using more ressources
first. Can you give me any suggestions where to start looking? What do
you need from me to be able to help?
I have two 2012 r2 domain controllers with passsync 1.6 x64 installed.
They're both targeting 389-ds-base-220.127.116.11-1.fc22.x86_64 . They're working
I dont know if it's been a software update or a change in the domain
settings. Thing is today, one of the controllers has stopped sync'ing.
Whenever I change one password in that controller, the following message is
logged in passsync.log:
08/29/16 11:30:07: Password list has 1 entries
08/29/16 11:30:07: Attempting to sync password for juankar
08/29/16 11:30:07: Searching for (ntuserdomainid=juankar)
08/29/16 11:30:07: Checking password failed for remote entry:
08/29/16 11:30:07: Deferring password change for juankar
and in the server access log I get ldap bind err=53 when the passsync user
tries to check the password:
[29/Aug/2016:11:30:07 +0200] conn=276 fd=67 slot=67 SSL connection from xxxx
[29/Aug/2016:11:30:07 +0200] conn=276 TLS1.2 128-bit AES
[29/Aug/2016:11:30:07 +0200] conn=276 op=0 BIND dn="uid=juankar,ou=xxx...."
[29/Aug/2016:11:30:07 +0200] conn=276 op=0 RESULT err=53 tag=97 nentries=0
[29/Aug/2016:11:30:07 +0200] conn=276 op=1 UNBIND
[29/Aug/2016:11:30:07 +0200] conn=276 op=1 fd=67 closed - U1
[29/Aug/2016:11:30:07 +0200] conn=275 op=2 UNBIND
Any hints? Could be a problem with certificates? They're both using the
same CA (windows CA Cert serv is installed in one of the DCs)
We are successfully using the compiled 1.3.4 git branch of 389DS in production on CentOS 7 since about a year (approximately 40 000 entries, about 4000 groups, hundreds of reads and tens of writes per second).
Our current topology consists of 3 servers in triangle (each server is a master replicating to 2 others, so two read-write replication agreements on each).
Since the fixes for the Ticket 48766 ("Replication changelog can incorrectly skip over updates") and Ticket 48954 ("Replication fails because anchorcsn cannot be found") I’ve started to see the following regular warnings in error logs:
[06/Sep/2016:01:21:43 +0200] clcache_load_buffer_bulk - changelog record with csn (57cdfe06000100010000) not found for DB_NEXT
[06/Sep/2016:01:21:43 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-lab.<domain>" (ldap-lab:636) - Can't locate CSN 57cdfe06000100010000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:02:35:25 +0200] - replica_generate_next_csn: opcsn=57ce0f4e000500020000 <= basecsn=57ce0f4e000500030000, adjusted opcsn=57ce0f4e000600020000
[06/Sep/2016:04:10:11 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce257e000400030000) not found for DB_NEXT
[06/Sep/2016:05:16:58 +0200] - replica_generate_next_csn: opcsn=57ce352b000000020000 <= basecsn=57ce352b000100010000, adjusted opcsn=57ce352b000100020000
[06/Sep/2016:06:56:04 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-ens.<domain>" (ldap-ens:636) - Can't locate CSN 57ce4c62000100030000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:29:00 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-ens.<domain>" (ldap-ens:636) - Can't locate CSN 57ce541a000200030000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:34:20 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-lab.<domain>" (ldap-lab:636) - Can't locate CSN 57ce5559000100010000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:34:27 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-lab.<domain>" (ldap-lab:636) - Can't locate CSN 57ce5561000000010000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:07:40:17 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce56c0000500030000) not found for DB_NEXT
[06/Sep/2016:07:40:24 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce56c5000100030000) not found for DB_NEXT
[06/Sep/2016:08:08:36 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce5d5f000f00010000) not found for DB_NEXT
[06/Sep/2016:08:12:39 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce5e54000200030000) not found for DB_NEXT
[06/Sep/2016:08:12:39 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-ens.<domain>" (ldap-ens:636) - Can't locate CSN 57ce5e54000200030000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:08:26:45 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce61a3000200030000) not found for DB_NEXT
[06/Sep/2016:08:27:40 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce61d8000200030000) not found for DB_NEXT
[06/Sep/2016:08:27:40 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-ens.<domain>" (ldap-ens:636) - Can't locate CSN 57ce61d8000200030000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:08:31:42 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce62c8000300010000) not found for DB_NEXT
[06/Sep/2016:08:34:05 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce635a000100010000) not found for DB_NEXT
[06/Sep/2016:08:44:28 +0200] clcache_load_buffer_bulk - changelog record with csn (57ce65c9000200030000) not found for DB_NEXT
[06/Sep/2016:08:52:25 +0200] agmt="cn=Replication from ldap-adm.<domain> to ldap-ens.<domain>" (ldap-ens:636) - Can't locate CSN 57ce67aa000100030000 in the changelog (DB rc=-30988). If replication stops, the consumer may need to be reinitialized.
[06/Sep/2016:08:53:04 +0200] - replica_generate_next_csn: opcsn=57ce67d1000100020000 <= basecsn=57ce67d1000200030000, adjusted opcsn=57ce67d1000200020000
These warnings are present on all three servers and for all replication agreements. One of them is virtual and two others are physical.
The replication still seems to work fine in spite of these warnings. The "replica_generate_next_csn" is not new - it existed since always with 1.3.4, the two new warnings are "clcache_load_buffer_bulk " and "Can't locate CSN ... in the changelog (DB rc=-30988)." There are no network problems or anything like that. So it could only be replication topology (3-master fully-connected triangle) and/or servers being rather busy. Is it a bug, a warning that can be ignored or anything else?
I have installed 389 Directory Server on a Centos 6.8 server.
I followed the instructions reported in :
and installed with yum the following packages :
To proceed with the installation I would like to read the instructions
reported here :
where I can choose the product version between 8.0 to 10.
I would like to know which version of 389 Directory Server match
installed packages so I can select the right manual.
Thanking you in advance.