Report on users connecting via RPC/HTTP in Office 365

By now, you should be well aware that Microsoft is planning to remove support for the RPC/HTTP protocol in Exchange Online, starting Oct 31, 2017. In case you’ve missed the announcement, multiple blog posts and the support article, you can find a nice summary for example here.

With less than two months remaining, most organizations have already moved away from older Outlook versions. If you are one of those that are yet to tackle the issue, there is some good news – Microsoft has released a report that should help you identify the users that are connecting to Exchange Online via RPC/HTTP. The report can be found under the Office 365 Admin Center -> Reports -> Usage -> Email app usage, or by clicking here.

Clicking the “Export RPC users” button will initiate a download of the CSV file, containing the needed information. Unfortunately, in my case there aren’t any details to show, as the tests I performed with older Outlook clients are yet to be reflected in the report (you can as well expect delays of few days, but after all it’s the historic data we’re most interested in). Rest assured though, the report works OK, as showcased by some good folks at Microsoft. Unfortunately, there seems to be no way to export this report via PowerShell or access it by any API.

There you have it! This has been a much requested functionality, as previously the only way to gather information about RPC/HTTP usage was indirect – one had to enable mailbox auditing and crawl the entries to gather the client version. Connecting with specific Outlook version itself doesn’t necessarily indicate that the user will be affected, but at least gives you a clue on which users to focus.

Posted in Exchange Online, Office 365 | Leave a comment

Security and Compliance Center PowerShell finally supports Modern authentication

Modern authentication, ADAL or MFA are all different things, but often used to designate the same scenario – using additional authentication factor when logging in to Office 365. Generally speaking, the added security is a great thing, especially important for any privileged accounts. The different teams at Microsoft however have been very slow to adopt this new trend, and Office 365 administrators had to make compromises with security, simply because some of the modalities did not support Modern authentication.

Well, slowly but surely the different PowerShell modules have been updated and now we finally have MFA support for the Security and Compliance Center (aka Protection Center) PowerShell cmdlets as well. It is delivered as part of the new, MFA-enabled Exchange Online PowerShell module, which I blogged about almost an year ago. Those of you that have used the ExO PowerShell module know that it’s delivered as click-once application, which updates automatically, and might have noticed that the latest version introduced a new cmdlet, namely Connect-IPPSSession.

The cmdlet is a simple wrapper function that gets an authentication token from Azure AD and passes it to the New-PSSession cmdlet in order to create a new remote PowerShell session to the Security and Compliance Center endpoint, Which means, you can simply do the steps yourself, following the approach I outlined here.

Or, simply use the shortcut you get on your desktop after installing the tool. You can download it from the Exchange Admin Center, Hybrid tab, or directly via Here’s how a connected session will look like:

So there you have it, the SCC PowerShell module is the last to get support for Modern authentication, which in turn means there are no reasons left to not protect all your administrative accounts with Azure MFA or any other form of multi-factor auth!

Posted in Uncategorized | Leave a comment

New Azure AD token defaults (and reminder of about token lifetime importance)

Few days ago, the Azure AD team announced that they are changing the default values for some of the parameters controlling token lifetimes. In a nutshell, any newly created tenants will have refresh token inactivity period of 90 days and unlimited max age for any refresh tokens. You can find the full article here.

Now, generally speaking, this is a good thing. Having seamless sign-on experience is what the users expect, and the fewer authentication prompts they get the better. However, in some cases, such as when a user leaves the company, this might have some unwanted consequences. It’s not that uncommon to see complaints and queries from Office 365 administrators about people still being able to access resources or sent mail after they account being disabled. The causes for such behavior are multi-layered, and not specific to Azure AD or the cloud. Experienced admins are already aware that there is a lot of caching going on front- and back-end servers. Replication can be a factor too, as changes might take some time to propagate through the whole environment. And in the case of Modern authentication, the access and refresh token model also has some implications.

