Problem browsing LDAP with Outlook
by Chris Bryant
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.
Thanks,
Chris
USA.NET
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.
2 years, 9 months
changelog
by Denise Cosso
Hi,
How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Thanks,
Denise
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
dn: cn=changelog5,cn=config
[...]
nsslapd-encryptionalgorithm: AES
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com> escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:34
On 06/04/2013 01:26 PM, Denise Cosso
wrote:
Hi, Rich
CentOS release 6.3 (Final)
389-ds-base-libs-1.2.10.2-20.el6_3.x86_64
389-ds-1.2.2-1.el6.noarch
389-dsgw-1.1.10-1.el6.x86_64
389-ds-console-1.2.6-1.el6.noarch
389-ds-console-doc-1.2.6-1.el6.noarch
389-ds-base-1.2.10.2-20.el6_3.x86_64
As far as replication goes - you will need to use a security layer
(SSL, TLS, or GSSAPI) to protect the clear text password on the wire
As far as encrypting it in the changelog - not sure
Denise
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
escreveu:
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
server project."
<389-users(a)lists.fedoraproject.org>
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
On
06/04/2013 12:39 PM, Denise Cosso wrote:
Hi,
Description of problem:
When a userPassword is changed in a server with changelog, the hashed password
is logged and also a cleartext pseudo-attribute version. It looks like this:
change::
replace: userPassword
userPassword: {SHA256}vqtiN2LHdrEUOJUKu+IBVqAVFsAlvFw+11kD/Q==
-
replace: unhashed#user#password
unhashed#user#password: secret12
This unhashed version is used in winsync where the cleartext version of the
password must be written to the AD.
Now if the DS is involved in replication with another DS, the change will be
replayed exactly as it is logged to the other DS replicas, including the
cleartext pseudo-attribute password.
What platform? What version of 389-ds-base are you
using?
thanks,
Denise
--
389 users mailing list
389-users(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
8 years, 1 month
389 GUI/Console
by Gonzalo Fernandez Ordas
Hi
I got 389 running on a remote linux box,and I would like to get use of
the Console without the need of exporting the X-Windows whenever I want
to make a change as I also would prefer not to keep tweaking the
configuration files all the time.
is there anyway of doing this through any remote client?
Any advise on this matter?
Thanks very much
8 years, 3 months
How to get password expiration working?
by Paul Tobias
Hi guys,
We need to implement password expiration because of some policy. The
problem is users are not able to bind to ldap anymore, after I switch on
password expiration for our ou=People subtree . The ldap command line
tools and 389-console both just hang forever when trying to connect.
This happens even when the user changes the password right before
switching on the password expiration so the password cannot be expired
yet. When I use the wrong password, then I get "ldap_bind: Invalid
credentials (49)", but when I use the correct password, then it's just a
hang. If I switch off password expiration then everything returns to
normal again. I've followed the guide at
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8....
I've tried both 389ds 1.2.11.32 on CentOS 6 and 389ds 1.3.2.23 on Fedora
20 with the same results.
Is password expiration working in 389ds at all?
Thanks in advance,
Paul Tobias
8 years, 5 months
Switching from 389-ds-base 1.2.11 to 1.3.3
by Fong, Trevor
Hi Everyone,
I’m afraid this will be a total newb question.
I’m currently running 389 DS 1.2.11.29-1.el6 and have seen the notice that 1.2.11.X will be discontinued soon (as of 24-Oct-2014). [It probably has already been discontinued since the COPR repository is no longer there.]
I’d like to switch from 1.2.11 to 1.3.3.5 and have yum downgraded to 1.2.11.15-48.el6_6.
However, when I try to "yum upgrade 389-ds-base 389-ds-base-devel 389-ds-base-libs” it tells me "No Packages marked for Update”. Am I doing something wrong?
I’ve followed the directions on http://www.port389.org/docs/389ds/download.html and epel-release-6-8.noarch.rpm is already installed. [That doc is still telling me to install the temporary COPR, by-the-way.]
Thanks in advance,
Trev
8 years, 6 months
Increase in search time operation in 1.2.11 vs 1.2.5
by Bartek
Hello
I have an use case where particular search operations on the same data in
1.2.5 and 1.2.11 differ significantly.
1.2.5 is on Centos 5.9 and 1.2.11 on Centos 5.11. I'm asking this as i'm in
the middle of upgrade process and I come across this performance issue.
After feeding both versions with data from the same text dump, particular
search operation takes 0.5s in 1.2.5 to complete whereas in 1.2.11 it takes
6s:
ldapsearch -D 'uid=root,ou=users,o=xxx' -x -b
'uid=someuser,dc=domain,dc=pl,o=xxx' -s subtree -w pass
'(objectClass=someObjectClass)'
There is a set of 40 acls at the dc=pl,o=xxx node and 9 more on
dc=domain,dc=pl,o=xxx. The acl allowing 'uid=root,ou=users,o=xxx' to access
everything is at o=xxx.
I did already manage to figure out that the more acis i remove the shorter
the search operation is. However even with those aci in place, search on
1.2.5 returns significantly faster.
I would like to ask if there are any factors that would make search
operations longer while jumping from 1.2.5 to 1.2.11?
--
Regards
Bartek
8 years, 6 months
389-console display count number for DS entries
by ghiureai
Hi Gurus,
I need to know how to cfg 389-admin console to be able to display the
total number of entries in DS ( the count number) , seems that Appache
Studio has a limitation to 2000 entries/counts ( is this correct ?), I
increase the browsing options to 100000 for DS Users but will show as (
2000) beside Users
Isabella
8 years, 6 months
Serious memory issues with 1.2.11.x on RHEL 6.6
by Steve Holden
Hi, folks
We've been really pleased with our 389 servers, which have been successfully running as a multi-master pair in production for 7 weeks, following (elapsed) months of development.
Unfortunately, in the last few days their performance has radically degraded to the point where they are becoming unusable due to excessive memory consumption. At first, we suspected a recent update to the package - but are no longer convinced that's the problem.
I'd really appreciate any suggestions on how to troubleshoot this further.
SYMPTOMS
389 ignores its 4GB userRoot nsslapd-cachememsize and its overall memory usage expands to encompass all of the server's 8GB RAM - and a large proportion of its 10GB swap. The service eventually fails, and hangs the server.
DETAILS
As per the previous guidance for RHEL 6 installations, we had been using the packages from the COPRS repository (389-ds-base-1.2.11.32-1 aka 1.2.11.32 B2014.247.2316).
(As several of our applications require CoS/dynamic attributes, earlier versions of the RHEL packages were unusable for us until this fix was ported: https://fedorahosted.org/389/ticket/47762#comment:8 - which was only recently applied to the RHEL packages).
Due to an unfortunate misconfiguration, the production servers received automated updates - and were upgraded to RHEL 6.6, the latest COPRS package (1.2.11.32-1), and a new kernel :-/
The directory contains 236,340 entries, and id2entry.db4 is 3.6GB.
STEPS TAKEN
We've tried to balance isolating the problem with maintaining a critical service for our users:
* An additional 8GB RAM (and additional CPU) was added to the VM to mitigate the immediate problem - but this was soon swallowed up too.
* Attempting to reproduce this on our equivalent development servers has not been successful, even when subjecting them to load.
* Downgrading to the RHEL packages (1.2.11.15-48 aka 1.2.11.15 B2014.300.2010) as per Noriko's very helpful procedure below (though I stopped the services prior to the downgrade). No obvious difference.
* Rebooting into the previous kernel (2.6.32-431.29.2). This slowed the problem, but only to an extent.
Not attempted yet:
* Turning on debugging on the production servers, as they're in a fragile and sluggish state.
* Building the latest 1.3.x build on RHEL 6. Will be attempting this soon...
* Installing RHEL 7.0 on a fresh VM, as we don't have experience with 7 yet.
* Downgrading to the previous COPRS package, as no longer publicly available(?)
Please let me know if more information would help...
Kind regards,
Steve
From: 389-users-bounces(a)lists.fedoraproject.org<mailto:389-users-bounces@lists.fedoraproject.org> [mailto:389-users-bounces@lists.fedoraproject.org] On Behalf Of Noriko Hosoi
Sent: 25 October 2014 00:05
To: 389-announce(a)lists.fedoraproject.org<mailto:389-announce@lists.fedoraproject.org>; General discussion list for the 389 Directory server project.
Subject: [389-users] Please take an action: 389 Directory Server 1.2.11.X Discontinued for EL6
389 Directory Server 1.2.11.X Discontinued for EL6
The 389 Directory Server team announces the binary release of 389-ds-base version 1.2.11 for EL6 will be stopped via temporary COPR repository. We encourage you to switch it to the official version included in the Red Hat Enterprise Linux 6 distribution or its equivalent OS.
How to switch to the official version
Remove a yum repo file which points to the temporary COPR repository (e.g., nhosoi-389-ds-base-epel6-epel-6.repo) from /etc/yum.repos.d.
If the current 389 Directory Server 1.2.11 has the greater build number than 15, for instance, 1.2.11.32, downgrade it once by "yum downgrade" as follows.
yum downgrade 389-ds-base 389-ds-base-libs
Then, upgrade to make sure you have the latest version.
yum upgrade 389-ds-base
After upgrade completes, run setup-ds-admin.pl -u to update your directory server/admin server/console information.
setup-ds-admin.pl -u
See Install_Guide<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.
http://www.port389.org/docs/389ds/releases/end-1-2-11.html
___________________________________________________________
This email has been scanned by MessageLabs' Email Security
System on behalf of the University of Brighton.
For more information see http://www.brighton.ac.uk/is/spam/
___________________________________________________________
8 years, 6 months
389ds v1.3.2.24 error log message: replica_generate_next_csn adjusted
by Ivanov Andrey (M.)
Hi,
we've migrated our production systems to 389ds version 1.3.2.24. Everything seems fine now, the only new messages i see in error logs (several times per day) are
[15/Nov/2014:03:58:43 +0100] - replica_generate_next_csn: opcsn=5466c164000000010000 <= basecsn=5466c164000000020000, adjusted opcsn=5466c164000100010000
[15/Nov/2014:10:38:38 +0100] - replica_generate_next_csn: opcsn=54671f1f000000010000 <= basecsn=54671f1f000000030000, adjusted opcsn=54671f1f000100010000
Are these only information messages that can be safely ignored or they may be a manifestation of some potential problem?
In source code (./ldap/servers/plugins/replication/repl5_replica.c) it looks like a serious one (SLAPI_LOG_FATAL):
slapi_log_error (SLAPI_LOG_FATAL, NULL,
"replica_generate_next_csn: "
"opcsn=%s <= basecsn=%s, adjusted opcsn=%s\n",
opcsnstr, basecsnstr, opcsn2str);
Thanks!
8 years, 6 months
