Administrators, AADConnect and AdminSDHolder Issues (or why are some accounts having permission-issue)

Posted on Leave a commentPosted in AADConnect, AADSync, active directory, AdminSDHolder, dirsync, exchange, exchange online, hybrid, Office 365

AdminSDHolder is something I come across a lot, but find a lot of admins are unaware of it. In brief it is any user that is a member of a protected group (i.e. Domain Admins) will find that their AD permission inheritance and access control lists on their AD object will be reset every hour. Michael B. Smith did a nice write-up on this subject here.

AdminSDHolder is an AD object that determines what the permissions for all protected group members need to be. Why this matters with AADConnect and your sync to Azure Active Directory (i.e. the directory used by Office 365) is that any object that the AADConnect service cannot read cannot be synced, and any object that the AADConnect service cannot write to can be targeted by writeback permissions.

For the read permissions this is less of an issue, as the default read permissions by every object is part of a standard Active Directory deployment and so you will find that AdminSDHolder contains this permission and therefore protected objects can be read by AADConnect. This happens in reality becase Authenticated Users have read permissions to lots of attributes on the AdminSDHolder object under the hidden System containing in the domain. Unless your AD permissions are very locked down or AdminSDHolder permissions have been changed to remove Authenticated Users you should have no issue in syncing admin accounts, who of course might have dependencies on mailboxes and SharePoint sites etc. and so need to be synced to the cloud.

Writeback though is a different ball game. Unless you have done AADConnect with Express settings you will find that protected accounts fail during the last stage of AADConnect sync process. You often see errors in the Export profile for your Active Directory that list your admin accounts. Ofter the easiest way to fix this is to enable the Inheritance permission check box on the user account and sync again. The changes are now successfully written but within the hour this inheritance checkbox will be removed and the default permissions as set on AdminSDHolder reapplied to these user accounts. Later changes that need written back from the cloud will result in a failure to writeback again, and again permission issues will be to blame.

To fix this we just need to ensure that the AdminSDHolder object has the correct permissions needed. This is nothing more than doing what the AADConnect Express wizard will do for you anyway, but if you don’t do the Express wizard I don’t think I have seen what you should do documented anywhere – so this is the first (maybe).

Often if you don’t run Express settings you are interested in the principal of least privilege and so the rest of this blog post will outline what you will see in your Active Directory and what to do to ensure protected accounts will always sync and writeback in the Azure Active Directory sync engine. I covered the permissions to enable various types of writeback permissions in a different blog post, but the scripts in this post never added the correct write permissions to AdminSDHolder, so this post will cover what to do for your protected accounts.

First, take a look at any protected account (i.e. one that is a member of Domain Admins):
image

You will see in the Advanced permissions dialog that their is an “Enable Inheritance” button (or a check box is unchecked in older versions of Active Directory. You will also notice that all the permissions under the “Inherited From” column read “None” – that is there are no permissions inherited. You will also see, as shown in the above dialog, that if Express settings have been run for your AADConnect sync service that a access control entry for the AADConnect service account will be listed – here this is MSOL_924f68d9ff1f (yours will be different if it exists) and has read/write for everything. This is not least privilege! If you have run the sync engine previously on different servers and later removed them (as the sync engine can only run on one server to one AAD tenant, excluding staging servers) then you might see more than one MSOL account. The description field of the account will show what server it was created on for your information.

If you compare your above admin account to a non-protected account you will see inheritance can be disabled and that the Inherited From column lists the source of the permission inheritance.

Compare the access control entries (ACE) to the list of ACE’s on the AdminSDHolder object. AdminSDHolder can be found at CN=AdminSDHolder,CN=System,DC=domain,DC=local. You should find that the protected accounts match those of the AdminSDHolder, or at least will within the hour as someone could have just changed something.

Add a permission ACE to AdminSDHolder and it will appear on each protected account within an hour, remove an ACE and it will go within the hour as well. So you could for example remove the MSOL_ account(s) from older ADSync deployments and tidy up your permissions as well.

This is what my Advanced permissions for AdminSDHolder looks like on my domain

image

If I add the relevant ACE’s here for the writeback permissions then within the hour, and then for syncs that happen after that time, the errors for writeback in the sync management console will go away. Note though that AdminSDHolder is per domain, so if you are syncing more than one domain you need to set these permissions on each domain.

To script these permissions, run the following in PowerShell to update AD permissions regarding to the different hybrid writebacks scenarios that you are interested in implementing.

Finding All Your AdminSDHolder Affected Users

The following PowerShell will let you know all the users in your domain who have an AdminCount set to 1 (>0 in reality), which means they are impacted by AdminSDHolder restrictions. The changes below directly on the AdminSDHolder will impact these users as their permissions will get updated to allow writeback from Azure AD.

get-aduser -Filter {admincount -gt 0} -Properties adminCount -ResultSetSize $null | FT DistinguishedName,Enabled,SamAccountName

Password Writeback

The following PowerShell will modify the permissions on the AdminSDHolder object so that protected accounts can have Self Service Password Reset (SSPR) function against the accounts. Note you need to change the DC values in the script for it to function against your domain(s).

To determine the account name that permissions must be granted to, open the Synchronization Service Manager on the sync server, click Connectors and double click the connector to the domain you are updating. Under the Connect to Active Directory Forest item you will see the Forest Name and User Name. The User Name is the name of the account you need in the script. An example is shown below:

image

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number or MSOL_number].
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls.exe '$AdminSDHolder' /I:S /G '`"$accountName`":CA;`"Reset Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /I:S /G '`"$accountName`":CA;`"Change Password`"'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /I:S /G '`"$accountName`":WP;lockoutTime'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls.exe '$AdminSDHolder' /I:S /G '`"$accountName`":WP;pwdLastSet'"
Invoke-Expression $cmd | Out-Null

