This article draws parallels to Microsoft 365 for enterprise tenants which include tenant models, optimal networking, identity, migration and device and app management. 

When we refer to a tenant, we refer to it by the tenant ID, but it is also possible to refer to them by the host names for the tenants in the deployment. A tenant specific sub-domain is set up in this case. The tenant host name, mytenant.myservice.com must be specified as an alternative in the tenant configuration.  The URL can specify the tenant ID and the tenant host name if we specify the host names as alternative IDs for tenants.   

Optimal networking involves optimizing the path between the on-premises users, and the closest location to the Microsoft Global Network, optimizing the access for remote users over VPN, using network insights to design the network perimeter for the office locations, optimizing access to specific assets hosted on SharePoint sites with the office 365 CDN, configure proxy and network edge devices to bypass processing for Microsoft 365 trusted traffic using an allowed list of endpoints.  

Optimal networking is only the first step in tenant management.  Identity Management is the next step.  

Identity infrastructure must be configured correctly, which is vital to managing the Microsoft 365 user access and permissions for an organization.   

There are two types of identity models which are Cloud only model and Hybrid model. User accounts only exist in the Azure AD tenant for the Microsoft 365 tenant in a cloud-only model.  Hybrid accounts have user accounts both in the on-premises Active Directory domain services as well as in the Azure AD tenant.  

The hybrid identity model and directory synchronization are the most common choice for enterprise customers who are adopting Microsoft 365. There are two types of authentications when using the hybrid identity model – the managed authentication and the federated authentication.  

In the managed authentication case, Azure AD handles the authentication process by using a locally stored hashed version of the password or sends the credentials to the on-premises Active Directory Domain Services.  In the federated authentication case, Azure AD redirects the client computer requesting authentication to another identity provider.  

 

Strong sign-in is another requirement for multitenant applications. This is enforced by capabilities such as Windows Hello for Business which replaces passwords with strong two-factor authentication, Azure AD Password protection which detects and blocks known weak passwords and their variants, MFA which requires user sign-ins to be subject to another verification beyond the user account password, identity and device access configurations such as the settings and policies that include conditional access, Intune, and Azure AD identity protection policies which protect against credential compromise. 

Determining which identity model to use and how to enforce strong user and device access is critical to the identity management for tenants. Besides that, only ongoing maintenance might be required for adding or modifying user accounts and groups, and adding or modifying identity and device access configuration to enforce sign-in security requirements. 

Enterprises can manage devices and the apps used on those devices with the help of Microsoft 365 Mobile Device Management and Mobile Application Management. There are two options for device management which include Microsoft Intune, which is a comprehensive device and app management solution for enterprises and Basic mobility and security which is a subset of Intune services. Intune helps with both MDM or MAM. MDM is used when users enroll their device into Intune. After a device is enrolled, it is a managed device and can receive organization’s policies, rules and settings. MAM helps to protect the organizational applications and their data by isolating it from the personal profile for the user on their devices and requiring strong sign-ins. A set of configurations is still required above MDM and MAM to ensure a secure and productive workforce and this includes Azure AD Conditional access policies, Microsoft Intune device compliance and app protection policies, and Azure AD Identity Protection user risk policies and additional policies of cloud applications. As with identity management, device and app management also involves maintenance to manage device enrollment, and revisions to settings and policies for additional applications, devices and security requirements. 

 

The following section continues to describe the tenant management of enterprise tenants with example of Microsoft 365.

Optimal networking involves optimizing the path between the on-premises users, and the closest location to the Microsoft Global Network, optimizing the access for remote users over VPN, using network insights to design the network perimeter for the office locations, optimizing access to specific assets hosted on SharePoint sites with the office 365 CDN, configure proxy and network edge devices to bypass processing for Microsoft 365 trusted traffic using an allowed list of endpoints.

Network design tries to minimize latency by reducing round trip time between clients and network. Some networks such as the Azure Backbone network offer much lower latencies than the public internet. When the Frontdoors are placed on the internet and the tenant is placed in the Microsoft Global Network, the path and the access are optimized. Routing over the network must also be followed up with proper identification of Microsoft 365 network traffic, allowing local egress of that traffic to the internet from each location, bypassing proxies and packet inspection devices for that traffic and avoiding network hairpins.

As with all networks, some maintenance is required for optimal networking on an ongoing basis. These might include updating edge devices and deployed PAC files for changes in endpoints or verifying that the automated process works correctly, managing assets in the CDN and updating the split configuration in the VPN clients for changes in the endpoints.

Optimal networking is only the first step in tenant management.  Identity Management is the next step.

