Re: [389-users] Stumped - SSL works for auth, sudo, etc, but fails for ldap user cronjobs

Just as a follow up to this, on ~5% of our hosts (RHEL[456]), crond would be unable to connect to the ldapserver after /etc/ldap.conf was updated to use SSL. Restarting crond fixed the issue. On Thu, Jul 19, 2012 at 10:54 AM, David Nguyen wrote: > The cert is self-signed, but by different C

Re: [389-users] Stumped - SSL works for auth, sudo, etc, but fails for ldap user cronjobs

s one for days David On Thu, Jul 19, 2012 at 6:34 AM, Carsten Grzemba wrote: > Hi, > > what kind of certificate do you use, selfsigned? Are the certificates signed > by the same CA? > > > > Am 18.07.12, schrieb David Nguyen : > > Hi all, > > I have a strange

[389-users] Stumped - SSL works for auth, sudo, etc, but fails for ldap user cronjobs

Hi all, I have a strange one. My current setup is working perfectly. client1 is able to connect to ldap-server1 via SSL and everything is working correctly. I then had a need to add another ldap server (ldap-server2) as a multi-master replica and everything is working (user auth, sudo via ldap u

[389-users] Require SSL/TLS connections?

Hi All, I have TLS connections working and would like to disable non-SSL connections (ie unencrypted traffic). Same situation as what was asked below in 2007: http://lists.fedoraproject.org/pipermail/389-users/2007-October/006347.html Is this possible with the latest version of 389 DS? Thanks

[389-users] SSH key based login bypasses password policies

Hi all, I noticed that logins via ssh key bypass the LDAP password policies (password ageing, password warning, and password lockout due to failed attempts, etc). Is there any way to force key based ssh logins to respect the password policies? I noticed that if I use the shadow attributes in LDA