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.
Friday, 16 November 2018
Thursday, 15 November 2018
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
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.com” to 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 “firstname.lastname@example.org”
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