Identity infrastructure must be configured correctly, which is vital to managing the Microsoft 365 user access and permissions for an organization.

There are two types of identity models which are Cloud only model and Hybrid model. User accounts only exist in the Azure AD tenant for the Microsoft 365 tenant in a cloud-only model.  Hybrid accounts have user accounts both in the on-premises Active Directory domain services as well as in the Azure AD tenant.

The hybrid identity model and directory synchronization are the most common choice for enterprise customers who are adopting Microsoft 365. There are two types of authentications when using the hybrid identity model – the managed authentication and the federated authentication.

In the managed authentication case, Azure AD handles the authentication process by using a locally stored hashed version of the password or sends the credentials to the on-premises Active Directory Domain Services.  In the federated authentication case, Azure AD redirects the client computer requesting authentication to another identity provider.

 

A multitenant solution provider facilitates service deployments in a new cloud for tenants. This provider creates tenant certificates and provides templates for services to create their service identities. These service identities include both the managed service identity as well as service accounts. The difference between the two is in the usage where the former is system defined and automatically maintained and the latter is an exclusive credential for the service. Also, Managed Service Identity is specific to Azure Active Directory while a service account can exist in any Active Directory domain, both on-premises and in Azure.

When we refer to a tenant, we refer to it by the tenant ID, but it is also possible to refer to them by the host names for the tenants in the deployment. A tenant specific sub-domain is set up in this case. The tenant host name, mytenant.myservice.com must be specified as an alternative in the tenant configuration.  The URL can specify the tenant ID and the tenant host name if we specify the host names as alternative IDs for tenants.

Migrating certificates is easy but migrating tenant identities is not. Even though the certificates change when they have different subject names that include different domains, it is easy to create those identities in either the source or the destination clouds because they request an external certificate authority to issue it. And once issued for a specific domain, they can be added to the concerned domain wherever it is.

New clouds provide a new challenge in that the migration is not between tenants in the same solution, but the tenant identities are migrated from one cloud instance to another. Therefore, there is a source and destination instance and artifacts for a tenant that existed in one instance must have a corresponding artifact in the destination.

As with any migration, there are four phases:

A.      These include phase 1 – discover and scope, phase 2 – classify and plan, phase 3 – plan migration and testing, and phase 4 – manage and gain insight.

B.      The first phase is the process of creating an inventory of all artifacts in the ecosystem. They fall into three categories those that can be migrated, not migrated, or marked for deprecation.

C.       The second phase involves detailing the artifacts within the categories with criticality, usage, and lifespan.  It prioritizes the artifacts for migration and plans a pilot.

D.      The third phase involves planning migration and testing by communicating changes and migrating artifacts and transitioning tenants.

E.       The fourth phase involves managing and gaining insight by managing end-user and admin experiences and gaining insight into artifacts and their usages.

These four phases transition the artifacts usages from old to new smoothly.

This is a continuation in a series of articles on Multitenant Applications. The previous articles talked about tenant-to-tenant migration and this article talks about tenant management in that context.

One of the first tenant decisions is how many to have. Each tenant is distinct, unique, and separate from all other tenants. A single tenant is one that has a single Azure AD tenant, with a single set of accounts, groups, and policies. Permissions and sharing of resources are facilitated by this central identity provider. Multiple tenants are created when there is administrative isolation, decentralized IT, historical decisions, mergers, acquisitions or divestitures, clear separation of branding for a parent company, pre-production, test or sandbox tenants. Some restrictions apply in providing services to users and intertenant collaboration such as a central location for files, conversations, calendars etc. must be set up for users to collaborate more effectively.

Prior to cross-tenant migration such as for mailboxes, it was required to completely offboard a user mailbox from the current tenant to on-premises and onboard them to a new tenant. Cross-tenant migration allows administrators to move artifacts such as mailboxes with minimal dependencies in their on-premises systems.

A tenant allows a central location and one or more satellite locations to facilitate data residency in specific datacenters while the tenant information is mastered centrally and synchronized into each geo-location. When a new datacenter is added to a tenant in a new geo-location, it’s possible to migrate the organization’s core customer data at rest to the new location. Opening a new datacenter does not impact existing usages of the organization’s data.

The set of products and number of licenses for each requires some planning to ensure that there are enough licenses from the users’ accounts that need advanced features and that there are sufficient licenses but not too many unassigned licenses based on staffing.

A summary of the steps for tenant management includes how many tenants are there or needed, what products or licenses must be purchased for each tenant, whether a tenant needs to be multi-geo  to comply with data requirements, whether inter-tenant collaboration must be setup, whether one-tenant must be migrated to another and whether core data from one datacenter must be moved to a new one.

 Tenant-To-Tenant Migration architecture model (continued):

