Navigating Windows Workload Modernization without Active Directory

AWS Customers often migrate Windows workloads to AWS using a lift-and-shift or modernization strategy. Modernizing is a popular choice due to the opportunity to use purpose-built cloud services and reduce TCO by lowering operational overhead and licensing costs. While modernizing, customers often need to evaluate whether they still require Microsoft Active Directory (AD) services which are part of their existing Windows Workloads or they desire to reduce their dependency on AD as part of their modernization journey.

In this article we discuss migration and modernization considerations for Windows OS based workloads that are integrated with AD and the feasibility of removing the dependency of AD for these workloads. We identify the features that are provided by AD and the reasons why customers often want to reduce their workload dependency on AD. We then provide guidance on how to categorize your applications for different modernization approaches and refer to appropriate tools and techniques that help facilitate these migrations.

Features provided by Active Directory

AD is mainly used to authenticate and to authorize users to access corporate resources such as servers, databases and applications. Windows Servers are joined to AD so workloads installed on those servers potentially use AD to perform the following:

• Authentication – if an application uses Windows native authentication and the server is joined to AD, applications can authenticate users seamlessly without an additional login prompt.
• Authorization – applications can query an AD users group membership to authorize access to a resource.
• File Access – applications can access file shares over the SMB protocol using AD authorization seamlessly.
• Printing – applications can use networked printers as these commonly also use the SMB protocol which is authorized using AD.
• Email – applications can access mailbox and email services hosted on Microsoft Exchange using AD.
• Application to database communication – Windows workloads commonly authenticate seamlessly to Microsoft SQL servers using Active Directory.

When modernizing Microsoft Workloads without AD, these features need to be discovered and refactored if still required.

Modern Cloud native alternatives to Active Directory

