Migrating to Entra ID in GCC High for Enhanced Compliance and Security

How to transition your identity management from Microsoft 365 commercial or local Active Directory to Entra ID in GCC High

If you are a government contractor or a federal agency that needs to comply with the Defense Federal Acquisition Regulation Supplement (DFARS) or the Cybersecurity Maturity Model Certification (CMMC), you may be considering moving your Microsoft 365 environment to GCC High. GCC High is a cloud offering designed for US government entities and their partners that handle controlled unclassified information (CUI). One of the main challenges of migrating to GCC High is how to manage your identity and access across different domains and platforms. In this blog post, we will explore some of the key scenarios and solutions for identity migrations to Entra ID in GCC High.

What is Entra ID?

Entra ID is a cloud-based identity and access management (IAM) solution that simplifies and secures your identity lifecycle in GCC High. Entra ID (formerly named Azure Active Directory) supports seamless integration with Microsoft 365, Azure, and other cloud and on-premises applications. Entra ID also provides advanced features such as multi-factor authentication (MFA), single sign-on (SSO), conditional access, identity governance, and privileged access management (PAM).

Why use Entra ID for identity migrations to GCC High?

Entra ID offers several benefits for identity migrations to GCC High, such as:

  • Reduced complexity and cost: Entra ID eliminates the need for multiple identity systems and synchronizations, and simplifies the migration process by automating the provisioning, deprovisioning, and updating of user accounts and groups.
  • Improved security and compliance: Entra ID enforces strong authentication and authorization policies, and helps you meet the security requirements of DFARS and CMMC by providing audit trails, reports, and alerts.
  • Enhanced user experience and productivity: Entra ID enables users to access all their applications and resources with one username and password, and reduces the risk of account lockouts, password resets, and help desk calls.

Identity Terminology is Critical

When dealing in the identity world, it’s critical that everyone from executive stakeholders to the IT Team use the exact same terminology. Frequently, we see many people call most things involved with identity as “login” or “username”, but this oversimplifies what identity is doing and can create many frustrating conversation and missed expectations.

Here are some examples of key attribute names associated with identities and how/where they are applied.

Attribute NameExampleSystemsUsage
Display NameJane DoeMajority of all providersFriendly full name . Used in email display name
samAccountNamejdoe OR md######Local Active DirectoryLogin: Legacy Windows ( i.e. domain2\ jdoe OR domain2\ mdxxxxxx )
userPrincipalNamejdoe OR md######@othermail.orgLocal Active Directory Entra IDLogin: Email style
proxyAddressesjdoe@othermail.com OR @othermail2.comLocal Active Directory Entra IDCollection of email addresses
GUID6ade9daf-92f5-4e4f-9e8f-3cb89ba157b0Local Active Directory Enta IDUnique ID that’s used to find and bind to objects in multiple systems
SecurityIdentifier (SID)S-1-5-32-544Local Active DirectorySecurity identifier is used to uniquely identify a security principal or security group
OnPremisesSecurityIdentifierS-1-5-32-544Azure Active DirectorySynced copy of the users SID
Immutable ID AnchorLocal Active Directory Entra IDValue stored in local AD, used by Azure AD Connect, and stored within Azure AD to “bind” objects (users, groups, and devices)

If you’re migrating from an existing local Windows Active Directory and migrating to Entra ID within GCC High, understanding those key attributes will be important.

Security and Compliance

While the migration process is a considerable project depending on the complexity of your existing environment, let’s not lose sight of both the compliance requirements for which you going into GCC High and ensuring that the migration is going to land you in an environment that can pass an audit.

This includes having the associated licensing, configuration, and policies to support the environments key objectives. Many organizations often have existing Managed Service Providers to manage and provide remote support and/or their own IT staff are using third-party tools for IT Management & Monitoring Services and Remote Desktop Management. As users, applications, Windows client devices and more transition to work within Microsoft 365 GCC High and Azure Government, those vendors and applications should be assessed to ensure they also meet the requirements as they may be required to participate in the audit.

If you’re diving into the Microsoft 365 GCC High ecosystem, you may decide to leverage the capabilities of your licensing, or expand, to meet the overall compliance requirements.

Windows client desktops (e.g., Windows 11)

Most customers moving to GCC High have Windows clients in their environment. In this environment, we mostly see that the organization is managing their users and desktops (and often much more) using Local Windows Active Directory and maybe syncing with Entra ID (Azure Active Directory).

In either case, when migrating these Windows clients to a GCC High environment, there is a big change occurring to those Windows clients. Keep in mind that the Windows client also has its own identity with the associated identity provider. Thus, when it’s time to migrate the device, it will be leaving one or more identity providers and joining a new one.