Exchange Hybrid Mode Writeback

The below script will set the permissions required for the service account that AADSync uses. Note that if Express mode has been used, then an account called MSOL_AD_Sync_RichCoexistence will exist that has these permissions rather than being assigned directly to the sync account. Therefore you could change the below permissions to utilise MSOL_AD_Sync_RichCoexistence rather than AAD_ or MSOL_ and achieve the same results, but knowing that future changes to the MSOL_ or AAD_ account will be saved as it was done via a group.

The final permission in the set is for msDS-ExternalDirectoryObjectID and this is part of the Exchange Server 2016 (and maybe Exchange Server 2013 later CU’s) schema updates. Newer documentation on AAD Connect synchronized attributes already has this attribute listed, for example in Azure AD Connect sync: Attributes synchronized to Azure Active Directory

$accountName = "domain\aad_account"
$AdminSDHolder = "CN=AdminSDHolder,CN=System,DC=contoso,DC=com"

$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;proxyAddresses'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;msExchArchiveStatus'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$AdminSDHolder' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID'"
Invoke-Expression $cmd | Out-Null

Once these two scripts are run against AdminSDHolder object and you wait an hour, the permissions will be applied to your protected accounts, then within 30 minutes (based on the default sync time) any admin account that is failing to get cloud settings written back to Active Directory due to permission-issue errors will automatically get resolved.

Exchange Edge Server and Common Attachment Blocking In Exchange Online Protection

Posted on Leave a commentPosted in 2007, 2010, 2013, 2016, Edge, EOP, exchange, exchange online, Exchange Online Protection, FOPE, IAmMEC, Office 365

Both Exchange Server Edge role and Exchange Online Protection have an attachment filtering policy. The default in Edge Server is quite long, and the default in EOP is quite short. There is also a few values that are common to both.

So, how do you merge the lists so that your Edge Server attachment filtering policy is copied to Exchange Online in advance of changing your MX record to EOP?

You run

Set-MalwareFilterPolicy Default -FileTypes ade,adp,cpl,app,bas,asx,bat,chm,cmd,com,crt,csh,exe,fxp,hlp,hta,inf,ins,isp,js,jse,ksh,lnk,mda,mdb,mde,mdt,mdw,mdz,msc,msi,msp,mst,ops,pcd,pif,prf,prg,ps1,ps11,ps11xml,ps1xml,ps2,ps2xml,psc1,psc2,reg,scf,scr,sct,shb,shs,url,vb,vbe,vbs,wsc,wsf,wsh,xnk,ace,ani,docm,jar

This takes both the Edge Server default list and the EOP default list, minus the duplicate values and adds them to EOP. If you have a different custom list then use the following PowerShell to get your two lists and then use the above (with “Default” being the name of the policy) PowerShell to update the list in the cloud

Edge Server: Get-AttachmentFilterEntry

EOP: $variable = Get-MalwareFilterPolicy Default
$variable.FileTypes

Get-SpoofMailReport in EOP

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Office 365, spam, spoof

Using Office 365 or EOP to protect your email and worried about spoofed emails? Then try this cmdlet in Remote PowerShell for EOP:

PS C:\Users\brian.reid> Get-SpoofMailReport

Date                Event Type Direction Domain Action       Spoofed Sender              True Sender     Sender IP
—-                ———- ——— —— ——       ————–              ———–     ———
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.186.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         someapp.com     198.2.179.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    1.130.217…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk                      1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.132.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     andrew@domain.com           mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          CaughtAsSpam wordpress@other.com         host-h.net      129.232.144…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.187.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk                     1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24

Thats the output I get from running this on the afternoon of April 20th (UK style dates for the American readers of this blog)! Notice a few things (its been somewhat redacted to remove private into), but the spam filter provider in front of EOP in this tenant is seen as spoofing postmaster emails and there are some from mandrillapp.com in a similar vein. Both of these companies send email on our behalf, so I expect to see them here – so nothing to see here for these. How about the others? One is a hosting company, probably hosting WordPress instances and so these are probably alerts of some kind from a web hoster to us, so again I think for us nothing here.

What do you get – is it more interesting for you?

Then finally, how about getting the results in date order, as they are not by default: Get-SpoofMailReport | sort -Property Date

 

 

Renewing Apple APN for Office 365 Mobile Device Management

Posted on 2 CommentsPosted in exchange online, iOS, iPad, iPhone, MDM, Mobile Device Management, mobile phones, Office 365

