30. SafenetDemos
customer premises
IdentityArchitecture
1. Microsoft Online IDs
AD
MS Online
Directory Sync
Provisioning
platform
Lync
Online
SharePoint
Online
Exchange
Online
Active Directory
Federation
Server 2.0
Trust
IdP Directory
Store
Admin Portal
Authentication
platform
Office 365
Desktop
Setup
Microsoft Online Services
2. Microsoft Online IDs + DirSync
3.Federated IDs + DirSync
IdP
31. safenetdemos customer
premises
Single Sign on Setup for New domains
1. Microsoft Online PowerShell Module for Windows
2. Connect to AD FS 2.0 and Microsoft Office 365
3. Add Domain (returns details for proof of ownership)
4. Add Domain
Identity Services
Provisioning
platform
Active Directory
Federation Server
2.0
Trust
Directory
Store
Admin Portal/
PowerShell
Authentication
platform
MSOL PowerShell
Module
Microsoft Online Services
Add Domain
Required
Cname
Add Trust
- Claim Rules
- User Source ID = AD ObjectGUID
Verify-Domain
- Active/Mex/Passive
- Token certs Current/Next
- Brand URI etc
Update
34. Identity Comparison options comparison
1. MS Online IDs
Appropriate for
• Smaller orgs without
AD on-premise
Pros
• No servers required
on-premise
Cons
• No SSO
• No 2FA
• 2 sets of credentials
to manage with
differing password
policies
• IDs mastered in the
cloud
2. MS Online IDs + Dir
Sync
Appropriate for
• Medium/Large orgs
with AD on-premise
Pros
• Users and groups
mastered on-premise
• Enables co-existence
scenarios
Cons
• No SSO
• No 2FA
• 2 sets of credentials to
manage with differing
password policies
• Single server
deployment
3. Federated IDs + Dir
Sync
Appropriate for
• Larger enterprise orgs
with AD on-premise
Pros
• SSO with corporate
cred
• IDs mastered on-
premise
• Password policy
controlled on-premise
• 2FA solutions possible
• Enables co-existence
scenarios
Cons
• High availability server
deployments required
How to pilot single sign-on in a production user forestThis post describes the steps necessary to pilot single sign-on (also known as identity federation) using corporate credentials within a production user forest through the use of a fictional organization “contoso.com”. This post assumes that the reader is somewhat familiar with single sign-on (identity federation) with Office 365 and that they have already read:How single sign-on worksPreparing for single sign-on Plan and deploy AD FS 2.0 for Office 365Establishing a trust to Office 365 Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-onThere are two key scenarios involved in piloting and staging rollout of single sign-on to an organization:Scenario 1: The organization knows that it wants single sign-on (identity federation) to Office 365 right from the start. Therefore the organization establishes a trust between its Active Directory (via Active Directory Federation Service 2.0) and Office 365.In this scenario, the organization is able to pilot and stage rollout, to its users, of single sign-on to Office 365 services, by simply licensing directory synchronized federated users in the administration portal (once they have established the trust using the Microsoft Online Services Module for Windows PowerShell)Additionally the organization can set up an Authorization claim rule on the ADFS 2.0 server, that will only generate a security token (for the authenticated user) if they are a member of an on-premise security group. Hence your pilot users can be put into this security group, as can your other users as you stage rollout to the organization.Scenario 2: The organization has decided initially not to use single sign-on (identity federation). Instead the organization’s users are using Microsoft Online cloud IDs (i.e. non-federated IDs) to sign in to Office 365 services. At some point later the organization decides that they want to start using single sign-on, by converting their existing users from standard Microsoft Online cloud IDs to federated IDs. This is a more complicated scenario for piloting and staging rollout, and hence is described in much more detail below.NOTE: Staging rollout of single sign-on to your organization for this scenario is not currently possible with Office 365. This is because conversion of a standard domain to a federated domain is currently an all or nothing switch (all users are automatically converted to use single sign-on at their next login). A federated domain may only contain federated/single sign-on users.However, piloting single sign-on with a set of production users from your production forest is possible and is described in detail below.Setting the stageContoso Ltd. is an Enterprise size organization with over 2000 employees worldwide. Contoso has deployed Active Directory on premise in a single forest contoso.com. Contoso is also an O365 customer and has over 2000 O365 suite licenses. Contoso has verified domain ownership of contoso.com with O365, and uses Directory Sync to synchronize their on premise AD forest contoso.com (users, contacts and groups) with O365. This has automatically created Microsoft Online IDs (cloud credentials) for each of the on premise users (logon enabled users) in the contoso.com forest. Hence, all Contoso employees using O365 have a cloud credential/UPN (separate from their corporate credential) under the contoso.com. Additionally, contoso.com is the organization’s primary SMTP domain. Contoso is very happy with their move to Office 365. However they are evaluating various pain points associated with managing accounts on premise and in the cloud. This has led to Contoso researching single sign-on. As such Contoso has decided that the investment to deploy single sign-on is worth taking. However, before making that investment, Contoso IT Admins would like to first pilot single sign-on with real production users and test various federated authentication scenarios before rolling this out to the rest of their company.AssumptionsContoso Publishing (or your organization) already has:AD on premise.A single forest containing the user accounts.Directory synchronization running in their forest.Users logging in to Office 365 using Microsoft Online cloud IDs that are under the forest domain (like contoso.com). These are non-federated accounts and are therefore authenticated by the Office 365 identity system.Users who have a primary SMTP address under contoso.com. (Note: this is not mandatory.)Not yet set up single sign-on.Steps to Pilot Deploy AD FS 2.0 (as per Plan for and deploy AD FS 2.0 for Office 365) in Contoso’s production environment.Purchase a new domain from a domain registrar. This domain should be distinct from your production domain (i.e. this cannot be a sub-domain of an existing production domain). For example here we will assume purchase of fabrikam.com and use this in the example from now on.Federate the fabrikam.com domain with Office 365 by following the instructions in Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on on “how to Add a federated domain”. Add fabrikam.com as another UPN domain suffix in your Active Directory forest (See http://technet.microsoft.com/en-us/library/cc756944(WS.10).aspx for instructions).Select pilot users for this pilot program and inform them (ahead of time via emails) that they are part of this single sign-on pilot and the login changes that they should expect during this pilot, and when this change is scheduled for. Inform them that once the transition is complete that at any time when asked to enter an ID, they need to enter their new UPN (the one under the fabrikam.com domain).Go into Active Directory Administrative Center or ADSI (Active Directory Users and Computers) and toggle the pilot user’s UPNs to be under the fabrikam.com domain.NOTE: If the users who are in the pilot test group have smart cards then this technique may not be appropriate, since it involves changing the UPN of the user and will render their smart cards invalid for the period of the pilot program. Organizations should also review whether there are any internal applications or resource access that makes use of user’s UPNs and whether they need any updating.NOTE: This will not affect the user’s SIP address or SMTP proxy addresses. It is perfectly valid to have a UPN that is different from a primary SMTP address.Once all the pilot users have had their UPNs changed, go to the DirSync machine and “force” a synchronization (or simply wait up to 3 hours for the next sync):Go to %program files%\Microsoft Online Directory Sync.Double click on DirSyncConfigShell.psc1 to open a powershellDirSync snap-in session.At the PS command line type: Start-OnlineCoexistenceSync and press Enter.Check that the DirSync update is complete by logging on to the O365 administration portal and into the Exchange Control Panel (ECP) and looking at the user lists in both places. Your pilot user’s UPN changes should be reflected in both the user lists.Contoso pilot users are asked to thoroughly test various sign in scenarios to ensure that single sign-on (and the AD FS 2.0 deployment) is correctly configured, and that single sign-on is ready to be rolled out across the entire organization. Tests include accessing Office 365 services from both browsers and rich client apps (such as Office 2007 or Office 2010, Lync and Outlook 2007 or Outlook 2010) in the following environments:From a domain joined machine.From a non-domain joined machine inside the corporate network.From a roaming domain joined machine outside the corporate network.From a home PC.From a web kiosk (browser only).From a smart phone (i.e. Exchange Active Sync).Federate the production domain contoso.comOnce Contoso is satisfied that single sign-on is correctly configured and working properly through the pilot testing process outlined earlier, Contoso is now ready to roll this out to the existing production users. This involves 2 main steps:Moving the pilot users back into the production standard domain (contoso.com) and removing the test federated domain (fabrikam.com). Removing the test federated domain means that the AD FS 2.0 deployment can now be used to federate your production domain (contoso.com)Federating the contoso.com domain, by converting this standard domain to be federatedInform the pilot users that they are being moved back to the regular production domain and that their single sign-on experience will temporarily go away. Inform them that their UPN will change back to the production domain (contoso.com) and that they will be issued with a new temporary password to access Office 365 (i.e. the experience they had before the pilot program began). They should also be informed that as part of this move they may experience a brief period of downtime.Toggle the pilot users UPN’s domain back to contoso.com from fabrikam.com.Either wait for DirSync to synchronize the changes or force a synchronization using the instructions given previously.Moving the pilot users back to the production domain (contoso.com)NOTE: Due to a code defect Directory Sync will show an error. Moving from a federated domain to a standard domain in this fashion will be supported in the future once this defect is fixed.Moving the user back to a standard (non-federated) domain in the cloud requires the use of the Microsoft Online Services Module for Windows PowerShell. This is the same module that contains the federation tool cmdlets. For each of your pilot users, move them to the contoso.comdomain by using the Set-MsolUserPrincipalNamecmdlet. For example:set-msoluserprincipalname –UserPrincipalNamejohn@fabrikam.com-newUserPrincipalNamejohn@contoso.comOnce you can see the pilot user’s UPNs updated in the administration portal, reset all those pilot user’s cloud passwords (using the administration portal) and distribute the temporary passwords to the pilot users.The pilot users will be forced to change their passwords the first time they login, after being moved back to the contoso.com domain[1].Federating the production domain (contoso.com)On the AD FS machine, open the Microsoft Online Services Module for Windows PowerShell (see Install and configure the Microsoft Online Services Module for Windows PowerShell for single sign-on for further information). This time, after connecting to the service and AD FS, remove the federated test domain fabrikam.com by using the Remove-MSOLFederatedDomaincmdlet.Inform all production users with Office 365 licenses/accounts in contoso.com that single sign-on is going to be enabled for their Office 365 login accounts and when this is scheduled for. Explain the changes in the login experiences to all end users once the contoso.com domain is federated.Next federate the contoso.com domain using the Convert-MSOLDomainToFederatedcmdlet. NOTE: This conversion process can take up to 24 hours to complete. Microsoft recommends that this operation is performed over a weekend.NOTE: This conversion process will convert all the contoso.com user’s cloud credentials into federated credentials – allowing them to use their corporate credentials to sign in to Office 365 services. Staging of this conversion process is not currently possible with Office 365.[1] Being prompted for credentials may not happen immediately because the client caches a service token for the user. When the service token expires, the user will be prompted for credentials.