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.
How to modify the attribute nsslapd-encryptionalgorithm in Centos?
Stop Master servers and set nsslapd-encryptionalgorithm. The allowed value is AES or 3DES.
--- 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
CentOS release 6.3 (Final)
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
--- Em ter, 4/6/13, Rich Megginson <rmeggins(a)redhat.com>
De: Rich Megginson <rmeggins(a)redhat.com>
Assunto: Re: [389-users] changelog
Para: "General discussion list for the 389 Directory
Cc: "Denise Cosso" <guanaes51(a)yahoo.com.br>
Data: Terça-feira, 4 de Junho de 2013, 16:11
06/04/2013 12:39 PM, Denise Cosso wrote:
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:
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
389 users mailing list
We have a master - master replication agreement. When we initialize the replication it works perfectly we can see changes to a test user we have set up go up and down from the two servers. However at some point the replication stops and we cannot get replication to start once again. The only way we can get replication to start once again is to recreate the replication agreement and then it fails again. Can anyone please point us in a direction. I am relatively new to 389 so any help would be greatly appreciated.
Santos U. Ramirez
Linux Systems Administrator
National DCP, LLC
150 Depot Street
Bellingham, Ma. 02019
This email and any attachments are intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, do not copy or forward to any unauthorized persons, permanently delete the original and notify the sender by replying to this email.
Just upgraded my packages from:
After that I ran "setup-ds-admin.pl -u". Now I'm having problems starting dirsrv-admin:
# service dirsrv-admin start
httpd.worker: Syntax error on line 136 of /etc/dirsrv/admin-serv/httpd.conf: Cannot load /usr/lib64/dirsrv/modules/mod_admserv.so into server: /usr/lib64/libadminutil.so.0: undefined symbol: ldap_explode
Server failed to start !!! Please check errors log for problems
# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
I checked any error logs I could think of but found nothing.
Thanks in advance for the help!
This communication, including any attached documentation, is intended only for the person or entity to which it is addressed, and may contain confidential, personal and/or privileged information. Any unauthorized disclosure, copying, or taking action on the contents is strictly prohibited. If you have received this message in error, please contact us immediately so we may correct our records. Please then delete or destroy the original transmission and any subsequent reply.
During the bind process is there anyway to tell 389 directory server to
hash a plaintext password n (multiple) times before trying to compare to
what is stored?
I am trying to implement something similar to what's described in this
Our plan was to to use SSHA256 to hash the passwords around 200,000 times
before storing. This would at least slow down any cracking attempts should
someone get access to our directory.
I've read through the documentation on the Red Hat Directory Server site,
including the "Plug-in Guide". Under "5.8 Checking Passwords" it refers to
calling function "slapi_pw_find_sv()" - looking at the doc for this
function it does not look like hashing multiple times is supported.
Is there some means of doing this that is not obvious to me?
I can certainly do it by re-writing the security plugins for the various
servers (Tomcat, PHP Wordpress, etc) such that they hash the plaintext
password n minus 1 times before issuing the bind - but was hoping not to do
I'm relatively new to 389 directory server, but so far quite happy to have
moved to it from another directory server.
Thank you - Richard
Custom Computer Creations, L.L.C.
mobile: (480) 577-6834 office: (480) 614-3442
email: rnmixon(a)CustCo.biz <mailto:rnmixon@CustCo.biz>
Microsoft Partner ID: 1263725
The messages and documents transmitted with this notice contain
confidential information belonging to the sender. If you are not the
intended recipient of this information, you are hereby notified that any
disclosure, copying, distribution or use of the information is strictly
prohibited. If you have received this transmission in error, please notify
the sender immediately.
We are trying to reindex RHDS 9.1 after importing an updated index. Services were stopped. Started the /usr/lib64/dirsrv/slapd-instance/db2index.
Reindex starts but then consistently reports:
Processed 300,000 entries ( pass 1)
Processed 300,000 entries ( pass 2)
and keeps repeating that sequence with same amount of entries. How long does it usually take to complete the process and is there a limit or issue with this feature? This happened once before and system was left overnight performing indexing only to still processing with new passes. We ended up breaking the process and just reinitializing the server.
Paul M. Whitney
In setting up my 389-ds instance for SSL, the dirsrv instance doesn’t appear to recognize cert9.db or key4.db, the SQLite NSS database formats. Did I miss a setting? Is 389-ds restricted to cert8.db/key3.db? A quick search of the 389-ds wiki didn’t help; Google returns a lot of noise and not much signal.
# service dirsrv start
ds01...[27/Jan/2014:21:28:12 -0800] SSL Initialization - Warning: certificate DB file cert8.db nor cert7.db exists in [/etc/dirsrv/slapd-ds01] - SSL initialization will likely fail
[27/Jan/2014:21:28:12 -0800] SSL Initialization - Warning: key DB file /etc/dirsrv/slapd-ds01/key3.db does not exist - SSL initialization will likely fail
[27/Jan/2014:21:28:12 -0800] - SSL alert: Security Initialization: Unable to authenticate (Netscape Portable Runtime error -8192 - An I/O error occurred during security authorization.)
[27/Jan/2014:21:28:12 -0800] - ERROR: SSL Initialization Failed.
David - Offbeat http://dafydd.livejournal.com
dafydd - Online http://pgp.mit.edu/
Battalion 4 - Black Rock City Emergency Services Department
Rene Descartes walks into his neighborhood watering hole. The publican sees him and asks, "Will you have your usual, sir?"
Descartes ponders a moment and replies, "I think not."
And promptly disappears...
I need to be able to reset a LDAP user's password if they forget it with the user root. But when I try the "passwd" command as root for a LDAP user, I get the following:
Changing password for user tuser.
Password reset by root is not supported.
passwd: Authentication token manipulation error.
I am using sssd as the LDAP authentication mechanism tool, to be specific. Does anyone have a solution to dealing with this issue of resetting a LDAP user's password if they forgot it?
From: <Chaudhari>, "Rohit K. Chaudhari" <rohit.chaudhari(a)jhuapl.edu<mailto:firstname.lastname@example.org>>
Date: Tuesday, January 21, 2014 3:29 PM
To: "General discussion list for the 389 Directory server project." <389-users(a)lists.fedoraproject.org<mailto:email@example.com>>
Subject: using passwd with 389
I want to be able to use the Unix "passwd" command to reset a LDAP user's password from the command line. However, I keep getting an authentication token manipulation error whenever I try to reset the password using that command. What do I need to do in the 389 DS or on Unix in order to get this command to work?