AOS must be configured to use DOD public key infrastructure (PKI) as multifactor authentication (MFA) for interactive logins.

Severity	Group ID	Group Title	Version	Rule ID	Date	STIG Version
high	V-266929	SRG-APP-000149-NDM-000247	ARBA-ND-000247	SV-266929r1039808_rule	2024-10-29	1

Description
MFA is when two or more factors are used to confirm the identity of an individual who is requesting access to digital information resources. Valid factors include something the individual knows (e.g., username and password), something the individual has (e.g., a smart card or token), or something the individual is (e.g., a fingerprint or biometric). Legacy information system environments only use a single factor for authentication, typically a username and password combination. Although two pieces of data are used in a username and password combination, this is still considered single factor because an attacker can obtain access by learning what the user knows. Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. MFA, along with strong user account hygiene, helps mitigate the threat of having account passwords discovered by an attacker. Even in the event of a password compromise, with MFA implemented and required for interactive login, the attacker still needs to acquire something the user has or replicate a piece of the user's biometric digital presence. Private industry recognizes and uses a wide variety of MFA solutions. However, DOD PKI is the only prescribed method approved for DOD organizations to implement MFA. For authentication purposes, centralized DOD certificate authorities (CA) issue PKI certificate key pairs (public and private) to individuals using the prescribed x.509 format. The private certificates that have been generated by the issuing CA are downloaded and saved to smart cards which, within DOD, are referred to as common access cards (CAC) or personal identity verification (PIV) cards. This happens at designated DOD badge facilities. The CA maintains a record of the corresponding public keys for use with PKI-enabled environments. Privileged user smart cards, or "alternate tokens", function in the same manner, so this requirement applies to all interactive user sessions (authorized and privileged users). Note: This requirement is used in conjunction with a centralized authentication server (e.g., Authentication, Authorization, and Accounting [AAA], Remote Authentication Dial-In User Service [RADIUS], Lightweight Directory Access Protocol [LDAP]), a separate but equally important requirement. The MFA configuration of this requirement provides identification and the first phase of authentication (the challenge and validated response, thereby confirming the PKI certificate that was presented by the user). The centralized authentication server will provide the second phase of authentication (the digital presence of the PKI ID as a valid user in the requested security domain) and authorization. The centralized authentication server will map validated PKI identities to valid user accounts and determine access levels for authenticated users based on security group membership and role. In cases where the centralized authentication server is not used by the network device for user authorization, the network device must map the authenticated identity to the user account for PKI-based authentication. Satisfies: SRG-APP-000149-NDM-000247, SRG-APP-000080-NDM-000220, SRG-APP-000153-NDM-000249, SRG-APP-000177-NDM-000263

Description

MFA is when two or more factors are used to confirm the identity of an individual who is requesting access to digital information resources. Valid factors include something the individual knows (e.g., username and password), something the individual has (e.g., a smart card or token), or something the individual is (e.g., a fingerprint or biometric). Legacy information system environments only use a single factor for authentication, typically a username and password combination. Although two pieces of data are used in a username and password combination, this is still considered single factor because an attacker can obtain access by learning what the user knows. Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. MFA, along with strong user account hygiene, helps mitigate the threat of having account passwords discovered by an attacker. Even in the event of a password compromise, with MFA implemented and required for interactive login, the attacker still needs to acquire something the user has or replicate a piece of the user's biometric digital presence. Private industry recognizes and uses a wide variety of MFA solutions. However, DOD PKI is the only prescribed method approved for DOD organizations to implement MFA. For authentication purposes, centralized DOD certificate authorities (CA) issue PKI certificate key pairs (public and private) to individuals using the prescribed x.509 format. The private certificates that have been generated by the issuing CA are downloaded and saved to smart cards which, within DOD, are referred to as common access cards (CAC) or personal identity verification (PIV) cards. This happens at designated DOD badge facilities. The CA maintains a record of the corresponding public keys for use with PKI-enabled environments. Privileged user smart cards, or "alternate tokens", function in the same manner, so this requirement applies to all interactive user sessions (authorized and privileged users). Note: This requirement is used in conjunction with a centralized authentication server (e.g., Authentication, Authorization, and Accounting [AAA], Remote Authentication Dial-In User Service [RADIUS], Lightweight Directory Access Protocol [LDAP]), a separate but equally important requirement. The MFA configuration of this requirement provides identification and the first phase of authentication (the challenge and validated response, thereby confirming the PKI certificate that was presented by the user). The centralized authentication server will provide the second phase of authentication (the digital presence of the PKI ID as a valid user in the requested security domain) and authorization. The centralized authentication server will map validated PKI identities to valid user accounts and determine access levels for authenticated users based on security group membership and role. In cases where the centralized authentication server is not used by the network device for user authorization, the network device must map the authenticated identity to the user account for PKI-based authentication. Satisfies: SRG-APP-000149-NDM-000247, SRG-APP-000080-NDM-000220, SRG-APP-000153-NDM-000249, SRG-APP-000177-NDM-000263

