Disclaimer

The content provided is only for informational purposes and is not intended to be directly applied to a production system. Those individuals who leverage this information should place it into a development and test environment prior to production. Within dev and test, the implementation can be verified and validated against a structured test plan with organizational specific requirements.

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).

Translation:

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

Background and Linked Articles

Amazon

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:

About SAML 2.0-based Federation

Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0 and

How to Set Up Uninterrupted, Federated User Access to AWS Using AD FS

Microsoft

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

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

** Important **
CAC enabling AD FS requires a one-to-one identity mapping. Within a user's MS Active Directory account, the CAC digital certificate's principal name is mapped to an AD user principal name (UPN). Leveraging one-to-one identity mappings contradicts DoD and Federal best practices, which recommends disabling UPN or one-to-one mapping and enabling one-to-many or many-to-one mapping methodologies^DMDC.

The two most common one-to-many or many-to-one mappings include: subject and/or issuer mappings. This allows one CAC to be mapped to numerous, role-based, non-privileged and privileged accounts. However, AD FS does not support name hints which are a dependency of these mappings. Additional detail on one-to-many or many-to-one mappings are outside the scope of this article, but can be found here: MS Technet: Step-by-Step Guide to Mapping Certificates to User Accounts

Understanding this limitation is instrumental because this solution will not work on systems where UPN has been disabled.

** Important **
This solution leverages the DoD Electronic Data Interchange Personal Identifier (EDIPI) and Federal Agency Smartcard Number (FASC-N), which are DoD and Federal unique identifiers, respectively. EDIPI is specific to DoD and replaces personnel's social security number (SSN). Because it is unique and replaces a SSN, commonly defined as high-risk personally identifiable information (PII), EDIPI is usually categorized as low-risk PII.

According to the Navy CIO Office, "...Since the loss, theft or compromise of the DoD ID number [EDIPI] is low risk for possible identity theft or fraud, a PII breach report will not be initiated unless accompanied by other PII elements, such as date of birth, birthplace or mother’s maiden name, which would normally require a report to be submitted.^{Navy CIO}" Considering its perceived sensitivity — although printed on the back of every CAC in plaintext and in every digitally signed DoD memo — do not publically disclose it without official approval and only use it for official use (e.g., CAC multi-factor authentication within a government system).

Understanding the risk associated low-risk PII is required for its use.

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.

Understanding DoD Certificates

** Note **
Often, CACs have 3-4 certificates on them for different purposes. Not all CAC certificates have a principal name (PN) or the same PN, but those that do have a PN, all start with the same first 10 digits, which is the DoD user's EDIPI (also known as DoD ID number); it's a unique number, specific to the user. If you encounter a longer 16 digit number from a certificate, it is the Federal Agency Smart Credential Number (FASC-N). The FASC-N allows a CAC to be uniquely identifiable across all Federal, including DoD.

If you want to learn more about FASC-N, the DoD PIV Transitional Implementation Guide, Section 5.1.5.2 FASC-N, has plenty of amplifying information.

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 mail.mil 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).

** Note **

This walkthrough uses the native Windows 10 drivers which work to a limited extent. However, by installing ActivClient, a common DoD commercially procured application for managing smart card certificates, additional features become available. These features allow the server to fall more in line with the Secure Host Baseline (SHB) mandate.

ActivClient is available for Army personnel via Army Knowledge Online (AKO). Other agencies will require assistance from their help desk, IT staff, comms department, etc. Militarycac.com has more information.

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.

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.

** Note **
IL2 systems are meant to be separate, public, non-hybrid cloud models, which makes interfacing with DoD on-premise dependencies challenging. However, IL4 systems, as defined by the DoD Secure Cloud Computing Architecture (SCCA), are hybrid cloud models with limited or no public facing capability. Yet, IL4 systems are still challenged with DISA and DMDC limiting enterprise services required to operate.

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.

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.

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.
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.

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.

** Note **
I have removed the ADFS- from after the "role/" portion of the below Roles claim policy. It does not matter if you keep it or remove it, it will only slightly change your federated login.

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.
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)

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.

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.

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.

Navigate to the AD FS landing/login portal.

Select Amazon Web Services from the drop down.

Click the Sign in button.

When prompted to Select a certificate, select the ID certificate.

Click OK.

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.

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.

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., no-reply@boyletcs.com) attributes passed.
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