Sogo+Jabber cannot bind to ldap, possibly due to binary data in password

NethServer Version: 7.4
Module: Sogo+Jabber


I’m new to NethServer 7.4 since last month. I feel very pretty :slight_smile: using it at home, so that all client (windows) computers can login to the AD domain. Unfortunately I cannot get Sogo and Jabber working.

The sogod.service failed, it says:

Cannot read configuration from ‘/etc/sogo/sogo.conf’.

When I edit the conf-file I can see that the bindPassword is in binary format between quotes. After I deleted this binary data between the quotes, the service is running OK but (of course) I still cannot login to Sogo, as it says in the log:

Jan 03 13:46:46 sogod [29531]: “GET /SOGo/ HTTP/1.1” 200 8204/0 0.071 26614 69% 3M
Jan 03 13:46:59 sogod [29531]: <0x0x55940a9f7380[LDAPSource]> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{“error_code” = 49; login = “samaccountname=frank,dc=ad,dc=z62,dc=nl”; }
Jan 03 13:46:59 sogod [29531]: [ERROR] <0x0x55940a55d1c0[LDAPSource]> Could not bind to the LDAP server ldaps:// (389) using the bind DN: Z62\SERVER$
Jan 03 13:46:59 sogod [29531]: [ERROR] <0x0x55940a55d1c0[LDAPSource]> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{“error_code” = 49; login = “Z62\SERVER$”; }
Jan 03 13:46:59 sogod [29531]: SOGoRootPage Login from ‘’ for user ‘frank’ might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0
Jan 03 13:46:59 sogod [29531]: “POST /SOGo/connect HTTP/1.1” 403 34/85 0.348 - - 10M

The ejabberd.log says:

2018-01-03 14:01:52.860 [info] <0.422.0>@eldap:connect_bind:1062 LDAP connection on
2018-01-03 14:01:52.960 [warning] <0.422.0>@eldap:report_bind_failure:1007 LDAP bind failed on
Reason: invalidCredentials

The ejabberd.cfg also has the binary data between quotes for the ldap_password.

How can I change the configuration so that I can use Sogo and Jabber?

Best regard,

Frank Timmers

Hi @ftimmers,

welcome to NethServer Community!

I could reproduce your problem and it seems that some binary passwords are working with sogo while others don’t. For ejabberd I had to use an AD user, the machine account was not working.

For making sogo work you may unbind/rebind your AD to get another bind password.

For ejabberd change two lines in /etc/ejabberd/ejabberd.cfg and enter previously created AD user credentials:

 {ldap_rootdn, "YOURDOMAIN\\someuser"},
 {ldap_password, "SOMEUSERSPASSWORD"},

This is just a workaround working until next reboot or config change. If it works for you, we may create a custom template so it will be applied permanently.

This is my not working binary password killing sogo:


I isolated the char breaking sogo, it’s just this one in this case: “﷗” <- put this char in your sogo.conf even as comment and sogo won’t start anymore… @stephdl, @mark_nl, do you have an idea how to find out which chars are killing sogo and not use them in bind password anymore?

1 Like

This is a bold move, but you could try to install testing packages which should solve the problem.
From the command line:

yum --enablerepo=nethserver-testing update nethserver-dc nethserver-sssd



Thank you very much for your help.
For ejabberd your solution worked :laughing:, even after a reboot. I hardcoded ‘someuser’ to ‘admin’ and the password to the admin-password. I assume that after an update of config change these lines have to be (hardcoded) changed again.
I haven’t tested the unbind/rebind AD to get another bind password for making sogo work, so I cannot tell you whether this solution works…

Thank you also very much for your help.
I tried to install the testing packages and this solved :laughing: the problems, for ejabberd and sogo. In the config files I saw a new account ‘ldapservice’ was created with a non-binary password. Everything seems to work fine, I tested:

  • sending and receiving email;
  • login in on windows client to AD and reading/writing files;
  • sogo login;
  • ejabberd.
    In the accounts provider page I saw a new section:

Hi Markus,

It’s quite embarrassing, over lunch I tried to fire up an new Nethserver VM and was not able to get Sogo running. sogod was not able to read the configuration from sogo.conf to write it to its internal configuration in /var/lib/sogo/GNUstep/Defaults/sogod.plist. After creating a “custom” bind user it worked.
So the binary passwords seem to be a bigger problem as expected or something else is bugging sogod to read the configuration. Which leaves the question if the sogo.conf is parsed to sogod.plist on existing installs at all or does it work because the existents of an former configuration?

Hi Mark,

the testing update, that @giacomo recommended, should solve all these problems.

With this update the binary password is not used in sogo anymore. An ldapservice user is now used in sogo (and other LDAP apps):

My updated testserver:

bindDN = "ldapservice@AD.DOMAIN.LOCAL";
bindPassword = "tpiym4sZtGS3YZKB";
baseDN = "dc=ad,dc=domain,dc=local";
hostname = ldaps://ad.domain.local;