[SOLVED]Sogo+AD+Chinese Typo on sogo.conf - I do not understand

I tested with a full ns7.4 updated before to install nethserver-dc and after nethserver-sogo

1 Like

I tested it on updated 7.4b1 with local AD, and it works, even with binary password in sogo.conf. Didn’t test remote AD for now.

1 Like

Tested remote ad now. Joined a 7.4b1(remotead) to a 7.4b1 DC(testserver) with Samba 4.6.8 container and installed sogo…

/var/log/messages:

Oct 20 17:32:20 remotead esmith::event[35839]: [ERROR] /usr/libexec/nethserver/smbads: failed to add service primaries to system keytab
Oct 20 17:32:20 remotead esmith::event[35839]: [ERROR] /usr/libexec/nethserver/smbads: failed to initialize keytabs
Oct 20 17:32:20 remotead esmith::event[35839]: Action: /etc/e-smith/events/nethserver-mail-server-update/S50nethserver-sssd-initkeytabs FAILED: 5 [1.262279]
...
Oct 20 17:32:24 remotead esmith::event[36074]: expanding /etc/sogo/sogo.conf
Oct 20 17:32:24 remotead esmith::event[36074]: Traceback (most recent call last):
Oct 20 17:32:24 remotead esmith::event[36074]:  File "<stdin>", line 3, in <module>
Oct 20 17:32:24 remotead esmith::event[36074]: KeyError: 'SECRETS/MACHINE_PASSWORD/AD'
Oct 20 17:32:24 remotead esmith::event[36074]: WARNING in /etc/e-smith/templates//etc/sogo/sogo.conf/45user_source: Use of uninitialized value $secret in scalar chomp at /usr/share/perl5/vendor_perl/NethServer/SSSD.pm line 309.
Oct 20 17:32:24 remotead esmith::event[36074]: WARNING in /etc/e-smith/templates//etc/sogo/sogo.conf/45user_source: Use of uninitialized value $bindPassword in substitution (s///) at /etc/e-smith/templates//etc/sogo/sogo.conf/45user_source line 62.
Oct 20 17:32:24 remotead esmith::event[36074]: WARNING in /etc/e-smith/templates//etc/sogo/sogo.conf/45user_source: Use of uninitialized value $bindPassword in concatenation (.) or string at /etc/e-smith/templates//etc/sogo/sogo.conf/45user_source line 63.
Oct 20 17:32:24 remotead esmith::event[36074]: WARNING in /etc/e-smith/templates//etc/sogo/sogo.conf/45user_source: Use of uninitialized value $bindPassword in concatenation (.) or string at /etc/e-smith/templates//etc/sogo/sogo.conf/45user_source line 63.
Oct 20 17:32:24 remotead esmith::event[36074]: WARNING: Template processing succeeded for //etc/sogo/sogo.conf: 4 fragments generated warnings

/var/log/sogo/sogo.log

Oct 20 17:44:57 sogod [36179]: 192.168.221.1 "POST /SOGo/connect HTTP/1.1" 403 34/84 0.034 - - 576K
Oct 20 17:45:14 sogod [36179]: <0x0x555d78f65160[LDAPSource]> <NSException: 0x555d78fb0040> NAME:LDAPException REASON:operation bind failed: Strong(er) authentication required (0x8) INFO:{"error_code" = 8; login = "samaccountname=testuser,dc=ad,dc=domain,dc=local"; }
Oct 20 17:45:14 sogod [36179]: [ERROR] <0x0x555d78f5c730[LDAPSource]> Could not bind to the LDAP server ldap://nsdc-testserver.ad.domain.local (389) using the bind DN: AD\REMOTEAD$
Oct 20 17:45:14 sogod [36179]: [ERROR] <0x0x555d78f5c730[LDAPSource]> <NSException: 0x555d78fb1ff0> NAME:LDAPException REASON:operation bind failed: Strong(er) authentication required (0x8) INFO:{"error_code" = 8; login = "AD\\REMOTEAD$"; }
Oct 20 17:45:14 sogod [36179]: SOGoRootPage Login from '192.168.221.1' for user 'testuser' might not have worked - password policy: 65535  grace: -1  expire: -1  bound: 0
  • Changing TLS to yes in Account Provider doesn’t help so trying with this:

