I am running a 389 box with TLS enabled. Now I would like to change the
hostname, which would render the current certificate invalid. Is there
an easy way to create a new certificate with the new hostname?
Hi, version: 188.8.131.52build: 2012.180.1655 After audit log is enable, I do not see any record in the audit log after a entry is added. Thanks. $grep changetype log/audit changetype: modify
Hi, I've been struggling to setup 389 Directory server with Start TLS.
I have a multi-master replication working with four server. From an
external client running openldap's ldapsearch, I'm trying to do the
ldapsearch -ZZ -x -h "myserver" -b "dc=example,dc=com" -D "cn=Directory
Manager" -W ""
I get an unsupported protocol error on servers that do not have
In an attempt to resolve this, I tried to install a self-signed cert. I
created a ca.cert and a server.crt, and imported them into the Directory
Server. I then imported the ca.cert to the admin server. When I attempted
to import the same server.crt to the admin server, I got an error message
stating the certificate was for another host. Since the admin server and
directory server reside on the same host, if I generate a new request, it
will have an identical host name (I'm not sure if that's relevant to my
issue). After all of that, I now receive a "Connect Error
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed". I'm guessing I
need to import the root cert onto the client somehow, but I'm not sure how
to go about doing that.
This has become pretty time consuming, so I was hoping that someone more
knowledgeable could confirm that I'm at least travelling down the right
path. I've been following this Red Hat document:
I've installed 10.2.11.15 on a lab machine (fedora17) and set passwordTrackUpdateTime to on in config. This is the first time I'm testing this feature, I dont know if this also happens in former 10.2.11x versions. I've noticed that whenever a password policy is applied to an user, either directly or inherited from branch/ou, the pwdUpdateTime stops updating upon password changes. If I remove the password policy then the attribute works as expected. Is this the correct behaviour?
J u an Carlos Camargo Carrillo
957-211157 , 650932877
Hi Raimund Eimann,
Am 09.07.2012 13:27, schrieb Ray:
> Hi Alberto,
> I got it working, logical, actually:
> When you start out the way I did, i.e. fresh installation, then
> running setup-ds-admin.pl, then setupssl2.sh both services (dirsrv
> dirsrv-admin) will be restarable cleanly, i.e. they do actually run
> (see details below in my initial posting).
> When you then run 389-console, all you need to make sure is
> 1) use the fqdn you configured in /etc/hosts and setup-ds-admin.pl
> in the URI.
> 2) change from http to https in the URI string.
> Please try that out. It works now for me. You should be able to log
> into 389-console and populate you directory at this point.
> The next confusing thing (for the client side) that noone tells you
> (because it's sooo obvious?! - I don't think so…) is that there are
> two ldap.conf files to take care of:
> 1) /etc/openldap/ldap.conf (this one is for the openldap-clients
> [ldapsearch et al.]
> 2) /etc/pam_ldap.conf (this one takes care of the actual OS
> user/group resolution
> Here are mine:
> URI ldap://ldap.baar.intra.bbcomputing.org/
> BASE dc=bbcomputing,dc=org
> TLS_CACERTDIR /etc/openldap/cacerts
> TLS_REQCERT allow
> base dc=bbcomputing,dc=org
> uri ldaps://ldap.baar.intra.bbcomputing.org/
> ssl start_tls
> tls_cacertdir /etc/openldap/cacerts
> pam_password md5
> Now, in both configs you see the tls_cacertdir parameter.
> 1) Make sure you have that directory.
> 2) After you ran setupssl.sh, you should find a certificate in
> /etc/dirsrv/slapd-<server identifier you chose in
> setup-ds-admin.pl>/cacert.asc. Copy this certificate: cp
> /etc/dirsrv/slapd-<server identifier you chose in
> This is not enough. The clients will only pick up certs with
> hashed filenames, so (not very prominent information in the docs
> 3) cd /etc/openldap/cacerts/
> 4) ln -s cacert_389_ldap.pem `openssl x509 -in
> cacert_389_ldap.pem -noout -hash`.0
> You'll need to repeat that on each and every client you plan to use.
> After all this things should work. You can try
> id <username from your directory>
> And see whta comes back. Alternatively you can try
> "getent passwd" to see all users you configures in your directory, or
> "getent group" for the groups
> ldapsearch -x -ZZ -h <fqdn of your ldap machine> should also work and
> return all entries as ldifs.
> Let me know how the things are going
I recently had same trouble with setupssl2.sh on RHEL 5.8 box with
389-console. Your post has been really useful to me. Everything you
have mentioned in the last two posts in this topic have worked
successfully for me. Thanks so much!
389-ds rocks as well as 389-console too :)
I have a web base application and user authenticate web application using
Directory Service (FDS). I want to restrict some user to not allow to login
so i have implement host base deny ACL. But somehow it doesn't works. may
be i am missing something. following acl i have.
(targetattr = "*") (version 3.0;acl "Host ACL";deny (all)(userdn =
> "ldap:///uid=test,ou=People,dc=example,dc=com") and (ip="10.101.100.236");)
But interesting thing is, it works with ldapsearch but not with Web
The 389 Project team is pleased to announce the release of
389-ds-base-184.108.40.206 for Testing. This release fixes another issue
with CLEANALLRUV, some schema and userpassword related fixes, and other
The new packages and versions are:
NOTE: 1.2.11 will not be available for Fedora 16 or earlier, nor for EL6
or earlier - 1.2.11 will only be available for Fedora 17 and later. We
are trying to stabilize current, stable releases - upgrades to 1.2.11
will disrupt stability.
yum install 389-ds --enablerepo=updates-testing
# or for EPEL
yum install 389-ds --enablerepo=epel-testing
yum upgrade 389-ds-base --enablerepo=updates-testing
# or for EPEL
yum upgrade 389-ds-base --enablerepo=epel-testing
How to Give Feedback
The best way to provide feedback is via the Fedora Update system.
Go to https://admin.fedoraproject.org/updates
In the Search box in the upper right hand corner, type in the name
of the package
In the list, find the version and release you are using (if you're
not sure, use rpm -qi <package name> on your system) and click on the
On the page for the update, scroll down to "Add a comment" and
provide your input
Or just send us an email to 389-users(a)lists.fedoraproject.org
If you find a bug, or would like to see a new feature, use the 389 Trac
* Release Notes - http://port389.org/wiki/Release_Notes
* Install_Guide - http://port389.org/wiki/Install_Guide
* Download - http://port389.org/wiki/Download
One ACI related question. I've been learning to use ACIs and read
various documentation. Let's say we have the following structure.
Then we have servers authenticating using credentials.
Question: What kind of ACI is needed to limit server1 access to read
Customer1 entry only?
Would I need to create an ACI for each server separately? I was
wondering that one should limit the amount of ACIs, so is there some
other way to achieve this? Thanks for help!
How Can allow a normal user from my directory (for example
uid=my.appuid,ou=test,dc=test,dc=com ) to add an user entry in the tree?
(Remebering that I dont want this user as a administrator, I just want that
user to be able to add users into a specific subtree in my directory). Is
ldapmodify -a -c -h 389_ds_host -D "uid=my.appuid,ou=test,dc=test,dc=com"
-w - -f test.ldif
adding new entry uid=testando,ou=test,dc=test,dc=com
ldap_add: Insufficient access
ldap_add: additional info: Insufficient 'add' privilege to the
I tried this kind of ACI:
aci: (targetattr="userPassword")(version 3.0;aci "shib writer";allow
aci: (targetattr="*")(version 3.0;aci "shib writer";allow
I've been banging my head against this one for a few hours and was hoping for some input. I have a group:
dn: cn=mxadmins,cn=groups,cn=accounts,dc=int,dc= example,dc=com
memberURL: ldap:///cn=users,cn=accounts,dc=int,dc= example,dc =com??sub?(ou=Supervisor)
description: MX administrators group
From the documentation I've read, there shouldn't be much more I need to then query that group and pull all the unique members into the list, but unfortunately I'm not getting the results I /think/ I should.
I'm running an older version of DS:
Perhaps that's part of the issue, but if anyone can help point me in the right direction it would be greatly appreciated.