Send-As anyone or Bypass Anti-Spam agents for a single mailbox using extended-rights with Exchange 2010

Posted on December 13, 2010

Roaming SMTP Solution for Exchange Servers

Looking for a quick and efficient method to allow roaming POP3 users or remote equipment to send e-mail from anywhere in the world? Typically ISPs block port 25 (SMTP) and force customers to send through their own SMTP servers to prevent spam, but realistically how painful is it to consistently find the new SMTP server information and change your settings every time you change networks? I think not ...

Our common solution for the roaming user is to open a separate SMTP port (generally 587 or 2525) and allow them to send from anywhere. As these users require authentication to send, you need to update the advanced settings on their POP3 profile to use the same username / password when sending, and change the SMTP port to either 587 or 2525 (which ever you chose). Simple and efficient.

What about network devices without actual mailboxes? For example: a network scanner or scheduled task which relies on no POP3 account?

Instead of creating a separate mailbox for every device, why not share one?
By default, if the incoming sender address does not match the address of the mailbox, you will be given "550 5.7.1 Client does not have permissions to send as this sender".
Here's how the fix that issue:

1) Forward external port 2525 or 587 on your firewall to port 25 on your exchange server
2) Create an exchange mailbox to be used for sending (ie. deviceSMTP) and use a complex password
3) Load the Exchange Management Shell
4) Choose the default receive connector for port 25


mailserver\Client Mailserver {, :::25,} True

4) Apply extended rights to the user you created to allow any-incoming authenticated users to send as an alternative address

Get-ReceiveConnector "mailserver\Client Mailserver" | Add-ADPermission -user "<user you created>" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Sender"

5) Set your network device to use authenticated SMTP, enter the username/password you created, select port 2525 or 587.

Happy sending!

Bypass Anti-Spam agents for a specific mailbox

If your organization has a mailbox that requires unfiltered/un-protected mail, you can use extended rights to bypass the spam agents.

Get-ReceiveConnector "mailserver\Client Mailserver" | Add-ADPermission -user "<mailboxname>" -ExtendedRights "ms-Exch-Bypass-Anti-Spam"

SSL VPN authentication by Security Group using LDAP on Fortigate Firewall Appliances with 4.0 MR2

Posted on December 6, 2010

If you're using a fortigate appliance, one of the most fantastic features is the SSL VPN. It's light-weight, efficient, msi, highly secure, and supports authentication using LDAP (in this example active directory).

First and foremost, do NOT mistake FSAE with LDAP when using the SSL VPN. FSAE is designed for internal network policies only, not for incoming SSL authentication requests. You must use LDAP, radius, etc. to facilitate incoming SSL VPN auth requests.

For this example, we are using default locations to save objects. We recommend you use unique OUs for users and groups created below.

1) Create a standard active directory user object to allow the Fortigate to run LDAP queries

In this example we are using the following:

User Name: Fortinet LDAP
Username: fortinet
Password: (something verify complex)
Password never expires: Enabled
User cannot change password: Enabled

2) Create an Active Directory security group

Users who are members of this group will be allowed to authenticate to the SSL VPN.
For this example we are using: SSL VPN Users

3) Add the LDAP server to the Fortigate appliance

To speed things up we are using the CLI. You will require the following information to complete this step:

  • Pick an LDAP ID Name:  serverLDAP
  • LDAP Server (domain controller):
  • CNIDAllows you to choose what values are to be referenced when authenticating. In this example, we are using staff usernames (ie. jsmith):CNID = sAMAccountName
  • Distinguished NameA distinguished name is path the OU or domain you wish to filter. In most cases using the entire domain is sufficient and will not affect performance (less than 1000 users). For this case we will be using a default instance, please replace with your own details.DN: DC=domain,DC=com
  • LDAP Auth Type (basic, regular, anonymous)


Use regular, it requires a valid user ID to make LDAP queries.

  • AD Username


You will need the LDAP path to the "Fortinet LDAP" user object created in section 1. Load the command prompt on your domain controller:

dsquery user -name "Fortinet LDAP"

which will return the value you need:

"CN=Fortinet LDAP,OU=Users,DC=domain,DC=com"

Now that you've acquired all the information, you can generate the required entry into the Fortinet CLI:

config user ldap

edit "serverLDAP"

set server ""

set cnid "sAMAccountName"

set dn "dc=domain,dc=com"

set type regular

