Friday, 16 November 2018

Customise the AD Connect sync scheduler time window

By default AD Connect automatically syncs to Azure AD every 30 minutes. Although this works fine in most companies, it could be considered too long a period if there is a high rate of change within an organisation. 

To alter the default sync period use Powershell

Set-ADSyncScheduler -CustomizedSyncCycleInterval 00:05:00 

The above command sets the sync period to 5 mins. It's important that you do not set the sync period too low, so that sync jobs don't begin to clash. A delta sync should not take a full 5 minutes unless the AD of a large enterprise scale.

Thursday, 15 November 2018

Understanding and extending AD CS CRL publication periods

By default when you deploy a two-tier AD CS the default CRL publication period is 1 week. This is set on the Offline CA and the Onsite CA. 

What does this mean?

If you have the CRL publication period set to one week, a new CRL must be published and available to clients on a weekly basis of certificate revocation will fail. 

In a two-tier AD CS infrastructure there are two CRL's in created;

Offline CA CRL - this is published by the Offline CA and should be blank unless you have revoked historic Root Certificates. This CRL is only used to by the Online CA to check the validity of Root Certificate which has been issued by the Offline CA. If certificate revocation fails for the Offline CA Root Certificate, the entire AD CS will fail. This is because all certificates are signed by the top certificate in the trust chain. By default this is set to one week, which means every week an administrator will have to boot the Offline CA, publish a new CRL and then copy it to the revocation points. It is likely that your Offline CA will only issue a single certificate, to the Online CA, if this is the case there is no risk in setting the Offline CA's CRL publishing time to months, or even years. 

To do this login to the Offline CA, open Certification Authority expand the server object, right click on Revoked Certificates and select Properties. Once this is committed, a new CRL must be created which can be done if you right click Revoked Certificates and select All Tasks > Publish. 

The newly published CRL can be found at C:\Windows\System32\CertSrv\CertEnroll the CRL files should be copied to the revocation points which are usually stored in AD LDAP, HTTP or both. It's typical for a HTTP revocation point to be on the Online CA, so that it's reachable by clients. 



Online CA CRL - this is published by the Online CA and will contain any certificates that have been revoked by administrators. Revoked certificates are not listed in the CRL until a new CRL has been generated. The Online CA CRL publication period is more important than the Offline CA, this is because it's likely that certificates issued by the Online CA might actually be revoked during the course of normal business. I usually set the Online CA to have a CRL publication period of 1 month, which means a new CRL will automatically be published every month, however once published the CRL files are not automatically copied to the revocation points on disk, which are usually served over HTTP by IIS or similar. If no certificates are revoked over the period of a month, the CRL will be unchanged, however the new files must be copied into the revocation point locations or certificate revocation will fail. 

With the Online CA CRL set to 1 month I usually just build it into a monthly maintenance task that should be provided by the SysAdmin team who are managing the AD CS environment. 

A useful way to check CRL expiration times is to use pkiview.msc which gives a clear overview of the CRL's all the way up the trust chain.


Thursday, 8 November 2018

Things to remember when configuring Exchange Hybrid to Office 365 and Exchange Online


Tip 1 – Office 365 should be used as a smart host for external mail routing

The Hybrid Configuration Wizard creates connectors on the Exchange Server to route mail to and from Office 365. By default, the on premise Send Connector is configured to only route mail destined for the “tenantname.mail.onmicrosoft.com SMTP namespace.

This Send Connector is configured to use MX records lookups to find its next hop to route mail to this SMTP domain. I have had far better results if the Send Connector is manually configured to send all mail for “tenantname.mail.onmicrosoft.comto the tenant’s public MX record target. In theory it should make no difference!

For clarity you modify the Send Connector on the Exchange Server it is usually labelled “Outbound to Office 365” if the HCW was used to configure your server. You can also find the MX record target by using MX Toolbox.



You will notice the smart host authentication option is set to None. Office 365 will use the federation certificate in place to authenticate the server, therefore no authentication is required on the Send Connector. 


Tip 2 – The Exchange Hybrid Configuration Wizard does not complete the job

If you have on premise Exchange Server before adopting Office 365, it is likely that you will have Send Connectors already in place to route mail to the Internet. During the design phases you must decide how you are going to architecture your mail flow. Personally I think it’s best to route all email from the Internet through Exchange Online, then down to the Exchange Server if the mail enabled recipient resides on premise. I also think routing outbound mail (for all domains) should be done through Exchange Online. This is something that the HCW does not do during the wizard led set up.

A new Send Connector is created labelled “Outbound to Office 365” which routes mail to the tenant SMTP domain for hybrid mail flow. My recommendation would be to edit this Send Connector and add the all domains asterisks. With this configuration all mail for all domains will be pushed to Exchange Online for routing. 


