Postpone upgrading AAD Connect if you deployed Hybrid Azure AD join

Tuesday, October 8, 2019
Microsoft has reported an issue with Azure AD Connect 1.4.18.0 and Hybrid Azure AD joined devices. They recommend not deploying this version if you have deployed Hybrid AAD join.

1.4.18.0https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history#14180


Warning
We are investigating an incident where some customers are experiencing an issue with existing Hybrid Azure AD joined devices after upgrading to this version of Azure AD Connect. We advise customers who have deployed Hybrid Azure AD join to postpone upgrading to this version until the root cause of these issues are fully understood and mitigated. More information will be provided as soon as possible.

This version has been removed from manual download until their incident investigation is complete. The latest version available now on the website is AAD Connect 1.3.21.0.

Details of the incident are not available, but if you have deployed AADC 1.4.18.0 and are experiencing problems, I recommend completely uninstalling AAD Connect and installing version 1.3.21.0.

Read more ...

The Death of Basic Authentication in Office 365

Tuesday, September 24, 2019
Microsoft posted the article, "Improving Security - Together" where they explain that they will be turning off Basic Authentication in Exchange Online for EWS, Exchange ActiveSync (EAS), POP, IMAP and Remote PowerShell on October 13, 2020. That means that only apps that support modern authentication using OAUTH 2 will be able to connect to Exchange Online after that time. There are currently no plans to override this behavior.

I applaud this move, since it greatly improves the security posture for your tenant and Office 365 as a whole. The vast majority of bad actors use Basic authentication (username/password credentials) for their attacks. That said, there are caveats you should be aware of.

Exchange ActiveSync is probably the most heavily utilized protocol in this list. EAS has been shipping with every version of Exchange since Exchange Server 2003. Millions of users across the globe count on it to manage emails from their mobile phones and tablets. Many of these users have moved over to the Outlook mobile apps for iOS and Android, but a very significant number are still using the native email apps on their phones.

Apple started supporting modern auth in iOS 11, so any reasonably up-to-date iOS device should be unaffected by the removal of Basic auth for EAS. Android is a different story. There are so many older devices out there with different Android versions from different vendors, it's hard to say which devices will be affected. Some versions may have native support for OAUTH 2 using the AppAuth for Android library, while some mail apps in the Play Store may have built-in support in the app (Outlook for Android is one example). In the end, you really need to test your apps.

The best way to do that is to setup or reconfigure a mail account on your mobile devices. If you're prompted for modern auth to setup your account, as below, you should be good to go.

OAUTH 2 (Modern Auth) prompt

If you get a Basic authentication prompt within the app, you're app probably doesn't support OAUTH 2. Download the Outlook mobile app for iOS or Android, or another email app that supports it.

The POP and IMAP protocols are less often used, but when they are, it's typically for app integration with a line of business app. Examples include help desk ticketing systems, ERP solutions, life-cycle management systems, etc. These apps are usually critical to the business, so anything that affects email connectivity must be carefully planned. Microsoft is planning to add OAuth support to both POP and IMAP in the next few months, but the apps that use these protocols must also be updated to support it. That means software updates for these LOB apps (assuming they will support OAUTH 2), possible additional support costs, contracts, etc. Plan ahead and talk with these vendors now to see how they plan to support OAUTH 2. You may even need to go so far as to change LOB solution providers.

Read more ...

An Overview of Tenant to Tenant Migrations in Office 365

Wednesday, September 18, 2019

Recently I wrote a chapter for the eBook, "Everything you need to know about Tenant to Tenant Migrations" for Practical 365. You can download the eBook for free here.

You can read a quick teaser for that chapter here on the Practical 365 site.


Read more ...

Syncing Email Signatures Across Devices is soon to become a reality!!

Tuesday, September 10, 2019
Will wonders never cease. Just when I was convinced that Outlook UserVoice was the place where all good ideas go to die, I received the following update:

"Thank you to everyone who voted. We’re happy to report that we’re working on sync’ing signatures across devices. More details to come as we have them.

Sincerely,

Ricardo, Duncan, Sunder and David on behalf of the Outlook team"



After I posted the article, "Storing email signatures in the Exchange mailbox" on this blog, this UserVoice request became the top voted request on the Outlook UserVoice website by a wide margin, with over 7,915 votes. It has more than twice the number of votes than the #2 most voted item. Thank you to all of you who voted!

This new feature will undoubtedly come to Office 365 ProPlus customers first, so if you're hot on seeing it, make sure you're using the latest and greatest version of Outlook. I'll let you know when the new feature lands.

Read more ...

Video Tutorial on Hybrid Azure AD Join

Thursday, August 22, 2019

Microsoft produced this short (7:21) video which shows how to configure Hybrid Azure Active Directory Join in your on-premises environment. Hybrid AAD join is an important step in using Intune to manage your corporate devices and information. With device management in Azure Active Directory (Azure AD), you can ensure that users are accessing your resources from devices that meet your standards for security and compliance.

This video will be included in future hybrid AAD join documentation to be published in the next few days and weeks. You can view it at https://www.microsoft.com/en-us/videoplayer/embed/RE3C9hO.

Read more ...

Managing SSL certificates may be getting that much more difficult

