Sogo users in NS ldap client cannot login to NS ldap server

NethServer Version: NS7.3
Module: Sogo

I have setup one NS host to serve as a dedicated ldap server to provide authentication services to a number of ldap client hosts.

One of the client hosts is a new NS mail server. Its able to successfully connect to the NS ldap account provider and pull all the Users and Groups. Users are able to login via Roundcube, but they are getting a “Wrong username or password” error when using Sogo.

= Sogo logs:

<0x0x7f7701869a30[LDAPSource]> <NSException: 0x7f7701a52360> NAME:LDAPException REASON:operation bind failed: Invalid credentials (0x31) INFO:{"error_code" = 49; login = "cn=testuser,dc=example,dc=com"; } May 02 23:28:24 sogod [9281]: SOGoRootPage Login from '10.1.1.24' for user 'testuser' might not have worked - password policy: 65535 grace: -1 expire: -1 bound: 0

= Slapd logs

conn=2950 fd=29 ACCEPT from IP=10.1.1.215:36108 (IP=0.0.0.0:389) 
conn=2950 op=0 BIND dn="" method=128 
conn=2950 op=0 RESULT tag=97 err=0 text= 
conn=2950 op=1 SRCH base="dc=example,dc=com" scope=1 deref=0 filter="(|(mail=testuser)(uid=testuser))" 
conn=2950 op=1 SRCH attr=dn
<= bdb_equality_candidates: (uid) not indexed 
conn=2950 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= 
conn=2951 fd=30 ACCEPT from IP=10.1.1.215:36110 (IP=0.0.0.0:389)
conn=2951 op=0 BIND dn="cn=testuser,dc=example,dc=com" method=128
conn=2951 op=0 RESULT tag=97 err=49 text= 
conn=2951 op=1 UNBIND

= sogo.conf (as configured by NS)

    id = users;
    type = ldap;
    CNFieldName = cn;
    UIDFieldName = uid;
    IDFieldName = mail;
    bindFields = (
            mail,
            uid
        );
    IMAPLoginFieldName = mail;
    baseDN = "dc=example,dc=com";
    bindDN = "";
    bindPassword = "";
    scope = ONE;
    MailFieldNames = ("mail");
    canAuthenticate = YES;
    displayName = "ns7 users";
    hostname = ldap://10.1.1.29;


I also tried changing to baseDN = “ou=Groups,dc=directory,dc=nh”;
but this also didnt work. I was unsuccessful also logging with full email address.

Sogo ldap config appears to be similar Roundcube’s, so I am confused why the latter is able to login.

I also test installed Sogo on the ldap server and from there it can login, but from the client, nope.

Is this a bug ? How can I fix this ? Let me mention that I am an ldap novice.

Regards,

Clemo

roundcube doesn’t use ldap to allow users, it uses imap…and imap is local on the email nethserver

I will need to get the real /etc/sogo/sogo.conf (of the remote ldap client) by email and also the output of

account-provider-test dump

Hi Steph,

Below I have posted the output and the config you requested.

Remote ldap client’s account-provider-test dump

{
   "startTls" : "",
   "bindUser" : null,
   "userDN" : "dc=example,dc=com",
   "port" : 389,
   "isAD" : "",
   "host" : "10.1.1.29",
   "groupDN" : "dc=example,dc=com",
   "isLdap" : "1",
   "ldapURI" : "ldap://10.1.1.29",
   "baseDN" : "dc=example,dc=com",
   "bindPassword" : "",
   "bindDN" : ""
}

This is sogo.conf settings related to mail. I have removed mysql, notifications, Active sync etc settings to make it shorter

Remote ldap client’s sogo.conf settings

  /* 20 Mail */
    SOGoDraftsFolderName = "Drafts";
    SOGoSentFolderName = "Sent";
    SOGoTrashFolderName = "Trash";
    SOGoJunkFolderName = "Junk";
    SOGoIMAPServer = "localhost";
    SOGoSieveServer = "sieve://localhost:4190";
    SOGoSMTPServer = "127.0.0.1:587";
    SOGoMailDomain = "example.com";
    SOGoMailingMechanism = "smtp";
    NGImap4ConnectionStringSeparator = "/";
