Partager via

Choosing a sign-in model for Office 365

  • Article

Hola me encontre con este excelente articulo de Paul Andrew @pndrw, aqui el detalle:

Choosing a sign-in model for Office 365

Source Office Blogs

Paul Andrew is technical product manager for Identity Management on the Office 365 team.

We get a lot of questions about which of the three identity models to choose with Office 365. Which of these models you choose will impact where you manage your user accounts for Office 365 and how those user sign-in passwords are verified. In this post I’ll describe each of the models, explain how to move between them, and provide guidance on how to choose the right one for your needs.choosesignin_01

Three identity models for Office 365

In the diagram above the three identity models are shown in order of increasing amount of effort to implement from left to right. Our recommendation for successful Office 365 onboarding is to start with the simplest identity model that meets your needs so that you can start using Office 365 right away. Then, as you determine additional necessary business requirements, you can move to a more capable identity model over time. The way to think about these is that the Cloud Identity model is the simplest to implement, the Federated Identity model is the most capable, and the Synchronized Identity model is the one we expect most customers to end up with. Let’s look at each one in a little more detail.

choosesignin_02

Cloud Identity. In this model a user is created and managed in Office 365 and stored in Azure Active Directory, and the password is verified by Azure Active Directory. Azure Active Directory is the cloud directory that is used by Office 365. There is no equivalent user account on-premises, and there is nothing that needs to be configured to use this other than to create users in the Office 365 admin center.

choosesignin_03

Synchronized Identity. In this model the user identity is managed in an on-premises server and the accounts and password hashes are synchronized to the cloud. The user enters the same password on-premises as they do in the cloud, and at sign-in the password is verified by Azure Active Directory. This model uses the Microsoft Azure Active Directory Sync Tool (DirSync).

choosesignin_04

Federated Identity. This model requires a synchronized identity but with one change to that model: the user password is verified by the on-premises identity provider. This means that the password hash does not need to be synchronized to Azure Active Directory. This model uses Active Directory Federation Services (AD FS) or a third- party identity provider.

 

You can switch between the models

We recommend that you use the simplest identity model that meets your needs. If your needs change, you can switch between these models easily. Here’s a description of the transitions that you can make between the models.

Cloud Identity to Synchronized Identity. This transition is simply part of deploying the DirSync tool. You may have already created users in the cloud before doing this. If you switch from the Cloud Identity model to the Synchronized Identity model, DirSync and Azure Active Directory will try to match up any existing users. There are two ways that this user matching can happen. The first one occurs when the users in the cloud have previously been synchronized from an Active Directory source. In this case they will have a unique ImmutableId attribute and that will be the same when synchronization is turned on again. Users with the same ImmutableId will be matched and we refer to this as a “hard match.”

The second way occurs when the users in the cloud do not have the ImmutableId attribute set. In this case we attempt a “soft match,” which looks at the email attributes of the user to find ones that are the same. If we find multiple users that match by email address, then you will get a sync error. If you want to be sure that users will match using soft-match capabilities, make sure their PrimarySMTP addresses are the same both in Office 365 and in the on-premises Active Directory. If all of your users are entered in the cloud but not in your Active Directory, you can use PowerShell to extract them and then you can import them into Active Directory so that soft match will work.

Synchronized Identity to Federated Identity. This transition is required if you deploy a federated identity provider, because synchronized identity is a prerequisite for federated identity. The user identities are the same in both synchronized identity and federated identity. Because of this, changing from the Synchronized Identity model to the Federated Identity model requires only the implementation of the federation services on-premises and enabling of federation in the Office 365 admin center. Switching from Synchronized Identity to Federated Identity is done on a per-domain basis. The operation both defines the identity provider that will be in charge of the user credential validation (often a password) and builds the federation trust between Azure Active Directory and the on-premises identity provider. When you switch to federated identity you may also disable password hash sync, although if you keep this enabled, it can provide a useful backup, as described in the next paragraph.

choosesignin_05

Federated Identity to Synchronized Identity. You can convert a domain from the Federated Identity model to the Synchronized Identity model with the PowerShell command Convert-MsolDomainToStandard. Since the password sync option in DirSync is a recent addition, some customers will make this transition to take advantage of that and simplify their infrastructure. This transition can also be a useful backup in case there is a failure with the federated identity provider, because any failure with the federated identity provider—including the physical server, the power supply, or your Internet connectivity—will block users from being able to sign in.

The switch back from federated identity to synchronized identity takes two hours plus an additional hour for each 2,000 users in the domain. Once you have switched back to synchronized identity, the user’s cloud password will be used. We recently announced that password hash sync could run for a domain even if that domain is configured for federated sign-in. Previously Azure Active Directory would ignore any password hashes synchronized for a federated domain. This recent change means that password hash sync can continue for federated domains, so that if you switch from Federated Identity to Synchronized Identity the password validation will be available immediately. If you do not have password sync configured as a backup and you switch from Federated Identity to Synchronized Identity, then you need to configure that, assign passwords with the set-MsolUserPassword PowerShell command, or accept random passwords.