Office 365 MDM (Mobile Device Management) allows you to manage iOS based Apple devices. Once you have had Office 365 Mobile Device Management is use for a year, the Apple APN certificate that you would have created a year ago for this purpose will expire. If you did not add this renewal date to your calendar when you set up Office 365 MDM, or if you have taken over as administrator from someone else since then you had best check for your renewal dates, as Apple will email the address they have for the certificate at 30 days, 10 days and the day before it expires. Here is the day before it expires email warning – and I got this yesterday. So I had better renew the certificate now then. You of course will not leave it so late!

image

To check your renewal date, login as a Global Admin to the Office 365 Portal. On the old portal visit the Mobile Management tab on the left and the renewal date is shown on the right:

SNAGHTMLe083076

The above is for one of my clients, and the 30 day warning arrived for them today – so I will do them in a few days time.

If you are using the new Office 365 admin portal, then expand Resources > Mobile Management on the left navigation bar (note, at the time of writing, you cannot renew your APNs from the new portal and must use the old – the new portal redirects you back to your starting page all the time and does not start the correct wizard). This opens the same window as shown above. Later versions of the new portal might integrate the page with the portal, but that is not currently active (April 2016):

SNAGHTMLe0b34ae

To renew your certificate click the Manage settings link under the APNs Certificate for iOS devices message to the top right.

You will see the “Set up mobile device management” page:

image

Click Set up to the right of the “Configure an APNs Certificate for iOS devices”. This takes you to the “Install Apple Push Notification Certificate” page. On one of my tenants (possibly with the APNs expired already) clicking Set up took me back to the “Mobile Device Management for Office 365” and I could never get past it. That tenant needed a support call raised to fix.

On the “Install Apple Push Notification Certificate” page click “Download your CSR file” and save the file somewhere you can find shortly.

SNAGHTMLe183115

Click Next once file saved to disk.

SNAGHTMLe1a0325

On the second page of the wizard, click the “Apple APNS Portal” link. As this is a renewal, you need to login to the Apple Developer site with the same credentials used last time. If you have lost these and cannot reset them, then I suspect uploading a new certificate issued to a new ID will work, but I have not tested this.

SNAGHTMLe1cb6db

Once signed in click Renew. If changing issuer account and you have access to the old account, then click Revoke and login with the new account to https://identity.apple.com/pushcert to generate the new APNs certificate.

SNAGHTMLe1eb134

On the Renewal page, upload the saved CSR file from step 1 into the “Vendor-Signed Certificate Signing Request” and click Upload:

SNAGHTMLe1fdded

If you get a prompt about opening or saving a file called renew.json then cancel it and refresh the web browser page to continue the CSR file upload. The Apple web site often issues a JSON file as a download, but that should not happen and is not the file you need. Once the APNs is ready the browser will change back to the Apple Push Certificates Portal home page with a new certificate present (confirm this as the date will be a year from today). Click Download to get the APNs file.

SNAGHTMLe27d904

Upon clicking download you are offered to save a .pem file. This file will be called “MDM_ Microsoft Corporation_Certificate.pem”. If you are a Microsoft Partner and are doing this for multiple customers then rename it to suit the end client.

Close the Apple Push Certificates Portal page and in the previous tab you will find yourself back at step 2. Click Next.

SNAGHTMLe2a4532

In the file upload field, browse for MDM_ Microsoft Corporation_Certificate.pem (or whatever you renamed it to) and upload it to Office 365. The certificate is automatically uploaded. Click Finish and you are done.

Don’t forget to add a calendar appointment for this time next year just in case the reminders from Apple don’t reach you.

Exchange Online Archive–Counting Archives

Posted on Leave a commentPosted in archive, exchange, exchange online, Exchange Server, EXO, IAmMEC, Office 365

If you are using Exchange Online Archive and what to get a count of the number of users with an archive, or a list of the users with an archive, then the following PowerShell scripts will give you this info:

List all users with an Exchange Online Archive:

Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}

Count all users with an Exchange Online Archive:

(Get-MailUser -ResultSize Unlimited | where {$_.ArchiveName -ilike “In-Place Archive*”}).Count

Both of these PowerShell cmdlets need to be run in Exchange Online via Remote PowerShell.

Unable To Remove Office 365 Domain Error

Posted on Leave a commentPosted in dirsync, exchange online, hybrid, IAmMEC, MSOL, Office 365, powershell

If you need to remove a domain from Office 365 it needs to not be in use. This includes the services that use that domain, for example an Accepted Domain in Exchange Online. If though you have an expired, maybe test, Office 365 tenant and you want to remove a domain from it you may find unhelpful error messages. For example I have seen in the domain removal process in the portal a message saying “Please don’t close this page while we remove your domain” etc. It tries for several minutes as it predicts, but did not complete:

image

Upon failing to complete you get a further warning before it finally gives up and tells you that it cannot complete:

image

So the obvious next step (or obvious to me anyway) is to try the removal in remote PowerShell to Office 365. The cmdlet is Remove-MsolDomain -DomainName domain.com but this comes back with with messages that might be helpful, but after repeated running of the cmdlet and fixing the error still suggests the same fix.

image

The error reads: Remove-MsolDomain : Unable to remove this domain. Use Get-MsolUser -DomainName <domain name>  to retrieve a list  of objects that are blocking removal. The problem with this error is the list of objects here are only user accounts and not any of the other objects that could block a domain removal.

