389-users March 2020

389-users@lists.fedoraproject.org

13 participants
17 discussions

Password lockout not working
by Todor Petkov 13 Mar '20

13 Mar '20

Hello, 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 log). Can someone point me, what am I missing here? Versions of packages: 389-admin-console-doc-1.1.12-1.el7.noarch 389-ds-base-1.3.9.1-12.el7_7.x86_64 389-adminutil-1.1.22-2.el7.x86_64 389-ds-base-snmp-1.3.9.1-12.el7_7.x86_64 389-admin-1.1.46-1.el7.x86_64 389-admin-console-1.1.12-1.el7.noarch 389-ds-console-doc-1.2.16-1.el7.noarch 389-ds-1.2.2-6.el7.noarch 389-console-1.1.19-6.el7.noarch 389-ds-console-1.2.16-1.el7.noarch 389-dsgw-1.1.11-5.el7.x86_64 389-ds-base-libs-1.3.9.1-12.el7_7.x86_64 Thanks,

2 3

Force use of secure connections
by Matthew Aguirre 10 Mar '20

10 Mar '20

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 in ds-389. -- Matt

6 5

Re: Console Troubleshooting
by Nelson Bartley 10 Mar '20

10 Mar '20

Hi Mark, 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: 389-ds-base.x86_64 1.4.2.8-3-fc31 Cockpit-389-ds.noarch 1.4.2.8-3-fc31 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. Cheers, Nelson

2 2

cockpit doubt
by Alberto Viana 06 Mar '20

06 Mar '20

Hi Guys, 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? Thanks

4 9

errors messages in /var/log/messges
by Mitja Mihelič 05 Mar '20

05 Mar '20

H! 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 into /var/log/messages. 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? Kind regards, Mitja Mihelič

2 2

Console Troubleshooting
by Nelson Bartley 02 Mar '20

02 Mar '20

Good afternoon, 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...

2 1

winsync password problems
by Alberto Viana 01 Mar '20

01 Mar '20

Hi Guys, 389-Directory/1.4.3.2 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 --bind-dn="CN=my_win_account" --bind-passwd=password --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 Thanks.

3 28

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users March 2020