Sunday, July 8, 2012

How to federate existing Office365 users

The most common scenario for federating users that are already using Office365 is when users have transitioned from BPOS to Office 365. The customer/company was waiting to use this excellent feature of Office365 and wanted to implement it once they had transitioned from BPOS to Office365

So in this scenario I will describe how it could be done for 200 users but the same steps apply for any amount of users.

So the first thing to do is to add in a new upn for users. If the customer had an internal domain of contoso.local we will need to add in a new upn of contoso.com. To add the new UPN in , you browse to Active Directory Domains and Trusts and right click on the Active Directory Domains and Trusts icon and select properties and add the new UPN as per the image below.

In this particular scenario , there was no no onpremise exchange , so no email address fields were populated. So we need to modify all user's UPN and add in their email addresses before we implement Directory Sync because DirSync matches the onpremise AD users with the existing Office365 users by their primary SMTP address. This is described in Microsoft KB 2641663

So we use ADMODIFY from Codeplex. You can download it HERE
Download ADMODIFY , Extract the package, Launch Admodify , Connect to AD and select a domain controller.

So firstly we will select all the users we need to modify..Then click add to list and select all and we can now easily modify all the users.

So firstly we will modify all users UPN. All existing users in Office365 have an email address policy of firstname.lastname. So when selecting the UPN tab I enter this variable switch in LegacyAccount tab %'givenname'%.%'sn'% as per the image below.

When we hit apply on the UPN Change , We will need to select all the users again and then go to the email tab we need to enter this string in the add smtp address as per the image below %'givenname'%.%'sn'%@contoso.com


So by adding in this address , admodfy has placed the primary email address on the general tab and updated the required Active Directory proxyAddresses attribute as per the Microsoft KB 2641663 mentioned earlier.

So now we are ready for Dirsync, So when Dirsync runs it will match the active directory user objects with the existing Office365 user accounts and both the Office365 and Active Directory users will have the same immutable ids. To verify the Office365 user's immutable ID you can run the powershell command in the Microsoft Online Services Powershell module and output the query to a text file.

Get-MsolUser -all where {$_.isLicensed -eq $true} select-object userprincipalname,immutableid out-file c:\users.txt

The next step then is to federate the contoso.com domain , this can be done using the Microsoft Online Services Powershell module on the primary adfs server

winrm quickconfig
Connect-MsolService –Credential $cred
Set-MsolAdfscontext -Computer adfsprimary.contoso.local
Convert-MsolDomainToFederatedDomainName contoso.com

So what affect does this have on users?

All user's domain logins remain the same as when we were modifying UPN's we didnt alter the (pre-Windows 2000) value.


Outlook will prompt for a user name and password so the user will enter sean.ofarrell@contoso.com , their ad passord and remember credentials.

Smartphone user names will be the user's priamry email address followed by the users active directory password.

Within the domain via group policy the service name of the adfs farm will be published to each users internet explorer intranet zone which will allow single sign on to the Office 365 portal and Sharepoint.

Lync will auto sign in provided the sign in assistant is installed.

One last thing , dont forget to apply Rollup2 for ADFS 2.0

And also the Exchange Remote Connectivity Analyzer can also troubleshoot Single Sign On as well as ActiveSync and Auto Discover

8 comments:

  1. So once federated does 365 just "dump" their existing 365 passwords then?

    Or i suppose maybe it just ignores them and re-directs its usual "local password check" to the federated services servers?

    ReplyDelete
  2. Yes it dumps the online passwords and users are authenticated against their active directory

    ReplyDelete
  3. We have a number of users who have different immutable ID's on prem than in Office365 due to a previous domain merger. Is there a way to edit the ID's on a server 2003 box or in the O365 system?

    ReplyDelete
  4. This comment has been removed by the author.

    ReplyDelete
  5. Stop the dirsync service , Convert the user that is having the problem to a standard online user.Ensure the onpremise ad account has the correct attributes to match up with the online user like SMTP:primary office365 email address in the proxy address attribute as well as on the general tab. Start the dirsync service and do a manual sync and that should fix it for you.

    ReplyDelete
  6. Get-MsolUser -all where {$_.isLicensed -eq $true} select-object userprincipalname,immutableid out-file c:\users.txt

    This command isn't working for me, I get:

    PS C:\Users\administrator.LITEDUSUPPORT\Desktop> Get-MsolUser -all where {$_.isLicensed -eq $true} select-object userprincipalname,immutableid out-file c:\users
    .txt
    Get-MsolUser : A positional parameter cannot be found that accepts argument 'where'.
    At line:1 char:13
    + Get-MsolUser <<<< -all where {$_.isLicensed -eq $true} select-object userpri
    ncipalname,immutableid out-file c:\users.txt
    + CategoryInfo : InvalidArgument: (:) [Get-MsolUser], ParameterBi
    ndingException
    + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.Online.Adm
    inistration.Automation.GetUser

    ReplyDelete
  7. Sean,

    This is an excellent post, thank you!

    I am trying to migrate a client and I think this may help but will lay out the scenario.

    I have a client that is looking to implement Office 365. They have 2 forests – One that contains their user accounts that they use to log into their workstations. All the workstations are joined to this forest (lets called it ABC.CORP). They then have a second forest called XYZ.LAN that has their exchange organization. Each user basically has 2 user accounts (one of logging onto the domain and gaining access to local resources and the second to access their mail data in the 2nd forest – the 2nd forest is part of a hosted service they subscribe to so the physical servers are not onsite. They want to get rid of XYZ.LAN and have their users use their ABC.CORP credentials.

    My thoughts are:

    •Configure Exchange 2010 hybrid servers in the XYZ.LAN forest
    •Connect the Exchange management console to the Office 365 tenant
    •Migrate users to Office 365 from the Exchange console, making the user an Office 365 user and not a XYZ.LAN user
    •Once all Exchange resources have been migrated, remove hybrid servers
    •Configure new UPN suffix in ABC.CORP domain
    •Assign new UPN suffix to all users
    •Modify user accounts to add proxy addresses matching their addresses in O365
    •Install and configure DirSync in ABC.CORP domain – DirSync process will match the AD users with their O365 counterpart based on email addresses
    •Install and configure ADFS\ADFS proxy in ABC.CORP domain

    Do you think this will work?

    ReplyDelete
  8. Hi Ibena, Glad the you like my blog posting. Firstly you cant sync 2 forests into Office365.This is something that will be available in future releases but not currently available. So it would be a separate tenant per forest. But heres a cool idea. If your customer had a Windows Azure subscription then you could sync the two forests into Azure and then once in Azure you can authenticate across all the microsoft stack of cloud of products. http://www.windowsazure.com/en-us/home/features/identity/

    ReplyDelete