In many cases we see our customers Active Directory grew over decades to a monolithic system that does not serve modern applications in a secure, scalable and cost-effective way due to its architecture (for example, a domain controller is needed in multiple locations). Also, companies have already started to setup and run their directory services in the Cloud to serve modern applications from a central place. Services like AWS Identity Center, Ping Identity, OneLogin and Azure AD are examples of Cloud based directory services (note: even though the name may indicate a similarity between Microsoft Active Directory and Azure AD (Microsoft Entra ID), these are two separate services and Azure AD doesn’t provide the same AD services we mentioned in the section Features provided by Active Directory. Even though there are ways to synchronize your Cloud based directory with AD, we see many customers would like to consolidate to one identify service and desire to sundown their AD.

Replacing services provided by Active Directory

We mentioned above the main services that are provided by Active Directory. Here are a list of cloud-native protocols you can implement in your workload to replace functionality currently provided by Active Directory:

• Authentication/Authorization – we’d replace the AD Kerberos authentication with modern cloud scale authentication mechanisms like Security Assertion Markup Language (SAML) or Open ID Connect (OIDC). While SAML also manages authorization, OIDC focuses on authentication. To manage authorization, OIDC is typically combined with Open Authorization (OAuth).
• File Access – Since SMB file shares integrate with AD, you can change your applications to store data on S3 which is fully integrated with AWS IAM. Other solutions like Dropbox or Box provide a filesystem like access but using object storage as the backend but using OIDC/OAuth or SAML for authentication and authorization. The AWS Marketplace offers a variety of file sharing services that provide enterprise ready file sharing solutions without using the SMB protocol and AD integration for example Cloudberry Drive.
• Printing – There are many print service solutions that don’t require AD integration and instead use modern protocols such as OAuth. Examples are CUPS, PaperCut NG or PrintNode. A SaaS solution is offered by PrinterLogic and offered as serverless deployment through the AWS Marketplace.
• Email – For Microsoft Exchange on-premise, OAuth 2.0 is supported as part of Microsoft’s “Hybrid Modern Authentication (MA)”. However, this still needs Active Directory Federation Services to work. Microsoft Exchange Online does also supports OAuth 2.0 as part of what Microsoft calls the “Modern Authentication (MA)” but it is still tightly integrated with Azure AD. So if you want to retire AD and have no intentions to use Azure AD as you Identity provider, you must consider to repurchase another solution.
• Application to database communication – Microsoft SQL server allows different methods for authentication and don’t require AD integration. This article describes the authentication modes.

AWS customers can use AWS IAM Identity Center to manage their identities. IAM Identity Center is built on top of AWS Identity and Access Management (IAM) to simplify access management to multiple AWS accounts, AWS services and resources (e.g. Amazon EC2 instances and Amazon S3 buckets) and SAML-enabled cloud applications.

IAM Identity Center can federate identities from your existing workforce identity provider, such as Okta, Ping, or Azure AD using industry standard SAML and SCIM protocols.

Single Sign on for Amazon EC2-Windows instances without AD

If at the end of the whole migration assessment you find that you still have to run Windows systems, you also want to make sure your users have a Single Sign on experience even without your Windows server being joined to an AD domain. The article How to enable secure seamless single sign-on to Amazon EC2 Windows instances with AWS IAM Identity Center explains the architecture that uses AWS IAM Identity Center and the AWS Systems Manager Fleet Manager to accomplish that. You can either manage your user and groups directly in AWS Identity Center or integrate with any of the supported identity providers such as Okta, Ping, OneLogin, Azure AD etc. This approach provides a central place to manage your users, groups, permissions and roles without Active Directory.

Another thing that you need to consider is how you would deal with Group policies that a Domain Controller provides. A good way to replace that would be by using AWS Systems Manager State Manger that applies Desired State Configurations for your Windows Systems to a fleet of Instances. For more information see the Walkthrough of Creating associations that run MOF files.

Migration Approaches

For the purpose of how to migrate into a non-AD environment, we categorize the application types and discuss the “R” strategy which is used, See 7 Strategies for Migrating Application to the Cloud to learn more about the different “R” strategies

Consumer off the shelf apps & Desktop Services

Consumer applications can support a variety of authentication and authorization methods. You need to check if the application is relying on native Active Directory features to perform its tasks. On a windows server you can determine this by checking if the application service is using an AD user

Figure 1 – Services management console.

If the application does not use an AD user you can be confident on running the software on a server not joined to AD. If the application is using an AD user then you must consult the vendor or documentation for alternative mechanisms for the domain features.

For authentication, this could be OIDC instead of Kerberos or the above-mentioned method using IAM Identity Center and Fleet Manager.

File access via SMB shares could be replaced with solutions like Amazon Workdocs Drive, Dropbox or S3. These Services integrate with an external IDP to grant file- or directory level permissions.

Jump Servers or Bastian Hosts can be securely replaced by AWS native services such as AWS Systems Manager Session Manager.

Desktop Apps: Commonly Windows is used to provide a GUI environment for users to perform application administration/maintenance or reduce latency to the backend. AWS offers end user Compute services such as AWS Appstream to provide modern desktop applications with GUI environments. These integrate with OIDC/OAuth for authentication/authorization.

E-Mail: if an application needs to send E-Mails, AWS Simple Email Service (SES) can be used. If an application needs to access a Microsoft Exchange Mailbox, OIDC authentication should be used instead of Kerberos.

Databases

Active Directory authentication is commonly used with Microsoft SQL server and it is possible other DB engines are configured to use Active Directory for authentication. Changing the authentication method to the database is usually a minor configuration change to the software. Other DB engines like Oracle can support IAM database authentication or Password authentication with passwords stored safely in AWS Secrets Manager.

Apart from authentication, keep an eye out for applications which use SQL Server to send email (look for stored procedures using sp_send_dbmail) or write files to a file share, these may use Active Directory and therefore need refactoring.

In the spirit of modernization, while assessing your use of Microsoft SQL server, use the Babelfish tool to check if the database is compatible to run on Amazon Aurora PostgreSQL using Babelfish to reduce the licensing cost for your database.

In-house developed Applications

With your applications developed In-house you are free to make changes as required but making significant changes has a cost in terms of time, effort and complexity to change. If your application is using native AD integration for authentication within Windows (common in .Net Framework and IIS applications), the effort of implementing alternative mechanisms (eg OIDC authentication flows) can be significant. If significant refactoring is required you might want to consider adopting a microservice architecture, see Monolithic to Microservice Journey
for .NET Applications and the AWS Modernization Calculator for Microsoft Workloads for help on how you can transform your applications into modern architectures.

Also see the Decision Matrix in AWS Prescriptive Guidance which goes into more details regarding modernization approaches and considerations regarding .NET applications

Cross platform code eg Java or .NET core can be recompiled to run on Linux. These applications commonly do not use native AD integration due to their cross-platform architecture. You can use AWS App2Container for analyzing your applications, extract dependencies and build docker images as well as creating an inventory of applications running in bare metal, virtual machines, Amazon Elastic Compute Cloud (EC2) instances, or in the cloud.

A Decision Flow

The following decision diagram and tables can guide you through the different questions to ask, categorize your applications and migration options to consider:

Figure 2 – Migration path flowchart.

Consumer off the shelf apps & Desktop Services

Databases

Inhouse Apps

Plan B: What if you cannot (yet) run without AD

If, after the assessment of your landscape, you find yourself in the situation that you cannot (yet) retire Active Directory, with AWS Directory Services, you can spin up an AWS managed Microsoft AD in the cloud. It can be configured with a one-way or two-way trust to your on-premise AD. You can configure it as a resource forest that contains primarily computers and groups with trust relationships to your on-premises directory. This enables your users to access AWS applications and resources with their on-premises AD credentials.

If you want your users to be able to single sign on to the AWS console and services, you can also decide to configure your AD as the external provider in AWS Identity Center. However, this step should be taken with care if you plan to retire your AD soon. Changing the source in Identity Center to something else later on, all user and group assignments are removed and needed to be re-applied after the change.

For further guidance of how to migrate Active Directory to AWS, see AWS prescriptive guidance – Migrating Active Directory.

Summary

In this article we discussed some considerations and strategies for migrating and modernizing Windows workloads into a non-AD landscape. We highlighted the features provided by AD which need to be addressed when modernizing workloads.

We highlighted replacement options and migration approaches for AD services, including modern authentication mechanisms like SAML and OIDC, alternative file access solutions and non-AD integrated print services. We then detailed an approach to assessing which migration method is possible and the potential effort involved.

Please refer to Windows on AWS to find more resources for migrating and modernizing your Windows workloads

Further Reading:

7 Strategies for Migrating Application to the Cloud

About the Authors