Introduction
After having described what a Landing Zone is and having discussed its benefits, we want to explore what components are part of a Landing Zone and where design is needed.
In detail, we want to cover the following points:
- Identity and Access Management
- Resource hierarchy
- Group creation and naming conventions
- Organizational polices
- Connectivity
- Network Design
- DNS Design
- Availability and DR Strategy
Let’s begin with Identity and Access Management
Identity and Access Management
Every Google Cloud journey starts with setting up the basic organization – and hence setting up Google Cloud Identity. Google Cloud Identity is basically free, but also has an enterprise tier with additional features. It offers a range of benefits for organizations seeking to manage user identities and access to applications and services securely:
- Centralized Identity Management: It allows for centralized management of users and groups, making it easier to control access to resources across an organization.
- Secure Access to Applications: Google Cloud Identity provides secure, single sign-on (SSO) access to both Google services and third-party applications.
- Multi-factor Authentication (MFA): It supports multi-factor authentication, which adds an extra layer of security beyond just passwords.
- Integration with Existing Identity Systems: Google Cloud Identity can be integrated with existing identity management systems, such as Microsoft Active Directory or Entra ID. This allows organizations to extend their current identity and access management (IAM) policies to Google Cloud resources without needing to manage separate IAM systems. As many companies already use Office 365 and its user management, this is a crucial factor.
- Access and Identity Governance: It offers tools for identity governance, allowing organizations to enforce policies regarding who can access what resources under what conditions. This includes setting up conditional access policies based on user attributes, device status, location, and more. Note that some of those features come in the free Cloud Identiy Edition, but some features are only within the paid edition.
- Enhanced Compliance and Reporting: It helps organizations comply with regulatory requirements by providing detailed access and activity logs. These logs can be used for auditing purposes to ensure that access policies are being followed and to investigate security incidents.
In essence, while the features of Google Cloud Identity in its paid edition are certainly worth paying, companies that do already have Microsoft Entra ID in place, for example because they use Microsoft Office 365 usually want to integrate Google Cloud Identity with Microsoft Entra ID. Fortunately, this can be done, but takes a little effort for the integration.
Entra ID and Google Identity Federation
Setting up such a federation involves two main processes:
- Provisioning users and groups: Users and groups from Microsoft Entra ID are periodically synchronized to Cloud Identity or Google Workspace. This ensures that new users in Microsoft Entra ID are also available in Google Cloud for access management, including before their first login. It also ensures that deletions in Microsoft Entra ID are propagated to Google Cloud. This provisioning is unidirectional; changes in Microsoft Entra ID are mirrored in Google Cloud but not the other way around, and passwords are not included in the synchronization.
- Single sign-on (SSO): For authentication, Google Cloud uses the Security Assertion Markup Language (SAML) protocol to delegate authentication to Microsoft Entra ID. Depending on the configuration, Microsoft Entra ID can authenticate directly, use pass-through authentication or password hash synchronization, or delegate to an on-premises AD FS server. This setup avoids the need for password synchronization and ensures enforcement of any configured security policies or multi-factor authentication (MFA) mechanisms in Microsoft Entra ID or AD FS.
The following picture depicts this integration:
One important thing to consider is the use of DNS – which plays an important role both for Entra ID and Cloud Identity. In detail, customers have to consider how to share DNS names between Entra ID and Cloud Identity.
Basically, Cloud Identity uses email addresses for identifying users, which guarantees that Google can send notifications to those users. This email address is stable and needs to be mapped to an user attribute in Entra ID. This can be the UPN or the email address itself.
When implementing the federation between these two systems, the following steps have to be done:
- Users for the automatic account provisioning must be set up and configured accordingly.
- Within Entra ID, there is an Enterprise Application for Google (Google Cloud/G Suite Connector by Microsoft), which must be configured. This involves at least the configuration of user provisioning and optionally the group provisioning. After the configuration, users and groups are synchronized with Cloud Identity.
- Single Sign-on must be set up. Once again, there is an Enterprise Application: Google Cloud/G Suite Connector by Microsoft.
- Last but not least, SSO needs to be configured in Cloud Identity.
Once everything is configured, users will be able to log in to the Google Cloud with their Entra ID credentials.
Active Directory Federation with Google Identity
In other scenarios, customers might not have Entra ID, but use Active Directory and want to use those credentials for Cloud Identity. The basic steps remain the same:
- Users and groups should be provisioned to Cloud Identity
- SSO should be configured.
To set up federation for user identity management, two main tools can be used:
1. Google Cloud Directory Sync: This is a free tool from Google that facilitates the synchronization process between your existing identity management system and Google Cloud. It operates over Secure Sockets Layer (SSL) for security and is typically deployed within your current computing infrastructure.
2. Active Directory Federation Services (AD FS): Offered by Microsoft as a component of Windows Server, AD FS allows the use of Active Directory to achieve federated authentication.
The configuration depends on the customer’s Active Directory. Many companies will have a single forest and a single domain in AD, but larger enterprises might have multiple fores. The following graphic depicts a simple scenario:
When an Active Directory forest comprises only one domain, it’s possible to link the entire forest to a singular Cloud Identity or Google Workspace account. This setup forms a unified Google Cloud organization through which all Google Cloud resources can be managed. In such a single-domain scenario, both domain controllers and global catalog servers grant access to the entirety of objects managed within Active Directory. Typically, managing this setup involves running a single instance of Google Cloud Directory Sync to synchronize user accounts and groups to Google Cloud, alongside maintaining a single AD FS instance or fleet for single sign-on functionality.
As this blog series focus on Landing Zone, we will not go into more details here and continue with resource hierarchies in the next blog post.