but new error(the credentials are correct, I tried several times and copy/pasted)

Oct 20 18:07:01 sogod [37256]: [ERROR] <0x0x55da720b6850[LDAPSource]> Could not bind to the LDAP server ldap://nsdc-testserver.ad.domain.local (389) using the bind DN: AD\REMOTEAD$
Oct 20 18:07:01 sogod [37256]: [ERROR] <0x0x55da720b6850[LDAPSource]> <NSException: 0x55da72176ad0> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{"error_code" = 49; login = "AD\\REMOTEAD$"; }
Oct 20 18:07:01 sogod [37256]: SOGoRootPage Login from '192.168.221.1' for user 'markus' might not have worked - password policy: 65535  grace: -1  expire: -1  bound: 0

Roundcube login is working but join to remote AD is strange:

[root@testserver ~]# account-provider-test dump
Traceback (most recent call last):
  File "<stdin>", line 3, in <module>
KeyError: 'SECRETS/MACHINE_PASSWORD/AD'
{
   "BindDN" : "AD\\REMOTEAD$",
   "LdapURI" : "ldap://nsdc-testserver.ad.domain.local",
   "StartTls" : "",
   "port" : 389,
   "host" : "nsdc-testserver.ad.domain.local",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "DC=ad,DC=domain,DC=local",
   "GroupDN" : "DC=ad,DC=domain,DC=local",
   "BindPassword" : null,
   "BaseDN" : "DC=ad,DC=domain,DC=local",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Ddomain%2Cdc%3Dlocal"
}

Oops, I noticed there is a wrong bind dn, should be DOMAIN\REMOTEAD$. I deleted my changes regarding tls weak auth.
I did an unbind and join again via web UI and now sogo login works.

AD join looks good again:

[root@remotead ~]# account-provider-test dump
{
   "BindDN" : "DOMAIN\\REMOTEAD$",
   "LdapURI" : "ldap://nsdc-testserver.ad.domain.local",
   "StartTls" : "",
   "port" : 389,
   "host" : "nsdc-testserver.ad.domain.local",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "DC=ad,DC=domain,DC=local",
   "GroupDN" : "DC=ad,DC=domain,DC=local",
   "BindPassword" : "篅毝뼍籥מּ뻉...",
   "BaseDN" : "DC=ad,DC=domain,DC=local",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Ddomain%2Cdc%3Dlocal"
}

Fun, I tested like you the unbind, and bind it again with the same parameters, this time the bind has been successful.

But I can still not use sogo until

I had ldaps and i restart sogo

-        hostname = ldap://ad.plop.org;
+        hostname = ldaps://ad.plop.org;

fun that when you install sogo on the local samba4ad the correct ldaps url is there, but when you install sogo with a remote account provider the ‘$sssd->ldapURI();’ gives back a bad url

do you noticed it in the sogo.conf file @mrmarkuz

I could force the bad ldaps url by

    #force the ldaps url
    $ldapURI =~ s/ldap:/ldaps:/;

but before I would prefer to understand why NethServer::SSSD doesn’t give the good ‘ldapURI’ when I bind to a remote (NS) samba4 AD

when the user authentication (nethserver-dc) is installed on the nethserver

[root@ns7dev ~]# account-provider-test dump
"LdapURI" : "ldaps://ad.plop.org",

when I bind to the remote samba4 AD (user authentication is remote)

[root@ns7dev6 ~]# account-provider-test dump
 "LdapURI" : "ldap://nsdc-ns7dev.ad.plop.org"

why the LdapURI is no the same ???

do I can force the ldaps url in the sogo code @giacomo @davidep

1 Like

No, it worked without changing sogo.conf but I had old nethserver-dc version on testserver samba dc, so I removed nethserver-dc-1.2.6-1.9.g6e3010d.ns7.x86_64 and installed nethserver-dc-1.3.0-1.ns7. Then I got on the remotead:

