Rc2 QA/testing campaign

There have been some issues around “remote account providers”. For instance:

Whilst glibc/PAM based apps, like Dovecot and Samba file server, rely on sssd setup, some applications still connect directly to the account provider and must support all possible scenarios. To cope with them, the configuration should read the settings from NethServer::SSSD Perl module. I tried to improve it with

  • Better default values / prop override handling
  • STARTTLS, LDAPS support

So there are updates to nethserver-sssd, nethserver-dc, nethserver-directory. Furthermore the core applications that connect the LDAP/AD directly are

  • nextcloud
  • webtop4 (can’t work with ldaps by now)
  • ejabberd (the ldap roster wants to browse the LDAP)
  • roundcube (the public addressbook wants to browse the LDAP)

In NethForge we have SOGo, that still requires some work /cc @mark_nl.

I need your feedback! Please update those packages from nethserver-testing repository and report any successful/failed case! :construction_site:

See also

  1. https://github.com/NethServer/dev/issues/5161
  2. https://github.com/NethServer/dev/issues/5158
  3. https://github.com/NethServer/dev/issues/5156

/cc @quality_team


That’s a big chance to help effectively the project and be noticed by our @quality_team coordinator @dz00te :slight_smile:

More info about QA process here:


I don’t know a lot about the schema’s MS uses, I know there is a difference between MS server 2003 and 2008 (and above).

If ns7 binds to a external AD does the (sssd) bindDN db entry include all attributes? ( CN=bind_user_name, CN=Users, DC=server, DC=domain, DC=net)

I’m pretty sure connecting over secure lapds is possible, (as said before) i still have to look into the new sssd package. I get back to you if further questions come up.


It seems we have a new corner-case to support!

By now, when joined to AD, NethServer::SSSD returns the computer account credentials to applications (namely SOGo, NextCloud, Ejabberd, Roundcube) that bind the LDAP directly. Today I verified that Microsoft Active Directory (2012 at least) does not allow simple binds with the computer account credentials, whilst Samba does.

[root@vm7 ~]# ldapsearch -x -H ldap://nethad.org -D 'cn=VM7,cn=Computers,dc=nethad,dc=org' -w 'rightpassword' '(objectClass=computer)'
ldap_bind: Invalid credentials (49)
	additional info: 80090308: LdapErr: DSID-0C0903D9, comment: AcceptSecurityContext error, data 710, v2580

Find the differences:

[root@vm7 ~]# ldapsearch -x -H ldap://nethad.org -D 'cn=VM7,cn=Computers,dc=nethad,dc=org' -w 'wrongpassword' '(objectClass=computer)'
ldap_bind: Invalid credentials (49)
	additional info: 80090308: LdapErr: DSID-0C0903D9, comment: AcceptSecurityContext error, data 52e, v2580

I couldn’t find any documentation for data 710 code, whilist data 52e is “wrong password”.

In other words, when we join to Microsoft AD, the machine account is not good for our purpose and we must ask the admin for other credentials. There should be an AD account, with a non-expiring password and read-only access to LDAP that we can use to browse the LDAP.

1 Like

A better default value if the provider is AD would be ldaps://. As I wrote on the issue #5161:

Recent Active Directory admin practice allows LDAP simple binds over SSL-protected connections only.

I was talking with @filippo_carletti and @giacomo this morning, and we agree to set ldaps:// as default protocol for the so-called third-party apps (SOGo, WebTop, Ejabberd, Roundcube, NextCloud).

We could add ldaps support on WebTop4 soon. /cc @gabriele_bulfon

A downgrade to ldap:// would be possible with a couple of commands.

What do you think? /cc @dev_team @quality_team


over ssl always


We also agreed to disable SSL certificate verification, as a Man-In-The-Middle attack in LAN could be the smallest problem in a compromised LAN.

If, on the contrary, we enable certificate verification, all those apps would stop working until either

  • valid certificates are purchased and installed on network clients
  • or custom CA certificate is installed on the network clients

This scenario requires a lot of hardening work for the sysadmin; we would like to provide a simple setup by default.

Please comment!

IMO a simple default setup is always the best approache. If someone what’s to complicate something because of security concerns he/her is free to do it. The MITM solution causes a lot of problems or at least a lot of work. The new solution is easy to handle and effective. Like it. Please keep it. :slight_smile:


I’m happy you agree, and I hope others will chime in, too!

There’s another proposal. I hope you agree on this, too:

We could store locally the credentials supplied to join the AD domain (see issue 5165) and use them to bind LDAP. Of course, before doing so, we would ask the admin to confirm.

As above, this choice would ease the initial configuration, but is not optimal from the security point of view. To harden this configuration in a further step an specific account should be created on AD with a non-expiring password and on NethServer apps should bind LDAP with it.

I can’t give a fundamental technical statement, because I’ve not much experience with AD.
But I think it’s similar to above. If the way to store logically credentials is acceptable from point of security and not really to weak, everybody is free to harden the system by additional steps (and often complicate things).
You maybe just have to write a HowTo, but that’s another discussion… :smile:

1 Like

IMO, this is different than the web access.
Usually, Active Directory is used to secure and protect the data access.
A computer/user can be joined into an AD domain only by the system administrator.
This action is one time and rarely.
If anything could compromise these things (secure and protect the data), should be avoided.

Just for the curious (cit. A.H.) : we have implemented ldaps on webtop5 using more modern ldap libraries, we have to check webtop4 ldap libraries (an older implementation from Novell) if they will help us implement ssl/tls.



I’m one of the curious. When will you release WT5? Is there a date yet?

by default means including binding to a local authentication provider?

IMHO: it’s a small trade of which makes configuration simple.

1 Like

Yes, when the accounts provider is AD, both “local” and remote.

By default Samba4 does not allow simple binds on LDAP:// I’d like to enforce the default policy.

1 Like


Briefly tested binding SOGo to samba over ldaps:// and it seems to work!

Currently nethserver-sogo binds to openldap over unix sockets (ldapi://).
I’ll guess (did not test it) this isn’t working for a remote openldap (ie ns6). Although for a local bind ldapi:// is fast and secure deploying the the SSSD LpadURI makes the sogo configuration more rigid.

I am worried about binding to a remote openldap over ssl, IIRC openldap listens to port 636 for ssl connections. If this is true we would need a port entry in the SSSD config…

Its od samba ssl seems to work:

I think sogo.conf template should expand the values from NethServer::SSSD API avoiding hardcoding ldapi://, unless the admin set LdapURI prop to that value explicitly.

Hints (IIRC)

  • if URI is like ldap://hostname/?starttls in SOGo, a STARTTLS command is issued. You could append “?starttls” to LdapURI if required by NethServer::SSSD, method startTls()

  • sogo supports the LdapURI syntax. ldaps scheme implies port 636 by default.

  • if you need a port number invoke port() method

1 Like

done: in nethforge testing, version 1.6.1-1.14.g6835f7b.