I recently assisted a client of ours with implementing Identity Federation (single SignOn) with ADFS. This client was an original BPOS customer that was transitioned to Office 365. The client originally migrated to BPOS from on-premises Exchange 2003. Once we implemented Identity Federation all of the accounts became Federated users and now making any changes to email aliases. This has not been an issue for any of my previous Office 365 deployment as I have always setup the migration in a Hybrid Deployment with an Exchange 2010 SP2 server on-premises. With the Hybrid server, and configuring DirSync with the Hybrid Config checkmark, the email addresses for the users are replicated back to on-prem and can be modified with the EMC or directly via the ProxyAddresses attribute using ADSIEDIT or Attribute Editor in AD Users and Computers (assuming 2008 R2 DCs).

So for this client, when we installed and configured DirSync, the Hybrid Deployment checkmark was greyed out and unavailable. At the time I figured this was just because the Forest/Domain was not prepped for Exchange 2010 SP2, and really didn’t think much of it. Well that situation didn’t take long for that greyed out option to bite us. We wanted to switch around some email addresses and first attempted via the Exchange Online Management Portal and we get an error that cannot modify Federated user properties and the changes must be made on the on-premises Active Directory user account. Well that is pretty hard seeing how none of the email addresses are able to be sync down to the AD user account.

PowerShell to the Rescue! I needed to get the EmailAddresses from the Online account replicated to the AD Account ProxyAddresses. So what I did was create a PowerShell script that does this for me.

I designed the script to run from a Server 2008 R2 domain controller. The script starts out by importing the Active Directory cmdlets. It then creates a remote PowerShell session to Exchange Online. I then have it get all of the mailboxes in Exchange Online into the variable $Mailboxes. I then loop thru each Mailbox and connect to the online mailbox using the user UPN. The script then gets the EmailAddresses from the online mailbox and sets them into the $OnlineAd variable. The script then cycles through all the email addresses and adds them to the on-prem AD account ProxyAddresses attribute.

The script is below:

import-module activedirectory

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection

Import-PSSession $Session

$mailboxes = get-mailbox –ResultSize Unlimited

foreach ($MB in $Mailboxes)

                {

                $UPN = $mb.UserPrincipalName

                $OnlineUser = Get-mailbox $mb.UserPrincipalName

                $OnlineAdd = $onlineUser.EmailAddresses

                foreach ($add in $OnlineAdd)

                                {

                                get-aduser -filter {UserPrincipalName -eq $UPN}|set-aduser -add @{proxyaddresses = $add}

                                }

                }

So now my client can administer the email addresses for the Federated users by changing the ProxyAddresses attribute for the AD account. I warned them only to change the Addresses the are have “SMTP”, the primary or reply to address, or “smtp”, the alias addresses; and ensure they do not make any changes to any other type. I think I smell an app I could write to make the changing of only the smtp addresses via a GUI PowerShell interface.

So I blogged a little while ago about an issue with enabling Online Archive for a Migrated user in Office 365 Hybrid Deployment So I came up with a work around to fix this:

This has worked well for me and I have not run into any issues with manually setting the MSExchangeVersion Attribute.

I am running into a problem trying to enable Online Archive for a migrated mailbox and getting this error:

[PS] C:\Windows\system32>Enable-RemoteMailbox smcneill -Archive

property ArchiveGuid can’t be set on this object because it requires the object to have version 0.10 (14.0.100.0) or later. The object’s current version is 0.1 (8.0.535.0).

+ CategoryInfo : NotSpecified: (0:Int32) [Enable-RemoteMailbox], InvalidObjectOperationException + FullyQualifiedErrorId : 55181214,Microsoft.Exchange.Management.RecipientTasks.EnableRemoteMailbox

The environment I am working in is a Exchange 2007 on-premises with a Exchange 2010 SP2 (RU1) Hybrid server. The mailbox move to O365 works fine and so does ADFS SSO. Researching this seems that the only fix is to disable and then re-enable the remotemailbox, but this wipes the exchange info requiring the remote email address (and probably the LegacyDN) to be reset. This to me is not the best option.

When I look on the Mailbox online it has the proper version, so this appears to be a problem with the Migration process or DirSync not writing back the correct version to the RemoteMailbox object.

Any other thoughts on this?

Note: This post looks at the planning phase for ADFS 2.0 on Office 365 Beta for Enterprises. Configuring is covered in a separate post.

Office 365 supports identity federation which allows true single sign-on capabilities. This is achieved through Active Directory Federation Services (ADFS) 2.0. With identity federation, users can enter their Active Directory credentials to access Office 365 services.

An ADFS 2.0 solution consists of the following components:

• ADFS server(s) (internal network joined to AD forest)
• ADFS Proxy Server(s) (perimeter network used to support remote users)

There are three basic ADFS 2.0 deployment options for Office 365 with differing levels of access and availability:

1. Single server configuration
2. ADFS 2.0 server farm and load-balancer
3. ADFS 2.0 Proxy server(s) for offsite users

Benefits of implementing ADFS:

• Improves user productivity by enabling true single sign-on to domain joined computers
• Reduces usability issues by allowing users to use AD credentials to access all Office 365 services and not have to remember two identities and two passwords
• Allows administrators the ability to enforce the organization’s password policies and account restrictions in both the on-premises and cloud-based organizations
• Increases security of AD credentials since passwords are never synced to the cloud, all authentication happens on-premises
• Reduces overall administration time and costs associated due to the above points

The following are different sign-on experiences when using Federated Identity depending on location and status of computer:

* – Outlook 2007 will be updated after Office 365 has been made generally available to have same experience as Outlook 2010 on Windows 7

** – When first prompted, you can save your password for future use.  You will not receive another prompt until you change the password

*** – In beta period, you will be prompted when first accessing the services

Authentication Mechanisms when using Federated Identity:

Note that Outlook 2007 is planned to be backported to support WS-Trust and WS-Federation after the beta period.

Two-Factor Authentication can be achieved for Office 365.

The following are requirements of ADFS 2.0:

• Microsoft Online Services Directory Synchronization tool (DirSync) is installed
• ADFS servers must have Windows 2008 or Windows 2008 R2 Server operating system installed
• Client computers must be running the latest updates of Windows 7, Windows Vista, or Windows XP (running the Office 365 Desktop Setup from the Office 365 portal will automatically install necessary updates)
• Public SSL certificate to secure traffic associated with ADFS
• Microsoft Online Services Identity Federation Management Tool to establish trust with Office 365

Capacity Planning

When identity federation is enabled and configured in Office 365 there is no fall-back to a different form of authentication if ADFS servers fail. This means that if ADFS servers are not available, users will not be able to authenticate with Office 365 servers. It is very important to configure a highly available ADFS solution utilizing multiple servers and hardware or software load balancing. It is also critical to implement a monitoring solution for the ADFS servers. This includes both the internal ADFS servers and the ADFS proxy servers.

Namespace Planning

ADFS currently only allows for one namespace per ADFS farm/instance. If your company will support multiple namespaces for authentication, you will need to implement an ADFS infrastructure for each. Only internet routable domains that have been validated within Office 365 can be used in an ADFS deployment. If your organization has a non-routable domain for the AD infrastructure (such as .local, .priv, etc), you will need to add a UserPrincipalName (UPN) suffix in AD and configure each user with that UPN suffix (discussed in Part 2).

Summary

Part 1 of this post introduced ADFS 2.0 in relation to Office 365 and discussed environmental requirements required to implement.  Part 2 will walk through the configuration of ADFS 2.0 and Office 365.