Multi-Factor Authentication in Office 365 (Part 2)

Posted on July 9, 2014 by Michel de Rooij

Multifactor Authentication is a must-have for services based in the cloud, especially for accounts with administrative purposes. We have already covered what Office 365 Multifactor Authentication is and how to configure it in Office 365 tenants with the Office 365 admin center, and we briefly showed the end user experience. Now we will look at how we can use the Azure Active Directory Module for Windows PowerShell to configure Office 365 authentication with MFA.

Azure Active Directory Module for Windows PowerShell (AADMPS) enables organizations to not only configure MFA for existing end users who use PowerShell, but also enhance their current provisioning process with MFA options. By pre-configuring MFA, administrators can prevent end users from having to go through the initial MFA setup process and use their currently configured mobile phone or office number for verification.

Read the full article over on SearchExchange

Multi-Factor Authentication in Office 365 (Part 1)

Posted on June 17, 2014 by Michel de Rooij

Multi-Factor Authentication identifies an end user with more than one factor. Authentication is based on something you know, such as your password; something you have, such as a security token or smart card; or something that’s a physical characteristic of who you are, such as biometrics. By creating an additional factor on top of the password, identity is better protected. Multi-Factor Authentication is seen as a must-have for cloud-based services, especially for administrative types of accounts.

In this first tip on SearchExchange, I explain how you can configure Multi-Factor Authentication in Office 365, discuss the so-called contact methods, explain app passwords for non-MFA applications as well as show the MFA end user experience.

Read the full article over on SearchExchange

Sent Items Management

Posted on February 13, 2013 by Michel de Rooij

With the release of Exchange 2010 SP3, you can now control where sent items are stored when Send-As or Send-on-Behalf permissions are configured and you’re using Outlook Web Access. In Outlook we already had the possibility to control where sent items are stored this using registry keys, but now we can do so from Outlook Web Access or using the Exchange Management Shell. Unlike Outlook, you unfortunately can’t control where deleted items are stored.

As a quick reminder, to configure permissions for user Francis to send e-mail messages as Philip or on behalf of Philip, you would use:

Add-ADPermission Philip -User Francis -Extendedrights "Send As"
Set-Mailbox Philip -GrantSendOnBehalfTo Francis

Sent Items Management from Outlook Web Access
To access the Sent Items Management option, use OWA to open the (shared) mailbox and navigate to Settings > Sent Items

You can configure the following options for Send-As or Send-on-Behalf e-mail:

From mailbox: The sent item will be stored in the Sent Items folder of the (shared) mailbox;
Sender and From mailboxes: The sent item will be stored in the Sent Items folder of the (shared) mailbox and actual sender;
Sender mailbox: The sent item will be stored in the Sent Items folder of the actual sender (default).

Sent Items Management using EMS
To inspect where sent items are stored, use Get-MailboxSentItemsConfiguration, e.g.

Get-MailboxSentItemsConfiguration Philip

To configure the settings, use Set-MailboxSentItemsConfiguration in conjunction with SendAsItemsCopiedTo or SendOnBehalfOfItemsCopiedTo specifying Sender, From or SenderAndFrom. For example, to configure the items sent as Philip to be stored in the mailbox of both Philip and the actual sender, use the following cmdlet:

Set-MailboxSentItemsConfiguration Philip –SenderAndFrom

It would be nice if Outlook would honor these settings, just like the signatures, so you configure this centrally and have consistent behavior regardless of the client setting. It shouldn’t be difficult, using Exchange Web Services as a vehicle to store and retrieve this information.

MsExchQueryBaseDN and Exchange 2010 SP1

Posted on April 5, 2011 by Michel de Rooij

Note: At TechEd NA 2011 session EXL326, announcing Exchange 2010 SP2 features (e.g. GAL segmentation), Greg Taylor stated that SP1 breaks MsExchQueryBaseDN in Exchange 2010. This might explain the behaviour as described in this article.

As you may know, the msExchQueryBaseDN attribute can be used to limit a user’s scope of the global address book and address searches (also see kb817218). This is helpful for restricting access in environments consisting of multiple organizations or organizations with a substantial number of mail-enabled objects. The attribute is part of the user object and you configure it by pointing it to a DN of the OU or address list of choice, e.g. OU=sales,DC=company,DC=com. Note that by default msExchQueryBaseDN is empty, so that user will search the whole domain the user’s part of.

With Exchange 2010 SP1, the following unexpected behavior is encountered in Outlook when you’ve set the msExchQueryBaseDN attribute:

msExchQueryBaseDN Set
When msExchQueryBaseDN is set to a valid DN, Outlook WebApp (OWA) will show the default global address with elements from the configured msExchQueryBaseDN downwards. Outlook 2007/2010 will show an empty global address list; other global address lists are invisible. Searching the address book in OWA works, in Outlook it doesn’t because Outlook thinks the address list is empty:

Note that if the structure contains many elements, opening the global address list in OWA may result in the following exception:

Url: https://…/owa/forms/premium/SubPageContainer.aspx?ae=AddressList&t=Recipients&subpage=DirectoryView.ascx
User host address: …
User: Blake, Francis
EX Address: /o=…
SMTP Address: francis@eightwone.com
OWA version: 14.1.270.1
Mailbox server: ex2010a.domain.local
Exception
Exception type: Microsoft.Exchange.Data.Directory.ADVlvSizeLimitExceededException
Exception message: Active Directory operation failed on ex2010a.domain.local. There are too many entries which exceed limit of Virtual List View. Additional information: The directory service encountered an unknown failure. Active directory response: 000020EF: SvcErr: DSID-03140350, problem 5010 (UNAVAIL_EXTENSION), data 0

The message indicates it tries to fit too many elements in the list.

MsExchQueryBaseDN cleared
When msExchQueryBaseDN is cleared, Outlook and OWA will show the default global address list as well as other address lists. Also, even though the number of elements is equal or larger than when msExchQueryBaseDN is set, the global address list will show in OWA. So, apparently the number of elements isn’t an issue, which makes the exception you get in OWA when msExchQueryBaseDN is set confusing.

After some digging, I think this behavior is related to dropping address list segregation support for on-premises Exchange 2010 and moving several functions and support for it to Exchange 2010 hosting mode. A possible clue can be found in the Exchange 2010 mailbox attribute QueryBaseDNRestrictionEnabled, which description reads:

The QueryBaseDNRestrictionEnabled parameter specifies whether to restrict a user’s ability to view or search for other mailboxes in their organization. If this parameter is set to $true, the global address list (GAL) of the specified mailbox user isn’t populated. Specifically, if the user views the GAL, it will appear empty. If this parameter is set to $false, users can use the GAL to view all mailboxes in their organization, including mailboxes for which this parameter is set to $true. The default value is $false.

This empty GAL behavior when QueryBaseDNRestrictionEnabled is set to $true matches the behavior encountered when setting the msExchQueryBaseDN attribute.

So be advised that while we wait for Service Pack 2, of which the Exchange Team said it will contain some form of (still undisclosed) address list segregation (announcement here),you will run into the issues described above when using msExchQueryBaseDN in an Exchange 2010 SP1 environment.

To bulk clear the msExchQueryBaseDN attribute for a whole domain, execute the following command from the Exchange Management Shell:

Get-Mailbox –ResultSize Unlimited | ForEach {$o=[ADSI](“LDAP://”+$_.distinguishedName);$o.PutEx(1,”msExchQueryBaseDN”,0);$o.SetInfo()}

Updated: Added SP2 announcement mentioning to broken MsExchQueryBaseDN (May 18th).

Disabling editing account information in OWA

Posted on March 31, 2011 by Michel de Rooij

In Exchange 2010, by default users have permission to edit their contact information from the Exchange Control Panel. In organizations where this is unwanted, like when account information is provisioned, you need to remove these permissions.

These permissions flow from the Default Role Assignment Policy.

Note: You could have changed the default role assignment. To view the default assignment policy, check the IsDefault attribute, e.g.

Get-RoleAssignmentPolicy | Where { $_.IsDefault -eq $True }

Now, each mailbox-enabled user is assigned the default policy when created. You can verify this by inspecting the RoleAssignmentPolicy using Get-Mailbox, e.g.

The assigned roles of this policy can be viewed using Get-ManagementRoleAssignment:

The ability to edit contact information lies in the MyContactInformation. You can view a description of this role using:

Get-ManagementRole MyContactInformation | select Description

The output reads, “This role enables individual users to modify their contact information, including address and phone numbers.”

To remove this ability you have the option of removing the assignment or you can simply disable the assignment using Set-ManagementRoleAssignment, e.g.

Set-ManagementRoleAssignment -Identity "MyContactInformation-Default Role Assignment Policy" -Enabled $false

Now after logging into OWA the contact information is view-only (despite the Edit button) and the Save option is gone.

Note that after performing this step, if you want to enable contact information for some users, you need to create a new RoleAssignmentPolicy, similar to the default one but with the MyContactInformation and assign that policy to those users. For example:

New-RoleAssignmentPolicy "Default Role Assignment Policy with Info"
Get-ManagementRoleAssignment -RoleAssignee "Default Role Assignment Policy" | New-ManagementRoleAssignment -Policy "Default Role Assignment Policy with Info"

You can use the same exercise to remove other unwanted functions, like the ability to create distribution groups (MyDistributionGroups) or to manage distribution group memberships (MyDistributionGroupMembership).