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 
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 
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.
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 ?
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:
When you then look in dovecot-acl, you get username without ‘@domain.com’:
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.
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.
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
what is in the back of my mind is:
(https://sogo.nu/files/docs/SOGoInstallationGuide.html)
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?
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
=> 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;
create a migration fragment and look after two properties UIDFieldName and CNFieldName
UIDFieldName and CNFieldName with good values we want (It is a new installation)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)I create a bash script, we will need the backup we do each night, in short
UIDFieldName and CNFieldName
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
{
# 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');
}
}
}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?