Wednesday, August 14, 2019
Remember when you used to be able to get an SSL certificate that lasted 3-5 years? Now you can only get one that lasts 2 years, and a change proposed by Google would reduce the maximum validity period to just 13 months beginning March 2020. This would be a global change to the industry, impacting all certificate authorities.

Read this important update from Digicert:


IMPORTANT UPDATE
Dear Security Professional,

We are reaching out to you regarding an important proposal raised recently at the CA/Browser Forum that could impact the products you are using.

What’s happening?
Google proposed a change that, if the ballot passes, will reduce the validity period of certificates from the current maximum of two years to 13 months. The proposed ballot was endorsed by Apple and another CA, making the ballot eligible for voting. If the ballot passes at the CA/Browser Forum, the change in requirements will go into effect in March 2020. Any certificates issued after the effective date would need to comply with the shortened validity period requirements. Even if the ballot fails, the browsers sponsoring the ballot could unilaterally implement this requirement in their root program and make compliance required for certificates issued by trusted CAs in their root stores.

This change is a follow up on Google’s previous initiative to reduce lifetimes from three to two years https://www.digicert.com/blog/3-year-certificates-eliminated-industry-wide-change/) in 2018.

Who is impacted?
The changes proposed by Google would impact all publicly trusted TLS certificate users, regardless of which certificate authority issues the certificate. If the ballot passes, all publicly trusted certificates issued or re-issued after March 2020 would have a maximum validity of 13 months. Customers using certificates with validity periods longer than 13 months are encouraged to review their systems and evaluate how the proposed changes might impact their deployment and use of certificates.

Please note that all TLS certificates issued prior to March 2020 with a validity period longer than 13 months will remain functional. This ballot does not affect non-TLS certificates, including code signing, private TLS, client certificates, etc. There will be no need to revoke any certificates as a result of this ballot.

This would be a global change to the industry, impacting all certificate authorities.

DigiCert’s position
DigiCert believes industry-wide changes should be made only after measuring whether the changes in security are sufficiently balanced with the impact on end users. In this case, we feel that further shortening certificate lifetimes, especially absent reasonable timelines for companies to prepare, would have the opposite effect in causing significant pain to customers and possibly leading to some human-caused errors as they scramble to adjust.

We believe the goal of improving certificate security is better served by allowing more time for companies to continue their growing use of automation and to prepare for these changes. DigiCert would like to continue the conversation and gather customer input before this issue is brought to a ballot. We think this discussion should include a timeline that allows for companies to properly plan for shorter lifetimes.

Regardless of the outcome of this ballot, we stand ready to help our customers. DigiCert’s focus and deployment of discovery and automation tools make sure our systems are fully capable of helping our customers meet changes that may arise in industry standards, including shortening lifecycles. In fact, DigiCert currently offers certificate lifetimes as short as eight hours for customers who want that option. Having said that, our ability to help our customers with these changes doesn’t mitigate all the potential impact that a rushed implementation would have on the industry.

What to do
The CA/Browser Forum makes changes to standards as security issues evolve. To remain compliant with these changes, organizations with large amounts of certificates should consider sophisticated automation tools to help manage certificate inventories and ease certificate deployment. At DigiCert, we are focused on simplifying the certificate management process and developing new tools for automating certificate use. Customers worldwide use DigiCert to automate their process using our Lemur plug-ins, REST APIs, SCEP and EST services, and ACME service. Combining ACME with the automated scanning service in CertCentral allows TLS customers to easily scan their entire environment, find certificates that require replacement, and deploy up-to-date technology.

DigiCert will continue to keep you apprised of CA/B Forum activities. Please read our position to the industry in this new blog: https://www.digicert.com/blog/how-reduced-tls-ssl-certificate-lifetimes-to-one-year-would-affect-you/

Be heard
The CA/Browser Forum accepts comments from outside participants; however, all discussions are public. You have two choices: you can submit your comments to DigiCert through this survey, which we plan to summarize and provide to the CA/B Forum or you can join the CA/B Forum as an Interested Party, which will allow posting of your comments directly to the Forum mailing list. See https://cabforum.org/working-groups/ (bottom of page).

We are eager to share information with the browsers about the impact these changes may have on customers. We look forward to providing this information and representing your interests in the Forum and security world.

Read more ...

How to Create a Hub Transport Rule Based on Any Attachment

Tuesday, August 13, 2019
Transport rules are cool. Except when they don't work the way you expect.

I wanted to create a transport rule that blocks outgoing email to external recipients that contains an attachment, except for members of the "Allow Outbound Attachments" group. So, I created the following rule:


The trouble is, that it blocks any email that is not sent as plain-text, even though there is no attachment. Not good.

I examined the headers on emails with and without attachments and found the X-MS-Has-Attach X-header has a yes value when there's an attachment and is <blank> when there isn't.
...Message-ID: <BL0PR01MB4243EF8B4D8DD1624C9C6E77D4D20@BL9PR01MB4243.prod.exchangelabs.com>References: <1db58e8b507e4f7f81a892f1bb48654e@ex.contoso.com>In-Reply-To: <1db58e8b507e4f7f81a892f1bb48654e@ex.contoso.com>Accept-Language: en-USContent-Language: en-USX-MS-Has-Attach: yesX-MS-TNEF-Correlator:Authentication-Results-Original: spf=none (sender IP is )...
I modified the rule as below and it now works perfectly.


It's worth noting that the header values are not cAsE sensitive.

Read more ...