Synchronized Identity to Cloud Identity. You can turn off directory synchronization entirely and move to cloud-managed identities from within the Office 365 admin center or with the PowerShell command Set-MsolDirSyncEnabled. This update to your Office 365 tenant may take 72 hours, and you can check on progress using the Get-MsolCompanyInformation PowerShell command and by looking at the DirectorySynchronizationEnabled attribute value. There is a KB article about this.

 

When to choose the Cloud Identity model

Choosing cloud-managed identities enables you to implement the simplest identity model, because there is no on-premises identity configuration to do. All you have to do is enter and maintain your users in the Office 365 admin center. This is likely to work for you if you have no other on-premises user directory, and I have seen organizations of up to 200 users work using this model.

You may also choose the Cloud Identity model if you have a very complex on-premises directory and simply want to avoid the work to integrate with it. These complexities may include a long-term directory restructuring project or complex governance in the directory. If you have an existing on-premises directory, but you want to run a trial or pilot of Office 365, then the Cloud Identity model is a good choice, because we can match users when you want to connect to your on-premises directory.

It is most common for organizations with an existing on-premises directory to want to sync that directory to the cloud rather than maintaining the user directory both on-premises and in Office 365. In that case, either password synchronization or federated sign-in are likely to be better options, because you perform user management only on-premises.

To sum up, you would choose the Cloud Identity model if you have no on-premises directory, if you have a very small number of users, if your on-premises directory is undergoing significant restructuring, or if you are trialing or piloting Office 365.

 

When to use the Synchronized Identity model

The Synchronized Identity model is also very simple to configure. It requires you to have an on-premises directory to synchronize from, and it requires you to install the DirSync tool and run a few other consistency checks on your on-premises directory. This is described in my recent blog post Synchronizing your directory with Office 365 is easy. Before June 2013 this model did not include password synchronization and users provisioned using synchronized identity had to create new cloud passwords for Office 365. This was a strong reason for many customers to implement the Federated Identity model. Now that password synchronization is available, the Synchronized Identity model is suitable for many customers who have an on-premises directory to synchronize with and their users will have the same password on-premises and in the cloud.

In addition to leading with the simplest solution, we recommend that the choice of whether to use password synchronization or identity federation should be based on whether you need any of the advanced scenarios that require federation. I’ll talk about those advanced scenarios next. However if you don’t need advanced scenarios, you should just go with password synchronization. You can also use the Synchronized Identity model when you ultimately want federated identity, but you are running a pilot of Office 365 or for some other reason you aren’t ready to dedicate time to deploying the AD FS servers yet.

To sum up, you would choose the Synchronized Identity model if you have an on-premises directory and you don’t need any of the specific scenarios that are provided for by the Federated Identity model.

 

When to use the Federated Identity model

As mentioned earlier, many organizations deploy the Federated Identity model just so that their users can have the same password on-premises and in the cloud. With the addition of password hash synchronization to the Synchronized Identity model in July 2013, fewer customers are choosing to deploy the Federated Identity model, because it’s more complex and requires more network and server infrastructure to be deployed.

All of the configuration for the Synchronized Identity model is required for the Federated Identity model. Because of this, we recommend configuring synchronized identity first so that you can get started with Office 365 quickly and then adding federated identity later.

The following scenarios are good candidates for implementing the Federated Identity model. If none of these apply to your organization, consider the simpler Synchronized Identity model with password synchronization.

Existing infrastructure

Scenario 1. You already have an AD FS deployment. If you already have AD FS deployed for some other reason, then it’s likely that you will want to use it for Office 365 as well. This also likely means that you now have multiple SaaS applications that are using AD FS federated sign-in and Azure Active Directory is connecting to the existing infrastructure that you maintain for AD FS with little additional overhead. Of course, having an AD FS deployment does not mandate that you use it for Office 365. You can still use password hash sync for Office 365 and your AD FS deployment for other workloads.

Scenario 2. You already use a third-party federated identity provider. If your company uses a third- party, non-Microsoft, identity provider for authentication, then federated identity is the right way to do that. Third-party identity providers do not support password hash synchronization. Microsoft has a program for testing and qualifying third-party identity providers called Works with Office 365 – Identity.

Scenario 3. You use Forefront Identity Manager 2010 R2. Forefront Identity Manager 2010 R2 can be used to customize the identity provisioning to Azure Active Directory with the Forefront Identity Manager Connector for Microsoft Azure Active Directory. It offers a number of customization options, but it does not support password hash synchronization.

Technical requirements

Scenario 4. You have multiple forests in your on-premises Active Directory. The DirSync tool does not support multiple forests. Because of this, if you are synchronizing multiple forests you need to either use Forefront Identity Manager 2010 R2 with the Forefront Identity Manager Connector for Microsoft Azure Active Directory or the new Azure Active Directory Sync Services. None of these alternate synchronization tools currently support password hash sync; hence users would not automatically have the same password on-premises and online without federated identity. Before proceeding with such a deployment, you may also consider consolidating your forests so that you can use the DirSync tool, which supports only one forest. Forest consolidation is described in this TechNet article.

