SOGo LDAP bind failed after updates

Support
#1

After update Sogo can not login

Authentication Failed
Unhandled error response
Dec 13 22:25:42 sogod [309]: [ERROR] <0x0x7face3ed7fb0[LDAPSource]> Could not bind to the LDAP server ldapi:// (389) using the bind DN: cn=admin01,dc=xxxxx,dc=com
Dec 13 22:25:42 sogod [309]: [ERROR] <0x0x7face3ed7fb0[LDAPSource]> <NSException: 0x7face3e99230> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{“error_code” = 49; login = “cn=admin01,dc=xxxxx,dc=com”; }
Dec 13 22:25:42 sogod [309]: [ERROR] <0x0x7face3ca4fc0[LDAPSource]> Could not bind to the LDAP server ldapi:// (389) using the bind DN: cn=admin01,dc=xxxxx,dc=com
Dec 13 22:25:42 sogod [309]: [ERROR] <0x0x7face3ca4fc0[LDAPSource]> <NSException: 0x7face4268120> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{“error_code” = 49; login = “cn=admin01,dc=xxxxx,dc=com”; }

I need help to configure NethServer to use external OpenLDAP server
#2

Looks like you’re binding a local LDAP provider, could you confirm?

So, those credentials used to work but don’t work any more.

Could you attach the RPMs versions?

rpm -qa | grep -E '(^neth|release)' | sort
1 Like
#3

For server ldapi:// is binding a local LDAP provider

rpm -qa | grep -E ‘(^neth|release)’ | sort
centos-release-7-3.1611.el7.centos.x86_64
centos-release-scl-2-2.el7.centos.noarch
centos-release-scl-rh-2-2.el7.centos.noarch
epel-release-7-8.noarch
nethserver-antivirus-1.2.0-1.ns7.noarch
nethserver-bandwidthd-1.0.0-1.ns7.noarch
nethserver-base-3.0.11-1.ns7.noarch
nethserver-cgp-2.1.1-1.ns7.noarch
nethserver-collectd-3.0.4-1.ns7.noarch
nethserver-directory-3.1.0-1.33.gdb300d6.ns7.noarch
nethserver-dnsmasq-1.6.1-1.ns7.noarch
nethserver-duc-1.4.0-1.ns7.noarch
nethserver-firewall-base-3.1.2-1.ns7.noarch
nethserver-firewall-base-ui-3.1.2-1.ns7.noarch
nethserver-getmail-1.0.0-1.ns7.noarch
nethserver-hosts-1.2.1-1.ns7.noarch
nethserver-httpd-3.1.1-1.ns7.noarch
nethserver-httpd-admin-2.0.4-1.ns7.noarch
nethserver-lang-en-1.1.5-1.ns7.noarch
nethserver-letsencrypt-1.1.2-1.ns7.noarch
nethserver-lib-2.2.1-1.ns7.noarch
nethserver-lsm-1.2.0-1.ns7.noarch
nethserver-mail-common-1.6.2-1.ns7.noarch
nethserver-mail-filter-1.4.3-1.ns7.noarch
nethserver-mail-server-1.10.4-1.ns7.noarch
nethserver-mail-smarthost-0.1.0-1.ns7.noarch
nethserver-memcached-1.1.0-1.ns7.noarch
nethserver-mysql-1.1.0-1.ns7.noarch
nethserver-nethforge-release-7-0.3.ns7.noarch
nethserver-ntp-1.1.0-1.ns7.noarch
nethserver-openssh-1.2.0-1.ns7.noarch
nethserver-p3scan-1.1.2-1.ns7.noarch
nethserver-phonehome-1.2.1-1.ns7.noarch
nethserver-php-1.2.0-1.ns7.noarch
nethserver-release-7-0.5.ns7.noarch
nethserver-roundcubemail-1.2.4-1.9.g849b0ce.ns7.noarch
nethserver-smartd-1.1.0-1.ns7.noarch
nethserver-sogo-1.6.1-1.ns7.noarch
nethserver-spamd-1.0.0-1.ns7.noarch
nethserver-sssd-1.0.8-1.56.g3ee0f8e.ns7.noarch
nethserver-unbound-1.1.0-1.ns7.noarch
nethserver-yum-1.4.1-1.ns7.noarch

#4

I guess @mark_nl can lend us an hand!

#5

same issue here!

#6

In Nethforge testing is a nethserver-sogo package which uses the SSSD ldapURI() method to read the (open)Ldap URI from the nethserver-sssd configuration. This solves the ldapi// failure.

However:

This package still relies on providing a bind userDN ($bindDN = $sssd->bindDN()) and a bind password ($bindPassword = $sssd->bindPassword()), reading other threats i’m not sure this still works with the new nethserver-sssd.

I can test it tomorrow in the evening, if it’s easy i’ll fix this then.

3 Likes