I have one historical plug-in (from times of SunOne Directory), it was
in past ported for 1.2 version of 389 DS. But it fails to work with 1.4.
It is a bit more complicated than the one I was seeking help before, but
maybe it is possible to replace it with some standard plug-in. However,
I didn't find any suitable. :(
We are using attribute named entryStatus with several possible values
like prepared, active, marked, dead - those are used for keeping status
of user entry.
I need to keep track when and by whom was entryStatus attribute
modified. For those informations, we have two attributes
entryStatusTimestamp and entryStatusModifier attributes. And every time
entryStatus is changed, our plugin changes automatically those two
Is there any standard, or maybe some contributed plugin how I can
Jan Tomasek aka Semik
in past, I've created a simple plug-in for disabling authenticated binds
over non-encrypted lines. But still allowing anonymous binds over LDAP.
I did know about nsslapd-require-secure-binds but if recall correctly it
is including SASL authenticated binds which I believe protects only user
password and not transferred data.
I published plug-in here:
but it is maybe obsoleted today.
Today I think is TLS a must. Is it possible to disable 389 port at all?
Or instruct 389 DS to bind port 389 on localhost?
Jan Tomasek aka Semik
We have the following scenario:
We use a "global" password policy at cn=config where a customer of ours defines:
We provide as default configuration "passwordMustChage: on" to force a new user to chage the initial password. In this setup a user whose password expired, i.e. also after this user is created and needs to change its initial password, cannot login to the account, but he can change the password.
The customer now wants a setup which prevents a user whose password expired from changing the password. A plugin "Account Policy Plugin" can therefore be activated by the customer, which uses the following configuration:
dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
As a consequence, the initial password change does not work anymore, thus the customer must change to "passwordMustChange: off". This would probably be acceptable.
A problem is, however, that a user account which has its own user password policy with "passwordexp: off" and "passwordmustchange: off" is affected by the plugin in such a way that the attribute passwordExpirationTime of the user itself is evaluated and the attribute passwordexp of the user password policy is ignored. That means, a user password policy for special user accounts without password expiration cannot be used in combination with the Account Policy Plugin.
Can the plugin be configured to enable this possiblity or is there another way to achieve the desired behaviour?
All developers, and any other interested individuals, should make sure
to "watch" this repo. We moved off of Pagure and onto github, but the
Pagure subscribers were not migrated. So if you want to keep an eye on
what's happening make sure to watch this project!
389 Directory Server Development Team
We have two CentOS 8 directory servers running 389ds. They are setup
with one as a master and the other as a consumer. Both of these servers
use a wildcard GoDaddy SSL cert. The cert has two intermediate certs,
and the root cert.
Initially, I had both intermediates and the root cert chained in a CA
cert file and I used the cockpit web interface to upload the chained
file, to both directory servers.
When I did this, I was able to connect to both directory servers with
Apache Directory Studio. However, replication was not working.
openssl s_client -connect showed that each directory server was only
presenting the server cert and the first intermediate. Still, openssl
reported that everything was "OK". But again, replication wasn't working.
During replication, the master was reporting this in the debug logs:
(error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (unable to get issuer certificate))
In an effort to fix this, I uninstalled the chained intermediate/root
cert file. I then installed both intermediates, individually, and the
the root cert individually. Sure enough, openssl s_client -connect now
showed the full chain (server cert -> intermediate 1 -> intermediate 2
-> root CA cert). And replication started working!
However, now, when I try to connect to either directory server with
Apache Directory Studio, I get the following error:
Error while opening connection
- ERR_04120_TLS_HANDSHAKE_ERROR The TLS handshake failed, reason: Failed to verify certification path: Algorithm constraints check failed on signature algorithm: SHA1withRSA
org.apache.directory.api.ldap.model.exception.LdapTlsHandshakeException: ERR_04120_TLS_HANDSHAKE_ERROR The TLS handshake failed, reason: Failed to verify certification path: Algorithm constraints check failed on signature algorithm: SHA1withRSA
Can anybody assist with telling me either what this error means or what
is the proper way to be installing the intermediate certs into 389ds in
RHEL/CentOS 8, so that both replication and Apache Directory Studio will
Bryan K. Walton 319-337-3877
Linux Systems Administrator Leepfrog Technologies, Inc
I am running into an issue where I am trying to set up a DS master on CentOS 7.
When I run setup-ds-admin.pl, I am able to successfully create the slapd-config instance. But the admin-serv fails to bind to the config. The error is like this
"Sat Jan 02 21:32:12.629960 2016] [:warn] [pid 1497:tid $THREAD] NSSSessionCacheTimeout is
[Sat Jan 02 21:32:12.630027 2016] [:crit] [pid 1497:tid $THREAD] do_admserv_post_config(): unable to create AdmldapInfo
AH00016: Configuration Failed"
I found this post at https://email@example.com... this is not an upgrade for me. Just trying to create the config and admin-serv.
I have the following installed:
I dont believe it is the packages installed, but something missing. When I do install initially, the 389-admin packages, /var/log/dirsrv/admin-serv does not get created. i end up creating it along with the error and access file, then run restorecon -r on the directory.
The server I am working is actually a clone of a working directory server, even more puzzling.
Any suggestions to get past this is greatly appreciated.
Paul M. Whitney
Sent from my browser.