Identity and Access Management (IdAM) | Common Access Card (CAC) | multi-factor Authentication (MFA) to the Amazon Web Services (AWS) Console leveraging a DoD Common Access Card (CAC), Active Directory Federated Services (AD FS), and SAML Single Sign-On (SSO)

DoD | Privileged Access to the AWS Console

DoD Cloud SRG Definition

Mission Owner access control credentials [are] required at each information impact level IAW DoDI 8520.03 in the following categories:
• Mission Owner privileged user access to the CSP’s customer ordering and service management interfaces or portals for all service offerings (IaaS,PaaS, and SaaS).


CAC Authentication is required for access to the AWS Console or any custom platform or software with the same capability (e.g., a custom cloud broker application or system leveraging AWS APIs to provision AWS infrastructure). This is important because if individuals have access and authorization to provision or deprovision, modify, or copy infrastructure and its data, they control your entire system. Holding individuals with these permissions accountable is extremely important.

AWS article on federating using Active Directory Federation Services (ADFS)

AWS article on Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0. After completing, continue onto CAC Enabling an ADFS IdP


Amazon already provides multiple articles that can be leveraged to perform 90% of this use case — short of multi-factor authentication using CAC or smartcard. (1) is background, while (2) and (3) are required to complete the full solution. Instead of reproducing the articles, they can be found at:

  1. About SAML 2.0-based Federation
  2. Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0 and
  3. How to Set Up Uninterrupted, Federated User Access to AWS Using AD FS


In addition, a brief understanding of the digital certificates deployed during AD FS setup is also recommended.

  1. MS Technet article, Understanding Certificates Used by AD FS
To meet DoD Instruction 8520.02, Public Key Infrastructure (PKI) and Public Key (PK) Enabling, default self-signed certs provided during AD FS installation and deployment should be replaced with DISA/DoD digitally signed certificates. The requests can be placed by an agency trusted agent (i.e., designated personnel within a government agency who submits the certificate signing request (CSR) through a DISA, non-public, web-based portal for signing.)

The correct implementation of all of the above procedures are the basis for second part, Common Access Card (CAC) Enabling ADFS. Before proceeding, read through the above articles and complete the referenced procedures.

Common Access Card (CAC) Enabling ADFS

User Principal Name (UPN) Mapping: Understanding the Relevance of the Federal Agency Smartcard Number (FASC-N) and Electronic Data Interchange Personal Identifier (EDIPI)

If you are integrating CACs into an official, government, cloud system that will have an authority to connect and operate, the combination of the FASC-N or EDIPI and subsequent domain (e.g., @mil) is how the user will uniquely authenticate to the system. The combination is known as the CAC certificate's Principal Name. The concept requires the mapping of the unique principal name, contained in the subject alternate name field of a CAC's certificate to a centrally managed directory system (e.g., Active Directory).

The below pictured numbers (e.g., 1234567890123456 — FASC-N or 1234567890 — EDIPI) and the domain that follows it (e.g., @mil) are required in the creation of the new Active Directory user account. Depending on the system and purpose, the CAC certificate used may change. Different certificates contain different principal names containing either the FASC-N or EDIPI, but not both. The FASC-N or EDIPI combined with the @mil domain suffix populate the MS AD User Login Name field. This is the simplest form of identity mapping, known as User Principal Name (UPN) mapping.

Common Access Card (CAC) Principal Name is the same as the Electronic Data Interchange Personal Identifier or EDIPI

Understanding DoD Certificates

Depending on the middleware you're using, you may see what is perceived to be duplicate certificates (e.g., multiple EMAIL and ID certificates). They are not duplicates, but have differing purposes and supported principal names. For this walkthrough, the DoD ID — Friendly Name: Authentication certificate with Smart Card Logon and Client Authentication purposes — will be used. However, you will see certificates that include:

EMAIL certificates which:

  • perform digital signature and non-repudiation,
  • use the 10 digit EDIPI or DoD Email as the principal name, and
  • are used to log into and encrypt DoD email e.g., DISA OWA email servers.

ID certificates which:

  • perform digital signature and non-repudiation,
  • use the 16 digit FASC-N as the principal name, and
  • are used for non-email specific authentication and also for Federal interoperability with PIV activation (OSD milConnect).
Common Access Card (CAC) personal digital certificates

Obtaining a CAC's Principal Name (Windows UI)

In order to complete UPN mapping, the first step involves obtaining a CAC certificate's principal name, so it can be associated/mapped with a not yet existent, new user account and group. Since DISA and DMDC will not provide any identity services (e.g., IdSS) or raw data to support creating cloud identity services to any DoD organizations that leverage commercial cloud service providers (CSPs), you'll have to manually retrieve the Principal Name from each certificate that requires authentication.