......
  /* 40 Authentication */
  //SOGoPasswordChangeEnabled = YES;

  /* 45 ldap authentication */
    SOGoUserSources =(
     {
        id = groups;
        type = ldap;
        CNFieldName = cn;
        UIDFieldName = cn;
        IDFieldName = cn;
        baseDN = "dc=example,dc=com";
        bindDN = "";
        bindPassword = "";
        scope = ONE;
        canAuthenticate = YES;
        MailFieldNames = ("mail");
        displayName = "ns7 groups";
        hostname = ldap://10.1.1.29;
        isAddressBook = NO;
     },
     {
        id = users;
        type = ldap;
        CNFieldName = cn;
        UIDFieldName = uid;
        IDFieldName = mail;
        bindFields = (
                mail,
                uid
            );
        IMAPLoginFieldName = mail;
        baseDN = "dc=example,dc=com";
        bindDN = "";
        bindPassword = "";
        scope = ONE;
        MailFieldNames = ("mail");
        canAuthenticate = YES;
        displayName = "ns7 users";
        hostname = ldap://10.1.1.29;
        isAddressBook = YES;
     }
    );

Regards,

Clemo

Did you modify the files…I cannot see a password nor a ldap account name.

@davidep @giacomo some ideas ?

I have not modified the files. That is as is. Apparently, it is how NS does config on client ldap settings. Roundcube on client also has an ldap settings for addressbook and there were done the same (See below). I also replicated this on another test setup.

/etc/roundcubemail/config.inc.php Settings

