https://wiki.zimbra.com/api.php?action=feedcontributions&user=Lebha&feedformat=atomZimbra :: Tech Center - User contributions [en]2024-03-28T14:42:41ZUser contributionsMediaWiki 1.39.0https://wiki.zimbra.com/index.php?title=Restrict_sending_to_certain_domains&diff=12348Restrict sending to certain domains2008-12-30T11:41:41Z<p>Lebha: fix</p>
<hr />
<div>{{Unsupported}}<br />
<br />
Requirement "users in the sender.allowed.com domain must be<br />
allowed to email only users in the sender.allowed.com or another.allowed.com<br />
domains."<br />
<br />
Here is how to implement that requirement in postfix. If using this elsewhere,<br />
be sure to change the domain name!<br />
<br />
After implementing this, the sender.allowed.com user gets an error<br />
dialog in the web UI when trying to email an outside address:<br />
<br />
At least one address is not valid.<br />
Invalid addresses: joe@example.com<br />
<br />
Postfix generates this error message on rcpt to (clearly we are not<br />
propogating the exact error up, but not a big deal):<br />
<br />
Sender address rejected: Access denied<br />
<br />
Solution is to add a sender restriction, and then define that<br />
restriction to be that only some recipients are OK. This has to be<br />
done on every MTA box. <br />
<br />
a) Populate the sender check table so a recipient restriction is applied on senders from the domain.<br />
<br />
cd /opt/zimbra/conf<br />
echo "sender.allowed.com restrict_tpmail" > tpmail_senders<br />
postmap tpmail_senders<br />
<br />
b) Populate a table which lists who they are allowed to send to<br />
<br />
cd /opt/zimbra/conf<br />
echo "another.allowed.com OK" > tpmail_recipients<br />
echo "sender.allowed.com OK" >> tpmail_recipients<br />
postmap tpmail_recipients<br />
<br />
'' this step is obsolete in newer zimbras<br />
c) add these three line to postfix main.cf:<br />
<br />
smtpd_sender_restrictions = check_sender_access hash:/opt/zimbra/conf/tpmail_senders<br />
smtpd_restriction_classes = restrict_tpmail<br />
restrict_tpmail = check_recipient_access hash:/opt/zimbra/conf/tpmail_recipients, reject''<br />
<br />
c) newer versions of Zimbra edit main.cf every restart, so its better to modify zmmta.cf. add this lines to zmmta.cf:<br />
<br />
POSTCONF smtpd_sender_restrictions FILE postfix_sender_restrictions.cf <br />
POSTCONF smtpd_restriction_classes restrict_tpmail<br />
POSTCONF restrict_tpmail FILE postfix_restrict_tpmail.cf<br />
<br />
after this line:<br />
POSTCONF virtual_transport LOCAL postfix_virtual_transport<br />
<br />
d) create two files with the restriction definition inside:<br />
<br />
cd /opt/zimbra/conf<br />
echo "check_sender_access hash:/opt/zimbra/conf/tpmail_senders" > postfix_sender_restrictions.cf<br />
echo "check_recipient_access hash:/opt/zimbra/conf/tpmail_recipients, reject" >> postfix_restrict_tpmail.cf<br />
<br />
done.<br />
<br />
<br />
Also see: http://wiki.zimbra.com/index.php?title=RestrictPostfixRecipients<br />
<br />
{{Article Footer|unknown|5/24/2006}}<br />
<br />
[[Category:Administration]]</div>Lebhahttps://wiki.zimbra.com/index.php?title=Migrating_from_Dovecot_with_External_LDAP&diff=6336Migrating from Dovecot with External LDAP2007-08-10T13:28:02Z<p>Lebha: /* Step Two: User Migration */ fix</p>
<hr />
<div>Note: This tutorial is specific to Dovecot but is useful wherever the following issues exist:<br />
* You have a number of existing users, and obtaining the passwords for them is impractical.<br />
* You are authenticating against an external LDAP server<br />
* The old mailserver offers the ability to conduct IMAP auth as an administrator for all user accounts<br />
<br />
----<br />
<br />
<br />
==Problem Definition==<br />
You're ready to migrate from your old IMAP/POP3 server to your new Zimbra machine. The only problem is, there are a few hundred users on the old server, and tracking them all down to give you their passwords is neither practical nor desirable - after all, one should try to encourage users to '''not''' give out their passwords. The Dovecot box does support a "manager" login method for IMAP login, but the Zimbra server does not. And since the Zimbra server is going to authenticate against an external LDAP server, it will be wanting valid passwords for IMAP.<br />
<br />
==Problem Solution==<br />
Doing everything in the right order makes this possible:<br />
#[[Bulk Create]] the user accounts with identical passwords.<br />
# Perform [[User Migration]] using a modification of the suggested script.<br />
# Connect to the external LDAP server<br />
<br />
==Details==<br />
===Step One: Create Users===<br />
First, get a dump from the LDAP server in CSV format. Open that CSV file with a spreadsheet program, and edit it so that only the following four columns remain:<br />
#UID. This is the part that goes before the @ in the email address: john.smith@yourzimbraserver.example would have a UID of john.smith<br />
#Password. Make this identical and reasonably hard to guess - this is going to be a temporary "administrative" password on your zimbra server. Hint: use the drag trick on your spreadsheet program to duplicate your password to all the rows in the user list.<br />
#First Name. Self-explanatory.<br />
#Last Name. Ditto.<br />
Now save the csv file and open it up with vi^Wyour favorite text editor and use it to strip out all the quotation marks. The correct vim commands to do this (and save and exit vim) are as follows:<br />
:%s/\"//g<br />
:wq<br />
Now run your recently-edited csv2mprov.pl script against your csv as indicated in the [[Bulk Provisioning]] article, and use the output of this script to provision your user accounts on the Zimbra server.<br />
===Step Two: User Migration===<br />
For the most part, this section tracks the previously-written [[User_Migration]] page - the process is to install imapsync and all its dependencies somewhere (for performance reasons, it should be a powerful machine that is neither the zimbra server nor the original mail server), test execute it against an account, and then run a script to do the full user migration. However, our case includes two significant differences: the usage of an administrative account format for usernames in Dovecot, and the fact that each machine may (or may not) use a different administrative password.<br />
<br />
First off, configure Dovecot to enable manager authentication. This requires [http://dovecot.org/list/dovecot/2006-April/012317.html Dovecot 1.0.b4] or later, which may require backporting or other sorts of dependency battles to obtain. While a lenghthy discussion of the changes in configuration syntax are beyond the scope of this article, do take note of the fact that some changes will need to be done by hand if you are upgrading from 0.9x to >=1.0b4. Once you have a functioning dovecot server again, uncomment or create the following lines in dovecot.conf:<br />
auth_master_user_separator = *<br />
passdb passwd-file {<br />
args = /etc/dovecot/dovecot.master<br />
master=yes<br />
}<br />
Next, create /etc/dovecot/dovecot.master by executing the following command:<br />
htpasswd -c /etc/dovecot/dovecot.master zimbra<br />
This will result in a prompt to enter and verify the password for a user called zimbra on the Dovecot server, and to crypt that password into the indicated file. Once these steps have been taken, reload Dovecot.<br />
<br />
Return to your CSV file from before. This time, trim it until only two columns exist:<br />
#UID Same as before<br />
#*zimbra This is the second half of the authentication piece being passed to Dovecot to identfy the IMAP authentication as an administrative login.<br />
Save this CSV and again use a plaintext editor to strip out all quote marks, commas, and spaces. The result should be a list that resembles the following:<br />
john.smith*zimbra<br />
jane.smith*zimbra<br />
sugar.ray.leonard*zimbra<br />
and so on. Save this file as, say, users.txt, and put it in an empty directory. In the same directory create a file named host1pass.txt that contains only the password you created for the Dovecot administrative account. Do the same thing for the password you used for all the user accounts on the Zimbra server, and call this one host2pass.txt. Now, you'll want to create a shell script that does the work. The following is based very heavily upon the one from the [[User_Migration]] page. Note that I've stripped out the logging features. Feel free to add them back in if you feel the need to have that. Also be sure to edit the hostnames I've given in the script to match your setup. You can use either DNS or IP address for this script.<br />
#!/bin/bash<br />
<br />
host1=dante<br />
#host1 is Source<br />
<br />
host2=alighieri<br />
#host2 is Dest<br />
<br />
cat users.txt | while read<br />
do<br />
username1=`echo $REPLY` # $REPLY is a bash builtin<br />
username2=`echo $REPLY | cut -d\* -f 1` # Strip the star etc<br />
<br />
echo "Syncing User $username1 to $username2"<br />
imapsync --nosyncacls --syncinternaldates \<br />
--host1 $host1 --user1 "$username1" --passfile1 host1pass.txt \<br />
--host2 $host2 --user2 "$username2" --passfile2 host2pass.txt<br />
done<br />
Save this script as migrate-imap.sh in the same directory as users.txt, host1pass.txt, and host2pass.txt. Tar it all up and copy it over to the machine that you have installed imapsync on. <br />
<br />
Now shut down the MTA on your old server - postfix, exim, sendmail, whatever. Just make sure it's not accepting any new inbound email for a while - the sending servers will defer the messages it has for your server for at least 24 hours before returning failure messages to the sending parties, so as long as this goes well, your users won't lose any mail.<br />
<br />
Test the synchronization by running the commands from the script by hand against one user - you can probably use your own account if it is on the server being migrated, as you'll know whether the messages came across successfully.<br />
<br />
Now run the migrate-imap.sh script - I '''strongly''' recommend running this under a screen session, as it can and will take several hours to run, and the last thing you want is a network hiccup to kill the execution of your script midway through. As you run this script, you may notice a number of error messages. My experience was that all the mails synchronized anyhow, but your mileage may vary. This is why you want to test the migration on one user first. At any rate, be patient, but also watch for a hung user account. This will often happen right as another user loops into the script - you'll see a number of plus signs and discussions about the sizes of the various INBOX folders, but then nothing at all. My best guess is that this occurs when Dovecot's index files get out of whack, but I'm not sure. At any rate, ctrl-c out of the script, and delete all the users up to the one where the script filed, then go to the old server and delete using rm -rf dovecot* from within that user's Maildir and restart Dovecot. Run the script again, and it should go well. <br />
<br />
Unfortunately, imapsync is high-maintainance, so if you're on a strict timeline, plan to be stuck in front of the keyboard for several hours. You can shorten this time considerably by encouraging all your users to empty their IMAP trashes in the days leading up to the migration, but do expect this part to be an all-day operation. Be patient, and eventually it will complete.<br />
<br />
===Step Three: Connect Zimbra to the External LDAP Server===<br />
In the Zimbra admin console, navigate to Configuration/Domains/yourdomain.example. On the main pane at the top, click "Configure Authentication." A wizard will pop up. Select External LDAP from the Authentication mechanism drop-down menu, and click Next. Give the address of your LDAP server, and fill in the filter and search base fields. I suggest uid=%u for the LDAP filter, and whatever is correct for your domain with syntax like ou=People, dc=mydomain, dc=example for the search base. You may or may not need to use a password and bind DN to connect to the LDAP server. Ours doesn't require this. Next, test the authentication by first passing your username but rubbish for the password, then upon an error, click the back button and use the correct password. If the test is successful, you can click the finish button.<br />
<br />
That's it - your users will now authenticate to Zimbra using their regular credentials from the LDAP server, and the mock-admin password you created back in Step One will be ignored (and will not work at all so long as LDAP is the auth source). The user mailboxes will be as the users left them.<br />
<br />
The next steps would be to edit DNS, firewall, etc. but that's material for a different tutorial.</div>Lebha