Use these settings to specify the way in which the peer computer is authenticated. The first authentication method is performed during the main mode phase of Internet Protocol security (IPsec) negotiations.

You can specify multiple methods to use for first authentication. The methods are attempted in the order you specify. The first successful method is used.

For more information about the authentication methods available in this dialog box, see IPsec Algorithms and Methods Supported in Windows (http://go.microsoft.com/fwlink/?linkid=129230).

To get to this dialog box

When modifying the system-wide default settings:
1. In the Windows Firewall with Advanced Security MMC snap-in, in Overview, click Windows Firewall Properties.
2. Click the IPsec Settings tab, and then under IPsec defaults, click Customize.
3. Under Authentication Method, select Advanced, and then click Customize.
4. Under First authentication, select a method, and then click Edit or Add.
When creating a new connection security rule:
1. In the Windows Firewall with Advanced Security MMC snap-in, right-click Connection Security Rules, and then click New Rule.
2. On the Rule Type page, select any type except Authentication exemption.
3. On the Authentication Method page, select Advanced, and then click Customize.
4. Under First authentication, select a method, and then click Edit or Add.
When modifying an existing connection security rule:
1. In the Windows Firewall with Advanced Security MMC snap-in, click Connection Security Rules.
2. Double-click the connection security rule that you want to modify.
3. Click the Authentication tab.
4. Under Method, click Advanced, and then click Customize.
5. Under First authentication, select a method, and then click Edit or Add.

Computer (Kerberos V5)

You can use this method to authenticate peer computers that have computer accounts in the same domain or in separate domains that have a trust relationship.

Computer (NTLMv2)

NTLMv2 is an alternative way to authenticate peer computers that have computer accounts in the same domain or in separate domains that have a trust relationship.

Computer certificate from this certification authority (CA)

Use a public key certificate in situations that include external business partner communications or computers that do not run the Kerberos version 5 authentication protocol. This requires that at least one trusted root CA is configured on or accessible through your network and that client computers have an associated computer certificate.

Signing algorithm

Specify the signing algorithm used to cryptographically secure the certificate.

RSA (default)

Select this option if the certificate is signed by using the RSA public-key cryptography algorithm.

ECDSA-P256

Select this option if the certificate is signed by using the Elliptic Curve Digital Signature Algorithm (ECDSA) with 256-bit key strength.

ECDSA-P384

Select this option if the certificate is signed by using ECDSA with 384-bit key strength.

Certificate store type

Specify the type of certificate by identifying the store in which the certificate is located.

Root CA (default)

Select this option if the certificate was issued by a root CA and is stored in the local computer’s Trusted Root Certification Authorities certificate store.

Intermediate CA

Select this option if the certificate was issued by an intermediate CA and is stored in the local computer’s Intermediate Certification Authorities certificate store.

Accept only health certificates

This option restricts the use of computer certificates to those that are marked as heath certificates. Health certificates are published by a CA in support of a Network Access Protection (NAP) deployment. NAP lets you define and enforce health policies so that computers that do not comply with network policies, such as computers without antivirus software or those that do not have the latest software updates, are less likely to access your network. To implement NAP, you need to configure NAP settings on both server and client computers. NAP Client Management, a Microsoft Management Console (MMC) snap-in, helps you configure NAP settings on your client computers. For more information, see the NAP MMC snap-in Help. To use this method, you must have a NAP server set up in the domain.

Enable certificate to account mapping

When you enable IPsec certificate-to-account mapping, the Internet Key Exchange (IKE) and Authenticated IP (AuthIP) protocols associate (map) a computer certificate to a computer account in an Active Directory domain or forest, and then retrieve an access token, which includes the list of computer security groups. This process ensures that the certificate offered by the IPsec peer corresponds to an active computer account in the domain, and that the certificate is one that should be used by that computer.

Certificate-to-account mapping can only be used for computer accounts that are in the same forest as the computer performing the mapping. This provides much stronger authentication than simply accepting any valid certificate chain. For example, you can use this capability to restrict access to computers that are within the same forest. Certificate-to-account mapping, however, does not ensure that a specific trusted computer is being allowed IPsec access.

Certificate-to-account mapping is especially useful if the certificates come from a public key infrastructure (PKI) that is not integrated with your Active Directory Domain Services (AD DS) deployment, such as if business partners obtain their certificates from non-Microsoft providers. You can configure the IPsec policy authentication method to map certificates to a domain computer account for a specific root CA. You can also map all certificates from an issuing CA to one computer account. This allows IKE certificate authentication to be used to limit which forests are allowed IPsec access in an environment where many forests exist and each performs autoenrollment under a single internal root CA. If the certificate-to-account mapping process is not completed properly, authentication will fail and IPsec-protected connections will be blocked.

Preshared key (not recommended)

You can use preshared keys for authentication. This is a shared, secret key that is previously agreed on by two users. Both parties must manually configure IPsec to use this preshared key. During security negotiation, information is encrypted by using the shared key before transmission and decrypted by using the same key on the receiving end. If the receiver can decrypt the information, identities are considered to be authenticated.

Caution

Preshared key methodology is provided for interoperability purposes and to adhere to IPsec standards. You should use the preshared key for testing purposes only. Regular use of preshared key authentication is not recommended because the authentication key is stored in an unprotected state in the IPsec policy.
If a preshared key is used for the main mode authentication, second authentication cannot be used.

Dialog Box: Add or Edit First Authentication Method