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.
3 years, 9 months
Disable unhashed#user#password altogether
by Lucas Sweany
Is there a way to prevent the unhashed#user#password attribute from being
stored or used at all? I don't need it to be replicated anywhere--I presume
that the hashed password will be enough to authenticate users.
Thanks,
-Lucas
11 years, 11 months
public-key-authorization SSH keystore?
by David Barr
Good Morning!
Has anyone configured 389-server to hold the SSH public key for users, and use that key instead of an authorized_keys file on each host for each user? Google has shown me the patch for OpenSSH and a little bit of the corresponding customization for OpenLDAP. Has anyone tried it with 389-server?
Thanks!
David
--
David - Offbeat http://dafydd.livejournal.com
dafydd - Online http://pgp.mit.edu/
Battalion 4 - Black Rock City Emergency Services Department
Integrity*Commitment*Communication*Support
----5----1----5----2----5----3----5----4----5----5----5----6----5----7--
Failure is not an option. It comes bundled with the software.
--unknown
12 years
GSSAPI authentication between 1.2.10 and 1.2.11
by Edward Z. Yang
Hello all,
We are trying to setup GSSAPI SASL authentication using Kerberos keytabs
between 389-ds 1.2.10.6 (on Fedora 15) and 1.2.11.4 (on Fedora 17).
However, we are getting an unspecified GSSAPI error. Are there
any known bugs / changes that could possible cause this to happen?
Edward
12 years
Get Effective Rights on centOS 6
by Josh Ellsworth
So, I'm trying to debug some ACLs and need to use the Get Effective Rights search control. My issue is that my centos 6 box does not have the Mozilla LDAP packages and I can't see how to install them. I read somewhere that they are deprecated - are there any plans to support the Get Effective Rights in the future?
Josh
--
Joshua Ellsworth
System Administrator, Primatics Financial
Phone: 571.765.7528
jellsworth(a)primaticsfinancial.com
12 years
password expiration warnings
by Josh Ellsworth
Is there documentation showing how to get password expiration warnings to work? I have them enabled in the console but for some reason they aren't being sent. I am not sure where the SMTP relay is configured, etc and would like to be sure that everything is configured correctly.
Josh
--
Joshua Ellsworth
System Administrator, Primatics Financial
Phone: 571.765.7528
jellsworth(a)primaticsfinancial.com
12 years
Upgrade to fedora 16 with real CA fails
by Cawley, Chris
Hello,
I went through some of the docs/emails; however, it still seems like
The NSS is not working correctly.
On a separate, but related issue, it seems like you cannot use
the GUI to generate a key with 2048 bits. To get a real CA, some
vendors ask for this.
- Thanks
- Chris
Chris Cawley
System Administrator
Washington Research Library Consortium
301-390-2049
cawley(a)wrlc.org
12 years
Using Wildcard SSL Certificate
by Jeff Field
Hello,
I'm attempting to use a Wildcard SSL certificate for my domain with 389ds.
The certificate and the CA (godaddy) intermediate cert import fine into
both the admin server and the directory server, but attempts to use an
LDAPS:// URI with ldapmodify result in this error:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
curl gets this:
curl -vvv -3 https://myserver.ldap.mydomain.com:636
* About to connect() to myserver.ldap.mydomain.com port 636 (#0)
* Trying x.x.x.x... connected
* Connected to myserver.ldap.mydomain.com (x.x.x.x) port 636 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* SSL: certificate subject name '*.mydomain.com' does not match target host
name 'myserver.ldap.mydomain.com'
* NSS error -12276
* Closing connection #0
curl: (51) SSL: certificate subject name '*.mydomain.com' does not match
target host name 'myserver.ldap.mydomain.com'
Am I not able to use a wildcard SSL cert in this instance? If that is the
case, what would my best course of action be?
Thanks,
-Jeff
12 years
About 389 cache and backend behavior
by Roberto Polli
Hi all,
where can I find a brief description of the 389 communication between:
- client
- 389 cache
- 389 backend
- COS and VLV
Is there a way to dwell into it without reading the code?
Thx+ Peace,
R.
--
Roberto Polli
Community Manager
Babel S.r.l. - http://www.babel.it
T: +39.06.9826.9651 M: +39.340.652.2736 F: +39.06.9826.9680
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)
CONFIDENZIALE: Questo messaggio ed i suoi allegati sono di carattere
confidenziale per i destinatari in indirizzo.
E' vietato l'inoltro non autorizzato a destinatari diversi da quelli indicati
nel messaggio originale.
Se ricevuto per errore, l'uso del contenuto e' proibito; si prega di
comunicarlo al mittente e cancellarlo immediatamente.
12 years
389 vs Sun DS ldapmodify performance
by Russell Beall
Does anybody have a pointer to any performance comparisons between Sun DS and 389?
I was extremely happy with the performance boost using 389 on a Linux VM which is 5-8 times faster for ldapsearch operations than the older Sun machines with Sun DS 6.3.
In testing one of our most important use cases just now, I find that the ldapmodify speed is many many times slower. This doesn't make much sense, so I think I'm doing something wrong or having something misconfigured.
Earlier I improved the write performance by using large db cache sizes and moving the nsslapd-db-home-directory to tmpfs. Now most modify operations have very little I/O wait except when occasionally flushing the index files and such, and yet, there is a CPU pegged for very long periods of time, orders of magnitude higher than on Sun DS.
Is there any documentation on ldapmodify performance that I could review? Google searching seems eerily silent on the issue… (which also leads me to believe I have something misconfigured if nobody has been asking about the issue…)
The particular use case I am working with involves replacing large quantities of uniqueMember values on entries in ou=groups.
Thanks,
Russ.
==============================
Russell Beall
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
beall(a)usc.edu
==============================
12 years