All of your design decisions should be led by requirements, however in a simple environment this will cover most basis. It does however, become complicated if you bring third party mail hygiene solutions into the mix.

Tip 3 – Active Directory attributes matter in hybrid for proper mail flow

Active Directory attributes are used to route mail in a hybrid environment. The attribute “targetAddress” is the most important for internal mail flow to work correctly. If you have mailboxes on premise and in Office 365 this is needed for your AD users who have a mailbox in Office 365.

On premise mailbox users do not have the “targetAddress” populated, however if you complete a mailbox migration to Office 365 and commit the changes, Exchange will populate this attribute in AD to ensure internal mail flow will work correctly.

One project I worked on had Office 365 before it had Active Directory. In this case you might have to do some work to manually populate the AD attributes for mail flow to work. In most scenarios AD and Exchange will be in place long before Office 365. Another important point to remember is that when you have on premise Exchange, this should be used to administer mailboxes (including creating new Office 365 mailboxes), this way all the attributes required will be populated for you.
I’ve written a dedicated blog post to cover AD attributes in Exchange Hybrid


Another useful post, how to add targetAddress and proxyAddress with Powershell to multiple objects, this could be useful if you have incorrectly created Office 365 mailboxes without using on premise Exchange in hybrid.


In addition to the above, if you incorrectly create an Office 365 mailbox you might need to run the command, before your cloud mailboxes work correctly. This command should be run from the Exchange Server.

Enable-RemoteMailbox “user” –RemoteRoutingAddress “email.address@tenant.onmicrosoft.com

This command will also ensure any cloud mailboxes which were created before the Exchange Server show up inside the on premise ECP under Recipients.

Tip 4 -  Autodiscover must point to the on premises Exchange in hybrid

Although there is conflicting documentation on this, the Exchange Deployment Assistant states that in hybrid environments the external autodiscover records must point towards the on premise Exchange Server. This will cause the Office 365 portal to show an error as it’s expecting all records to be pointing to it. After testing autodiscover will not work for on premise mailboxes if the external records point to Office 365. I generally create an internal CNAME record as well pointing to the internal Exchange Server.

Tip 5 – Network rules are important in hybrid

For hybrid to work SMTP is important. The Exchange Server must be able to communicate with Office 365 inbound and outbound on TCP 25. You can update your firewall rules to only allow the known Office 365 IP’s to be accepted for SMTP.


You can use the following command to test this from either side.
Test-NetConnection –ComputerName “fqdn” –Port 25

Thursday, 4 October 2018

Configure IP Whitelist for Network Devices to Send Mail to Exchange Server without SMTP Auth

This is very easy and is done using a new Recieve Connector. 

Login to the ECP and click Mail Flow, then Recieve Connectors. Create a new Recieve Connector.

Name the connector something descriptive. 

Select Frontend Transport and Custom.

In Network Adapter Bindings leave "All available IPv4" this is only the case if the Exchange Server has a single NIC. It's slightly different if your server has arms in two networks.

In Remote Network Settings, enter the IP's of the network appliances you want to be able to send mail without authentication.

Click Finish.

To test use the following Telnet commands (you run this from a server which is listed as allowed in the new Recieve Connector).


set localecho
OPEN mail.domain.com 25
EHLO domain.com
MAIL FROM:ise@domain.com
RCPT TO:ryan.betts@domain.com NOTIFY=success,failure
DATA
Subject: Test from Telnet

Testing
.
QUIT

If it's successful it should return a message similar to below.



If you want the server to be able to relay to external domains you must run another command as well.

Change it to reference your Exchange Server and Recieve Connector name, also remember and run it from Exchange Mgmt Shell or it will fail. 

Get-ReceiveConnector "EXSRV\REC CONN NAME" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient

Wednesday, 3 October 2018

Show "Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe." warning to users when mail originates from outside Exchange Organisation

To try and attempt to reduce phising attempts it is possible to attend a HTML warning to users when they receive emails from outside the organisation. This is overkill in many environments but some insist on it being in place. 

It's achieved using Transport Rules in Exchange Online, the code below implements a warning 

"Caution: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe."




//Create a Session to Exchange Online

