Welcome to Langenile

[email protected]
Contact Us

Yearly Archives: 2022

  1. Home / 
  2. 2022
Nov 16, 2022
Choosing between Azure AD Connect and Azure AD Connect Cloud Sync– Planning Identity Synchronization

Azure AD Cloud Sync is the next evolution of the directory synchronization product. While it does not yet have full parity with Azure AD Connect features, Azure AD Connect Cloud Sync (sometimes referred to as Cloud Sync) can provide additional features and benefits that Azure AD Connect cannot:

  • While Azure AD Connect requires on-premises connectivity between the Azure AD Connect server and all connected forests, Azure AD Connect Cloud Sync can import identities from forests that do not have site-to-site connectivity. This makes Cloud Sync advantageous when dealing with mergers and acquisitions as well as organizations that have multiple, disconnected business units.
  • Lightweight on-premises provisioning agents with cloud-managed sync configuration. Multiple sync agents can be installed to provide fault tolerance and redundancy for password hash synchronization customers.

However, Cloud Sync provides fewer overall features. The following list identifies the core feature gaps:

  • Cloud Sync does not support on-premises LDAP directories.
  • Cloud Sync does not support device objects.
  • Pass-through authentication is unavailable with Cloud Sync.
  • Advanced filtering and scoping (such as by using object attributes) are not supported with Cloud Sync, nor are advanced configurations of custom synchronization rules.
  • Azure AD Connect Cloud Sync does not support more than 150,000 objects per AD domain, nor does it support Azure AD Domain Services (Azure AD DS). Since Cloud Sync is limited to 150,000 objects, it does not support large groups (up to 250,000 members).
  • Cloud Sync does not support Exchange hybrid writeback or group writeback.
  • Cloud Sync cannot merge object attributes from multiple source domains.

A full comparison of features is available at https://learn.microsoft.com/en-us/azure/active-directory/cloud-sync/what-is-cloud-sync. As you can see from the previous lists, Azure AD Connect Cloud Sync is potentially a good option for organizations that don’t have more than 150,000 objects in any single domain, don’t require object or property writeback, and don’t need to heavily customize synchronization rules.

Planning user sign-in

The final step in planning your hybrid identity solution is around what type of sign-in experience you want to deploy for your users. As discussed briefly in the Designing synchronization solutions section, there are three core methods for managing user sign-in:

  • Password hash synchronization
  • Pass-through authentication
  • Federation

While all three of these solutions utilize some sort of identity synchronization technology, knowing the features and capabilities of each will help you choose the option that’s right for your organization.

Let’s explore each of these options in a little more detail.

More Details
Sep 15, 2022
AD FS– Planning Identity Synchronization

If you are using the Azure AD Connect installation wizard to configure AD FS, there are additional requirements that must be met:

  • If you are using Azure AD Connect to configure AD FS, the federation and web application proxy (WAP) servers must already have TLS/SSL certificates installed and the servers must be accessible via WinRM.
  • AD FS server hosts must be Windows Server 2012 R2 or later.
  • The AD FS farm servers must be domain-joined. The AD FS web application proxy servers must not be domain-joined.
  • AD FS also has specific name resolution requirements. The internal DNS domain must use A records for the federation server farm (external DNS can use A records or CNAME records).

Further information

While it is not covered by the MS-100 exam, per se, it’s important to note that externally, DNS will point to the AD FS WAP servers using the name deployed on the SSL/TLS certificate (such as sts.contoso.com or adfs.contoso.com). However, the AD FS WAP servers need to resolve the AD FS farm name to the internal farm servers, not to themselves. This is frequently accomplished by configuring a host’s file on the AD FS WAP servers.

Accounts and security

To successfully configure Azure AD Connect, you must have access to privileged accounts:

  • You must have either an Azure AD Global Administrator or Hybrid Identity Administrator account to configure synchronization. These credentials are used to create a service account in Azure AD that’s used to provision and synchronize objects.
  • If you use the Express setup option or upgrade from the legacy DirSync product, the installation account must be a member of Enterprise Admins in the local Active Directory.
  • If you are configuring Azure AD Connect with a service account, the account must have the following permissions delegated:
    • Write permissions to Active Directory (if any hybrid writeback features are enabled, such as Exchange hybrid writeback, password writeback, group writeback, or device writeback)
    • If password hash synchronization is deployed, the service account must be delegated the special permissions called Replicating Directory Changes and Replicating Directory Changes All to read the password data from Active Directory

Connectivity

Azure AD Connect needs to be able to communicate with both on-premises directories as well as Azure AD:

  • Azure AD Connect must be able to resolve DNS for both internet and intranet locations.
  • Azure AD Connect must be able to communicate with the root domain of all configured forests.
  • If your network requires a proxy to connect to the internet, you must update the .NET Framework’s machine.config file with the appropriate proxy server address and port. If your proxy server requires authentication, you must use a custom installation and specify a domain-member service account.

