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.
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?
David - Offbeat http://dafydd.livejournal.com
dafydd - Online http://pgp.mit.edu/
Battalion 4 - Black Rock City Emergency Services Department
Failure is not an option. It comes bundled with the software.
We are trying to setup GSSAPI SASL authentication using Kerberos keytabs
between 389-ds 188.8.131.52 (on Fedora 15) and 184.108.40.206 (on Fedora 17).
However, we are getting an unspecified GSSAPI error. Are there
any known bugs / changes that could possible cause this to happen?
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?
System Administrator, Primatics Financial
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.
System Administrator, Primatics Financial
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.
Washington Research Library Consortium
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
* SSL: certificate subject name '*.mydomain.com' does not match target host
* 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?
where can I find a brief description of the 389 communication between:
- 389 cache
- 389 backend
- COS and VLV
Is there a way to dwell into it without reading the code?
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.
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.
Programmer Analyst IV
Enterprise Identity Management
University of Southern California
I'm looking for some way how to "stack" LDAP sub-trees one on top of another.
What I mean: Let's have two subtrees:
dc=lower and dc=upper
dc=lower contains objects:
cn=obj2,attr A = 2
dc=upper contains objects:
cn=obj2,attr A = 4
Now I push dc=upper on top of dc=lower (let say it creates dc=stack)
Queries with base dc=stack will return:
cn=obj1 --> same object as in dc=lower
cn=obj2 --> same object as in dc=upper, attr A = 2
cn=obj3 --> same object as in dc=lower
cn=obj4 --> same object as in dc=upper
I saw overlays "relay" and "rwm" in OpenLDAP. Is there any support in 389 for
this use case?
I need to override several records from "lower" subtree with object from
"upper" subtree. Problem is, that subtree "lower" can contain 10 000 objects
and I need to override only 5 of them. I'm searching for effective way how to
accomplish this without copying whole subtree "lower" to "upper".
Thanks for your time.