Write-Host "Getting the Exchange Online cmdlets" -ForegroundColor Yellow
$Session = New-PSSession -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
    -ConfigurationName Microsoft.Exchange -Credential $credentials `
    -Authentication Basic -AllowRedirection
Import-PSSession $Session -AllowClobber

//Create a new Transport Rule

New-TransportRule -Name "External Mail Warning - Outside Organisation" -Priority 0 -FromScope "NotInOrganization" -ApplyHtmlDisclaimerFallbackAction Ignore -ApplyHtmlDisclaimerLocation "Prepend" -ApplyHtmlDisclaimerText "<div style=""background-color:#FFEB9C; width:100%; border-style: solid; border-color:#9C6500; border-width:1pt; padding:2pt; font-size:10pt; line-height:12pt; font-family:'Calibri'; color:Black; text-align: left;""><span style=""color:#9C6500; font-weight:bold;"">CAUTION:</span> This email originated from outside of the organization.  Do not click links or open attachments unless you recognize the sender and know the content is safe.</div><br>"

Tuesday, 2 October 2018

Disable Outlook Focused Inbox across the entire Office 365 tenant

Use the following command to disable the annoying "Focused Inbox" setting across your entire tenant. It is possible to disable it on a per user basis, but do the right thing and remove it for everyone!

$UserCredential = Get-Credential

Install-Module MSOnline -Force
Import-Module MSOnline

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection

Import-PSSession $Session 

Set-OrganizationConfig -FocusedInboxOn $false

Get-OrganizationConfig //Check to see FocusedInbox is set to “false”

Update all user "targetAddress" and "proxyAddress" attributes in AD using Powershell for Exchange Hybrid

AD attributes are important when you have a hybrid setup from your on premise Exchange to Office 365, the following script will help retrospectively publish the required objects to your domain users so that hybrid mail flow works correctly.

Review this article for details on AD attributes in Exchange with hybrid connectivity.

http://blog.ryanbetts.co.uk/2018/09/understanding-ad-attributes-in-exchange.html

The following command can be used to export a list of users to a CSV file, you should change the OU path to suit your own environment. Once you have a list of users copy and paste them into a blank text document.

Get-ADUser -SearchBase "OU=Standard Users,OU=User Accounts,OU=Grand Cayman,OU=Company X,DC=domain,DC=com" -prop * -Filter * | Select samaccountname | Export-CSV C:\Users\Administrator\Desktop\Users.csv

The following command will set the "targetAddress" attribute for every user listed in the text file.

The "targetAddress" is used when on premise mailboxes try to send mail to Office 365 mailboxes.

Remember to capatilise SMTP as this will ensure it's the primary email adress. 

Get-Content C:\Users\da.ryan.betts\Desktop\O365Users.txt | % { Set-AdUser $_ -add @{targetAddress="SMTP:$_@companyx.mail.onmicrosoft.com"}}

The following command will append the FQDN, your public domain should be set as the primary so ensure caps are used with SMTP.

Get-Content C:\Users\Administrator\Desktop\O365Users.txt | % { Set-AdUser $_ -add @{proxyAddresses="SMTP:$_@companyx.com"}}

A second pass of the same command will add the additional proxy address which should be tenantname.mail.onmicrosoft.com


Get-Content C:\Users\Administrator\Desktop\O365Users.txt | % { Set-AdUser $_ -add @{proxyAddresses="smtp:$_@companyx.mail.onmicrosoft.com"}}


When you sync the AD to AAD using AD Connect the x500 entry will also appear under proxyAddresses. 

Thursday, 27 September 2018

How to run the HCW to configure hybrid from Exchange Server to Exchange Online

I’ve put together a comprehensive list of my notes on how to implement an Exchange Hybrid to Office 365 with Exchange 2016. This is something I have done countless times now, but I always forget some of the finer details every time I do it, so this is for my own archive more than anything.
The setup in this example is simple, there is a single Exchange Server on premise which is used for:
  • Email administration (both on premise and Office 365)
  • Local SMTP relay for devices with no Internet route
The topology looks something like this, a single Exchange 2016 sits on premise, there is a firewall between it and the Internet. All external MX Records point to Office 365, the firewall is configured to all the Exchange Server out to the EXO IP’s on SMTP TCP 25. It also allows inbound SMTP TCP 25 which is NAT’d to the Exchange Server. In addition to this the NAT rule also include HTTPS TCP 443 from anywhere.

I’m going to assume you have the following things already configured:
  1. Install Exchange Server 2016 (latest CU)
  2. Configure Exchange Server
    1. Virtual Directories with External URL’s (e.g mail.domain.com)
  3. Configure External DNS
  4. Configure Exchange Certificates
    1. A wildcard certificate is best, but if you do not have a wildcard certificate ensure your certificate has multiple Subject Alternative Names (SAN’s) to cover things like mail.domain.com, autodiscover.domain.com to prevent any certificate warnings from Outlook.
In this post I’m going to cover the following with some lessons learned.
  1. Hybrid Configuration Wizard
  2. Verify and Test Hybrid
  3. Administering a Hybrid
Firewall Rules
Exchange Server should be presented to the Internet on TCP ports 25 and 443. The firewall rule should only accept incoming SMTP (TCP 25) from the Exchange Online IP’s. HTTPS (TCP 443) however should be open to all to ensure services such as Autodiscover work correctly. These rules should be done using NAT on your perimeter firewall.
The Exchange Server should be allowed out to the Exchange Online IP’s for SMTP (TCP 25). It’s advisable to only allow the server itself out and not the other nodes in the subnet.
MX Records
It’s possible to have your MX Records point to either Office 365 or the on premise server for a hybrid deployment. It’s my preference to always have these points to the Office 365 tenant. When your setup your custom domain for Office 365 you will be given the target address for your MX records to point.
Centralized Mail Flow
Centralized Mail Flow is when all your outbound mail is forced to go through the on premise Exchange Server. Personally I prefer all mail to be routed out via Office 365, ensure this option is not selected if you want Office 365 to route outbound mail.
Full or Minimal Hybrid
Full Hybrid gives the richest coexistence and will be required if your organization is going to retain hybrid for an extended period of time.  
Edge Transport
The Edge Transport server is an SMTP Relay which sits between your Exchange Server and the Internet, most commonly in a DMZ. You must decide if this is going to be in your topology before you run through the hybrid wizard.
AD Connect
AD Connect will be required to sync you on premise identities to Office 365. This should be configured with Password Sync and Exchange Hybrid Deployment. Please note if the Exchange Hybrid Deployment option is not selected AD Connect will not write-back the Exchange-specific attributes to AD which will cause internal mail routing issues.

If AD Connect is already in place, you must change the settings so that you can reconfigure it to use Exchange Hybrid Configuration. To do this open the AD Connect admin screen and edit the configuration, on the Optional Features you will see the option.

Login to the ECP on the Exchange Server and click the Hybrid tab, then click Configure. This will download the HCW, install and run it.



It should auto detect the Exchange Server, ensure you select the correct Office 365 (more than likely Worldwide).



You will be prompted for credentials for on premise AD and Office 365, the AAD creds must be Global Admin.



The HCW will check over each environment.



Select which features you want as part of this hybrid, Full Hybrid gives the richest integration between on premise and Office 365.



Now you need to publish a TXT record to the root of your domain so that the HCW can validate you own the domain. Create the record, wait for it to replicate and verify the record. This part of the HCW is prone to break. Top tip is to rerun the HCW if it continously fail, it will eventually pass the validation test if the record has been created correctly. 



Enable the federation trust, this will ensure free/busy information etc. can be share across the environments.



I don't have an Edge Transport server in my environment so I've chosen the CAS option. If you click Advanced you will be presented with an option to use Centralized Mail Flow, this will route all mail through your on premise Exchange, which is probabaly not wise.



The HCW will auto create Receive connector so that the Exchange Server can accept incoming mail from Office 365, choose from the drop down the server you want this to be created on.



Same goes for a Send Connector, we will examine the Send Connector further down and create another one to ensure mail flow to external recipients works correctly. 



A globally trusted certificate must be installed on the Exchange Server, the same certificate you use to secure the servers Virtual Directories can be used by the HCW. A wildcard is generally best as it can cover multiple service names behind a single domain.



You then need to input the on premise service name I tend to use mail.domain.com, this is how Exchange Online will route mail to mail-enabled objects that reside in your domain. Obviously a DNS A record must be created to direct this service name to the outside IP address of your Exchange Server. Please do some DNS testing to ensure this is working before you attempt this part.



Click Update and the HCW will run a bunch of scripts to implement the changes, based on the information you have provided to the HCW.



Understanding AD Attributes in an Exchange Hybrid

Scenrio: You have Active Directory which stores users with AD Connect doing password sync, all mailboxes with the exception of a few are in Office 365. Hybrid mail flow is required between the on premise mailboxes and Office 365. All the AD users were created using AD Users and Computers and not the Exchange Server.
Problem: If you have on premise user accounts with Office 365 mailboxes. If the user accounts have been created using Active Directory Users and Computers and not Exchange they will not have all the required attributes to route mail internally.
It's worth having an Exchange Server purely to do email administration, unless you know what AD attributes to manipulate manually.
Office 365 mailboxes should be created using the on premise Exchange Server, this will create the new AD object with the correct attitrbutes set.

When a new mailbox in Office 365 is created with an on premise user account Exchange populates the "targetAddress" attribute which is used to route mail from on premise to Office 365. Please note this attribute is not synced to AAD using AD Connect.
It's added in the format SMTP:username@domain.mail.onmicrosoft.com

It also populates the "proxyAddresses" attribute with a primary email set to the custom domain and another set to @domain.mail.onmicrosoft.com 

If you force AD Connect to sync the user will appear as unlicensed in the portal. 

Assign a license to it then force another AD sync.

If you return to the "proxyAddresses" attribute you will see another x500 field has been create. All of these attributes are required to ensure mail can be routed between on premise and Office 365.

If you have created a batch of users in the traditional way, synced them to Office 365, assigned licenses then allowed users to use the mailboxes. You will not be able to send mail from on premise mailboxes to them, this is because the "targetAddress" attribute is not populated by ADUC.

Comments system

Disqus Shortname