Sogo does not get the good LDAP settings

I have forgotten and cant find any info either way … was the setting of ACL’s by SOGo addressed or not ? It seems I still have the issue where it only writes user without adding @domain.tld when setting ACL’s with SOGo. Setting them with Thunderbird works.

Given my scenario where the users only get and use their alias, I’m not sure if that is the cause or if this was an open issue where it is not sure if it is a SOGo or other issue ?

@stephdl: I just confirmed it was fixed somewhat. I still insist that a bug remains :stuck_out_tongue:

As we can see in this picture, SOGo perfectly knows what my username is.

But whenever I grant rights, it will take the alias of the user, and not the username, to grant rights to.
For most people this scenario will result in exactly the same behaviour, but in mine it doesnt, and I think I can argue it isnt correct behaviour.

Could you hint me where to alter the configuration to fix this for my scenario ? I will fix it myself given my exotic config, but I really need it to behave different :slight_smile:

My argument: rights are granted to a user, and thus username … not to their alias. Since the screenshot demonstrates that SOGo knows the difference, I think whatever is entered at the alias or mail property for the AD account, should be irrelevant for this operation.

2 Likes

for samba4AD the bad ldap properties I know are

for the good full displayed

CNFieldName = cn;

should be

CNFieldName = displayName;

to allow the good imap acl

   UIDFieldName = sAMAccountName;

should be

    UIDFieldName = userPrincipalName;

I have some tricks to do, but I would want to come back on it

Actually, that further breaks things … at least, when I edit this in /etc/e-smith/templates-custom/etc/sogo/sogo.conf/45users_source

keeping this: (original config in e-smith/templates/etc/sogo/sogo.conf/45user_source )

