Rc2 QA/testing campaign

davidep · November 30, 2016, 2:17pm

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!

See also

/cc @quality_team

alefattorini · November 30, 2016, 5:18pm

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

More info about QA process here:

mark_nl · November 30, 2016, 10:02pm

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.

davidep · December 1, 2016, 9:30am

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.

davidep · December 1, 2016, 2:36pm

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

stephdl · December 1, 2016, 2:46pm

over ssl always

davidep · December 1, 2016, 3:04pm

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!

flatspin · December 1, 2016, 3:25pm

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.

davidep · December 1, 2016, 3:46pm

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.

flatspin · December 1, 2016, 4:04pm

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…

GG_jr · December 1, 2016, 4:32pm

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.

gabriele_bulfon · December 1, 2016, 4:35pm

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.

Gabriele

flatspin · December 2, 2016, 7:56am

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

mark_nl · December 3, 2016, 2:41pm

by default means including binding to a local authentication provider?

mark_nl · December 3, 2016, 2:45pm

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

davidep · December 3, 2016, 3:27pm

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.

mark_nl · December 3, 2016, 8:20pm

oke,

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…

EDIT:
Its od samba ssl seems to work:
https://wiki.samba.org/index.php/Samba_AD_DC_Port_Usage

davidep · December 3, 2016, 11:41pm

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

mark_nl · December 4, 2016, 2:08pm

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