If your environment meets the minimum requirements for deploying Azure AD Connect, you can download the components and begin the installation. You can download the most recent version of Azure AD Connect from https://aka.ms/aadconnect.

More Details
Aug 1, 2022
On-premises Active Directory– Planning Identity Synchronization

Before you install Azure AD Connect, you will also need to make sure that Active Directory meets certain requirements as well:

  • You must have at least one on-premises Active Directory environment with Windows Server 2003 or later forest functional level and schema. The NetBIOS name of the forest or domain cannot have a period in it.
  • The domain controller that Azure AD Connect uses must be writeable. Read-only domain controllers (RODCs) are not supported for use with Azure AD Connect. RODCs are permitted in the environment, but Azure AD Connect should be installed in an Active Directory site without RODCs.

SQL Server

In addition to the core prerequisites to install and configure Azure AD Connect, you should be aware of limitations regarding the size of the database.

By default, Azure AD Connect installs SQL Server 2019 Express for use with the Azure AD Connect database. Express editions of SQL are limited to a 10 GB database, which is sufficient for managing synchronization for approximately 100,000 objects. If the sum of objects in all of your connected directories is larger than 100,000 objects, you will need to configure Azure AD Connect during installation to connect to a full version of SQL Server.

Exam tip

SQL database server sizing and performance requirements are outside the scope of the MS-100 exam.

As previously mentioned, Azure AD Connect deployments that are used to synchronize more than 100,000 objects will require their own SQL Server. The memory and disk space requirements in Table 3.3 are for Azure AD Connect only and do not reflect the additional SQL Server sizing requirements.

Azure AD Connect server software components

Azure AD Connect has requirements specific to the minimum operating system versions, as well as other software components:

  • Currently, you can deploy to Windows Server 2016 or Windows Server 2019 (but not Server 2022 yet). You cannot deploy to Small Business Server or Windows Server Essentials editions before 2019.
  • The PowerShell execution policy for the server should be set to RemoteSigned or Unrestricted.
    • You must not have PowerShell Transcription enabled through Group Policy if you plan on using Azure AD Connect to configure Active Directory Federation Services (AD FS).

Note

This is a change from the original product documentation. Previously, PowerShell Transcription would cause the installation to abort.

  • The server used for Azure AD Connect must have a full GUI installed. It doesn’t support deployment to any edition of Windows Server Core.
  • Ensure you have PowerShell 5.0 or later as well as .NET Framework 4.5.1 or later installed.
  • Azure AD Connect checks for the MachineAccessRestriction, MachineLaunchRestriction, and DefaultLaunchPermission values in the Distributed COM (DCOM) configuration. If those values are missing or corrupt, the installation will fail.

While it is not required, Microsoft recommends forcing the use of TLS 1.2 for .NET Framework components. This can be configured by setting the HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\SchUseStrongCrypto registry value to DWORD:00000001.

More Details
May 14, 2022
FURTHER READING– Planning Identity Synchronization

You can learn more about the required and supported values for attributes at https://learn.microsoft.com/en-us/powershell/module/exchange/set-mailbox and https://learn.microsoft.com/en-us/microsoft-365/enterprise/prepare-for-directory-synchronization.

