Techniatures

E-mail notifications and Exchange Hub Transport

Konstantin Roskovshenko — Wed, 15 Aug 2012 08:55:00 GMT

Most of organizations have a number of smtp notification sources, which exist in background of common operations. They can compound a problem if something goes wrong with these notifications. Usually only a few of smtp sources are capable for TLS and authentication, while others are not perfectly configured. As a result, smtp server confines
itself with straightforward ip filter where IPs of anonymous “technology sources” are enlisted.
On the other hand, some of administrators may encounter ip address forging in their networks. Thus they want to prevent sending from forged email address but preserve anonymous emails from notification sources.
This is possible with help of Exchange transport server. The general approach is to prevent anonymous sending from sensitive accounts. This can be achieved through
standard sender filter, which is a part of antispam filter set.
The other side of the problem, anonymous sending to sensitive/all addresses, is a part of common antispam strategy and is not addressed here.

First, lets install sender filter agent on Hub Transport server. (You may use Edge server instead, avoiding most of the following recommendations.)

1. Install sender filter agent:
install-transportagent –name:”Sender Filter Agent” –transportagentfactory:”” –assemblypath:””

(Let me know please if you need an example, as I don’t remember the source and found nothing appropriate via fast search which was not thorough.)

Just launch install-antispamagents.ps1 as described in https://technet.microsoft.com/en-us/library/bb201691.aspx

2. Make sure that sender filter is enabled, see https://technet.microsoft.com/en-us/library/bb124087.aspx

Make sure that the next flags are set for the sender filter:

Externalmailenabled=true (anonymous connections are filtered);

Internalmailenabled=false (authenticated connections are NOT filtered).

See pls. https://technet.microsoft.com/en-us/library/aa996920.aspx

3. Create receive connector for technology sources <TechnologySources>, make IP filter allowing IPs of technology sources as usually. It is better to appoint connector type as Custom and to allow anonymous connections explicitly on this connector.

Take away relay permission from anonymous connection:
get-receiveconnector <TechnologyAccounts> | remove-adpermission -user "NT AUTHORITY\ANONYMOUS LOGON" -extendedrights ms-exch-smtp-accept-any-recipient

Take away sending as Exchange Authoritative domain (or Partner domain) permission:
get-receiveconnector | remove-adpermission -user "NT AUTHORITY\ANONYMOUS LOGON" -extendedrights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

Note, please, that sending is impossible if alert source appoints sender address belonging to "Authoritative Domain" or "Internal Relay Domain".

Make sure that the permission Ms-Exch-Smtp-Accept-Any-Sender and permission ms-Exch-SMTP-Submit are still present for anonymous account.

See pls. https://technet.microsoft.com/en-us/library/aa996395.aspx for more details.

4. Add blocked (sensitive) senders to external blocked senders list:
set-senderfilterconfig -blanksenderblockingenabled:$true -blockedsenders bigboss@contoso.com,superadmin@contoso.com

This parameter can accommodate up to 800 email addresses in Exchange 2010.

5. Create External Relay Domain in Exchange organization and have alert sources send alerts from external addresses. If this recommendation is not achievable for some reason, note, please, that you should not take away sending as Exchange Authoritative domain (or Partner domain) permission. In this case, emails might be sent as insensitive senders under the forged IPs.

Checkup sending via <TechnologySources> connector:

- Anonymously sent emails can be mailed to internal Exchange recipients only;

- Relay to other domains is not allowed;

- Anonymous sending from sensitive addresses is not allowed;

- Authenticated user can send as any (allowed to him) sender to any (allowed) recipient.

Sometimes you can find it useful to place external MTA in before of Exchange Hub Transport to accept emails from some internal sources. For example, it might be a typical coexistence scenario.

Thus you will use only authenticated connections from only one source on the receive connector.

Just create sending account <domain\connectorsvc> to enter it’s credentials onto the external MTA gateway and allow this account to send as any sender.

6. Create receive connector <Partner>, and add external MTA’s IP to the corresponding list. It is better to create connector of the Custom type. No permissions should be granted under creation. Allow basic authentication and TLS on the connector.

7. Grant the account <domain\connectorsvc> permission ms-exch-smtp-accept-any-sender and permission ms-exch-smtp-submit on the <Partner> receive connector.

Checkup sending via external MTA:

- You can send a message as any sender (allowed by MTA) except of the sender in Authoritative/Partner domain (no permission ms-Exch-SMTP-Accept-Authoritative-Domain-Sender);

- You can send a message to any recipient in Authoritative/Partner domain;

- You can not send a message to the recipient in Internet (no permission ms-exch-smtp-accept-any-recipient).

Note please that the authentication is much simpler since external MTA supports mutual TLS authentication, as described in https://technet.microsoft.com/en-us/library/bb123543.aspx

Sending E-mail via Powershell script

Konstantin Roskovshenko — Mon, 13 Aug 2012 06:07:17 GMT

This task can be basically performed in two ways.

First one is fairly straightforward as well as documented. The object is Net.Mail.SmtpClient, see https://msdn.microsoft.com/en-us/library/system.net.mail.smtpclient.aspx

Relevant script code is similar to the next:

$mod1=New-Object Net.Mail.SmtpClient

$mod1.Host = “SMTP Gateway FQDN”

$mod1.Send(“sender@address”, “recipient@address”, “Subject line”, “Plain text body”)

Thus your script will anonymously send plain text email to the appointed SMTP gateway. Of course, if anonymous connections are allowed there.

Second method seems to be poorly documented for use with Powershell. This is an old good CDO.Message, see https://msdn.microsoft.com/en-us/library/ms872547(v=EXCHG.65).aspx