[root@remotead ~]# account-provider-test dump
{
   "BindDN" : "DOMAIN\\REMOTEAD$",
   "LdapURI" : "ldap://nsdc-testserver.ad.domain.local",
   "StartTls" : "",
   "port" : 389,
   "host" : "nsdc-testserver.ad.domain.local",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "DC=ad,DC=domain,DC=local",
   "GroupDN" : "DC=ad,DC=domain,DC=local",
   "BindPassword" : "端뉍牒ꁐ...",
   "BaseDN" : "DC=ad,DC=domain,DC=local",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Ddomain%2Cdc%3Dlocal"
}

and an error:

[root@remotead ~]# account-provider-test
ldap_bind: Strong(er) authentication required (8)
        additional info: BindSimple: Transport encryption required.

So I changed my AD ldap uri via web UI(account provider) on the remotead NS to ldaps://nsdc-testserver.ad.domain.local and then account-provider-test worked.

But now I have the same status as @Zwordi.

-- Unit sogod.service has begun starting up.
Oct 20 21:44:48 remotead.domain.local sogod[1784]: 2017-10-20 21:44:48.129 sogod[1784:1784] File NSString.m: 1507. In -[NSString initWithContentsOfFile:] Contents of file '/etc/sogo/sogo.conf' are not string data
Oct 20 21:44:48 remotead.domain.local sogod[1784]: <0x0x556396e9edd0[SOGoStartupLogger]> Cannot read configuration from '/etc/sogo/sogo.conf'. Aborting
Oct 20 21:44:48 remotead.domain.local systemd[1]: sogod.service: control process exited, code=exited status=1
Oct 20 21:44:48 remotead.domain.local systemd[1]: Failed to start SOGo is a groupware server.
-- Subject: Unit sogod.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sogod.service has failed.

Tried removing and installing Sogo and unbind/rejoin without success. Now I get

-- Unit sogod.service has begun starting up.
Oct 20 21:55:46 remotead.domain.local kernel: sogod[5723]: segfault at 7ffe69629b98 ip 00007f328312c9cf sp 00007ffe69629b80 error 6 in libgnustep-base.so.1.24.9[7f3282d9a000+4dc000]
Oct 20 21:55:46 remotead.domain.local systemd[1]: sogod.service: control process exited, code=killed status=11
Oct 20 21:55:46 remotead.domain.local systemd[1]: Failed to start SOGo is a groupware server.
-- Subject: Unit sogod.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sogod.service has failed.
--
-- The result is failed.
Oct 20 21:55:46 remotead.domain.local systemd[1]: Unit sogod.service entered failed state.
Oct 20 21:55:46 remotead.domain.local systemd[1]: sogod.service failed.

This is weird.

Houston we have a problem !

probably it comes from the password as a binary field

Can you remove it and place a dummy one, just to look if the sogo service starts

Oh no, I reinstalled the VM but I’ll try and report…

what a pity :cry:

I got the AD naming bug: If you enter no DNS Server IP on joining NS, the domain is AD instead of DOMAIN.

I freshly installed the VM with NS 7.4b1, updated, joined AD, changed ldap uri to ldaps so account-provider-test works again.

Then I installed sogo and it just worked. If you change the ldap uri it is correctly written to sogo.conf hostname:

/* 45 AD authentication */
    SOGoUserSources =(
     {
        id = AD_Users;
        type = ldap;
        CNFieldName = cn;
        IDFieldName = sAMAccountName;
        UIDFieldName = sAMAccountName;
        IMAPLoginFieldName = userPrincipalName;
        canAuthenticate = YES;
        bindDN = "DOMAIN\\REMOTEAD2$";
        bindPassword = "ꍝ꛸斦...";
        baseDN = "DC=ad,DC=domain,DC=local";
        bindFields = (
                sAMAccountName,
                userPrincipalName
            );
        hostname = ldaps://nsdc-testserver.ad.domain.local;
        filter = "(objectClass='user')";
        MailFieldNames = ("userPrincipalName");
        scope = SUB;
        displayName = "domain.local users";
        isAddressBook = YES;
     },
     {
        id = AD_Groups;
        type = ldap;
        CNFieldName = name;
        IDFieldName = sAMAccountName;
        UIDFieldName = sAMAccountName;
        canAuthenticate = YES;
        bindDN = "DOMAIN\\REMOTEAD2$";
        bindPassword = "ꍝ꛸...";
        baseDN = "DC=ad,DC=domain,DC=local";
        hostname = ldaps://nsdc-testserver.ad.domain.local;
        filter = "(objectClass='group') AND (sAMAccountType=268435456)";
        MailFieldNames = ("userPrincipalName");
        scope = SUB;
        displayName = "domain.local groups";
        isAddressBook = YES;
     }
    );