ℹ️ Check
Verify the AOS configuration using the web interface: 1. Navigate to Configuration >> System >> Admin and expand "Admin Authentication Options". 2. Verify what "Server group" is handling admin authentication. 3. Verify that Client certificate is enabled. 4. Expand "Admin Authentication Servers". 5. Select the Server Group identified from the "Options" section. 6. Verify that each authentication server configured in Server Group <server group name> is configured with the Key attribute: of userPrincipalName. If Client certificate is not enabled and the management authentication servers are not configured with userPrincipalName, this is a finding.

ℹ️ Check

Verify the AOS configuration using the web interface: 1. Navigate to Configuration >> System >> Admin and expand "Admin Authentication Options". 2. Verify what "Server group" is handling admin authentication. 3. Verify that Client certificate is enabled. 4. Expand "Admin Authentication Servers". 5. Select the Server Group identified from the "Options" section. 6. Verify that each authentication server configured in Server Group <server group name> is configured with the Key attribute: of userPrincipalName. If Client certificate is not enabled and the management authentication servers are not configured with userPrincipalName, this is a finding.

✔️ Fix
Configure AOS using the web interface: 1. Navigate to Configuration >> System >> Admin and expand "Admin Authentication Servers". 2. Click on the plus sign (+) under "All Servers" and configure the type of authentication server. Provide the Name, Type, and IP address. Click "Submit". 3. Select the created authentication server and configure the required attributes for LDAP: Admin-dn <username> Admin-passwd <password> Re-type admin-passwd <password> Auth port: 636 Base-dn: cn/ou=<container>,dc=<level>,dc=<mil> Key-attribute: userPrincipalName 4. Click "Submit." 5. Repeat this process and configure a second authentication server. 6. Click "Pending Changes" and then "Deploy changes". 7. Click on the plus sign (+) under "Server Groups" and add a server group. 8. Click "Submit". 9. Select the created server group and click the plus sign (+) in the Server Group <server group name> box. 10. Add the first configured authentication server. 11. Reselect the created server group and click the plus sign (+) in the Server Group <server group name> box. 12. Click Submit >> Pending Changes >> Deploy Changes. 13. Navigate to Management User. 14. Click on "Show users with certificate authentication". Click on the plus sign (+). 15. Configure each Trusted CA certificate name for any DOD Root CA that provides trust for admin users. 16. Select External server for the Authentication server. 17. Click Submit >> Pending Changes >> Deploy Changes. 18. Expand "Admin Authentication Options". Check "Enable" and "Client certificate". Select the Server group created earlier. 19. Click Submit >> Pending Changes >> Deploy Changes.

✔️ Fix

Configure AOS using the web interface: 1. Navigate to Configuration >> System >> Admin and expand "Admin Authentication Servers". 2. Click on the plus sign (+) under "All Servers" and configure the type of authentication server. Provide the Name, Type, and IP address. Click "Submit". 3. Select the created authentication server and configure the required attributes for LDAP: Admin-dn <username> Admin-passwd <password> Re-type admin-passwd <password> Auth port: 636 Base-dn: cn/ou=<container>,dc=<level>,dc=<mil> Key-attribute: userPrincipalName 4. Click "Submit." 5. Repeat this process and configure a second authentication server. 6. Click "Pending Changes" and then "Deploy changes". 7. Click on the plus sign (+) under "Server Groups" and add a server group. 8. Click "Submit". 9. Select the created server group and click the plus sign (+) in the Server Group <server group name> box. 10. Add the first configured authentication server. 11. Reselect the created server group and click the plus sign (+) in the Server Group <server group name> box. 12. Click Submit >> Pending Changes >> Deploy Changes. 13. Navigate to Management User. 14. Click on "Show users with certificate authentication". Click on the plus sign (+). 15. Configure each Trusted CA certificate name for any DOD Root CA that provides trust for admin users. 16. Select External server for the Authentication server. 17. Click Submit >> Pending Changes >> Deploy Changes. 18. Expand "Admin Authentication Options". Check "Enable" and "Client certificate". Select the Server group created earlier. 19. Click Submit >> Pending Changes >> Deploy Changes.