Lot of examples concerns “elder” scripting languages such as VBScript and C#, see
https://msdn.microsoft.com/en-us/library/ms875947(EXCHG.65).aspx, https://msdn.microsoft.com/en-us/library/ms527272(EXCHG.10).aspx
and others.

Portion of code relevant to the topic looks cumbersome:

$mod2=New-Object –comobject “CDO.Message”

$mod2.From=”sender@address”

$mod2.To=”recipient@address”

$mod2.Subject=”Caution”

$mod2.Htmlbody=” Your mailbox may be temporarily unavailable ”

$namespace=”https://schemas.microsoft.com/cdo/configuration/”

$mod2.Configuration.fields.item($namespace+"sendusing")=2 # stands for sending via smtp port

$mod2.Configuration.fields.item($namespace+"smtpserver”)= “SMTP Gateway FQDN”

$mod2.Configuration.fields.item($namespace+"smtpserverport”)=25

$mod2.Configuration.fields.item($namespace+"smtpauthenticate”)=1 # stands for sending via anonymous connection

$mod2.Configuration.fields.update()

$mod2.Send()

The difference matters when you need to pass authentication or add attachment or add recipients.

For the first method, you should arrange couple of additional objects, and you may find this somewhat tiring if you are not fond of scripting. When adding additional attrubutes, you will probably have:

$mod1=new-object Net.Mail.SmtpClient(“SMTP Gateway FQDN”)
$email = New-Object System.Net.Mail.Mailmessage
$email.Subject = “Caution”
$email.Body = ” Your mailbox may be temporarily unavailable ”
$email.IsBodyHTML = $true
$email.from = "sender@address ")
$email.To.Add("recipient1@address")
$email.To.Add("recipient2@address")
$email.Attachments.Add(“c:\Usersguide.doc”)
$mod.Send($email)

When adding credentials you should use:

…
$cred = New-Object System.Net.NetworkCredential
$cred.Domain=”Gateway1” # make sense if Gateway1 is Windows server trusting some other Windows domains
$cred.Username=”smtpuser”
$cred.Username=”P@ssw0rd”
$mod1.Credentials=$cred
$mod1.Send($email)

On the other hand, with the second method, you gain all of the above within one interface. Just need to add

…
$mod2.addatachment(“c:\Usersguide.doc”)

$mod2.configuration.fields($namespace+"sendusername”)=”Gateway1\smtpuser”

$mod2.configuration.fields($namespace+"sendpassword”)=”P@ssw0rd”

I prefer the second method as it allows to use basically the same sending script for different tasks or to rework it with less efforts. In addition, CDO object allows use your Exchange server as a Gateway1 mentioned above, establishing MAPI connection to Exchange. The parameter:

$mod2.Configuration.fields.item($namespace+"sendusing")=3

stands for sending the email via MAPI client. Thus you don’t need to allow anonymous connection and/or to change receive connectors.

Since Exchange 2007 you have to install version 1.2.1 of MAPI CDO library as a separate file, see KB https://support.microsoft.com/kb/171440#top and download https://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=1004 . Or you can launch your scripts on admin station where Outlook is installed.

CA cluster and NDES

Konstantin Roskovshenko — Wed, 06 Jul 2011 17:32:00 GMT

This is a brief of PKI solution intended to issue certificates for network devices. The initial requirement was to make issuing layer fully centralized and highly available. Thus it has fallen in some contradiction with normal placement of NDES feature. (List of standard AD CS features is here https://technet.microsoft.com/en-us/library/cc731564.aspx)

The decision was to place NDES feature on the separate box and to target it at the issuing CA cluster. Both components are not complex looked at one by one. Their deployment is documented well (here https://www.microsoft.com/download/en/confirmation.aspx?id=331 for the cluster and here https://www.microsoft.com/download/en/details.aspx?displaylang=en&id=1607 for NDES); most of possible consequences are described in knowledge bases and are known to the community.

All together looks like quite complex solution, and even it has not been yet tested by the developers. Usual supportability practice is that only tested configuration is supported. Nevertheless this time developers ensured us there are no known limitations of targeting SCEP at clustered CA, comparing to the standalone CA server.

So, the solution was adopted by the customer (we met all the requirements) and by the support service (we followed all the recommendations).

Unfortunately, Microsoft SCEP facility could not be used as a clustered or balanced solution, mostly due to the “enrollment password” encryption for initial certificate request. Password encryption relies in Windows onto DPAPI (https://msdn.microsoft.com/en-us/library/ms995355.aspx) and uses user profile data and system-dependent data. It appeared impossible (and unsupported, of course) to synchronize the password across machine boundaries. Thus customer was satisfied with two or more independent NDES servers of the same configuration, and transferred resolution of NDES availability issues to the network device operations.

What was wrong for the interaction: SCEP service, which is web application pool in behind, sporadically lost connectivity to the clustered CA. Usually it happened after CA failover, but later on connectivity might become restored “by itself”, and yet later on lost at once.

Network sniffer brought nothing or almost nothing. We ensured, yes, there is no connectivity to RPC service or DCOM service, but with no idea about the root cause. Fortunately, web application pool settings in IIS 7 (and previous as well) allow to recycle the pool and thus to avoid impact of “sporadically lost connectivity”. What has been done see here https://technet.microsoft.com/en-us/library/cc733120(WS.10).aspx and https://technet.microsoft.com/en-us/library/cc771956(WS.10).aspx .

I didn’t find any KB article describing the approach explained here. But this is hopefully seldom – i.e. complex – situation.