Blog

Sep 02
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: https://blogs.technet.microsoft.com/enterprisemobility/2017/08/31/changes-to-the-token-lifetime-defaults-in-azure-ad/

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"

Dec 23
Keep a copy of sent emails for delegates of user mailboxes!

The ability to send messages on behalf of somebody else has been around for a long time, but it has it quirks. One of the major issues with it was the fact that any messages send on behalf of say a shared mailbox weren't copied to the mailbox, thus other people working with it were unaware of the action. Over the course of the last few years and Exchange versions, Microsoft offered us different workarounds for this issue, the latest one being the use of the MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled parameters. For a brief overview on the different methods and details on said parameters you can refer to the EHLO blog post here: https://blogs.technet.microsoft.com/exchange/2015/03/03/want-more-control-over-sent-items-when-using-shared-mailboxes/

As you can see from the article above, while the new method proved very useful and easy to control, it was only available for shared mailboxes. If you tried to configure the setting for any user mailbox, you were greeted by the following error message:

PS C:\> Set-Mailbox huku -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

MessageCopyForSentAsEnabled can only be set on shared mailboxes

+ CategoryInfo : NotSpecified: (huku:MailboxIdParameter) [Set-Mailbox], TaskArgumentException

+ FullyQualifiedErrorId : [Server=HE1PR03MB1340,RequestId=e7ba59bb-a4a4-4de8-b751-1904ac73185c,TimeStamp=11/11/2015 8:34:59 PM] [FailureCategory=Cmdlet-TaskArgumentException] 36931497,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

This in turn meant that we still had to address issues with delegates for user mailboxes, say a secretary sending mail on behalf of a VP. Well, no more! The parameters can now be used for both shared and user mailboxes. For example, to turn this on for a single user mailbox you can use:

Set-Mailbox HuKu -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

To turn the settings on for all user mailboxes, use:

Get-Mailbox -RecipientTypeDetails UserMailbox | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

To turn the settings on for all user and shared mailboxes:

Get-Mailbox -RecipientTypeDetails UserMailbox,SharedMailbox | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

If you try to turn it on for any other type of mailbox, you will still run into the familiar error message:

MessageCopyForSentAsEnabled can only be set on shared mailboxes or user mailboxes.

+ CategoryInfo : NotSpecified: (WC:MailboxIdParameter) [Set-Mailbox], TaskArgumentException

+ FullyQualifiedErrorId : [Server=DB6PR0302MB2614,RequestId=602ce875-59c1-4353-8fd5-d37bc8565572,TimeStamp=12/23/2016 8:36:24 AM] [FailureCategory=Cmdlet-TaskArgumentException] 10E0541D,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

One last remark: at the time of this writing, the functionality is not yet rolled out fully, so while you can configure the settings, the actual copies of the send message don't get copied to the mailbox. Which I guess is why Microsoft hasn't yet announced this officially :)

Dec 23
Keep a copy of sent emails for delegates of user mailboxes!

The ability to send messages on behalf of somebody else has been around for a long time, but it has it quirks. One of the major issues with it was the fact that any messages send on behalf of say a shared mailbox weren't copied to the mailbox, thus other people working with it were unaware of the action. Over the course of the last few years and Exchange versions, Microsoft offered us different workarounds for this issue, the latest one being the use of the MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled parameters. For a brief overview on the different methods and details on said parameters you can refer to the EHLO blog post here: https://blogs.technet.microsoft.com/exchange/2015/03/03/want-more-control-over-sent-items-when-using-shared-mailboxes/

As you can see from the article above, while the new method proved very useful and easy to control, it was only available for shared mailboxes. If you tried to configure the setting for any user mailbox, you were greeted by the following error message:

PS C:\> Set-Mailbox huku -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

MessageCopyForSentAsEnabled can only be set on shared mailboxes

+ CategoryInfo : NotSpecified: (huku:MailboxIdParameter) [Set-Mailbox], TaskArgumentException

+ FullyQualifiedErrorId : [Server=HE1PR03MB1340,RequestId=e7ba59bb-a4a4-4de8-b751-1904ac73185c,TimeStamp=11/11/2015 8:34:59 PM] [FailureCategory=Cmdlet-TaskArgumentException] 36931497,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

This in turn meant that we still had to address issues with delegates for user mailboxes, say a secretary sending mail on behalf of a VP. Well, no more! The parameters can now be used for both shared and user mailboxes. For example, to turn this on for a single user mailbox you can use:

Set-Mailbox HuKu -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

To turn the settings on for all user mailboxes, use:

Get-Mailbox -RecipientTypeDetails UserMailbox | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

To turn the settings on for all user and shared mailboxes:

