Active Directory (AD) is essential for Windows workloads in the cloud. AWS offers customers multiple ways to integrate AD with cloud workloads like EC2, RDS, and AWS Enterprise Applications: AWS Directory Service for Microsoft Active Directory (Enterprise Edition) as a managed service and Active Directory running on AWS EC2 Windows instances. Which option is right for you? This session will discuss the key deployment considerations for each option to help you identify which best meets your project goals, and the effort involved. The session will cover options for integrating with your on-premises directory, port and security considerations, application considerations, and best practices.
The Ten Facts About People With Autism Presentation
Best Practices for Integrating Active Directory with AWS Workloads
1. Best Practices for Active Directory
with AWS Workloads
Ron Cully, Senior Product Manager
AWS Directory Service
2. What to Expect from the Session
Models – how AD is used (why is AD relevant in the cloud)
Options – AD deployment for Windows workloads in cloud
How to choose – considerations for selection
9. Options – AD deployment for Windows
workloads in cloud
10. AD Options – On-premises
• Create VPN or Amazon Direct
Connect link to your VPC
• Manually domain join EC2 instances
to on-premises
• Use VPC as an extension of your
network
– Security considerations
• Latency considerations?
On-premises
Windows Server DC
AD
You Manage
1
DC – Active Directory Domain Controller
VPC – Amazon Virtual Private Cloud
Endpoint – Accessed via IP address in your VPC
Generally accepted as a bad idea
11. AD Options – EC2 Self-managed
• Your responsibilities
– Availability deployment strategy
– EC2 DC configuration
• DNS configuration
• Sites & Services configuration
– Monitoring
– DC recovery
– Backup
– Restore
– Security group configuration
– Manual EC2 domain joining
– Patch Tuesday management
Microsoft AD w/trust to your AD required to support WorkSpaces, QuickSight, or Chime
On-premises
Windows Server DC
AD
You Manage
1
VPC
EC2 Windows
Server DC
AD
You Manage
2
12. AD Options – Where to run AD
On-premises
Windows Server DC
AD
You Manage
1
VPC
EC2 Windows
Server DC
AD
You Manage
2
VPC Endpoint
EC2 Windows
Server DC
AWS Manages
3
AWS Directory Service
for Microsoft Active Directory
(Enterprise Edition)
a.k.a. “Microsoft AD”
DC – Active Directory Domain Controller
VPC – Amazon Virtual Private Cloud
Endpoint – Accessed via IP address in your VPC
13. AD Options – “Microsoft AD”
• Windows 2012 R2 domain controllers (DC)
– ~3-click set-up
– 2 DCs each in a different Availability Zone (AZ)
• Stand-alone or connected to your AD w/trusts
• AWS apps and services integration
– EC2 seamless domain join
– RDS SQL Server authentication, authorization
– WorkSpaces, QuickSight Enterprise, Chime Plus/Pro
provisioning & authentication
• Some constraints
– AWS is domain admin
– You get an OU and delegated admin over the OU
– AWS apps/services/EC21 must be in same VPC
– Conservative delegated permissions2 to you
• Application enablement limits some apps
• Some admin functions unavailable
VPC Endpoint
EC2 Windows
Server DC
AWS Directory Service
for Microsoft Active Directory
(Enterprise Edition)
a.k.a. “Microsoft AD”
1EC2 can domain join manually in peered VPC configurations
2Delegations are being expanded over time
• Amazon responsibilities - Operate
– Patch, monitor, DC recovery, snap-
shot, restore
• Your responsibilities - Administer
– Administration via Active Directory
Users and Computers (ADUC) and
other standard AD tools
– Administer users, groups, GPOs,
other AD content
14. AD Options – Connecting AD in cloud to on-pemises AD
1
Replication
Your DCs only
On-premises
Windows Server DC
AD
VPC
EC2 Windows
Server DC
AD
On-premises
Windows Server DC
AD
VPC
EC2 Windows
Server DC
AD2
1-way Trust
2-way Trust
Your DCs or
Microsoft AD
On-premises
Windows Server DC
AD
VPC
EC2 Windows
Server DC
AD3
Sync Users Depends
(3rd party sync)
16. Availability Zone
Private Subnet
10.0.2.0/24
DBAPPWEB
SQL
Server
App
Server
IIS
Server
Availability Zone
Private Subnet
10.0.3.0/24
DBAPPWEB
SQL
Server
App
Server
IIS
Server
Remote
Users / Admins
Domain
Controllers
corporate data center
Example: AD on
EC2 with replication
or AD trust
Domain
Controller
Domain
Controller
Trust or Replication
Auth/
LDAP
Auth/
LDAP
Application
Auth/
LDAP
VPN
Direct
Connect
AD
EC2
AD
EC2
AD
17. Auth/
LDAP
Auth/
LDAP
DB
RDS
SQL Server
Availability Zone
Private Subnet
10.0.2.0/24
APPWEB
App
Server
IIS
Server
Availability Zone
Private Subnet
10.0.3.0/24
APPWEB
App
Server
IIS
Server
Remote
Users / Admins
Domain
Controllers
corporate data center
Example: AWS
Microsoft AD with
AD trust to on-prem
DB
RDS
SQL Server
AWS Managed Services
AWS Managed Services
Domain
Controller
DC
Domain
Controller
Trust
Application
Auth/
LDAP
VPN
Direct
Connect
AD
AD
AD
18. Availability Zone
Private Subnet
10.0.2.0/24
DBAPPWEB
SQL
Server
App
Server
IIS
Server
Availability Zone
Private Subnet
10.0.3.0/24
DBAPPWEB
SQL
Server
App
Server
IIS
Server
Remote
Users / Admins
Domain
Controllers
corporate data center
Example: AD on
EC2 with sync
Domain
Controller
Domain
Controller
Sync
Auth/
LDAP
Auth/
LDAP
Application
Auth/
LDAP
3rd party sync tool
Users loose single sign-on to cloud
(same sign-on)
VPN
Direct
Connect
AD
EC2
AD
EC2
AD
Sync
Tool
Password
Changes
19. Considerations for AWS apps and services when many VPCs
• AWS apps and services can’t integrate directly with your self-managed AD
– Microsoft AD with trust required to use a self-managed AD for credentials
(some regions AD Connector may be option)
• WorkSpaces/RDS SQL must be in same VPC as Microsoft AD
– Option 1 – Least cost, fewest trusts
• Deploy Microsoft AD in one VPC
– Use trust to your AD if integrating for use with “on-premises” users*
• Deploy all RDS SQL/WorkSpaces instances in same VPC with tagging for internal billing
– Option 2 – Least VPC peering, easiest billing
• Deploy Microsoft AD in each VPC
– Use trust from each VPC to your AD for use with “on-premises” users*
• Deploy RDS SQL/WorkSpaces instance(s) in each VPC
• QuickSight Enterprise must be in same account as Microsoft AD
*1-way trust for RDS SQL Server, 2-way trust for others
21. Deployment Differences
AWS Microsoft AD EC2 AD Instance On-Premises AD
Operation
Management
+AWS managed
in the cloud
-Customer managed
in the cloud
-Customer managed
own hardware
Availability
+Built-in redundancy and
replication
-Customer must design for
high availability
-Customer must design for
high availability
Networking
Trust1 ports from cloud to
on-premises
(least exposed)
Trust1 or replication2 ports
from cloud to
on-premises AD
-Open ports to support
cloud to on-premises AD3
(most exposed)
Admin Control
Designated OU control;
-some apps unsupported
+Full control +Full control
1
2
3
Hint
22. How to select an Active Directory option
AWS Microsoft AD EC2 AD Instances On-Premises AD
• Minimize cost, effort to run AD
• RDS SQL Server1
• AWS Enterprise Applications1
• Windows workloads on EC22
• Require a replicated, multi-region
AD solution
• Need NetBIOS name resolution
support
• You require permissions not yet
delegated by AWS Microsoft AD3
• E.g. Exchange, Sharepoint, SQL
Server AlwaysOn Availability
Groups
• Minimal EC2 instances require
access to AD
• Latency to AD over on-premises
link is acceptable
• Comfortable with connectivity
availability to on-premises AD
1RDS SQL, WorkSpaces, QuickSight, and Chime require trusts only if users are on-premises via trust
2Subject to delegation constraints (e.g. managed service account creation)
3AWS adding more delegations and application enablement over time
23. Deployment Differences – which connection model?
AWS Microsoft
AD w/Sync
AWS Microsoft
AD w/Trust
EC2 AD
w/Sync
EC2 AD
w/Trust
EC2 AD
Replicated
On-premises
App Access
SSO to cloud No Yes No Yes Yes Yes
Complexity/Effort
EC2 Seamless domain join Yes Yes No No No No
DC configuration Medium Low Highest High High None
Incremental Maintenance High Low Highest Low Medium None
Incremental system Medium Low Highest High High None
Incremental Entitlement High Low High Low None None
Sites & Services No No No No Yes None
Untested Recommended If necessary
25. Why sync (instead of trust) comes up
• Trusts seem scary
– Unfamiliar with the model
– Unfamiliar with how to secure
– Belief that a trust gives all cloud resources access to on-premises
– Belief that trusts give cloud admins control over on-premises directory
– Trusts are hard to set up and maintain
• Security team review, firewall ports
– “Breaks principle” of communication initiation only from on-premises to the cloud
• Vast majority of users don’t need authentication into cloud resources
– Only deploying SAML applications in cloud but on Windows infrastructure
26. Consideration for Sync from on-premises to the cloud
• Do your on-premises users need access to cloud resources
that use AD group-based authorization?
– If yes, will users revolt having to log out of on-premises and log back in to the cloud?
• Same sign-on, not single sign-on
• Requires 3rd party sync tool
– Requires special configuration for what gets sync’d
– Must map from on-premises directory to directory structure in the cloud
• With Microsoft AD, the tool must not require domain admin
– User creates with your delegated OU admin
• Sync adds configuration complexity and latency for managing users
– Incremental entitlements for sync
– What about security groups? How does sync map them to the cloud?
Have good reasons, know what you’re getting into
27. Amazon EC2
Amazon
DynamoDB
Amazon EC2
Appropriate for sync – admins’ usernames for RDP
App
Federated Authn
(SAML) Kerb
Authn
Domain Join/Machine Authn/GPO/LDAP
AD
On-premises
or Internet
Cloud
Cloud
28. Amazon EC2
Amazon
DynamoDB
Amazon EC2
Complex for sync – many users to many cloud services
App
Federated Authn
(SAML) Kerb
Authn
Domain Join/Machine Authn/GPO/LDAP
AD
On-premises
or Internet
Cloud
Cloud SQL Server AlwaysOn
Sharepoint
Exchange
.NET
29. Forest Trusts
• Time tested, secure model
• Trusting forest has no admin control
of trusted forest
• Trusted users have cloud resource
access only if entitled by trusting
admins (you control both sides)
• Resources in cloud have no access
to on-premises resources without
entitlement and trust from on-
premises to the cloud
AD AD
On-premises
Network
VPC
Trust
AWS Microsoft
AD DC
Windows
AD DC
Access
Security Group
(access entitlements here)
Security Group
Trusting Trusted
Cloud On-premises
30. No trust vs. 1-way vs. 2-way Trusts
• Do you need users from one forest to access resources in another forest?
– If no, use no trust
• Can you use only a 1-way trust?
– If yes, only use 1-way
– RDS SQL Server w/on-premises users requires at least 1-way
• Is a 2-way trust required?
– If yes, use 2-way trust
– WorkSpaces, QuickSight Enterprise Edition, and Chime use 2-way trusts
Always Secure Your Trust
31. Securing Trusts
• Leave SID filtering on when setting up on-premises side of trust
• Turn on selective authentication on the on-premises side
– https://technet.microsoft.com/en-us/library/cc755321(v=ws.10).aspx#w2k3tr_trust_security_zyzk
• Only permit AD trust ports to the DCs in the cloud
– https://technet.microsoft.com/en-us/library/cc756944(v=ws.10).aspx
• For cloud-client-to-AD, only permit AD authentication ports to on-premises AD;
minimize all other ports from cloud to on-premises
(e.g. WorkSpaces login using on-premises credentials)
– https://support.microsoft.com/en-us/help/179442/how-to-configure-a-firewall-for-domains-and-trusts
• Don’t grant groups in the cloud access to on-premises resources
32. References
• Documentation
– AWS Directory Service – aws.amazon.com/directoryservice
– Microsoft AD - aws.amazon.com/documentation/directory-service/
– RDS SQL Server - aws.amazon.com/documentation/rds/
• Quick Starts - aws.amazon.com/quickstart/
– Active Directory DS (Microsoft AD)
– Exchange Server 2013
– SharePoint 2016 Enterprise
– Lync Server 2013
– SQL Server 2014 AlwaysOn
– PowerShell DSC