adam121 - Fotolia
The AWS Directory Service enables IT teams to connect on-premises Active Directory domains to the cloud, which...
allows for greater control over hybrid cloud resources. But administrators must carefully configure networks before establishing a trust relationship -- a security principal that exists between two domains and allows one to access resources from another. The AWS Directory Service console creates and tests trust relationships with one or more existing local AD domains and cloud resources. And this integration process removes the need to create a new directory in the cloud.
The Enterprise Edition of AWS Directory Service allows IT teams to establish this connection. Developers must create and configure trust relationships between the local and cloud domains to resolve DNS queries during AWS Active Directory integration.
There are two primary types of forwarders in a trust relationship -- typical forwarders and conditional forwarders. A typical forwarder is a network server that forwards domain name system (DNS) queries for external names -- or sites -- to DNS servers outside the network. A conditional forwarder is a DNS network server that forwards queries based on the desired domain name. Trust relationships rely on conditional forwarders during the AWS Active Directory integration process.
Conditional forwarders let a network send external queries to specific, known, trusted outside DNS servers. This is usually accomplished through the Directory Service console, which can forge one-way -- incoming or outgoing -- and bi-directional trust between directories. However, administrators still need to create corresponding conditional forwarders on local DNS servers.
Once a trust relationship exists between AWS and a local AD domain, administrators can deploy workloads on AWS that depend on AD control, such as SQL Server-based applications. Local AD continues to authenticate access and enforce security over the AWS resources. New directory-aware workloads launch directly on AWS, while existing local workloads can seamlessly migrate from on-premises resources to AWS resources -- all authenticated through local user accounts in the local AD.
Matching AWS services to enterprise needs
Spin up an instance, process data in real time and manage the security of the cloud with these Amazon services. But which service performs which function? Take this quiz to test your knowledge of AWS services.
Developers must connect the local network to the Amazon Virtual Private Cloud (VPC) that contains Microsoft AD. Developers need to properly configure the VPC for inbound and outbound rules. User accounts must also have Kerberos preauthentication enabled. Next, administrators must configure conditional forwarders on the local domain and then select a suitable trust relationship password that's used when setting up the relationship during AWS Active Directory integration.
Admins need the fully qualified domain name of the trusted domain and IP address of the local DNS server. Trust must be complementary -- outgoing trust on one end must correspond to incoming trust on the other for a one-way trust relationship. Once the relationship is configured, use the AWS Directory Service console to test the relationship and make any necessary changes. If you need to remove the relationship in the future, the console can be used to delete the trust.
Tag AWS resources for audits
Know your AWS cloud directory service options
AWS Directory Service challenges Azure on apps
Dig Deeper on AWS network management
Related Q&A from Stephen J. Bigelow
Access management is critical to securing the cloud. Understand the differences between AWS IAM roles and users to properly restrict access to AWS ... Continue Reading
Containers have rapidly come into focus as a popular option for deploying applications, but they have limitations and are fundamentally different ... Continue Reading
ALM and SDLC both cover much of the same ground, such as development, testing and deployment. Where these lifecycle concepts differ is the scope of ... Continue Reading