Get-Mailbox -RecipientTypeDetails UserMailbox,SharedMailbox | Set-Mailbox -MessageCopyForSendOnBehalfEnabled $true -MessageCopyForSentAsEnabled $true

If you try to turn it on for any other type of mailbox, you will still run into the familiar error message:

MessageCopyForSentAsEnabled can only be set on shared mailboxes or user mailboxes.

+ CategoryInfo : NotSpecified: (WC:MailboxIdParameter) [Set-Mailbox], TaskArgumentException

+ FullyQualifiedErrorId : [Server=DB6PR0302MB2614,RequestId=602ce875-59c1-4353-8fd5-d37bc8565572,TimeStamp=12/23/2016 8:36:24 AM] [FailureCategory=Cmdlet-TaskArgumentException] 10E0541D,Microsoft.Exchange.Management.RecipientTasks.SetMailbox

One last remark: at the time of this writing, the functionality is not yet rolled out fully, so while you can configure the settings, the actual copies of the send message don't get copied to the mailbox. Which I guess is why Microsoft hasn't yet announced this officially :)

Dec 15
New Calendar sharing experience in Office 365

Without any big announcements, Microsoft has started rolling out the new Calendar sharing experience we first saw earlier this year at Ignite. The improvements are long overdue for sure, as the process of sharing your Calendar or getting access to other people's availability data has been confusing and unreliable for many users. On top of this, we also face issues with the limited availability of sharing functionality on mobile devices.

There are few major sets of improvements coming. First, we will get a simpler, streamlined UI experience for both sharing and accepting invitations. The new experience is already available in OWA for First Release tenants, so you might want to give it a go. Outlook for desktop and mobiles will follow suit in the coming weeks. Next, reliability and speed improvements are coming thanks to the use of modern protocols and APIs. Instead of the old "linked" Calendar model, now a local copy of the shared Calendar will be created and the service will take care of updating it with both yours and the owner's changes. Yes, this means mobile clients will also display shared Calendars! Lastly, a set of new features is coming, such as reminders for events in shared calendars or notifications for changed items! You will also be able to configure or check for Delegate permissions, that pesky "delegate can see my Private items" setting and the equally troublesome meeting delivery options:

At this time, only a subset of the above is rolled out to the service, and most of it requires you to use OWA. Which I guess is the reason why Microsoft has chosen to keep this quiet. Rest assured though, the new experience is coming to all Outlook modalities soon! For timeframes and additional details on the new experience (including some other great features not directly related to Calendar sharing), make sure to watch the video recording from Ignite: 

 

 

Dec 05
Immediately revoke access to Office 365 applications

Being able to immediately revoke user's access to applications is one of the most requested security related features for Office 365. Because of the different caching mechanisms employed in the service and/or the apps you use, accomplishing this can be a tricky task. As an example, you can refer to this article detailing the different factors that affect this in Exchange (Online). Modern authentication made things even messier, with the very long validity of the refresh tokens and the lack of proper methods to revoke them.

Almost a year ago, the SharePoint Online team gave us the opportunity to revoke access via the Revoke-SPOUserSession cmdlet. I blogged about this here. Now, at long last, we finally have global control over this via the AzureAD PowerShell module and Revoke-AzureADUserAllRefreshToken cmdlet. Here are few examples on how to use the cmdlet:

  • The only parameter the cmdlet accepts is -ObjectId, which isn't really convenient (if only the folks at Microsoft listened to feedback):


    C:\> Revoke-AzureADUserAllRefreshToken -ObjectId 582b2b38-888c-4b85-8471-c9716cb4791b

    No output will be returned unless an error occurs.

  • An easier way is to get the objectId via the Get-AzureADUser cmdlet and pipe it to Revoke-AzureADUserAllRefreshToken:


    C:\> Get-AzureADUser -SearchString huku | Revoke-AzureADUserAllRefreshToken

  • Similarly, you can do something like this:


    C:\> Revoke-AzureADUserAllRefreshToken -ObjectId (Get-AzureADUser -SearchString huku).objectId

  • Our you can get more creative like for example revoking access for all members of a particular group:


    C:\> Get-AzureADGroup -SearchString CloudSecGrp | Get-AzureADGroupMember | Revoke-AzureADUserAllRefreshToken

Another similar cmdlet exists, namely Revoke-AzureADSignedInUserAllRefreshToken. It's used to revoke tokens for the currently signed in user, i.e. the one issuing the cmdlet. It doesn't accept any parameters and can be used to for testing/development purposes.

Lastly, a word of caution. Although the cmdlet does revoke the refresh token, the access token remains valid and the user will be able to continue to access data until the browser is closed (or the app restarted). In other words, the user is not immediately forced to reauthenticate, but with the refresh token purged he will have to do so as soon as the access token has expired (max 1 hour). Or the app/browser is closed.

1 - 5Next