This is a continuation of the previous article on Migration architecture models. Specifically, it focuses on Microsoft365 migration, tools, and migration of on-premises tenants.

The Tenant-to-Tenant migration architecture model is one of the popular ones among several architectural approaches towards tenant management. A tenant-to-tenant migration can be single-event migration, phased migration, or tenant move or split. These are also referred to as batched migration or cutover migration.

In a single event migration, everything is migrated as a single event. There is a higher risk and a shorter timeline. When there is no strict organization and users wear multiple hats or belong to multiple project teams, it becomes hard to segregate them into migration groups.  A single event can be used to migrate all and eliminate the need for coexistence considerations. The net benefit to the users is that they keep their original email address. The drawback is that automation might rely on APIs and there might be rate limits on their invocations.

Phased migration is the gradual migration of users, services, and data. With separation into multiple migration groups, there is continuity of access for users to their emails and meetings. There is lower risk and a longer timeline. The only drawback is the coexistence limitation.  Users will have an email address in a new domain and a tool might be required to do the migration.  A variety of third-party tools are available from say Consulting Services to migrate Exchange mailboxes, public folders, SharePoint sites, OneDrive folders, Office 365 groups, while users can help themselves with native capabilities from Intune and Windows 10 such as for subscription activation license. Native tools also have their place but they make calculation for Total Cost of Ownership a bit tedious.

Since the migration tasks are complex, there may be many activities occurring simultaneously such as migration of servers and other infrastructures. Coordination to minimize effort and risk and to avoid overlap is essential. Migration might not even be scheduled in certain periods. The overall picture matters more for phased migrations. This warrants the use of an overall plan where individual projects such as Exchange, SharePoint and Teams workload migrations can be managed.

Talking to users is critical towards this purpose. Certain business functions might not even be on the plan until that occurs. Even though these might be limited in number, they matter to the overall migration.

Advanced reporting tools for large and complex projects or periodic migrations can reduce stress because they anticipate common needs and have lower maintenance than custom or ad hoc reporting. Reports also help backwards in the planning process.

As with all projects of this nature, some discretion is required between balancing migration with one or the other factors. Sometimes, a single tool helps better than having teams onboard on multiple native tools.

Migration tools like BitTitan MigrationWiz for migrating Microsoft 365, Exchange and G Suite as well as Fast Cloud File migrations for SharePoint Data are also well-known. Mover.IO is a free migration manager from Microsoft for work or school. These tools work very well for hybrid environment and tenants. When doing the migration directly, it might be better to 1) recreate the teams’ structure by adding users and permissions at the target tenant, 2) migrate content from the associated SharePoint Sites and upload to the target tenant, and 3. Export data from the Exchange mailboxes and import it into the destination. A back-of-the-envelope calculation of the time and cost would be helpful to this case.

 

Tenant-To-Tenant Migration architecture model:

Migration comes into play when there are scenarios such as mergers, acquisitions, divestitures, and others where an existing 365 tenant must be moved to a new tenant. There are dedicated personnel and consulting services to help with this migration, so it warrants a brief introduction in a book for multitenant applications.

A specific architecture model called the Tenant-to-Tenant migration architecture model is one of the popular ones among several architectural approaches towards this purpose. This model provides guidance and a starting point for planning with focus on mapping of business scenarios to architecture along with design considerations.

Let us take the traditional names of Contoso for a source tenant and Fabrikam for a target tenant.

A tenant-to-tenant migration can be single-event migration, phased migration, or tenant move or split.

In a single event migration, everything is migrated as a single event. There is a higher risk and a shorter timeline. Single-event migrations larger than 15000 users or 7 TB of site content. In this case, data volumes, network bandwidth, and helpdesk capacity can be limiting factors to scale. The next approach might be preferable when the single-event approach is limiting. Identities migrate to a target tenant and will keep the existing domain as part of the migration. The net benefit to the users is that they keep their email address as say user@contoso.com

Phased migration is the gradual migration of users, services and data. Source domains are not transferred. Users assume a new target domain.  There is lower risk and a longer timeline. The only drawback is the coexistence limitation. Identities will migrate to a new target tenant and will change the brand identity as part of the migration.  Users will have an email address as user@fabrikam.com

Tenant move or split is similar to single-event but it does not include migrating accounts to a new on-premises AD DS forest. This approach should not be used with long-term coexistence for tenant splits. There is additional work required to re-establish existing identities to the new tenant. The identities remain in the source tenant but all the users in the affected domain and all the workloads are moved to a new tenant.