/* 45 AD authentication */
    SOGoUserSources =(
     \{
        id = AD_Users;
        type = ldap;
        CNFieldName = cn;
        IDFieldName = sAMAccountName;
        UIDFieldName = sAMAccountName;
        IMAPLoginFieldName = $CustomEmailField;
        canAuthenticate = YES;
        bindDN = "$bindDN";
        bindPassword = "$bindPassword";
        baseDN = "$userDN";
        bindFields = (
                sAMAccountName,
                $CustomEmailField
            );
        hostname = $ldapURI;
        filter = "(objectClass='user')";
        MailFieldNames = ("$CustomEmailField");
        scope = SUB;
        displayName = "$DomainName users";
        isAddressBook = YES;
     \},

…works for DISPLAYING things correctly, but setting rights will fail in this scenario. I can not find the place where SOGo sets the permissions and have trouble finding out where it is taking its values for setting them.

It seems the email property is used, not userPrincipalName (which holds username@domain.tld) … could this be SOGo using the wrong property when setting ACL’s and not at all Nethserver implementation ?

Lets work on this :thinking:
moderator, could it be an idea to split this off?

So … meh … it’s getting late and I just realized it could get confusing quick. With the CURRENT sogo version and when using an alias, while setting rights with SOGo, you will search for the user and see alias@domain.com:

image

When you then look in dovecot-acl, you get username without ‘@domain.com’:

image

I tried to awk something together, but that didnt quite work … anybody any clues how to make this work:

find /var/lib/nethserver/vmail/user* -type f -name dovecot-acl -exec gawk '!($1 ~ /@domain.com/) && (/user*/) {$1=$1 "@domain.com"} 1' {} +

It looks in the vmail dir for any user’s (they all start with abc) dovecot-acl and looks if the first column contains abc* but NOT *@domain.com, then adds @domain.com to the first column when these conditions are met.

Effectively changing acb123 to abc123@domain.com

Except, our gawk doesnt support -i inplace nor can I use echo in this construction … and then I was out of ideas for tonight.

@planet_jeroen @stephdl
I feel responsible for this mess: did not had the guts, nor the knowledge, to shift the identification by SOGo to name@ns_domain.hoho . Meaning in the SOGo mysql db users are identified by ‘name’ without @ns_domain.hoho.
The issues I could not solve where “virtual” mail-domains while identifying users with “FQDN’s” and migrating to FQD-Named users.

I can’t say, or promise, more than it’s has my attention trying to solve your issue.

2 Likes

The workaround is going into the dovecot-acl file and adding a string to the user. This can be scripted and cron’ed, no people will die because of it and many newcomers benefitted, but a clean solution would be welcome.

1 Like

in fact the workaround is

get the good ldap settings
change mysql table name from sogouserxxxxxxxxxxxx to sogouser@domain.comxxxxxxxxxxxx

the dovecot-acl is just a consequence, not really the trouble

a bit harder, the new name cannot be determined

MariaDB [sogo]> show tables;
+-------------------------------+
| Tables_in_sogo                |
+-------------------------------+
| sogo_alarms_folder            |
| sogo_folder_info              |
| sogo_sessions_folder          |
| sogo_user_profile             |
| sogoadminnet0033fea5312       |
| sogoadminnet0033fea5312_acl   |
| sogoadminnet0033fea5312_quick |
| sogohelenene0021d871397       |
| sogohelenene0021d871397_acl   |
| sogohelenene0021d871397_quick |
| sogototoneth0014a9634ab       |
| sogototoneth0014a9634ab_acl   |
| sogototoneth0014a9634ab_quick |
+-------------------------------+

the full email is admin@nethservertest.org

I do not fully understand what you mean here;
Is the solution found in migrating the users in the sogo db to FQDNs?

when you change the ldap settings to use the email for dovecot-acl and to display the full name in sogo, the map between the user and the mysql is lost, calendar and contact cannot be retrieved

1 Like

what is in the back of my mind is:
(Installation and Configuration Guide)

SOGoEnableDomainBasedUID

Parameter used to enable user identification by domain. Users will be able (without being required) to login using the form username@domain, meaning that values of UIDFieldName no longer have to be unique among all domains but only within the same domain. Internally, users will always be identified by the concatenation of their username and domain.

Consequently, activating this parameter on an existing system implies that user identifiers will change and their previous calendars and address books will no longer be accessible unless a conversion is performed.

Defaults to NO when unset.

Would this help us?

1 Like

Don’t know but it is the same symptom…I hope that even if we lost settings, calendar and contacts, we could put them back by the backup trigerred each night. But of course we need a manual administrator action.

@asl @mark_nl @mrmarkuz @m.traeumner @planet_jeroen and all other this is what I plan to make, no hurry first we discuss of it

what I want to solve :

=> allow the imap acl to share the email box by dovecot
=> display the full name (in the top left corner)

all of this is for SambaAD (not sure that for ldap we need all of this)

 for the good full displayed name

CNFieldName = cn;

should be

CNFieldName = displayName;

to allow the good imap acl

   UIDFieldName = sAMAccountName;

should be

    UIDFieldName = userPrincipalName;

My plan is

create a migration fragment and look after two properties UIDFieldName and CNFieldName

  • case properties exist -> do nothing
  • case properties AND sogo mariadb do not exist-> create UIDFieldName and CNFieldName with good values we want (It is a new installation)
  • case properties do not exist AND sogo mariadb exists->create UIDFieldName and CNFieldName with the actual (bad) values because it is an older installation to migrate (in short do nothing and wait a manual migration if wanted)

now the live manual migration

I create a bash script, we will need the backup we do each night, in short

  • create a dump of mysql (I do not like headache)
  • cp backupfolder/user to backupfolder/user@domainName
  • migrate some user values to user@domainName in the relevant sogo backup file
  • import the backup to sogo mariadb by sogo-tool
  • set the correct values of properties UIDFieldName and CNFieldName
  • expand-template to the sogo configuration file
  • restart sogo and enjoy

this is my script

#!/usr/bin/bash
#
# script to fix  the bad ldap settings sogo
# stephane de labrusse <stephdl@de-labrusse.fr>
#

MYBACKUPDIR=$1
DOMAIN=$(/usr/sbin/e-smith/config get  DomainName)
DATE=$(date '+%Y-%m-%d_%H_%M_%S')

if [ -z "${MYBACKUPDIR}" ]; then
    exec >&2
    echo "Restore the good UID user@domainName"
    echo ""
    echo "Usage: " 
    echo "    " $(basename $0) "/var/lib/sogo/backups/sogo-DateOfBackup"
    echo ""
    exit 1 
fi

echo "# dump the sogo database"
/usr/bin/mysqldump sogo > /root/sogo-MARIADB-$DATE.dump

   #set good values for ldap
   config setprop sogod UIDFieldName userPrincipalName CNFieldName displayName
   expand-template /etc/sogo/sogo.conf
   systemctl restart sogod
cd $MYBACKUPDIR
    for i in `ls`
    do
        if [[ $i =~ $DOMAIN ]]; then
        continue
        fi

        echo "#"
        echo "#change name of $i to $i@$DOMAIN"
        echo "#"
        /usr/bin/cp -f $i $i\@$DOMAIN
        /usr/bin/sed -i "s|/Users/$i|/Users/$i@$DOMAIN|g" $i@$DOMAIN
        /usr/bin/sed -i "s|$i:|$i@$DOMAIN:|g" $i@$DOMAIN
        sogo-tool restore -p $MYBACKUPDIR $i@$DOMAIN
        sogo-tool restore -f ALL $MYBACKUPDIR $i@$DOMAIN
    done

you call it by

myScript /var/lib/sogo/backups/sogo-2018-02-06_003

Of course what we will break is all links we did in carddav/caldav/ when we used user in place after of user@domainName
The purpose is to let in the hand of the admin the choice to fix or not the ldap settings, new installations will start with the good values.

After that if something went wrong, restore mariadb and it is done, I tested on my server with my caldav/carddav and it seems workable

3 Likes
{
# this fragment is done to set the good values to UIDFieldName and CNFieldName
# if it is a new install, we can remove it for ns8
# https://community.nethserver.org/t/sogo-does-not-get-the-good-ldap-settings/8754

use NethServer::SSSD;
use esmith::ConfigDB;

my $db = esmith::ConfigDB->open() || die "Can't open config database: $!\n";
my $sssd = new NethServer::SSSD();

my $UIDFieldName = $db->get_prop('sogod','UIDFieldName') || '';
my $CNFieldName =  $db->get_prop('sogod','CNFieldName') || '';

if ($sssd->isLdap){
    if (($UIDFieldName eq '') && ( ! -d '/var/lib/mysql/sogo')) {
        $db->set_prop('sogod','UIDFieldName','mail');                     
        }
    elsif (($UIDFieldName eq '') && ( -d '/var/lib/mysql/sogo')) {
        $db->set_prop('sogod','UIDFieldName','uid');
        }
    }
    
elsif($sssd->isAD){
    if ((($UIDFieldName eq '') || ($CNFieldName eq '')) 
              && ( ! -d '/var/lib/mysql/sogo')){
        $db->set_prop('sogod','UIDFieldName','userPrincipalName');
        $db->set_prop('sogod','CNFieldName','displayName');
        }
    elsif ((($UIDFieldName eq '') || ($CNFieldName eq '')) 
              && ( -d '/var/lib/mysql/sogo')){
        $db->set_prop('sogod','UIDFieldName','sAMAccountName');
        $db->set_prop('sogod','CNFieldName','cn');
        }
    }
}
2 Likes

In my opinion it’s a good idea, a similar point to echo "#change name of $i to $i@$DOMAIN" was already discussed.

So I think there will be some people who are interested in that.
The full name would be also important for sending mails.

what about if you map stephane@secondDomain.com to stephane@MyFirstDomain.com and you try to use stephane@secondDomain.com to login ?

Oh, I’ve only found this thread and thought it could be interesting, because they want to login with any mailaddress…
Can you tell me how to map one address to another? I think if I do so, I have only one Inbox, is it right?
What else happens if you map one address to the other?

menu email address > tab mail aliases

1 Like