Active Directory Synchronization or Federation – Which One Should I Choose? July 7, 2015 //, In the last few months, I’ve had many customers looking to move to ask what the difference was between Active Directory Synchronization and Active Directory Federation. These customers needed to manage user identities and credentials in the cloud and wanted to know how these alternate solutions stack up in terms capabilities, cost and user experience. Below is a quick overview on the differences between Active Directory Synchronization and Federation. What is Directory Synchronization?
Directory Synchronization is the integration of your On-premises Active Directory with an instance of Active Directory running in the Azure cloud. Synchronization essentially makes a copy of the on-premises directory objects and then propagates them to an Active Directory instance in the Azure cloud. After that, synchronization runs on a scheduled basis to push changes from the on-premises directory to the cloud instance.
With few exceptions, synchronization only goes from on-premises to the cloud. If one were to create a new user on the Azure Active Directory tenant, that user would live only in the cloud and would never be propagated down to the on-premises directory. This would create a Cloud (only) Identity (see below) which would have its own login credentials and identity for Office 365 applications.
Over the years, there have been several products to effect directory synchronization. FIM, Microsoft’s Directory Synchronization (affectionately known as DirSync) and Azure Active Directory Sync Services tools (commonly referred to as AAD Sync). AAD Sync was the replacement for DirSync; however, both tools are being deprecated by Microsoft in favor of Azure Active Directory Connect. Since directory synchronization is much simpler to configure than single sign-on (SSO), the benefits of synchronization make it a great choice for many customer scenarios.
DirSync (Directory Synchronization) is a tool for making copies of a local directory in a hybrid cloud deployment of Microsoft Exchange. DirSync makes a copy of the local directory and then propagates itself to a Windows Azure cloud tenant Active Directory instance. After synchronization MailStore users can log on to MailStore Server via Standard Authentication with their Active Directory username and Active Directory password. To use Windows-Authentication it is a requirement that the client and the MailStore Server computer are member of the same domain and that the client is authenticated at the domain.
What is Federation? Active Directory Federation Services (AD FS) can be used to provide federation and single sign-on capabilities for end users who want to access Office 365 applications. Windows Server 2012 R2 includes an AD FS role that can function as an identity provider or as a federation provider. An identity provider authenticates users to provide security tokens to applications that trust AD FS (e.g. Office 365 applications). A federation provider consumes tokens from other identity providers and then provides security tokens to applications that trust AD FS.
Now with Microsoft moving from the old MSOL to AzureAD PowerShell commands (see my blogpost on ), you get new features but (unfortunately) things are starting to disappear as well. In the past you could use Azure AD PowerShell to enable or disable directory synchronization using the Set-MsolDirSyncEnabled cmdlet. During a recent lab deployment, I found out that this cmdlet is no longer available. In fact, not a single Msol cmdlet is available anymore, try Get-Command.msol.
and nothing is returned. To get more information regarding Azure AD you can use Get-Command.Set-AzureAD. This reveals enough information, but nothing that points to directory synchronization.
When logging on to the Azure Portal (of the newly created Office 365 tenant) it is obvious that Azure AD Connect sync is not enabled, as shown in the following screen shot: When you dive deeper into the Azure Active Directory section of the Azure Portal, you can see that synchronization has never run, and that password sync is disabled (which makes sense at this point): Nowhere can an option be found to enable directory synchronization, as you had to do previously before configuring directory synchronization. The only option you have is to download Azure AD Connect, using the following link: So, let’s give it a try. Logon to the new Azure AD Connect server, download Azure AD Connect and start the wizard. Every now and then I get a question regarding creation of Room- or Shared Mailboxes in Office 365 when Exchange Hybrid is in place.There are multiple solutions available, but at the same time there are some restrictions as well. In this blog post I’ll discuss Room Mailboxes, Equipment Mailboxes and Shared Mailboxes.
Room Mailbox To create a room Mailbox in your hybrid environment create a user account for this room mailbox first. In this example I’m going to create a Room Mailbox called ‘conference room 1 st floor’ and have it created directly in Office 365 (for your information, I’ve tested this with Exchange 2010 hybrid as well as Exchange 2016 hybrid).
To create the Mailbox in Exchange Online, you can use the Enable-RemoteMailbox cmdlet in Exchange PowerShell. This will mail-enable the account in your on-premises environment and will automatically create a mailbox in Exchange Online the next time Azure AD Connect runs. For the Enable-RemoteMailbox cmdlet you need to use the -RemoteRoutingAddress (which should point to the Mailbox in Exchange Online) and for a Room Mailbox you have to use the -Room option. If you want to create a Shared Mailbox you can use the -Shared option, the result will be the same. To create the Room Mailbox in Exchange Online we can use the following command: Get-User -Identity Conference1 Enable-RemoteMailbox -Room -RemoteRoutingAddress When Azure AD Connect has run, the account has been provisioned in Azure AD and the Room Mailbox has been created. It is visible in Exchange Online EAC and permissions can be granted to other users can manage the Room Mailbox.
Resource (Equipment) Mailbox To create a Resource (aka Equipment) Mailbox the process is very similar. There are a lot of articles on the Internet on how to create a hybrid environment, where Exchange 2016 is connected to Office 365. Now that’s fine, but when you’re running Exchange 2016 you most like are NOT going to move to Office 365 anytime soon I guess. If you are running Exchange 2010 chances are that you will move to Office 365 (soon), but there aren’t that much articles about moving from Exchange 2010 to Office 365. And a lot of the articles available don’t have the right approach I’m afraid, and will result in you (the customer) having to pay way too much money to your system integrator.
In this article, I’ll try to outline the recommended approach when moving from Exchange 2010 to Office 365 in a hybrid scenario. With Azure AD Connect for synchronization purposes.
Cliffhanger: I’m not going to install Exchange 2016 into the existing Exchange 2010 environment Existing Exchange environment Our organization is called Inframan and they have their own on-premises Exchange 2010 environment which they have been running for 5 years now without too much issues. There are internal Outlook clients using Outlook 2010 and higher, and there are external clients using Outlook Anywhere. There are also mobile clients using ActiveSync to connect to their Mailboxes. Of course, there is Outlook Web Access, but POP3 and IMAP4 are not used. Overview of the Inframan Exchange 2010 environment. The question in my previous blog post was “Can we decommission our Exchange servers after moving to Office 365?” and the blunt answer was “No, you cannot decommission your last Exchange server on-premises”.
In this previous blog post I showed you what happens if you synchronize a user to Azure Active Directory from your on-premises Active Directory, and how to create a Mailbox in Exchange Online with a proper primary Email address. At the same time, it was only possible to set only one Email address, and there’s no possibility to add multiple Email addresses, nor is it possible to change any other Exchange related setting.
In this blog post I’ll discuss how to extend Active Directory with Exchange attributes to unleash more functionality and management options in Exchange Online. Please note that the solution in this blog works fine, but it is not recommended and not supported by Microsoft. I get a lot of questions regarding Office 365, Directory Synchronization from an on-premises Active Directory and decommissioning Exchange servers on-premises. A lot of customers want an Active Directory on-premises, they want Mailboxes in Office 365 and they don’t want an Exchange server on-premises anymore. So the question is basically “Can we decommission our Exchange servers after moving to Office 365?” It is an easy question with an easy answer, and the answer is “No, you cannot decommission your last Exchange server on-premises”. Let me explain why. Source of authority In I already discussed the three types of Identities:.
Cloud Identities. Synced Identities. Federated Identities. With Directory Synchronization (through Azure AD Connect) in place we’re talking about Synced Identities or Federated Identities. Important to note is that the Source of Authority, which means where the identities are managed, is the on-premises Active Directory. Account are created and managed on-premises and not in the cloud. This is also true for properties of the accounts.
Suppose we have the following situation. There’s an Active Directory environment, no Exchange servers on-premises and there’s an AADConnect server for replication purposes to Azure Active Directory as shown in the following picture. Azure AD Connect is synchronizing user accounts to Office 365.
The internal domain is Exchangelabs.local, the external domain Exchangelabs.nl is only verified in Office 365 and set as the default domain. In the on-premises Active Directory there’s an OU=Accounts where objects are in various OU’s like OU=Groups, OU=Users, OU=Contacts etc. User accounts in Active Directory Users and Computers. Please note the different settings in the E-mail Address column. The installation of Azure AD Connect automatically detects that there’s no Exchange server installed (the Active Directory Schema is not even prepared, so it’s truly a green-field Active Directory) and thus the Exchange Hybrid option is not available in the setup application: Figure 3. Azure AD Connect is configured with Password hash synchronization The only option that’s selected is the Password hash synchronization. The Organizational Unit OU=Accounts as mentioned before is the only OU that’s selected for object replication, so after finishing the setup application and the initial synchronization the user account will appear in the Microsoft Online Portal.
When the Office 365 (E3) licenses are assigned to the replicated user accounts, one strange thing is visible. The user account is exactly as expected, i.e. [email protected], but the primary SMTP address does not reflect this, and is actually based on the tenant name, i.e.
[email protected] as shown in the following screenshot. User’s email address is set incorrectly. The tenant email address is set as primary SMTP address. When you want to change the email address from the tenant email address to the regular email address you’ll see the following warning: Figure 5. It is not possible to change the user’s primary SMTP address The Set as Primary button is greyed out, so it’s not possible to change the email address. When you try this in the Exchange Admin Center (in Exchange Online) it doesn’t work either and you get the following error message: The operation on mailbox “Bram Wesselius” failed because it’s out of the current user’s write scope. The action ‘Set-Mailbox’, ‘EmailAddresses’, can’t be performed on the object ‘Bram Wesselius’ because the object is being synchronized from your on-premises organization.
This action should be performed on the object in your on-premises organization. An error message about ‘write scope’ is shown when the user’s Email address is changed. Now it gets interesting.
Have a closer look at Figure 2. You will see that user BWesselius does not have an email address set in Active Directory, but user Ahaverkamp does have an email address. This is not an Exchange email address (since Exchange is not installed on-premises, Active Directory doesn’t have the Exchange schema changes applied, it really is a green-field Active Directory) but the email address is set in Active Directory Users and Computers. The user’s Email address is set in Active Directory Users and Computers. When the Email address is set using Active Directory Users and Computers it is synchronized correctly to Office 365 and used in Exchange Online as the user’s primary Email address. So, now we know how to set the primary Email address when the user is provisioned in the on-premises Active Directory. Despite the fact the user now has the correct primary Email address, it is still not possible to change the user’s Email address in the Office 365 portal or Exchange (online) Admin Center.
This behavior is caused by the fact that the account in this scenario is a Synced Account. The source of authority is the on-premises Active Directory, and this is where all changes need to be made. Once changed the new settings are synchronized to Office 365. So, to change the primary Email address for user BWesselius it’s a matter of adding the Email address to the mail property in Active Directory users and computers and wait for synchronization to happen (or ). If you want to change an Email address, for example for user AHaverkamp you can just change the mail property of the user in Active Directory Users and Computers. So, now we know how to create a user in the on-premises Active Directory and have the Exchange Online primary Email address set correctly. In my next blog I’ll talk more about an on-premises Exchange server.
Posts navigation.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |