Sogo default config doesn't work on nethserver 7 beta 2 when using Samba Active Directory

Hi,

Sogo default configuration points to 127.0.0.1:389 to find the LDAP server. This is not correct when using the Samba Active Directory which resides in a linux container with a user defined ip address.

This should be detected and handled when installing the Sogo app.

1 Like

please what is the output of

rpm -qa nethserver-dc; rpm -qa nethserver-directory

2 Likes

Please, provide us some details about your problem so we can go further :slight_smile:

1 Like

I’ll post you an update late this evening.

nethserver-dc-1.0.7-1.ns7.x86_64

nethserver-directory is not installed since the “Samba Active Directory” is installed.

If that matters :

nethserver-samba-2.0.2-1.ns7.noarch

I solved my problem by editing sogo.conf :
hostname = ldap://192.168.0.250;

(192.168.0.250 being the address I chose at the AD initialisation)

so it is a bug, welcome on board, can you paste the relevant part of your sogo configuration.

@mark_nl are you aware of this issue ?

1 Like

the toolkit required to fix it is on the testing version of NethServer::SSSD :wink:

please @pagaille you are welcome to test the fix of @davidep and report back :slight_smile:

No, basic tests worked so far, I will look in to this:

The ip for Lpad in in the sogo configuration is read from a sssd db entry ($ldapURI = $sssd->ldapURI(); )

I have not checked this, will do and report.

It would help me to debug this if you can remember if you installed sogo before or after the AD authentication provider.

Thx for reporting this!

1 Like

Hi,

That might be a good lead indeed : I remember i installed the OpenLDAP server before (by mistake).

Thanks Steph.

How should I test ? Remove Sogo and the AD, update then install again ? (It’s working now, I edited sogo.conf manually)

Hi @pagaille ,

The best way is to install and configure the account provider and after that anything you want. In this case, Samba AD and then, SOGo.

Still not working :

  • Did a yum --enablerepo=nethserver-testing update :
    Updated: dovecot-antispam.x86_64 0:0.0.49-3.3.gca425d9.ns7 nethserver-base.noarch 0:3.0.11-1.4.geb68376.ns7 nethserver-dc.x86_64 0:1.0.7-1.3.gfac89e9.ns7 nethserver-ejabberd.noarch 0:1.1.2-1.2.gd32b6bd.ns7 nethserver-mail-server.noarch 0:1.10.4-1.3.g186327a.ns7 nethserver-samba.noarch 0:2.0.2-1.2.g15d0e6c.ns7 nethserver-sssd.noarch 0:1.0.8-1.25.g1340b2f.ns7 python2-crypto.x86_64 0:2.6.1-10.el7

  • Rebooted

  • Removed Sogo app from the Software Center

  • Deleted the sogo.conf file

  • Installed again using the Software Center

  • Tried to authenticate on Sogo : failure.

  • Checked sogo.conf and changed hostname = ldap://127.0.0.1; by hostname = ldap://192.168.0.250;

Working again.

How can I help further ?

That’s what I did. Only I happened to install the OpenLDAP server first by mistake, then installed the AD, then installed SOGO.
Error seems reproducible (see above post)

I see.

It’s very hard for you to try all from scratch, in the proper order?
If you use VM …

This could be a problem. You must be sure this file does not exist in your machine:

rpm -qf /etc/e-smith/db/configuration/force/sssd/LdapURI

If the file exist remove nethserver-directory:

yum remove nethserver-directory

Thnx for this feedback, now it is clear the nethserver-sogo package has to improve.
We need (better) hooks to update the sogo.conf if the authentication-provider / sssd-configuration is changed.

I work on it!

1 Like

Sadly not

 rpm -qf /etc/e-smith/db/configuration/force/sssd/LdapURI
 error: file /etc/e-smith/db/configuration/force/sssd/LdapURI: No such file or directory

I tried to install from scratch on an VM to try to reproduce the bug.

It wasn’t easy, since lot of issues happened, the install is not yet as straightforward as it should be. Especially, the system should update itself automatically during or just after the first install.

Regarding SOGO Ldap authentication :

After having installed the updates (not from the testing repo), then the Samba AD module, then configured it, then installed SOGO, there was something really unexpected : the system detected another LDAP server on the same subnet and decided to use it.

This other LDAP server is the one running on another nethserver running on the same subnet. Why did the installer choose that one and not the locally hosted one ?

So… I think I found another bug by chance @mark_nl :wink:

More generally I believe that while it was certainly decided for really good reason, making the AD samba server reside in a linux container with a user defined IP address will more that certainly lead to mistakes and configuration headaches.

Don’t hesitate to ask if I can help further.

Matthieu

1 Like