Scenario 5. You have an on-premises integrated smart card or multi-factor authentication (MFA) solution. Azure Active Directory does not have an extensible method for adding smart card or other authentication providers other than by sign-in federation. Often these authentication providers are extensions to AD FS, where Office 365 sign-in can take advantage of them through federation with the AD FS provider. Azure Active Directory does natively support multi-factor authentication for use with Office 365, so you may be able to use this instead.

Scenario 6. Custom hybrid applications or hybrid search is required. Custom hybrid application development, such as hybrid search on SharePoint or Exchange or a custom application on SharePoint, often requires a single authentication token to be used both in the cloud and on-premises. This is more than a common password; it is a single sign-on token that can be passed between applications for user authentication. This is only for hybrid configurations where you are undertaking custom development work and require both the on-premises services and the cloud services to be authenticated at the same time.

Scenario 7. Web-accessible forgotten password reset. For a federated user you can control the sign-in page that is shown by AD FS. It is possible to modify the sign-in page to add forgotten password reset and password change capabilities. This feature is not provided with AD FS but can be manually added during deployment of your AD FS implementation, as described on TechNet. You cannot edit the sign-in page for the password synchronized model scenario. Alternatively, Azure Active Directory Premium is an additional subscription that can be added to an Office 365 tenant and includes forgotten password reset for users in any of the three Identity models.

Policy requirements

Scenario 8. You require sign-in audit and/or immediate disable. With federated identity using AD FS, each sign-in attempt is logged in the standard Windows event log in the same way that on-premises sign-in attempts are logged. You can also disable an account quickly, because disabling the account in Active Directory will mean all future federated sign-in attempts that use the same Active Directory will fail (subject to internal Active Directory replication policies across multiple domain controller servers and cached client sign-in tokens). Sign-in auditing and immediate account disable are not available for password synchronized users, because this kind of reporting is not available in the cloud and password synchronized users are disabled only when the account synchronization occurs each three hours. An alternative for immediate disable is to have a process for disabling accounts that includes resetting the account password prior to disabling it. The password change will be synchronized within two minutes to Azure Active Directory and the user’s previous password will no longer work. Alternatively, you can manually trigger a directory synchronization to send out the account disable.

Scenario 9. Single sign-on is required. Password synchronization provides same password sign-on when the same password is used on-premises and in Office 365. With single sign-on, you can sign in to your Windows PC that is connected to your Active Directory domain and you do not need to re-enter your password when you connect to Office 365. This requires federated identity and works because your PC can confirm to the AD FS server that you are already signed in. An alternative to single sign-in is to use the Save My Password checkbox. This stores the user’s password in Windows Credential Manager (CredMan), where it is secured by the login credentials for the PC, and the user can sign in to their PC to unlock the passwords that CredMan uses. Note that the Outlook client does not support single sign-on and a user is always required to enter their password or check Save My Password.

Scenario 10. Require client sign-in restrictions by network location or work hours. There are two features in Active Directory that support this. Client Access Policy is a part of AD FS that enables limiting user sign-in access based on whether the user is inside or outside of your company network, or whether they are in a designated Active Directory group and outside of your company network. For users who are to be restricted you can restrict all access, or you can allow only ActiveSync connections or only web browser connections. In addition, Active Directory user policies can set login restrictions and are available to limit user sign-in by work hours. Federation delegates the password validation to the on-premises Active Directory and this means that any policies set there will have effect.

Scenario 11. Policy preventing synchronizing password hashes to Azure Active Directory. A small number of customers will have a security policy that precludes synchronizing password hashes to Azure Active Directory. In that case, you would be able to have the same password on-premises and online only by using federated identity. Microsoft is strongly committed to the security of all customer data. We encourage security professionals to review our Office 365 Trust Center. Also, we have details about how password hashes are synchronized in the TechNet article Implement Password Synchronization, and we have additional security guidance about password hash synchronization published on TechNet.

To sum up, you should consider choosing the Federated Identity model if you require one of the 11 scenarios above.

 

Recent enhancements change the landscape

Recent enhancements have improved Office 365 sign-in and made the choice about which identity model you choose simpler. The guidance above for choosing an identity model that fits your needs includes consideration of all of these improvements, but bear in mind that not everyone you talk to will have read about them yet.

The three identity models you can use with Office 365 range from the very simple with no installation required to the very capable with support for many usage scenarios. By starting with the simplest identity model that meets your needs, you can quickly and easily get your users onboarded with Office 365. Later you can switch identity models, if your needs change.

Saludos

@ferglo

 

 

Comments

  • Anonymous
    May 14, 2014
    Pingback from Blog Post: Choosing a sign-in model for Office 365 | Isupon