set username "CN=Fortinet LDAP,OU=Users,DC=domain,DC=com"

set password



4) Create a firewall user group

This group is used when creating your SSL VPN firewall policies.

You will require the following information to complete this task:

  • Group Name: LDAP VPN UsersPick a name to reference in future tasks.
  • Tunnel Type: Tunnel-AccessYou can create unique tunneling policies by visiting (VPN->SSL->Portal). We will use the default tunnel-access for this task. If you would like to setup split tunneling, you will need to visit the "tunnel access" profile and enable it.
  • LDAP Server Profile Name (created in section 3)serverLDAP
  • Security Group LDAP pathThis is the important part! You need to acquire the exact LDAP path to the security group you are using to allow access to the SSL VPN. In this example, we created this security group in section 2.To find it, use dsquery. Load the command prompt on your domain controller:

    dsquery group -name "SSL VPN Users"
    which will return the value you need:

    "CN=SSL VPN Users,OU=Builtin,DC=domain,DC=com"

    Now that you've acquired all the information, you can enter the details into the Fortigate CLI: :

    config user group

    edit "SSL VPN Users"

    set sslvpn-portal "tunnel-access"

    set member "serverLDAP"

    config match

    edit 1

    set server-name "serverLDAP"

    set group-name "CN=SSL VPN Users,OU=Builtin,DC=domain,DC=com"





    5) Create an incoming firewall policy to open the SSL VPN Auth mechanism

    Generally most situations call for WAN1 to Internal1. Depending on your network, you may need to setup several incoming rules if you would like to allow authenticated users to access internal WLAN or other internal interfaces. For this example, we will just create the standard.

    Using the Web-Gui:

    - Firewall -> Policy -> Policy -> Create New

    Source Interface: WAN1
    Source Address: All
    Destination Interface: Internal1
    Destination Address: ALL or Internal LAN
    Action: SSL-VPN

    At this point you will notice the form change.

    - Click for the "Add" button located directly below "Configure SSL-VPN Users".

    - Move "LDAP VPN Users" to the available user groups

    - Move "Any" to the selected services.

    - Save.

    - Save the new firewall policy.

    - Move it to the top of the "Wan -> Internal" list so that this new policy is the first.

    6) Create a firewall policy to allow the authenticated users to access your internal network.

    Once users are authenticated, they need access to the internal lan. Create another policy as follows:

    Source Interface: SSL Tunnel Interface
    Source Address: All
    Destination Interface: Internal1
    Destination Address: ALL or Internal LAN
    Action: Accept

    This allows all SSL traffic to pass to all internal LAN IPs

    7) Add users to the security group and test

    Remember that each user with access to the VPN needs to be a member of the security group in section 2. Once added, you can load the SSL VPN client from an external location and attempt a connection.

    Server: (your external ip or hostname)
    Username: (active directory username)
    Password: (active directory password)

    Hopefully this helps!

    UPDATE: As this article is apparently being leeched on other sites without mentioning the original author rights, please be advised this was written by Kris Wilkinson @

Filed under: Uncategorized 4 Comments

Exchange 2010 SP1 – Exporting mailboxes to PST or another mailbox or mailbox folder

Posted on December 1, 2010

Just a quick note that several changes to the export features built into Exchange 2010 have been revised in SP1. The following are quick commands to help you get it done quickly.

1) Export a mailbox directly to a PST file

New-MailboxExportRequest -mailbox {mailbox} -FilePath \\server\folder\mailbox.pst

This will export the entire mailbox to a location and file name of your choice.

2) Export a mailbox directly to another mailbox

New-MailboxExportRequest -mailbox {mailbox} -FilePath \\server\folder\mailbox.pst
New-MailboxImportRequest -mailbox {newmailbox} -FilePath \\server\folder\mailbox.pst

This will export/import the entire mailbox contents to an alternative mailbox. Existing data located in the destination mailbox will be merged with the incoming data.

3) Export a mailbox directly into a unique folder in another mailbox

New-MailboxExportRequest -mailbox {mailbox} -FilePath \\server\folder\mailbox.pst
New-MailboxImportRequest -mailbox {newmailbox} -FilePath \\server\folder\mailbox.pst -targetrootfolder "Mailbox Contents"

This particular process is extremely useful when employees are terminated or leave the organization.

If you would like to review the progress of your imports or exports, use:

get-mailboxmoverequest | fl