Existing Identity Services (aka Source)

Many customers we see have typically lived within the same identity configuration for years and have customized it along the way. This often leads to technical debt, lack of well documented and understood configurations, and a ghost town of scripts, tools, and settings.

While there are some common starting points, every current/existing environment is different. That said, let’s start with some common identity starting points and what to consider for a migration.

  1. Local Windows Active Directory Domain Services
  2. Entra ID/Microsoft 365/Azure Active Directory: Cloud Only
  3. Local Windows Active Directory with Entra ID: Hybrid Identity
  4. Local Windows Active Directory with Entra ID: Hybrid Identity & Desktop
  5. Local Windows Active Directory with Entra ID: Hybrid Identity, Desktop, & Exchange

Local Windows Active Directory Domain Services

Local Windows Active Directory Domain Services (AD DS) is a scenario where you have a local Windows Server running the AD DS role, which provides identity and access management for your network. You can create and manage users, groups, computers, and other objects in your domain, and apply policies and permissions to them. Your Windows clients are joined to this domain and authenticate with it.

Local Windows Active Directory Domain Services

Entra ID: Cloud Only

Let’s say your organization was born in the cloud and you don’t have a local Windows Active Directory environment, and all your users and devices are managed within an existing Entra ID environment. And thus your Windows clients are directly joined and simply look like this:

Entra ID: Cloud Only

In this case, here are some considerations when planning your migration:

  1. Custom Domain

    a. Regardless of your use of Exchange Online for email or not, you might have registered your business email address (e.g. contoso.com) with Entra ID and all of your users have that domain assigned when they login via Entra id (e.g. myuser.name@contoso.com)

    b. To use this same custom domain within your new Entra ID tenant for Microsoft 365 GCC High, the custom domain in your source environment must be completely removed

    c. This can impact email routing and more, but this risk can be mitigated with proper planning, communication, and scheduling

  2. Users and Groups

    a. Since Users passwords are firmly managed within Entra ID, those users will have to get new passwords and configure their multifactor authentication in the target tenant

    b. Users and groups can be created manually or via automation

  3. Windows Client Migration (aka desktops)

    a. Desktops that are directly connected to Entra ID will need to leave the current tenant and then join the new one

    b. During the transition, those devices will be in a “workgroup” and are in a vulnerable state as they frequently will also be without encrypted disks, protected by Microsoft Defender, and more

Local Windows Active Directory with Entra ID: Hybrid Identity

Having only a local AD DS environment can limit your ability to leverage cloud-based services and applications, such as Microsoft 365 or Azure. You’ve already deployed a hybrid identity solution, to synchronize your local AD DS users and groups with Entra ID, which is a cloud-based identity platform that offers single sign-on, multi-factor authentication, and identity protection.

The term “Hybrid” is thrown around a lot, so let’s split it up a bit:

  1. Hybrid Identity – Local Windows Active Directory users and groups synced with Entra ID
  2. Hybrid Windows clients – Windows clients that are Local Windows Active Directory joined and synced with Entra ID
  3. Hybrid Exchange – An Exchange Environment is still in production within the on-premises environment and has one server that has been configured for Hybrid Exchange connectivity with Exchange Online
  4. Hybrid SharePoint – Configuration of an On-premises SharePoint Environment that creates several integration points between SharePoint Server and SharePoint Online
  5. Hybrid Servers – Infrastructure management and monitoring of Linux, Windows servers, Windows IoT, and Windows client (if acting as an always on production service) while on-premises, datacenter, or non-Azure cloud provider (Google Cloud Platform, Amazon Web Services, etc.)

For now, let’s focus on the Hybrid Identity and Hybrid Windows clients.

Local Windows Active Directory with Entra ID: Hybrid Identity

In the above scenario, we have both Windows clients deployments where most desktops are directly joined to local Active Directory and a few that are directly joined to Entra ID.

In both deployments, we need to still migrate them to the new Entra ID within GCC High.

Servers/Applications

This topic alone is tremendously complex. We won’t cover this here, but understanding that many applications and they compute they run on often have their own identity within a local Windows Active Directory environment. This is part of the identity and security chain as users on a desktop consume services from those applications and servers.

Servers/Applications

Let’s take an example of a user who logs on to a Windows client that is joined to local Windows Active Directory and using their browser connects to a web-based ERP application. When the user connects to the web application, the user does not have to login. This is because the application is running on an IIS web server that has been configured with Integrated Authentication with local Windows Active Directory.

 local Windows Active Directory.