Yes, this does not scale well and is not ideal for large organizations with constantly new and expiring user certificates, but there should only be a limited number of privileged users accessing the AWS console anyway.

Eventually, DISA and/or DMDC will have to offer a trust relationship for DoD Enterprise Services to cloud resources (e.g., enterprise identity services). If your agency is considering federating or syncing enterprise services from DISA or data from DMDC without their knowledge, the agency may want to reread their Memorandum or Agreement and/or Understanding (MoA/MoU) and Service Level Agreements (SLAs) before proceeding. Until DoD federates or syncs their identities, manual is the only option. Follow the steps below to manually identify a CAC UPN.

The graphic below shows a CAC certificate in the Microsoft Management Console (MMC) Certificates snap-in | Details tab | Subject Alternative Name field. Remember the principal name (PN). Determining the PN, can also be accomplished through MS Windows Powershell and Linux OpenSSL — not listed here.

Follow the steps below to manually identify the principal name from a CAC digital certificate in Windows 10/Server 2016.

  • Run Microsoft Common Console with the Certificate snap-in.
  • The shortcut command is certmgr.msc
  • If the certificate has recently been used at a website or portal, it should be listed within your Current User - Personal certificate store.
  • Otherwise, navigate to the OSD milConnect portal and login using CAC.
  • That should populate your personal certificate store with the required DoD ID certificate.
  • Within the Certificates - Current User | Personal | Certificates store, identify the ID certificate and double-click it.
  • Two ID certificates may show. Choose the Authentication one which is intended for Smart Card logon.
  • Click on the Details tab.
  • Scroll down to the Subject Alternative Name attribute and click on it.
  • Record or remember the Principal Name.
Digital Certificates Principal Name found under the Details Tab and Subject Alternate Name (SAN)

Creating an alternative UPN suffix

Since the Principal Name of the 16 digit FASC-N ends in a @mil domain suffix and no commercial cloud service provider (e.g., AWS, MS Azure, etc.) operating at DoD Impact Level 2 (IL2) or IL4 are trusted with DoD Identity data from an on-premise domain server — DISA/DMDC issue with protecting DoD identities and other, sensitive, enterprise services — you will need to create an alternative UPN suffix within your Domain Controller (DC) to avoid a certificate mismatch.

