Microsoft makes it easy to synchronize Active Directory (AD) identities to Entra ID (formerly Azure Active Directory). However, if organizations don’t properly plan the synchronization solution for their cloud identities, which Microsoft calls Entra ID Connect, users will have poor experiences in the cloud. Because identity is central to security in the cloud, it’s critical to properly plan and implement Entra ID Connect.
Although not discussed in this blog post, it’s also critical to properly architect an identity life cycle management solution. Poor identity life cycle management in AD results in poor identity life cycle management in Entra ID, so an organization must get AD management in-check before implementing a hybrid sync solution. Simply reading Microsoft’s documentation will provide a basic foothold in understanding the many facets of Entra ID Connect.
Preparation and Installation with a Security-Driven Mindset
Before installing Microsoft Entra Connect, you should use a tool called IdFix to identify which AD objects will have problems syncing to Entra ID. IdFix can also help you determine whether there will be a cloud sync issue because of duplicate objects, conflicting attribute values, invalid characters, or one of many other potential issues.
For security and management reasons, you shouldn’t install Entra ID Connect on a domain controller (DC). Instead, install the software on a Windows server that is used only for Entra ID Connect. Apply the same security measures to this system as to your DCs.
Choosing the In-Scope Accounts to Synchronize
Partner with Microsoft experts you can trust
If it’s time to take that first step toward leveling up your organization’s security, get in touch with Ravenswood to start the conversation.
Microsoft makes it easy to implement Microsoft Entra ID Connect and make decisions on behalf of the administrator during installation. Unfortunately, organizations lose some control when they use Microsoft’s express installation settings. For example, when you select the express installation option, the in-scope objects in all organizational units (OUs) in AD get synchronized to Entra ID. Fortunately, you can very easily fix this retroactively so that you can be selective over which objects are synchronized to Entra ID. If the scope of OUs being synced changes, a full import and full sync (initial sync) must be performed.
You should consider whether synchronizing service accounts to Entra ID presents an unacceptable risk. Unfortunately, the express installation of Entra ID Connect will synchronize all user objects from AD to Entra ID, which includes user accounts acting as service accounts. Service accounts commonly have very weak passwords that don’t change often. A bad actor could have a successful password spray attack on such a service account, which—due to the nature of the hybrid identity—could provide an escalation path in AD.
Instead of using hybrid synchronized service accounts to perform automation tasks in Entra ID, use a service principal with the Graph API wherever required. Ensure that any relevant Graph API permissions are delegated appropriately to the registered app using the principle of least privilege. Alternatively, use accounts with certificate-based authentication only when it’s necessary to have a service account be a hybrid identity. Keep in mind that some solutions really do require an on-premises identity to sync to Entra ID, such as the service account used for the Microsoft Information Protection (MIP) scanner.
Choosing an Authentication Method
All organizations should implement password hash synchronization (PHS) to keep up with end user experience expectations that “everything should just work.” Implementing PHS minimizes infrastructure footprint and complexity. With PHS, users will authenticate directly with Entra ID instead of AD. There are no known security issues with syncing a hash of a salted password hash from AD. Other user authentication options available are pass-through authentication (PTA) and federation, such as AD Federation Services (AD FS). PTA may be employed by an organization if there is a compliance requirement to authenticate users with on-premises identity solutions such as AD. Even when PTA or federation is chosen as the authentication method, PHS should still be employed so that the leaked credentials report can be used and to have a disaster recovery option if all on-premises authentication systems become unavailable.
Organizations that can’t implement PHS due to industry compliance requirements or restrictions should instead implement PTA. Federation should be used only as a last resort. Even if an organization has a federation system already in place, it’s strongly recommended to not use this as a solution for user authentication to Entra ID—even if doing so seems to be more convenient for the administrator. Federation systems are inherently more complex to manage and maintain and cause large impacts to populations of users when there is an outage with the federation service. Microsoft has provided guidance for migrating certain apps from AD FS to Entra ID —namely, Software as a Service (SaaS) single sign-on (SSO) apps that use Security Assertion Markup Language (SAML) and Web Services Federation (WS-Fed) for authentication. Entra ID is highly available, with a 99.99% service level agreement (SLA), and takes most of the complexity out of configuring SSO apps for many of the SaaS-based SAML and WS-Fed apps that exist.
Full vs. Express Installations for Entra ID Connect
Although using an express installation for Entra ID Connect is convenient for administrators, doing so presents potential security risks. Express installations result in some accounts being synchronized to Entra ID that shouldn’t exist in AD—or that you don’t want to exist in Entra ID. Using the full installation takes longer but is much safer.
Need help with Entra ID Connect or any other facet of Active Directory? Ravenswood Technology Group has the expertise you’re looking for. Contact us today.