So sure, remove your unneeded users or change their UPN/email address to not include this domain that you want to remove, but also run Get-MsolContact and Get-MsolGroup and then remove or edit the contacts and the groups that use this domain.

So though the error says to fix the user objects that are blocking domain removal, you also need to fix or remove the groups and contacts as well.

Exchange Server and Missing Root Certificates

Posted on Leave a commentPosted in 2007, 2010, 2013, exchange, exchange online, Exchange Server, federation, Free/Busy

I came across an issue with a clients Exchange Server deployment today that is not well documented – or rather it is, but you need to know where to look. So I thought I would document the troubleshooting steps and the fix here.

We specifically came across this error when testing Free/Busy for an Office 365 migration, though it could happen for a variety of reasons. Free/Busy and other lookups in a cross-forest Exchange Server deployment require a working organization configuration and this was failing. Running Test-FederationTrust (a prerequisite of the organization relationship) in verbose mode (add -Verbose to the end) returned the following:

Unable to retrieve federation metadata from the security token
service. Reason: Microsoft.Exchange.Management.FederationProvisioning.FederationMetadataException: Unable to access the
Federation Metadata document from the federation partner. Detailed information: “The underlying connection was closed:
Could not establish trust relationship for the SSL/TLS secure channel.”.

The final result of the test will also show two errors for “Unable to retrieve federation metadata from the security token service.” and “Failed to request delegation token.”

The last part of the verbose error is the clue here. The server in question is unable to make an SSL/TLS connection to the endpoint that the federation trust needs to reach to get the federation trust metadata. That endpoint is listed right at the start of the Verbose output. It reads:

VERBOSE: [16:53:08.306 GMT] Test-FederationTrust : Requesting Federation Metadata from
https://nexus.microsoftonline-p.com/FederationMetadata/2006-12/FederationMetadata.xml.

Now that we have a URL and an error message, check that the URL is reachable from each of your Exchange Servers. At my client today we found one server could not successfully reach this endpoint without an SSL error turning up in the browser. The problem was that the certificate that the endpoint is secure with is issued by the Baltimore Cybertrust Root Certificate – one that Microsoft uses for lots of services, but the root certificate was not installed on that machine. Lots of root certs where missing from that machine as it had never had a root certificate update applied to it.

We installed the latest Root Certificate Update and then the federation trust worked and free/busy etc. (mail tips, cross-forest message tracking etc.) all worked fine.

Configuring Writeback Permissions in Active Directory for Azure Active Directory Sync

Posted on 23 CommentsPosted in 2008, 2008 R2, 2012, 2012 R2, active directory, ADFS 3.0, Azure, Azure Active Directory, cloud, exchange, exchange online, groups, hybrid, IAmMEC, Office 365, WAP, Web Application Proxy, windows

[Update November 2015 – User Writeback has been pulled from preview, so latest versions of AADConnect do not offer this option – it will probably return, so content about it remains in this blog]

[Update September 2016 – added new attributes as AADConnect now syncs more stuff, so updated scripts to match published changes]

[Update March 2017 – added another blog post on using the below to fix permission-issue errors on admin and other protected accounts at http://c7solutions.com/2017/03/administrators-aadconnect-and-adminsdholder-issues]

Azure Active Directory has been long the read-only cousin of Active Directory for those Office 365 and Azure users who sync their directory from Active Directory to Azure Active Directory apart from eight attributes for Exchange Server hybrid mode. Not any more. Azure Active Directory writeback is now available and in preview for some of the writeback types at the time of writing. This enabled objects to be mastered or changed in Azure Active Directory and written back to on-premises Active Directory.

This writeback includes:

  • Devices that can be enrolled with Office 365 MDM or Intune, which will allow login to AD FS controlled resources based on user and the device they are on
  • “Modern Groups” in Office 365 can be written back to on-premises Exchange Server 2013 CU8 or later hybrid mode and appear as mail enabled distribution lists on premises. Does not require AAD Premium licences
  • Users can change their passwords via the login page or user settings in Office 365 and have that password written back online.
  • Exchange Server hybrid writeback is the classic writeback from Azure AD and is the apart from Group Writeback is the only one of these writebacks that does not require Azure AD Premium licences.
  • User writeback from Azure AD (i.e. users made in Office 365 in the cloud for example) to on-premises Active Directory
  • Windows 10 devices for “Azure AD Domain Join” functionality

All of these features (apart from Exchange Hybrid writeback) require AADSync and not DirSync. Install and run the AADConnect program to migrate from DirSync to AADSync and then in the Synchronization Options on rerunning the AADConnect wizard you can add all these writeback functions.

Preparing for Device Writeback

If you do not have a 2012 R2 or later domain controller then you need to update the schema of your forest. Do this by getting a Windows Server 2012 R2 ISO image and mounting it as a drive. Copy the support/adprep folder from this image or DVD to a 64 bit domain member in the same site as the Schema Master. Then run adprep /forestprep from an admin cmd prompt when logged in as a Schema Admin. The domain member needs to be a 64 bit domain joined machine for adprep.exe to run.

Wait for the schema changes to replicate around the network.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Azure AD Global Admin and Enterprise Admin permissions for Azure and local AD forest respectively. The cmdlets for this are obtained by running the Azure AD Connect tool.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account in the form of AAD_number].
Initialize-ADSyncDeviceWriteBack -AdConnectorAccount $accountName -DomainName contoso.com #[domain where devices will be created].