The activities during migration events may vary but include the following:

Before the migration, communication is sent to each user and mailboxes and content are made read-only.

During the  migration, reverse forwarding mail is stopped and new email is allowed to be delivered to the target tenant. Target accounts are enabled, if required. The final data migration is completed.

After the migration, users must recreate their mobile profiles and the client software needs to be reconfigured which includes Outlook and Microsoft 365 clients.

The decision for the choice between the approaches depends on the factors such as if the domains in the target environment must be retained, where the environment to be migrated to is brand new, whether there is continued collaboration between the environments is expected to be in the end-state, whether there are on-premises AD domains that need to be synchronized to Azure, what workloads are being used in the source tenants, how many accounts are involved, is the mail forwarding required after migration, and whether there is a unified Global Address List required.

Reference: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN      

 

This is a continuation in a series of articles on Multitenant Applications. The previous articles talked about configuration management and this article talks about rotation of certificates. 

Multitenant solutions behave as infrastructure providers to tenants. This includes managing and maintaining secrets such as service accounts and certificates. The solution does not need to perform these duties itself and can delegate to external key management solutions for storing and rotating these secrets.  

While service accounts continue to be different from user accounts where the former represents applications and the latter represents users, the solution can register, persist, and rotate service accounts while delegating the same for user accounts to identity providers. User accounts are managed directly in the Active Directory and the solution does not interpret users; it validates assertions. Each request must assert an identity to the solution. The solution honors requests and every action is specified with the help of an API request at some level. Each request is unique, distinct, and self-contained for authentication and authorization purposes. Identity might merely an assertion in these requests.

 Service accounts are meant for interactions between tenants and their resources. A service account should never be mixed with user account otherwise they suffer many drawbacks. It should only be authorized with role-based access control otherwise any other scheme will encounter numerous items to audit. It should never be leaked, otherwise it can be abused indefinitely. This last item requires a rotation of service accounts so that the misuse of a service account is limited to its discovery an issue with the new account. The persistence of service accounts and their usage as a secret makes it valuable to an autonomous secret management system that can keep track of secrets and rotate them as necessary. The external key manager that manages keys and certificates was built for a similar purpose where the secret was a key certificate. That system can work well for a multitenant solution since it poses no restrictions on what these secrets are for.

The automation of periodic and on-demand rotation improves security and convenience for all solution provider usages. Service accounts can be backed by certificates, but the latter can be used for a wide variety of other purposes.

Certificates can be from different issuers. ACME issuer supports certificates from its server. CA supports issuing certificates using a signing key pair. Vault supports issuing certificates using a common vault. Self-signed certificates are issued privately. Venafi certificates supports issuing certificate from a cloud or a platform instance.

Although the solution manages the secrets, a consolidator can help with specific secret types. The libraries for this such as for certificate management are quite popular and well documented.   The use of libraries also brings down the code in the application to manage these specific types of secrets. The external dependencies for generating secrets are like any other dependency in the application code so these can be registered and maintained in one registry or container.

A self-signed certificate is one that is signed with its own private key. Generating a private key and public key is trivial for tools like openssl with the “–t rsa” command line option. For now, let’s look at the steps for self-signing. First, we generate a public-private key pair. Then we create the X509 certificate. Then we sign the certificate with its private key and providing the certificate to sign as well as the certificate with which to sign as the one we just created. 

Algorithms used for creating the keys are called digital signature algorithms. There are two kinds of encryption algorithms - RSA and ECDSA. In both cases, a message signed with the public key can only be opened with the help of the corresponding private key. RSA has historically been more popular with ECDSA gaining support only recently. They are usually compared in terms of bits to denote their security level. Bits is the number of steps taken before an attacker can compromise the security. A 2048-bit RSA public key has a security level of 112 bits. ECDSA needs only 224-bit sized public keys to provide the same security level which provides efficiency for storage. Signing and verification of the signature constitute the two most costly steps performed. The input size plays into this cost for embedded devices.  

The keystore and truststore can be one and the same if the connections are internal. In this case, the client and the server share the same key-certificate. On the other hand, mutual authentication is one where the server and the client present different certificates. In this sequence of message exchanges for mutual authentication between the server and the client, the server initiates the messages. First, the server sends hello message.  Next it sends the certificate, followed by a request to get the client’s certificate and lastly the server-side hello done message. The client responds first with its certificate. Then it sends the session key with the client key exchange message. Then it sends the certificate verify message and changes the cipher spec. Lastly it sends the client-side finished message. The server closes the mutual authentication with the cipher changed message and the server-side finished message.