Follow these steps to create an alternative UPN suffix:

  • Navigate to Active Directory Domains and Trusts.
  • Right-click Active Directory Domains and Trusts [ your domain ].
  • Click Properties.
  • Add mil, without the @, within the Alternative UPN suffixes: field.
  • Ensure mil has been added.
  • Click OK.
  • Active Directory Users and Computers Console open and user is creating a new group and user

    Creating a New, AD Role-Based User and Group

    At this point, the assumption is that you know how to do basic system administrative pieces like create the AD group and user. The steps here show you the intricacies specific to CAC UPN mapping. In the graphic below, AWS-Auditor and AWS-SecEng have already been created as role-based groups. The role-based user is then created by inputting the 16 digit FASC-N from the ID certificate's Principal Name into the User login name and combining it with the new @mil UPN suffix from the drop-down box. This creates the MS User Principal Name (UPN). This should not be confused with the CAC digital certificate's principal name. They are mapped to each other and should reflect one another for authentication to work, but they are different.

    Create a new CAC user within Active Directory depicting entering EDIPI or FASC-N into MS User Principal Name and changing UPN suffix to @mil

    Next, verify the email address of the user is filled out because this will be passed to AWS via SAML to populate the AWS Console federated login. Unlike the no-reply address shown, the email should be unique to the user. When creating a new CAC AD user, fill out the email field

    Altering the AD FS Configuration

    Verifying the Roles Claim

    Before editing both the authentication methods and access control policies to support multi-factor Authentication (MFA) with Certificate Based Authentication (CBA), follow the steps below to verify the claims policy, Roles, is setup correctly. The role was previously setup during the AD FS installation and creation of claim issuance policies in the AWS tutorial in the Background and Linked Articles section.

    • Within AD FS Management, navigate to Relying Party Trusts.
    • If you followed the AWS articles listed in Background and Linked Articles there should be a Relying Party Trust for Amazon Web Services.
    • As shown in the graphic below, right-click on Amazon Web Services and choose Edit Claim Issuance Policy...
    • Then within the Edit Claim Issuance Policy... window, choose the Roles policy and Edit Rule...
    • Continue to the next section and graphic.
    Verify Claim Issuance Policy

    The policy should reflect what is shown below. This will leverage the previously setup policy, Get AD Groups, identifying AD groups with the prefix, AWS-, passing them via SAML to AWS. As you learned in previous AWS articles, authorization and privileges can be modified in AWS to reflect what permissions the AD groups — now AWS roles — receive within AWS. The portion illustrated is only authentication to the AWS console, not the authorization controlled by the AWS role in AWS IAM.

    Verify Claim Issuance Policy named Roles

    Verifying the RoleSessionName Claim

    Perform the same steps as Verifying the Roles Claim, but ensure the RoleSessionName claim pulls from the user account's email address. This will pass the email address to AWS, along with the the AD role-based group (e.g., AWS-SecEng or AWS-Auditor). Both of these attributes will be reflected in the AWS console as the federated login. Verify Claim Issuance Policy named RoleSessionName

    Editing the Primary and multi-factor Authentication Methods

    The below graphic shows two different authentication methods that can be leveraged:

    • Forms Based (i.e., user and password) and
    • Certificate Based (i.e., X.509 certificate; e.g., CAC, PIV, or other smart card)
    Active Directory Federated Services (AD FS) landing / login portal with two forms of authentication for login: forms and certificate based

    Follow the steps below to ensure the only authentication method supported at the AD FS landing / login portal is certificate based authentication (CBA), in this case, CAC. This involves setting AD FS primary and multi-factor authentication to certificate based authentication for external and internal systems.

    Navigate to AD FS Management

    • Under Primary Authentication Methods, click the Edit link.
    • Under Extranet check Certificate Authentication.
    • Under Intranet check Certificate Authentication.
    • Click OK.
    • Under Multi-factor Authentication Methods, click the Edit link.
    • Out of the two MFA options present, check Certificate Authentication.
    • Click OK.
    Within Active Directory Federated Services (AD FS), edit the primary and multi-factor authentication methods

    Editing the Access Control Policies

    Follow the steps below to harden the AD FS access control policies to use only multi-factor authentication (MFA) with specific AD groups. These specific groups point to a parameter populated by the AWS claim policy, Roles. Within the AWS tutorials, the Get AD Groups and Roles policies form the base for selecting any AD group with the prefix, AWS- (e.g., selects both AWS-SecEng and AWS-Auditor). The second screen shot under Verifying the Roles Claim, provides a visual explanation.

    Navigate to AD FS Management

    • Within AD FS Management, navigate to Access Control Policies.
    • If a policy does not exist for Permit only a specific group with certificate, create one.
    • As shown in the graphic, check the Require users to provide credentials each time at sign-in.
    • Within the Name field, type Permit only specific group with certificate.
    • Provide an appropriate Description.
    • Under the Rule Editor, alter or create a policy that states: users from specific groups and require multi-factor authentication.
    • Click OK.
    Within Active Directory Federated Services (AD FS), enabling multi-factor, certificate based authentication with limitations on specific Amazon Web Service (AWS) role-based group access

    Logging into the Amazon Web Console (AWS) with multi-factor (MFA) using Common Access Card (CAC)

    Now that a new, role-based user and group have been created, mapped to a CAC digital certificate, the AD FS landing/login portal has been instructed to prompt users for certificate based authentication (CBA), and SAML claims have been verified to pass the correct attributes to the AWS Console, it is time to test the implementation.

    Testing AD FS with the AWS Console

    The following steps will assist in testing Certificate Based Authentication (CBA) leveraging Common Access Card (CAC) for Active Directory Federated Services (AD FS) to the Amazon Web Services (AWS) Console.

    AD FS landing / login page
    • When prompted to Select a certificate, select the ID certificate.
    • Click OK.
    Windows Select a Certificate Prompt
    • The CAC user should be prompted for their pin.
    • This prompt may appear to be different if ActivClient or other middleware is installed (e.g., OpenSC).
    • Enter the CAC pin.
    • Click OK.
    Windows Security CAC Pin Prompt
    • After entering the CAC pin, the user should be redirected to the AWS Federated Signin/Login Screen.
    • Based on the CAC user and associated AD groups, the user is presented with numerous roles with differing permissions that they may login into the AWS Console.
    • For this walkthrough, Select SecEng.
    AWS Federated Login Screen for selecting AWS Role After selecting the appropriate AWS role (e.g., SecEng), the user should be redirected to the Amazon Web Service (AWS) Console where it displays the user's federated login based on the claims: Roles (e.g., SecEng) and Role Session (e.g., attributes passed. AWS Federated Login Screen for selecting AWS Role

    That's it!

    Questions? Reach out with the button below. Thanks.

Have suggestions for cloud security issues you want to know more about?

Maybe we have an answer. Let us know below.

Reach out

Copyright © Boyle Technical Consulting Services LLC. All Rights Reserved