I configured password lockout policy for account (5 retries, 30
minutes lockout), but if the user tries to log with bad password,
passwordRetryCount is not being increased (I am tailing the audit
Can someone point me, what am I missing here? Versions of packages:
Is there a way to disable unsecured use of port 389? I am using FreeIPA,
so the client setup uses port 389 with TLS and that is fine, but I'd like
to be able to not allow unsecured connections as much as possible.
I was able to do this in OpenLdap, but haven't seen a comparable solution
Sorry for the delay in getting back to you. Mailing-list didn’t mail me…..
I’ve attached the chrome console log to this email.
The packages I’m using are Fedora 31:
Just as an aside, I’ve also run into exactly the same problem on my
full test server as well, though on that one I had to enable ldapi
according to the RH guidelines via cli, as it was upgraded from 1.2.
I'm testing some versions of 389 and I realise that in newer versions,
cockpit stopped to work to me:
*There is no 389-ds-base package installed on this system. Sorry there is
nothing to manage...*
In my case (due to internal reasons) we compile our version of 389.
Is this an expected behavior? Is it suppose to only work if I have a 389
package installed in the system? There's any workaround for that?
We have set up a new 389DS instance (389-ds-1.2.2-6.el7.noarch) on
CentOS7. Messages from the "errors" log file are also getting written
The instances (389-ds-1.2.2-1.el6.noarch) on CentOS6 do not do that.
I have checked the rsyslog facilities local0-local7 and none of them are
responsible. What could be causing this?
I have fedora 31 cloud server installed on a local virtualbox. I have installed 389-ds and the 389-cockpit admin module.
Using dscreate I created a local instance, and have successfully modified it with external tools.
I have not been able to get the cockpit component to work. Logging in to cockpit, via the root account or my sudo account works, as soon as I click 389ds admin the cockpit window comes up with "oops" "cockpit as experienced an unexpected error".
The admin shows I have an instance, it allows me to send server commands which appear to be successful.
It does not let me create new instances
It does not show any details under any tab (just blank page).
I'm wondering where to start looking to diagnose the problem. Obviously the web site message wasn't helpful, the inspection console is just complaining about css. The system error logs don't show anything out of the ordinary...
The password sync from 389 to windows(2012) is not working:
# dsconf RNP repl-winsync-agmt create --suffix=dc=rnp,dc=local
--host=gti-df-dc01 --port=636 --conn-protocol=LDAPS
--win-subtree=dc=my,dc=domain --ds-subtree=dc=my,dc=domain --win-domain=RNP
--sync-users=on --sync-groups=on --init AD-DF-DC01
Double checked everything including the user permissions on windows AD side
, also checked the windows log and passync log, could not found anything
related (at least the 389 trying to update my user's password or any error)
From windows to 389 works fine.
Attaching the log (in replication debug mode)
Don't know what else to look