Use these settings to specify the way in which the user account on the peer computer is authenticated. You can also specify that the computer must have a computer health certificate. The second authentication method is performed by Authenticated IP (AuthIP) in an extended mode of the main mode phase of Internet Protocol security (IPsec) negotiations.
You can specify multiple methods to use for this 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:
- In the Windows Firewall with Advanced Security MMC snap-in, in
the navigation pane, click Windows Firewall with Advanced
Security, and then in Overview, click Windows
Firewall Properties.
- Click the IPsec Settings tab, and then under IPsec
defaults, click Customize.
- Under Authentication Method, select Advanced, and
then click Customize.
- Under Second authentication, select a method, and then
click Edit or Add.
- In the Windows Firewall with Advanced Security MMC snap-in, in
the navigation pane, click Windows Firewall with Advanced
Security, and then in Overview, click Windows
Firewall Properties.
-
When creating a new connection security rule:
- In the Windows Firewall with Advanced Security MMC snap-in, in
the navigation pane, right-click Connection Security Rules,
and then click New Rule.
- On the Rule Type page, select any type except
Authentication exemption.
- On the Authentication Method page, select
Advanced, and then click Customize.
- Under Second authentication, select a method, and then
click Edit or Add.
- In the Windows Firewall with Advanced Security MMC snap-in, in
the navigation pane, right-click Connection Security Rules,
and then click New Rule.
-
When modifying an existing security rule:
- In the Windows Firewall with Advanced Security MMC snap-in, in
the navigation pane, click Connection Security Rules.
- Double-click the connection security rule that you want to
modify.
- Click the Authentication tab.
- Under Method, click Advanced, and then click
Customize.
- Under Second authentication, select a method, and then
click Edit or Add.
- In the Windows Firewall with Advanced Security MMC snap-in, in
the navigation pane, click Connection Security Rules.
User (Kerberos V5)
You can use this method to authenticate a user logged on to a remote computer that is part of the same domain or in separate domains that have a trust relationship. The logged-on user must have a domain account and the computer must be joined to a domain in the same forest.
User (NTLMv2)
NTLMv2 is an alternative way to authenticate a user logged on to a remote computer that is part of the same domain or in a domain that has a trust relationship to the domain of the local computer. The user account and the computer must be joined to domains that are part of the same forest.
User certificate
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 certification authority (CA) is configured on or accessible through your network and that client computers have an associated computer certificate. This method is useful when the users are not in the same domain or are in separate domains without a two-way trust relationship, and Kerberos version 5 cannot be used.
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 256-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.
Enable certificate to account mapping
When you enable IPsec certificate-to-account mapping, the Internet Key Exchange (IKE) and AuthIP protocols associate (map) a user certificate to a user account in an Active Directory domain or forest, and then retrieve an access token, which includes the list of user security groups. This process ensures that the certificate offered by the IPsec peer corresponds to an active user account in the domain, and that the certificate is one that should be used by that user.
Certificate-to-account mapping can only be used for user 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 users who are within the same forest. Certificate-to-account mapping, however, does not ensure that a specific trusted user 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 user account for a specific root CA. You can also map all certificates from an issuing CA to one user account. This allows 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.
Computer health certificate
Use this option to specify that only a computer that presents a certificate from the specified CA and that is marked as a Network Access Protection (NAP) health certificate can authenticate by using this connection security rule. 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. 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.
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.
Enable certificate to account mapping
When you enable IPsec certificate-to-account mapping, the IKE and AuthIP protocols associate (map) a certificate to a user or computer account in an Active Directory domain or forest, and then retrieve an access token, which includes the list of security groups. This process ensures that the certificate offered by the IPsec peer corresponds to an active computer or user account in the domain, and that the certificate is one that should be used by that account.
Certificate-to-account mapping can only be used for 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 accounts that are within the same forest. Certificate-to-account mapping, however, does not ensure that a specific trusted account is being allowed IPsec access.
Certificate-to-account mapping is especially useful if the certificates come from a PKI that is not integrated with your AD DS deployment, such as if business partners obtain their certificates from non-Microsoft certificate providers. You can configure the IPsec policy authentication method to map certificates to a domain account for a specific root CA. You can also map all certificates from an issuing CA to one computer or user 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.