Microsoft makes it easy to synchronize Active Directory (AD) identities to Azure AD. However, if organizations don’t properly plan the synchronization solution for their cloud identities, which Microsoft calls Azure AD 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 Azure AD 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 Azure AD, 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 Azure AD Connect.
Preparation and Installation with a Security-Driven Mindset
Before installing Azure AD Connect, you should use a tool called IdFix to identify which AD objects will have problems syncing to Azure AD. IdFix can also help you determine whether there will be a 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 Azure AD Connect on a domain controller (DC). Instead, install the software on a server that is used only for Azure AD Connect. Apply the same security measures to this system as to your DCs.
Choosing the In-Scope Accounts to Synchronize
Microsoft makes it easy to implement Azure AD 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 Azure AD. Fortunately, you can very easily fix this retroactively so that you can be selective over which objects are synchronized to Azure AD. 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 Azure AD presents an unacceptable risk. Unfortunately, the express installation of Azure AD Connect will synchronize all user objects from AD to Azure AD, 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 Azure AD, 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 Azure AD, such as the service account used for the Azure Information Protection (AIP) 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 Azure AD 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 Azure AD—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 Azure AD—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. Azure AD is highly available, with a 99.99% service level agreement (SLA), and takes most of the complexity out of configurating SSO apps for many of the SaaS-based SAML and WS-Fed apps that exist.
Full vs. Express Installations for Azure AD Connect
Although using an express installation for Azure AD Connect is convenient for administrators, doing so presents potential security risks. Express installations result in some accounts being synchronized to Azure AD that shouldn’t exist in AD—or that you don’t want to exist in Azure AD. Using the full installation takes longer but is much safer.
Need help with Azure AD Connect or any other facet of Active Directory? Ravenswood Technology Group has the expertise you’re looking for. Contact us today.