They were configured to bind anonymously.
Here is the authentication-related configuration of both Trac and Cacti, the two remote applications failing to authenticate, as well as their slapd logs in the nethserver.
Trac uses the following Apache configuration:
In slapd logs, Trac authentication attempts look like the following:
Nov 14 18:40:53 nethserver slapd: conn=6647 fd=25 ACCEPT from IP=192.168.8.2:53076 (IP=0.0.0.0:389)
Nov 14 18:40:53 nethserver slapd: conn=6647 op=0 BIND dn="" method=128
Nov 14 18:40:53 nethserver slapd: conn=6647 op=0 RESULT tag=97 err=0 text=
Nov 14 18:40:53 nethserver slapd: conn=6647 op=1 SRCH base=“ou=People,dc=directory,dc=nh” scope=2 deref=3 filter="(&(objectClass=inetOrgPerson)(uid=al))"
Nov 14 18:40:53 nethserver slapd: conn=6647 op=1 SRCH attr=uid
Nov 14 18:40:53 nethserver slapd: <= bdb_equality_candidates: (uid) not indexed
Nov 14 18:40:53 nethserver slapd: conn=6647 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Nov 14 18:40:53 nethserver slapd: conn=6647 op=2 BIND dn=“uid=al,ou=People,dc=directory,dc=nh” method=128
Nov 14 18:40:53 nethserver slapd: conn=6647 op=2 RESULT tag=97 err=49 text=
Nov 14 18:40:53 nethserver slapd: conn=6647 op=3 UNBIND
Nov 14 18:40:53 nethserver slapd: conn=6647 fd=25 closed
Cacti configuration looks like the following:
In slapd logs, Cacti authentication attempts look like the following:
Nov 14 18:45:25 nethserver slapd: conn=6676 fd=25 ACCEPT from IP=192.168.8.2:53360 (IP=0.0.0.0:389)
Nov 14 18:45:25 nethserver slapd: conn=6676 op=0 BIND dn=“uid=al,ou=People,dc=directory,dc=nh” method=128
Nov 14 18:45:25 nethserver slapd: conn=6676 op=0 RESULT tag=97 err=49 text=
Nov 14 18:45:25 nethserver slapd: conn=6676 op=1 UNBIND
Nov 14 18:45:25 nethserver slapd: conn=6676 fd=25 closed
Thank you very much for your detailed report @areguera. It was a great help to understand the problem!
From your log trace i see Trac/Apache(mod_ldap) performs two BINDs during the same “conn=6647”. The first is anonymous, but the second sends a clear-text password. For this reason the whole connection must be protected by TLS.
I tried to reproduce your Trac setup. Again, thank you for sharing it!
The slapd log trace was the same, so I tweaked the config to use STARTTLS. Just append “STARTTLS” to AuthLDAPURL line:
AuthLDAPURL "ldap://192.168.122.7/ou=People,dc=directory,dc=nh?uid?sub?(objectClass=inetOrgPerson)" STARTTLS
I think the ACLs from nethserver-directory-3.0.2 allowed authenticated BIND over an already established anonymous connection without TLS, from remote hosts. This is bad and the latest update tried to fix it. I’m sorry for the inconvenient it caused.
From the dev manual, to inspect ACLs:
ldapsearch -LLL -Y EXTERNAL -b cn=config -s one 'objectClass=olcDatabaseConfig' olcAccess 2>/dev/null | perl -MMIME::Base64 -MEncode=decode -n -00 -e 's/\n +//g;s/(?<=:: )(\S+)/decode("UTF-8",decode_base64($1))/eg;print'
On upgraded rc2 systems the output shows new ACLs prepended to older ones.
Let’s make a recap of the issues reported here! First of all thank you very much for your feedback @stef, @transocean and @areguera!
You reported different issues.
Nextcloud. It has been fixed and an update is available: nethserver-nextcloud-1.0.3-1.ns7.noarch.rpm.
Roundcube (Webmail). This has been reported also in another thread.
SOGo. This is not clear because @areguera didn’t confirm it. Perhaps it is related to the previous one (sieve filters)? We need more information to move forward: please report them in this discussion
Impossible to send mails via SOGo
Connections from external, remote applications didn’t work any more. This is explained by my previous post. I hope the fix works.
Now we’re waiting for the testing of nethserver-mail-server and nethserver-roundcubemail packages. Also a fix is required to nethserver-sssd.
All the problems were solved after upgrading sssd, nextcloud and
following your instructions. The only thing i had to do was dealing with
passwords in the dashboard after nextcloud had successfully
re-established connections with Openldap.
Thanks to all developpers/Grazie mille
(I’ll close the ticket in the evening)
Did you test the nethserver-nextcloud-1.0.3-1.ns7.noarch.rpm package?
Please @transocean and @areguera can you upgrade to the testing package?
I’d like to put this issue into a verified status
That’s it. Yum.log says :
Nov 14 17:14:26 Updated: nethserver-nextcloud-1.0.3-1.ns7.noarch
Hope it’ll help. If you have no other question, then the topic can be closed.
2 posts were split to a new topic: Impossible to send mails via SOGo
Yes I did. Nextcloud authentication works as expected. No authentication issues on it so far.
nethserver-sssd-1.0.8-1.2.g9e5d710 test packages were installed in the server where central openLDAP authentication takes place. No issue so far. Both local and external applications are working as expected.
I need to say that before installing these packages I had applied @davidep’s tuneup and had changed external application configuration to use TLS as he also described. After doing this, the authentication issues once presented on applications (both local and remote) went away and the remote authentication process end up being more secure now.
Thank you very much for such an excellent support and educative debate!
I did have the same problem and am using various devices with e-mail and XMPP client software, took me a while to work out what was happing.
Also, the last update did something weird to my DNS (still not sure what actually happened!)
All is working now though.
@areguera wow! Great help here.
NethServer family… please…
I don’t have any troubleshootings left using slapd ; after you solved authentification problem in openldap, i could not send mails in SOGo. It was my latest minor problem and uninstalling and re-installing SOGo this evening solved it.
Everything works fine now, so how can i help ?
You already did it! We will release soon the official updates!
NethServer : a wonderful project handled by nice people
This topic was automatically closed after 3 days. New replies are no longer allowed.