First of all, if the user has a valid access token, he will continue to be able to access the service for up to an hour. Yes, we can now customize the access token values as well, so we do have options (read here). The default setting of 1h for the validity of Access tokens means that if you want to immediately revoke access, you have to perform additional operations, such as disabling mailbox protocols for the case of Exchange (read here). The newly introduced defaults change nothing in this regard!

Next, it’s worth mentioning that the new defaults are not paired with any new token revocation triggers. To remind you, those include:

  • Manual revocation via the Revoke-AzureADUserAllRefreshToken cmdlet (requires the AzureAD PowerShell module) or by setting the StsRefreshTokensValidFrom parameter value via Set-MsolUser
  • Conditional access policies
  • Password changes or password expiration
  • For any synchronized users, the LastPasswordChangeTimestamp attribute. If this attribute is not being synced, a shorter value for the refresh token lifetime is configured (read the note here)
  • Some additional triggers for federated accounts (changes in account state, changes in device state)

As the changes affect only newly created tenants, they should not impact any organization that is already using Office 365 or any organization that has configured custom token lifetimes. And, one can always use the AzureAD PowerShell module to change those settings. For example, this is how to configure a policy with the “older” defaults:

New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxInactiveTime":"14.00:00:00″,"MaxAgeSingleFactor":"90.00:00:00″,"MaxAgeMultiFactor":"90.00:00:00″,"MaxAgeSessionSingleFactor":"until-revoked","MaxAgeSessionMultiFactor":"until-revoked"}}') -DisplayName "OrganizationDefaultPolicyScenario" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"

Posted in Uncategorized | Leave a comment

Limiting eDiscovery results to specific folders only

In this month’s article for ENow’s Solutions Engine Blog, I’m doing a quick review of the recently introduced “targeted collection” feature in Office 365, one that allows you to limit the results when performing an eDiscovery or Content Search to specific folders only.

This has been one of the most common asks for years, especially in the Exchange world where administrators are used to the convenience of the Search-Mailbox cmdlets to perform search and destroy operations against malware or simply need to copy some messages. Unfortunately, the new keywords that make this feature possible are not supported by the Search-Mailbox cmdlets, so the only way to use it is to head to the Security and Compliance Center.

To learn more about the feature, consult the documentation or head to the full article here:

Posted in Office 365 | Leave a comment

Clearing AIP client and PowerShell module token cache

The question on how to “log out” of the Azure Information Protection client or the corresponding Office add-in is one that seems to pop up often. The AIP team has actually published information on how to achieve this task in the following article. In a nutshell, in order to reset authentincation you have to delete the TokenCache value under HKEY_CURRENT_USER\SOFTWARE\Microsoft\MSIP or delete the TokenCache file under %localappdata%\Microsoft\MSIP.

In addition, the team has also started gathering feedback on the importance of support for multiple accounts, much like we’ve had for a while now with “pure” RMS in Office. Make sure to vote for the corresponding item on UserVoice and also leave your feedback there!

Now, the above doesn’t cover the AzureInformationProtection PowerShell module, which is another very useful tool. While the module allows for non-interactive mode, by using service principal credentials to execute any operations, it also can be used interactively. Once you provide credentials however, there is no way to actually log out or change the logged in user, and it will persist even across restarts, until the token has expired.

So, in case you want to log out of the module or change the logged in user, you have to again resort to manual actions. The steps are actually similar to the ones above regarding the AIP client, however both the registry key and the file are in different location. Anyway, without further ado, to remove the token and force the module to ask for credentials:

  • Start regedit
  • Navigate to the following key: HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\MSIPC\pscmdlet
  • Locate the subkey corresponding to the currently used tenant (either compare the GUID or simply expand the subkeys to check the corresponding user Identity)
  • Once you’ve located the relevant key, delete it
  • Also delete the file storing the token from %LocalAppData%\Microsoft\MSIPC\pscmdlet\Auth (should not be necessary, but just in case)
  • Run any AIP related cmdlet, such as Get-RMSTemplate, and provide the new set of credentials.

The above steps are not really supported by Microsoft, so use at your own risk!


Posted in Office 365, PowerShell | Leave a comment