$config['ldap_public']['public'] = array(
    'name'                   => 'Public LDAP Addressbook',
    'hosts'                  => array('ldap://10.1.1.29'),
    'port'                   => 389,
    'use_tls'                => false,
    'user_specific'          => false,
    'base_dn'                => 'dc=example,dc=com',
    'bind_dn'                => '',
    'bind_pass'              => '',
    'scope'                  => 'sub',
    'referrals'              => 0,
    'filter'                 => '(objectClass=inetOrgPerson)',
    'search_fields'          => array('mail','cn'),
    'fuzzy_search'           => true,
    'groups'                 => array(
        'base_dn'            => '',
        'filter'             => '(objectClass=posixGroup)',
        'object_classes'     => array("top", "posixGroup"),
        'member_attr'        => 'uid',

I believe NS ldap client setup should be able to input those settings, but it is not doing so.

On the ldap Server we also have the following settings as Base DN and BindDN, but for the client, the domain name fqdn is generated instead, though I think it shouldnt matter;

baseDN = "ou=Groups,dc=directory,dc=nh";
bindDN = "cn=ldapservice,dc=directory,dc=nh";

The login = "cn=testuser,dc=example,dc=com" looks strange, it is not what I would expect for a ns7 server…

I’d say the search base should be “dc=directory,dc=nh”

This search criteria cannot match a user entry in LDAP. That baseDN with scope = ONE does not lead to a posixAccount entry in ns7 LDAP.

@stephdl I think the key is the search base. If scope is ONE it should be something like ou=People,dc=directory,dc=nh, whilst if scope is SUB it can be dc=directory,dc=nh. IIRC it is more specific because of SOGo user and group management.


We are working on an improvement of automatic probing of LDAP settings, when a remote LDAP account provider is configured. As said during the last hangout we’re almost done:

1 Like

David,

Thanks,
I eagerly look forward to this improvement.

Regards,

Clemo

@wclemo @davidep I can now use a remote authentication with openldap and sogo (I tested with the new account provider). You can use an ‘Authenticated bind’ with a ‘BindDN’ and a ‘BindPassword’ found with

account-provider-test dump

or use an anonymous bind

@davidep which one should be the best…both are workable

with a remote samba4 ad (and the new account provider) I must add some changes

-        hostname = ldap://nsdc-ns7dev7.ad.stephdl.dyndns.org;
+        hostname = ldaps://nsdc-ns7dev7.ad.stephdl.dyndns.org;

this is something understandable because I’m remote, but there is something changed now, I must modify the line ‘IMAPLoginFieldName’ to ‘sAMAccountName’ if I want to display the email in the INBOX, else the content is empty even if the folder gets email (verified by a ll /var/lib/nethserver/vmail)

-       IMAPLoginFieldName = userPrincipalName;
+        IMAPLoginFieldName = sAMAccountName;

maybe it comes because I set ‘AD dns’ to ‘ad.stephdl.dyndns.org’ (remote) and I have a email domain name (DomainName) set to stephdl.dyndns.org

need further tests, @davidep @giacomo some clues ?

I have tried your suggestion but I dont appear to succeed in making SOGo login. I have used the account-provider-test dump found on the ldap server. May be its my ldap limited knowledge. Anonymous too didnt work.

Can you kindly provide an excerpt of your config that worked ?

In fact I did nothing except to upgrade the NS (about the account provider) to make it works with openldap (I have a bug with samba4). Maybe you need to reconfigure your account provider.

Like any ldap application, sogo rely on NethServer::SSSD, the issue with the remote account provider could be in it.

This sounds odd… I’m out of office I hope @giacomo can have a look at it. Maybe we need to call (conditionally) nethserver-sssd-notifyclients action during nethserver-dc-update event.

The samaccountname is a good choice. userprincipalname could be missing or being set to other mail domains…

Yes, changing the LDAP connection settings could fix the problem. It’s like doing

signal-event nethserver-sssd-save
1 Like

Hi Stephdl

I upgraded my NS systems (ldap server and remote ldap client) and noticed that the account provider has been improved. It has a setting for authenticated and anonymous bind options.

However, my Sogo login from remote ldap client persists. But this time I noticed where the issue might be. I must mention that the output of account-provider-test dump are perfectly matching this time on both ldap client and server, and so there is a huge improvement on Account provider setup.

What I noticed on the slapd logs is that from Sogo ldap client Bind DN is using cn instead of uid for user:

= Sogo Ldap remote Client Bind DN displayed when user unsuccesfully attempts to log in;

BIND dn="cn=johndoe,ou=People,dc=directory,dc=nh"

=Bind DN when user successfuly logs in from Ldap Server’s Sogo

BIND dn="uid=johndoe,ou=People,dc=directory,dc=nh"

I suspect that this might be the reason why remote ldap client Sogo user is unable to login.

The logs are as follows:

= From Sogo on remote ldap client

ACCEPT from IP=10.1.1.215:37110 (IP=0.0.0.0:389) 
BIND dn="cn=ldapservice,dc=directory,dc=nh" method=128
RESULT tag=97 err=49 text=
ACCEPT from IP=10.1.1.215:37112 (IP=0.0.0.0:389) 
BIND dn="cn=johndoe,ou=groups,dc=directory,dc=nh" method=128 
RESULT tag=97 err=49 text=
UNBIND

= Sogo on Ldap Server

ACCEPT from IP=127.0.0.1:58992 (IP=0.0.0.0:389) 
BIND dn="cn=ldapservice,dc=directory,dc=nh" method=128 
BIND dn="cn=ldapservice,dc=directory,dc=nh" mech=SIMPLE ssf=0
RESULT tag=97 err=0 text=
SRCH base="ou=people,dc=directory,dc=nh" scope=1 deref=0 filter="(|(uid=johndoe)(mail=johndoe))"

account-provider-test dump (same on both hosts but on Server is 127.0.0.1)

{
   "BindDN" : "cn=ldapservice,dc=directory,dc=nh",
   "LdapURI" : "ldap://10.1.1.29:389",
   "StartTls" : "1",
   "port" : "389",
   "host" : "10.1.1.29",
   "isAD" : "",
   "isLdap" : "1",
   "UserDN" : "ou=People,dc=directory,dc=nh",
   "GroupDN" : "ou=Groups,dc=directory,dc=nh",
   "BindPassword" : "StrongsPasswd",
   "BaseDN" : "dc=directory,dc=nh",
   "LdapUriDn" : "ldap:///dc%3Dexample%2Cdc%3Dcom"
}

So could this be the issue ?

What about if you do on the sogo server

signal-event nethserver-sogo-update

Then try to login

signal-event nethserver-sogo-update does not change anything.

Actually I had uninstalled Sogo on ldap client (and removed the remnant sogo.conf), then unbinded the ldap client and binded it afresh after a reboot. I then binded it afresh and installed Sogo.

does it is workable now ?

Hello. I can confirm this error is also affecting me.
I have recently installed Nethserver for a project, same version and with everything updated, and I have been trying to setup an Active Directory (samba) server with sogo,nextcloud and mail services, everything together.
Sogo and nextcloud throw authentication errors when trying to log in them. The rest of the services (roundcube,etc) work well.

Edit: Now I have tried to clone my VM, unistall the Active Directory domain and install OpenLDAP. It worked OOTB with the admin account. When I tried to unistall it and go back to the Active Directory domain, the problem persisted.

2 Likes

Unfortunately not, despite the fresh ldap client binding and Sogo reinstall.

Post the sogo.conf and the dump of ssssd otherwise try like the post above and reinstall your remote client…it works with openldap

Yes, we reverted Samba 4 to default config: it accepts only encrypted connections.
Do you think we should revert the modification?

SOGo login can’t work with actual configuration since it expects the same user for IMAP and LDAP.
You can find similar issues on Roundcube webmail.
We are working on it, stay tuned :slight_smile:

1 Like