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

NethServer Version: 7.4
Module: Sogo+Jabber

Hello,

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.

Sogo
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]: 192.168.0.24 “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://ad.z62.nl (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 ‘192.168.0.24’ for user ‘frank’ might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0
Jan 03 13:46:59 sogod [29531]: 192.168.0.24 “POST /SOGo/connect HTTP/1.1” 403 34/85 0.348 - - 10M

Jabber
The ejabberd.log says:

2018-01-03 14:01:52.860 [info] <0.422.0>@eldap:connect_bind:1062 LDAP connection on ad.z62.nl:636
2018-01-03 14:01:52.960 [warning] <0.422.0>@eldap:report_bind_failure:1007 LDAP bind failed on ad.z62.nl:636
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:

㤋牢ꝰ뷌㒶禸㸶둯괘ⰳ⥰㠄﷗窙㠂⺥㈃ś꼮朔㎸楞畅昲ȓ纹纙구껿挍懅㫲⿽㙊ꢉu㐴㣆湼閭持歝ꭸ㿢⻲ή㡛뗦焌﷘ﺆ浌渺梹꧘畃禺擆旚橯殯궚ﶵ熱攉ꒋ⧺ՙ⡹Ⱖ⡌ﹾޅ®ﴶ璭ⷡ꣒ﵤ獯懙(琬㕩ﶩ뭛뜵綊높긙㡖敓ꮌ睾浇烚ꃮ됃뫛淭檐汉ƈ⻲・⠻ē扱矐畖ﶉ燋Ȣ⻀꟝悾爴^榎꒟긖ꀄ㟵՘湛넱ꗀ睛⸟ꍪꃽ綥蝹Ҝ긭밒濑㪻ꏚ뼎㈬㦫昜è㕈啕推﮾둫瑆껷毸祃ꃌ㫖븁뾌﹎⼩璆괉D떭ꮧꞑ㛰ꤗ

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

Reference:

3 Likes

@mrmarkuz
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…

@Giacomo
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:
4 Likes

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;
4 Likes