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.
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:
In addition, a brief understanding of the digital certificates deployed during AD FS setup is also recommended.
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 methodologiesDMDC.
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.
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.
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.
** 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 188.8.131.52 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:
ID certificates which:
** 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.
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.
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:
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.
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.
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.
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.
The below graphic shows two different authentication methods that can be leveraged:
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
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
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.
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.
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.