At this point, let’s say your Windows clients and users have been migrated into Microsoft 365 GCC High and you organization has decided to no longer have a local Windows Active Directory environment. Yet, the ERP system still requires this level of integration. This is where Entra Domain Services comes into play as it’s a Microsoft managed Windows Active Directory environment that is synced from Entra ID.

Entra Domain Services will include syncing the sidHistory of users from Entra ID (previous configuration and validation is required) into Entra Domain Services and thus will be available to applications that leveraged that immutable attribute from those users as they once had them when the organization did have local Windows Active Directory.

Microsoft 365

Some application won’t need this level of deployment, and you might not need to move your services or remove your local Windows Active Directory if your environment can meet the compliance requirements already (or at least until you’re ready).

Files

With our focus on Identity migration, we can’t forget that many organizations have files that are permissioned based on user and group identities. Typically, this is found with File Servers running on a Windows Server with File Shares or Distributed File System, Network Attached Storage, or content management system like SharePoint Server. While there are also cloud providers (E.g. Box) that provide file services mapped to your users identities, those align closer to the SaaS Applications which is covered in the next section.

One principal method of defining permissions on folders and files is the use of Access Control Lists (ACLs), which specify the permissions for each user or group on a given resource. However, there are different protocols and standards for implementing file sharing across different platforms and networks. Two common ones are NTFS and CIFS.

NTFS stands for New Technology File System, and it is the standard file system used by Windows operating systems since Windows NT 3.1. NTFS supports various features such as encryption, compression, hard links, journaling, and security descriptors. NTFS uses ACLs to define the permissions for each file and folder, which can be inherited from parent folders or explicitly set by the owner or administrator. NTFS also supports share-level permissions, which are applied to the entire file share and can restrict access based on user accounts or passwords.

CIFS stands for Common Internet File System, and it is a network protocol that allows file sharing between different operating systems and devices over a network. CIFS is based on the older Server Message Block (SMB) protocol, which was originally developed by IBM and Microsoft in the 1980s. CIFS enables users to access files and folders on a remote server as if they were local, using standard file operations such as read, write, create, delete, and rename. CIFS also supports various features such as authentication, locking, notifications, and browsing. CIFS uses both share-level and file-level permissions, which are determined by the server’s configuration and the client’s request.

The following table summarizes some of the similarities and differences between NTFS and CIFS:

AspectNTFSCIFS
File system or protocolFile systemProtocol
Operating systemWindowsWindows, Linux, Unix, macOS, etc.
Network supportNo (local only)Yes (over TCP/IP)
Permissions modelACLsACLs and share-level
Security featuresEncryption, compression, journaling, etc.Authentication, locking, notifications, etc.

When migrating your files to the cloud, identifying, modifying, and/or maintaining file permissions is an important and often overlooked activity. Depending on the source location of the files, target locations (e.g. Azure File, Azure File Sync, Microsoft Teams, OneDrive, Team, etc.), and the method of migration an have a profound impact on what must be configured in your overall Identity environment to support your desired/required file permissions.

SaaS Applications

Entra ID within Microsoft 365 GCC has may of the Single Sign On (SSO) capabilities found in the Microsoft 365 Global (aka commercial) environment. However, there is one significant difference which is the API endpoints. That could impact connecting with some vendors as they may not support that level of integration, let alone be able to support and meet the requirements of CMMC or ITAR depending on what their service is intended to be used for.

For internally developed applications that integrated with Entra ID, SharePoint Online, Teams, and more, those application registrations within the new GCC High environment will need to be created and API’s tested. Furthermore, the IT and Development team should assess any Api consents for those applications to ensure they also are meeting the compliance requirements. This includes defining and managing those identities, services, and integration that align with Microsoft Cloud Adoption Framework (CAF) which provides patterns for separation of concerns.

Conclusion

dentity migrations to GCC High can be complex and challenging, but Entra ID can make them easier and faster. Entra ID is a cloud-based IAM solution that simplifies and secures your identity lifecycle in GCC High. Entra ID supports various identity scenarios and solutions, and helps you migrate your identity from Microsoft 365 commercial or local AD to AAD in GCC High. Entra ID also provides advanced features such as MFA, SSO, conditional access, identity governance, and PAM.

If you are interested in learning more about Entra ID and how it can help you with your identity migrations to GCC High, please contact us ….

Published on: .

How can we help?

Loading...

Let's start a conversation

location Agile IT Headquarters
4660 La Jolla Village Drive #100
San Diego, CA 92122

telephone-icon + 1 (619) 292-0800 mail-icon Sales@AgileIT.com

Don’t want to wait for us to get back to you?