This will create the “Device Registration Services” node in the Configuration partition of your forest as shown:

image

To see this, open Active Directory Sites and Services and from the View menu select Show Services Node. Also in the domain partition you should now see an OU called RegisteredDevices. The AADSync account now has permissions to write objects to this container as well.

In Azure AD Connect, if you get the error “This feature is disabled because there is no eligible forest with appropriate permissions for device writeback” then you need to complete the steps in this section and click Previous in the AADConnect wizard to go back to the “Connect your directories” page and then you can click Next to return to the “Optional features” page. This time the Device Writeback option will not be greyed out.

Device Writeback needs a 2012 R2 or later AD FS server and WAP to make use of the device info in the Active Directory (for example, conditional access to resources based on the user and the device they are using). Once Device Writeback is prepared for with these cmdlets and the AADConnect Synchronization Options page is enabled for Device Writeback then the following will appear in Active Directory:

image

Not shown in the above, but adding the Display Name column in Active Directory Users and Computers tells you the device name. The registered owner and registered users of the device are available to view, but as they are SID values, they are not really readable.

Preparing for Group Writeback

Writing Office 365 “Modern Groups” back to Active Directory on-premises requires Exchange Server 2013 CU8 or later schema updates and servers installed. To create the OU and permissions required for Group Writeback you need to do the following.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Domain Admin permissions for the domain in the local AD forest that you will write back groups to. The cmdlets for this are obtained by running the Azure AD Connect tool.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudGroupOU = "OU=CloudGroups,DC=contoso,DC=com"
Initialize-ADSyncGroupWriteBack -AdConnectorAccount $accountName -GroupWriteBackContainerDN $cloudGroupOU

Once these cmdlets are run the AADSync account will have permissions to write objects to this OU. You can view the permissions in Active Directory Users and Computers for this OU if you enable Advanced mode in that program. There should be a permission entry for this account that is not inherited from the parent OU’s.

At the time of writing, the distribution list that is created on writeback from Azure AD will not appear in the Global Address List in Outlook etc. or allow on-premises mailboxes to send to these internal only cloud based groups. To add it to the address book you need to create a new subdomain, update public DNS and add send connectors to hybrid Exchange Server. This is all outlined in https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx. This ensure’s that on-premises mailboxes can deliver to groups as internal senders and not require external senders enabled on the group. To add the group to the Global Address List you need to run Update-AddressList in Exchange Server. Once group writeback is prepared for using these cmdlets here and AADConnect has had it enabled during the Synchronization Options page, you should see the groups appearing in the selected OU as shown:

image

And you should find that on-premises users can send email to these groups as well.

Preparing for Password Writeback

The option for users to change their passwords in the cloud and have then written back to on-premises (with multifactor authentication and proof of right to change the password) is also available in Office 365 / Azure AD with the Premium Azure Active Directory or Enterprise Mobility Pack licence.

To enable password writeback for AADConnect you need to enable the Password Writeback option in AADConnect synchronization settings and then run the following three PowerShell cmdlets on the AADSync server:


Get-ADSyncConnector | fl name,AADPasswordResetConfiguration
Get-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD"
Set-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD" -Enable $true

The first of these cmdlets lists the ADSync connectors and the name and password reset state of the connector. You need the name of the AAD connector. The middle cmdlet tells you the state of password writeback on that connector and the last cmdlet enables it if needed. The name of the connector is required in these last two cmdlets.

To set the permissions on-premises for the passwords to be written back the following script is needed:

$passwordOU = "DC=contoso,DC=com" #[you can scope this down to a specific OU]
$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd&nbsp;| Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Change Password`";user'"
Invoke-Expression $cmd&nbsp;| Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;lockoutTime;user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;pwdLastSet;user'"
Invoke-Expression $cmd | Out-Null

Preparing for Exchange Server Hybrid Writeback

Hybrid mode in Exchange Server requires the writing back on eight attributes from Azure AD to Active Directory. The list of attributes written back is found here. The following script will set these permissions for you in the OU you select (or as shown at the root of the domain). The DirSync tool used to do all this permissioning for you, but the AADSync tool does not. Therefore scripts such as this are required. This script sets lots of permissions on these eight attributes, but for clarify on running the script the output of the script is sent to Null. Remove the “| Out-Null” from the script to see the changes as they occur (the script also takes a lot longer to run).

$accountName = "domain\aad_account"
$HybridOU = "DC=contoso,DC=com"

#Object type: user
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;user'"
Invoke-Expression $cmd | Out-Null

#Object type: iNetOrgPerson
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
#Object type: group
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;group'"
Invoke-Expression $cmd | Out-Null

#Object type: contact
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;contact'"
Invoke-Expression $cmd | Out-Null

Preparing for User Writeback

Currently in preview at the time of writing, you are able to make users in Azure Active Directory (cloud users as Office 365 would call them) and write them back to on-premises Active Directory. The users password is not written back and so needs changing before the user can login on-premises.

To prepare the on-premises Active Directory to writeback user objects you need to run this script. This is contained in AdSyncPrep.psm1 and that is installed as part of Azure AD Connect. Azure AD Connect will install Azure AD Sync, which is needed to do the writeback. To load the AdSyncPrep.psm1 module into PowerShell run Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudUserOU = "OU=CloudUsers,DC=contoso,DC=com"
Initialize-ADSyncUserWriteBack -AdConnectorAccount $accountName -UserWriteBackContainerDN $cloudUserOU

Once the next AADSync occurs you should see users in the OU used above that match the cloud users in Office 365 as shown:

image

Prepare for Windows 10 BYOD

Windows 10 devices can “domain join” Azure Active Directory and be written back to the on-premises Active Directory.

The AdSyncPrep.psm1 module supports the following two additional cmdlets to prepare your Active Directory for Windows 10 device writeback:

Initialize-ADSyncDomainJoinedComputerSync
Initialize-ADSyncNGCKeysWriteBack

These cmdlets are run as follows:

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$azureAdCreds = Get-Credential #[Azure Active Directory administrator account]

Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount $accountName -AzureADCredentials $azureAdCreds
Initialize-ADSyncNGCKeysWriteBack -AdConnectorAccount $accountName

Once complete, open Active Directory Sites and Services and from the View menu Show Services Node. Then you should see the GUID of your domain under the Device Registration Configuration container.

image

Advanced Threat Protection via PowerShell

Posted on 3 CommentsPosted in Advanced Threat Protection, ATP, EOP, exchange online, Exchange Online Protection, IAmMEC, Office 365, Safe Attachments, Safe Links

I discussed the newly released Advanced Threat Protection product in Office 365 on my blog, and in this article I want to outline the cmdlets that can be used to set this product up from Remote PowerShell to Office 365.

To connect to Office 365 via PowerShell take a search on your favourite search engine – there are lots and lots of articles on doing this. Once you have a connection to Exchange Online and you have purchased the Exchange Online Advanced Threat Protection product, you can use PowerShell to do your administration and report gathering.

The cmdlets you can use are for Safe Links are:

Disable-SafeLinksRule
Enable-SafeLinksRule
Get-SafeLinksPolicy
Get-SafeLinksRule
New-SafeLinksPolicy
New-SafeLinksRule
Remove-SafeLinksPolicy
Remove-SafeLinksRule
Set-SafeLinksPolicy
Set-SafeLinksRule

And the cmdlets you can use for Safe Attachments are:

Disable-SafeAttachmentRule
Enable-SafeAttachmentRule
Get-SafeAttachmentPolicy
Get-SafeAttachmentRule
New-SafeAttachmentPolicy
New-SafeAttachmentRule
Remove-SafeAttachmentPolicy
Remove-SafeAttachmentRule
Set-SafeAttachmentPolicy
Set-SafeAttachmentRule

And for reporting, you can run Get-AdvancedThreatProtectionTrafficReport to report on the number of attachments blocked and the type of notification sent when looking at Safe Attachments. Get-UrlTrace does the same report for Safe Links.

The cmdlet *-SafeLinksPolicy and *-SafeAttachmentPolicy controls the policy. Every rule needs to be associated with a policy and so a policy needs creating first:

New-SafeLinksPolicy “Protect C7 Solutions Users”

Will create a Safe Link policy with the default settings. This includes no URL tracking, no click through and is not enabled. A better start might be

New-SafeLinksPolicy “Protect C7 Solutions Users” -TrackClicks $true -IsEnabled $true -AllowClickThrough $false

Once a policy is created, a rule can be added to that policy. The *-SafeLinksRule and *-SafeAttachmentRule cmdlets control this in the shell. You can only have one rule per policy. An example cmdlet to create a rule would be:

New-SafeLinksRule “Protect C7 Solutions Users” -SafeLinksPolicy “Protect C7 Solutions Users” -RecipientDomainIs “c7solutions.com” -Enabled $true

Note that the –SafeLinksPolicy value matches that of the name of the previously created policy when making the rule.

To create a Safe Attachment policy and rule that protect all users by blocking malicious attachments and sending a report to an external mailbox you could use:

New-SafeAttachmentPolicy “Protect C7 Solutions Users” -Enable $true -Redirect $true -RedirectAddress brian@contoso.com –Action Block

New-SafeAttachmentRule “Protect C7 Solutions Users” -RecipientDomainIs “c7solutions.com” -SafeAttachmentPolicy “Protect C7 Solutions Users” -Enabled $true

The other cmdlets are self explanatory with regard to Enable- and Disable- and Set- and Remove-. The advantage of using PowerShell to administer Safe Links and Safe Attachments is you can set up a policy in a lab and then copy it to a production environment or enable the same policy on many different tenants if you are a Microsoft Partner with customers interested in this advanced protection of their mailbox.

Getting Started with Office 365 Advanced Threat Protection

Posted on 5 CommentsPosted in Advanced Threat Protection, ATP, EOP, exchange online, Exchange Online Protection, IAmMEC, malware, Office 365, proxy, Safe Attachments, Safe Links

Announced a few months ago, Advanced Threat Protection became generally available on 1st June. I have been involved with trialling this product during the beta and so I thought I would note down a few thoughts on setting this up and what to expect now that it is publicly available.

Advanced Threat Protection is an add-on product to Exchange Online/Exchange Online Protection with its own subscription, so you will not see these features and products unless you have subscribed. Once you have subscribed you will get two new features in the Exchange Control Panel for Office 365. These are the ability to find malware containing attachments before a detection signature for that malware exists (zero-day malware attacks) and the ability to filter all hyperlinks in email via a known malicious links service (filtering against spear-phishing attacks). The feature to detect zero-day malware is called Safe Attachments and the feature to protect against spear-phishing is known as Safe Links.

Subscribing to Advanced Threat Protection

After signing into the Office 365 administration portal click Purchase Services on the left hand menu and locate your current Office 365 subscription that contains Exchange Online or Exchange Online Protection (Office 365 Enterprise E3 contains EOP, so you would look for your suite purchase if you did not have a standalone purchase of EOP). Your current subscriptions will contain the words Already Purchased underneath the item as shown:

image or image

In the two screenshots above you can see that you have no Exchange Online Advanced Threat Protection licences purchased. To add Advanced Threat Protection licences click the Add more link and enter the number of licences you want to purchase. You do not need to purchases the same number of licences as EOP or Exchange Online mailbox licences as you use the policy below to control who Advanced Threat Protection is available for. Advanced Threat Protection for volume licence customers is available from August 2015 and for non-profit/educational licences from later in the year. Once the purchase is confirmed the Advanced Threat’s menu entry appears in the Exchange Administration Console. Also don’t forget to assign a licence to the appropriate users in the Office 365 portal.

Safe Attachments

Safe Attachments in Advanced Threat Protection takes any email that meets the conditions of any one of the Safe Attachment policies that you create that also contains an attachment and checks this email for for malicious behaviour as it passes through Exchange Online Protection (EOP). Before an email is checked by Safe Attachments the attachment has already been scanned for known malware and viruses. So if the attachment contains malware that was not detected by an existing AV signature or if it is a safe attachment (no malware) then the email is routed to the Safe Attachments component in EOP. If the email does not contain any attachments it is routed to the users mailbox by way of the other EOP spam filtering features.

Once an email is considered to have cause to be checked by the Safe Attachments component of ATP the individual attachments in the message are placed inside a newly created Windows virtual machine that is spun up in ATP for the purposes of this service. The attachment is then executed or otherwise run (for example if it is a Word doc, it is opened in Word in the new VM that was created for it). The VM is then watched for behaviour that is considered to be unsafe. Examples of unsafe behaviour include setting certain known registry key locations (such as the RunOnce group of keys in Windows) or downloading malicious content from the internet. If the attachment does not exhibit that behaviour then the email is released and sent on to the user. If the email does exhibit these actions the email is not sent onward, and optionally a copy of the email in a form of a report is forwarded to an administrators mailbox (where care should be taken on opening the attachment).

The time it takes to spin up a new VM and execute the attachment is in the region of 7 to 10 minutes. Therefore anyone subject to a Safe Attachments policy will have emails that contain attachments delayed by at least this amount of time. Of course this delay is necessary to ensure that the recipient is not being sent malware that is currently not detected (zero-day attacks) and the impact of this delay needs to be considered against the benefit of the additional filtering that happens and the impact of that user executing the malware themselves on their own machine.

To protect a user with Safe Attachments you need to create a policy. This is done in the Exchange Admin Centre in Office 365 and the “advanced threats” area as shown:

SNAGHTML43a8f613

In the above screenshot I have a single policy created called “Protect Brian Only”. This would be an example where I wanted to protect those users whom I though where more likely to be subject to zero-day malware attacks – good examples would be highly targets accounts (CEO etc.), IT administrator/help desk accounts and of course the accounts of users who will click anything and so you are often cleaning up their PC! There is no default policy, so unless a user is protected by a policy that you the administrator create, they are not subject to the Safe Attachments feature.

As Advanced Threat Protection is an additional licence, only those users who are licenced should be included in any policy.

Opening the “Protect Brian Only” example policy above shows me three sets of options. These are:

SNAGHTML43aa903b SNAGHTML43b22229 SNAGHTML43aad2b3

The first page allows me to edit the name and description. The second page sets the policy (more on this below) and the final page sets who the policy applies to. In this example it applies to a single recipient who was selected from the list of users in Office 365, though it could be a list of more than one user or anyone with a given email domain or anyone in an already created group.

The policy setting allows me to do the following:

  • Scan attachment containing emails (with options to not do this scanning, scan and send onward to the user regardless of the result, block the emails containing bad attachments or replace the attachments with a notification but allow the contents of the email to go on through).
  • Redirect the attachment containing emails to an alternative email address and what address to use. This is great for seeing what is blocked and acting as a sort of reporting service. Warning – this email address will get malicious emails sent to it, handle with extreme care.
  • Finally, in the event of a timeout at EOP/ATP where the attachment cannot be scanned in 30 minutes, check this box to treat the attachment in the same way as malicious emails are treated. This is the default action.

In the mailbox of the intended recipient, if block or replace is selected in the policy then the user will not see the malicious attachment and therefore cannot accidently execute its contents.

In the mailbox of the email address used for the redirection, you will see messages such as follows:

image

Here you see a report email that contains the email that was detected as malicious. You can see the To: address (redacted in the graphic above) and that it was not sent to the intended recipient and that it should not be opened.

All in all, its a very simple and inexpensive way to protect the mailboxes of either all staff or those you consider subject to targeted malware such as CEO type staff and the IT department. Even if you do not redirect emails containing malicious attachments, you can report on the number and type of attachments that are blocked from the reporting console available from the image icon on the ATP toolbar. The following shows a 30 day report for my tenant (which has only a few live mailboxes protected). For data-points beyond 7 days old it will take a short while for the information on the report to be returned to you and you need to request that report from the provided link. For data-points under 7 days you can see the information in real-time. The grey background to report shows where the 7 day period is located. In the below screenshot the above malware can be see in the report as the single instance of an email that passed AV scanning successfully but was in fact a zero-day attack. The second screenshot below shows the type of malware attachments that ATP is blocking. From this we can see that the risk lies in maliciously crafted Excel and Word attachments.

SNAGHTML43c1954c SNAGHTML43ce425b

Safe Links

When an email is delivered to the end recipient, any technology that checks the target of any link in the email is prone to one large issue – the web page or attachment on the other side of the hyperlink in the email may be safe and okay to view at the time of delivery, but might not be at the time the user comes to open the email and then click the link. Being aware of users working, or at least email reading hours, and delivering emails outside this timeframe with links to websites that are okay at the time of delivery means the email passes any web site or download checks done by the email server.

Advanced Threat Protection’s Safe Links feature protects the user by rewriting the hyperlink in the email body so that the link is checked at the point of click and not the point of delivery. To do this the hyperlink is changed from the target to the Safe Links portal. Then when the user clicks the link, they are taken to the Safe Links portal and if the site is now on a block list, the user is blocked, but if the target of the link is fine they are sent a browser redirect to the original target. Note that this is not a proxy server – you do not connect to the target URL through the Safe Links portal, you just visit the Safe Links portal when you click the link and if the target is safe at point of click you are directed via your browser to the target (a client side redirect). If the target is not safe at point of click then an error page is displayed.

In the following screenshot is an email with a hyperlink in it. This link was received by me to my Safe Links protected account and it looks link it might be an attempt to download malware to my computer, but I am going to click the link anyway (in second screenshot I am hovering over the hyperlink):

image image

You can see from the above screenshot that the hyperlink takes the user first to https://na01.safelinks.protection.outlook.com/?url=targetURL&data=value&sData=otherValue. The na01 part of the URL will be regionally specific and so might read emea01 or apac01 etc. When the user clicks the link they go to region.safelinks.protection.outlook.com. In my case I see the following webpage:

image

Here I am told the page has been classified as malicious. I also have an option to continue anyway (and I can control if this setting appears for users or not) and an option to close the browser window.

If the hyperlink is not malicious at the point of click then I still go to the Safe Links portal (as it is the portal that checks the link at point of click), but then get redirected to the target URL. This can be seen in the following screenshot which shows the F12 developer tools enabled in the browser and the network trace screen shown at the bottom of the window:

image

You will see that the first line is the Safe Links portal and this take 0.75 second before being redirected with a HTTP 302 client side redirect to the target URL and then the rest of the objects on the target page (until I paused the trace).

So how do I set this all up? It is very similar to the Safe Attachments above in that we create a policy, and then any email that contains hyperlinks that is delivered to the end user after that users is added to a policy get rewritten.

First we go to the Advanced Threats area of the Exchange Administration Console:

SNAGHTMLeafbb84

Here you can see an existing policy. There are no policies by default. If I create a new policy I need to provide the following:

SNAGHTMLeb3664c

You can see from the screenshot that you need a name for the policy and whether or not a link is rewritten (policies with greater priority take precedence, so if a user is subject to two or more polices then only the higher priority policy takes effect, therefore you can use a policy to turn off link rewriting for a subset of users covered under a lower policy that enabled it for more users). Also you can disable link tracking and not to allow users to have the option to click through to the target URL. Link tracking allows you to report who clicked what link and not allowing users to click through disables the “Continue to this website (not recommended)” link on the Safe Links warning page.

You also have the ability to control URL’s that you do not want to rewrite, and rewriting will only happen for FQDN URL’s (that is those with dots in them) and not single name URL’s such as http://intranet.  This allows you to bypass redirection for sites you know are safe or are FQDN’s but are internal.

Finally you get to set who the policy applies to. You do not need to apply the policy to all users if you have not licenced all users, but you can set policy based on who the recipient is, what domain the recipient is in (all users in that domain) or a group (some users).

On the Mail Flow menu in Exchange Control Panel you can view a URL Trace of the links that users have clicked in the past 7 days. The report shows you the link clicked and if it was blocked or not. If the click through option is enabled, it will show if that was done as well. Only users in policies that track clicks will be reported. As report looks like the following:

SNAGHTMLfdf4592

Further Administration

To administer your Safe Links and Safe Attachments policy and rules via Remote PowerShell see http://c7solutions.com/2015/06/advanced-threat-protection-via-powershell