This session discusses Amazon Directory Service and enterprise integration with Active Directory. We also cover a number of common scenarios, including on-premises federation to the AWS console and single-sign on (SSO) between on-premises and AWS applications.

1. © 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Michael Cotton, Senior Solutions Architect
Todd Gagorik, Senior Manager
June 20, 2016
AWS Directory Service
and Hybrid Strategy

2. What you will take away from this session
Understand your
federation options
Get it right at scale Plan your approach Tooling to
get started
(C) Copyright David Precious
and licensed for
reuse under the Creative
Commons Attribution 2.0
Generic
(C) Copyright GeographBot
Wallace and licensed for
reuse under the Creative
Commons Attribution-
ShareAlike 2.0 License
(C) Copyright BigMac and
licensed for
reuse under the Creative
Commons Attribution 3.0
License
License: Creative Commons
Public Domain Universal 1.0

3. Session prerequisites
• To get the most out of this session, you should be
comfortable with several building blocks:
AWS Identity &
Access
Management
(IAM)
Roles Policies AWS STS Long-lived
credentials
Temporary
credentials

4. IAM federation: A progression of options
Cross-
account
trust
AWS
Directory
Service
Security
Assertion
Markup
Language
(SAML)
Custom
identity
broker
Involvement
Control
Session focus

5. Active Directory options—Simple AD
• Microsoft Active Directory–compatible directory powered by Samba 4 and supports
common AD features
• User accounts, group memberships, domain-joining Amazon EC2 instances running Linux
and Microsoft Windows, Kerberos-based single sign-on (SSO), and group policies.
• User accounts can also access AWS applications
• Amazon WorkSpaces, Amazon WorkDocs, or Amazon WorkMail.
• Also can use IAM roles to access the AWS Management Console and manage AWS
resources.
• Also, provides daily automated snapshots to enable point-in-time recovery.
• Note: does not support trust relationships between Simple AD and other Active
Directory. You cannot perform schema extensions, multi-factor authentication,
communication over LDAPS, PowerShell AD cmdlets, and the transfer of FSMO roles.
• When to use
• Simple AD is the least expensive option and your best choice if you have 5,000 or less
users and don’t need the more advanced Microsoft Active Directory features.

6. Active Directory Options—Microsoft AD
• AWS Directory Service for Microsoft Active Directory
(Enterprise Edition)
• A managed Microsoft Active Directory
• Provides much of the functionality offered by Microsoft
Active Directory plus integration with AWS applications.
• Easily set up trust relationships with your existing Active Directory
domains
• Note:
• You cannot perform schema extensions, multifactor authentication, PowerShell
AD cmdlets, or the transfer of FSMO roles.
• When to use
• Microsoft AD is your best choice if you have more than 5,000 users and need a trust
relationship set up between an AWS hosted directory and your on-premises directories.

7. Active Directory Options—AD Connector
• Proxy service for connecting your on-premises Microsoft AD to AWS
• Forwards sign-in requests to your AD domain controllers for AuthN
• Provides the ability for applications to query your AD directory for data.
• Your users can use their existing corporate credentials to log on to AWS applications,
• WorkSpaces, WorkDocs, or WorkMail and AWS Management Console
• You can also use AD Connector to enable multi-factor authentication by integrating with
your existing RADIUS-based MFA infrastructure
• Continue to manage your Active Directory as usual and enforce your existing security
policies
When to use
AD Connector is your best choice when you want to use your existing on-premises
directory with AWS services.

8. Federation with Security
Assertion Markup Language
(SAML)

9. Why should I use federation?
Before:
After:
Result:
Unique credentials Long-lived keys One-off
Users Security Compliance
Short-term
tokens
Naturally alignedSingle sign-on

10. Quick SAML primer
Identity provider Service provider
Metadata
(in advance)
Assertion
(login flow)

11. Basic AWS federation with SAML
• Known science, assuming:
• Few AWS accounts
• AWS Management
Console access
• AWS CLI access
• Well-documented:
• Whitepapers
• Blogs
• Documentation
(C) Copyright Diliff and licensed for
reuse under the Creative Commons Attribution 3.0 License

12. AWS federation with SAML
Many AWS
accounts?
Lots of
IAM roles?
Multiple access
vectors?
Resource-level
permissions?
AWS CloudTrail
impacts?
Lots of users?
Dive deep = Get it right

13. AWS federation with SAML—planning
Choose your SAML provider
• Active Directory Federation Services (ADFS)
• OKTA
• PingFederate
• Shibboleth
• Optimal IDM
• Etc…
Understand point of AuthN and AuthZ
Plan role naming standards (assumeRoleWithSAML)
Do you have multiple AWS accounts?
For this demo we are using:
• ADFS
• Active Directory

14. Federation with AWS—high-level steps
Configure your network as a SAML provider for AWS
Create a SAML provider in IAM
Configure roles in AWS for your federate users
Create groups in your AD name match to IAM roles
Configure your SAML IdP and create assertions for the
SAML authentication response
Posted to: https://signin.aws.amazon.com/saml<SAML_AuthN_response>

15. A walkthrough of the configuration

16. Flow for SAML-enabled single sign-on

17. Demo
• AWS console federation w/SAML
• User name and password
• Certificate
• AWS CLI federation w/SAML
• User name and password
• What does a SAML token look like?
• AWS Management Console federation with AD
• User name and password

18. Smooth user experience
• Federation shouldn’t limit
access vectors
• Don’t create a “low-to-high”
exposure in the back end
AWS federation with SAML
Key takeaways
AWS
SDKs
AWS
CLI

19. Under the hood
• Naming conventions are
critical
• Configurations should rely on
patterns, not values
• Think about traceability now
AWS federation with SAML who/what/when
Key takeaways
IdP
configurations
AWS CloudTrail
samples

20. Your own journey:
Rationalizing the decision-
making process

21. Rationalizing the decision-making process
• Existing federation
investments?
• Federation needs beyond
AWS?
• Desired level of control vs.
involvement?
• Competency and bandwidth
for application development?
(C) Copyright Marco Bellucci and licensed for
reuse under the Creative Commons Attribution 2.0 Generic

22. Remember the principles of cloud architecture
• Don’t overanalyze—experiment and iterate
• Federation options are not mutually exclusive
• Several can exist in parallel
• Federation options use the same entities
• Evolve your federation approach as your needs evolve
• Right for tomorrow is not always right for today

23. Your own journey: Taking the
first steps

24. Additional information
• Session resources (code and samples)
• AWS documentation
• Manage Federation
• Integrating Third-Party SAML Solution Providers with AWS
• Request Information That You Can Use for Policy Variables
• Custom Federation Broker
• AWS blogs
• Whitepaper—Single Sign-On: Integrating AWS, OpenLDAP,
and Shibboleth
• How to Implement a General Solution for Federated API/CLI
Access Using SAML 2.0
• How to Implement ADFS with Multiple AWS accounts

25. Thank you!