When preparing to synchronize your directory, Microsoft recommends performing the following procedures:

  • Use the IdFix tool (https://aka.ms/idfix) to detect errors such as invalid characters in on-premises identities. Values that contain invalid characters will cause object synchronization errors.
  • Configure a user’s userPrincipalName (UPN) to be the same as their primary SMTP address. While it’s not required to have parity between UPN and SMTP addresses, it is recommended to help minimize the number of unique values that users have to remember.

You shouldn’t install and configure directory synchronization until you have resolved the issues identified by IdFix.

Identifying required Azure AD Connect features

Depending on your organization’s requirements for onboarding to Microsoft 365 as well as additional features or services that are included with your subscription, you may want (or need) to enable or configure additional Azure AD Connect features.

There are several additional features available post-installation for Azure AD Connect, such as managing duplicate attribute resiliency and user principal name soft-matching, both of which are used to manage how Azure AD handles conflicts and connect cloud accounts to on-premises accounts.

Further reading

More detailed information about the Azure AD Connect optional features, such as duplicate attribute resiliency, is available here: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-syncservice-features.

Understanding the prerequisites for Azure AD Connect

The Azure AD Connect synchronization has several prerequisites, including supported hardware and software, as well as permissions required for various synchronization options.

The Azure AD prerequisites can be broken down into seven sections:

  • Azure AD
  • On-premises Active Directory
  • SQL Server
  • Azure AD Connect server hardware requirements
  • Azure AD Connect server software requirements
  • Accounts and security
  • Connectivity

Let’s quickly review the requirements.

Azure AD

The first set of requirements surrounds your Azure AD environment:

  • You must have an Azure AD tenant (any Azure AD or Microsoft 365 subscription is sufficient)
  • You should have one or more verified domains in Azure AD

Note

The Microsoft Azure AD Connect documentation (https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-install-prerequisites) lists a verified domain as a requirement, but functionally, you can install and configure Azure AD Connect synchronization without a verified domain. The user interface will display a warning, but you can proceed. Objects will receive a managed domain name (onmicrosoft.com) suffix when they are synchronized.

More Details
Mar 22, 2022
Understanding Azure AD Connect with multi-tenant scenarios– Planning Identity Synchronization

In more complex scenarios, you can synchronize objects from one (or more) on-premises forests to one (or more) Azure AD tenants, as shown in Figure 3.5:

Figure 3.5 – Synchronization to multiple Azure AD tenants

This is relatively new, from a supported topologies perspective. This is a potential solution if you need to support multiple tenants in your organization. Microsoft, however, recommends trying to consolidate to a single tenant where possible.

There are some important caveats with this design, primarily the following:

  • You need to deploy an Azure AD Connect server to communicate with each tenant.
  • While the same object can be in scope for multiple Azure AD Connect instances, Exchange hybrid writeback, device writeback, and group writeback are only supported by one tenant. If you configure those writeback features for more than one tenant and have the same object in scope for those Azure AD Connect servers, you will enter a race condition where the object will get continuously updated errantly.
  • You can have Password Write-back enabled on multiple tenants for the same user object.
  • Hybrid Azure AD Join and Seamless SSO can only be configured with one tenant.
  • You cannot configure the same custom domain in more than one tenant.

As previously mentioned, Microsoft recommends trying to consolidate into a single tenant to get the best experience. And, regardless of the Azure AD Connect topologies selected, it is not supported to deploy more than one active Azure AD Connect server to a single tenant. If you need to connect multiple on-premises systems to a single Azure AD tenant, you can achieve that with a single Azure AD Connect server.

Identifying object source requirements

Since the purpose of Azure AD Connect is synchronizing user, group, contact, and device objects to Azure AD, you’ll need to make sure your objects meet the minimum requirements.

Microsoft has guidance surrounding preparing user objects for synchronization. Some attributes (specifically those that are used to identify the user throughout the system) must be unique throughout the organization. For example, you cannot have two users that have the same userPrincipalName value.

As you can see, very few attributes are required for an object to synchronize. Each attribute that is synchronized does have some core requirements around formatting, including length and allowed characters. Several attributes (such as mailNickname, userPrincipalName, mail, sAMAccountName, and proxyAddresses) must contain unique values – that is, no other object in the directory of any type can share those values.

More Details
Jan 24, 2022
Understanding Azure AD Connect with multi-forest scenarios– Planning Identity Synchronization

Azure AD Connect also supports several multi-forest scenarios.

In a basic multi-forest scenario, you have one or more on-premises Active Directory forests all contributing unique objects to a single Azure AD tenant.

You might need to support a configuration like this if you have multiple business units within your organization with their own autonomous Active Directory environments that all want to share a single Microsoft 365 environment:

Figure 3.2 – Multiple Active Directory forests contributing to a single Azure AD tenant

There are other organizational scenarios where you may need to support multiple forests. Large organizations sometimes configure multiple directories in what’s called a resource forest configuration.

In this structure, application resources (such as Microsoft Exchange) are configured in one forest (called the resource forest). A trust relationship is established with another forest containing accounts (intuitively called the account forest). The trust allows objects from the account forest to access applications and services in the resource forest. The user objects in the account forests are linked to a corresponding security principal account in the resource forest, thereby granting access to the resource forest. See Figure 3.3:

Figure 3.3 – Account forests and a resource forest contributing to a single Azure AD tenant

Another common multi-forest scenario involves two or more on-premises organizations that utilize some other form of directory synchronization (such as MIM GALSync) to ensure that each organization’s Exchange environment contains a full list of the objects in their partner’s directories. This example is shown in Figure 3.4:

Figure 3.4 – Multiple forests with on-premises synchronization to a single Azure AD tenant

In this scenario, users have a single primary account that they use for accessing services and resources. That account is represented in the partner organization’s directory as a contact object.

Multiple forests, multiple users, multiple options

Multi-forest configurations can be quite tricky. During the Azure AD Connect setup, you’ll be prompted to select how your users are represented across the organization. You have two core options: Users are represented only once across all directories and User identities exist across multiple directories.

The first option is straightforward – it’s a scenario where users only have one object.

The second option, though, has two additional choices: to match using Mail attribute or ObjectSID and msExchangeMasterAccountSID attributes.

In an on-premises directory synchronization scenario (which Microsoft refers to as full mesh), users may be represented by several objects, such as a security principal (user account), as well as a contact object in other forests. For this scenario, you would choose to match users based on the mail attribute.

In a resource forest configuration, users typically have more than one identity: an identity in the account forest that is linked to a corresponding account in the resource forest. Typically, the account in the resource forest is set to disabled. In an Exchange resource forest scenario, the objects are linked by copying the ObjectSID value from the user object in the account forest to the msExchangeMasterAccountSID value of the user object in the resource forest. With an Exchange resource forest design, you’ll want to select the ObjectSID and msExchangeMasterAccountSID attributes option.

More Details