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 ?
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.
…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:
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.
@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.
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
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.
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.
=> 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
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');
}
}
}
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?