Don’t know what was the problem before maybe removing and reinstalling sogo? I’ll try again…

I removed sogo from software center. Then I did “yum remove sogo”. Then I installed sogo from software center and now I have my error status again. I tried to empty the binary passwords in sogo.conf, but same error. I think it’s sogo install/remove procedure error and has nothing to do with binary password.

-- Unit sogod.service has begun starting up.
Oct 20 23:09:11 remotead2.domain.local kernel: sogod[6639]: segfault at 7ffdd9a52ff8 ip 00007f921262c107 sp 00007ffdd9a53000 error 6 in libc-2.17.so[7f92125ac000+1b8000]
Oct 20 23:09:11 remotead2.domain.local systemd[1]: sogod.service: control process exited, code=killed status=11
Oct 20 23:09:11 remotead2.domain.local systemd[1]: Failed to start SOGo is a groupware server.
-- Subject: Unit sogod.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit sogod.service has failed.

EDIT:

Summary:
I tried to join AD 3 times with fresh install and the first time join doesn’t work correctly, no matter if you enter DNS or not. The domain is set to AD instead of DOMAIN when DNS domain is ad.domain.local. Unbind and join the second time works.

The ldap uri on the joining Nethserver has to be changed via web ui to make accounts-provider-test work. You will get “ldap_bind: Strong(er) authentication required (8) additional info: BindSimple: Transport encryption required.” if you don’t do that.

@Zwordi, I could not reproduce your problem a second time, I just had it after updating my AD nethserver-dc from 1.2.6 to 1.3.
As @stephdl suggested, please try to change your sogo.conf to “BindPassword” : “dummypw” instead of the chinese typo and check if sogo starts.

2 Likes

I think because MS AD doesn’t come with SSL enabled out of the box, like Samba AD. And enabling SSL in MS AD is quite complex…

Perhaps the ad probe procedure can guess the best choice by attempting SSL and fall back to plain LDAP if not available. I thought it was so!

3 Likes

In this case the probe fails not seeing ldaps in Nethserver AD but it will work with any M$ AD…

1 Like

Hello Everybody,

Thank a lot for your feedback.
I tried few others things whitout any result.
At least as i was just testing the AD side it don’t bother me. I’m gonna use the Openldap which work fine.
I’m gonna use also the command line to create users based on theirs registration.

To be honest i wasn’t expecting a lot of feedback so i love the fact that i received quick answer.
I will put this on SOLVED.

Thanks everybody.

2 Likes

To put this on SOLVED please mark an answer as solution, check this:

https://community.nethserver.org/t/howto-mark-a-topic-as-solved/1750

1 Like

Done.
Thanks again

Hi Zwordi,
I think you got it wrong, your answer

should be the solution, not the answer of Markus “How to mark an answer as solution”.

1 Like

Fix Thanks

1 Like

can we mark this as a bug, or an undocumented feature ?

I’m facing the same issue here…
what I see is that once joined the domain, sogo.conf has the binary password even if I set a bind password… a nethserver-sogo-update event solve the issue…

digging a bit, I see that sogo.conf file is not expanded when I save the bind credentials… the Save button only stores the credentials into the db…
I’m not sure this is the right way to do… IMO, the save button should invocke the nethserver-sssd-update event and sogo should have its template expanded (and service restarted) in sssd-update event
my 2c