A Forefront Unified Access Gateway 2010 Direct Access client experiences repeated OTP prompts

Consider the following scenario:

- Windows 7 clients are accessing a Forefront Unified Access Gateway 2010 Service Pack 1 Direct Access (DA) server  
- Two factor authentication is being used with OTP (One Time Password)
- Force Tunneling is enabled  
- Web Proxy is being used

In this scenario, a user on a client computer may be prompted repeatedly for OTP credentials.

This issue typically manifests itself in the following way:

1. A user logs in. 
2. The first Direct Access tunnel is established.
3. The user tries to access an internal file share. 
4. The user is prompted for OTP credentials which the user provides.
5. The second Direct Access tunnel is established.
6. An internal file share can now be accessed successfully.
7. After a random amount of time (1 - 5 minutes) the OTP prompt is displayed again. 
If an IPsec Security Association (SA) is already established by a SYSTEM level service, it treats NETWORK SERVICE as machine traffic and sends it on the SYSTEM context IPsec SAs. But if an IPsec SA does not exist, AuthIP strictly impersonates Network Service such that it can’t use a computer certificate by default because it’s private key is ACLed to SYSTEM only.  

In our scenario, the NETWORK SERVICE machine traffic was generated by NCSI probes. The probes are HTTP requests and we are force tunneled to a web proxy (as specified in the Name Resolution Policy Table, or NRPT) so we need an IPSec SA for the web proxy. An IKE negotiation is initiated in the context of NETWORK SERVICE since the Network Location Awareness (NLA) service runs in the context of NETWORK SERVICE but IKE (impersonating NETWORK SERVICE) does not have access to the private key of the OTP certificate. Since we cannot access the private key, Direct Access Connectivity Assistant (DCA) thinks there is no OTP certificate in the store, thus triggering the OTP prompt to the user.  

To resolve this issue, create a custom certificate template for use with two factor authentication by duplicating a computer certificate template. The steps to do this are below:

1. Visit http://technet.microsoft.com/en-us/library/gg274319.aspx#user and follow all steps under “Manually configuring an OTP user certificate template” except in step 2, instead of duplicating a User template we are duplicating a computer template.

2. Set key permissions for NETWORK SERVICE (Read access) on this certificate template. You can do so from the properties of the certificate template by clicking on Key Permissions.

3. In the UAG wizard, configure Two-Factor Authentication and select the custom certificate template created above instead of "DaOTPUser".

4. The clients will now be issued OTP certificates with NETWORK SERVICE having read access to the private key.

As an alternate work around, you can implement either of the following:

Disable Force tunneling.  


Disable Teredo and 6to4 adapters via the Registry or group policy. This will stop the NCSI probes from occurring.
More Information
This issue will generate ERROR_IPSEC_IKE_NO_PRIVATE_KEY and eventually ERROR_IPSEC_IKE_NO_CERT in an IKEEXT ETL Log:  
[1] 04B4.1500::09/21/2012-16:48:35.694 [ikeext] ike_sspi_c4313 IkeDetermineSspiInfo() - 29|2002:c178:9417::c178:9417|Initializing SSL SSPI  
[1] 04B4.1500::09/21/2012-16:48:35.694 [ikeext] ike_sspi_c2370 IkeGetMySPNAuthIp() - 29|2002:c178:9417::c178:9417|My SPN: NT AUTHORITY\NETWORK SERVICE ----> network service being used  
[3] 04B4.1500::09/21/2012-16:48:35.731 [ikeext] ike_sspi_c4816 IkeFindSspiCert() - 29|2002:c178:9417::c178:9417|Looking up local cert chain for SSL:  
[1] 04B4.1500::09/21/2012-16:48:35.737 [ikeext] ike_cert_c249 IkeDumpCertChain() - 29|2002:c178:9417::c178:9417|Dumping Chain:  
[1] 04B4.1500::09/21/2012-16:48:35.737 [ikeext] ike_cert_c206 IkeDumpCert() - 29|2002:c178:9417::c178:9417|cert name: DXX0423  
[1] 04B4.1500::09/21/2012-16:48:35.737 [ikeext] ike_cert_c225 IkeDumpCert() - 29|2002:c178:9417::c178:9417|cert hash: 655f0d6dafcf3e514417653459100ecf3b39b187  
[1] 04B4.1500::09/21/2012-16:48:35.737 [ikeext] ike_cert_c206 IkeDumpCert() - 29|2002:c178:9417::c178:9417|cert name: euro-SERV06-CA  
[1] 04B4.1500::09/21/2012-16:48:35.737 [ikeext] ike_cert_c225 IkeDumpCert() - 29|2002:c178:9417::c178:9417|cert hash: 2c57a29dce6f05be03b2640b5407189924a3fced  
[1] 04B4.1500::09/21/2012-16:48:35.737 [ikeext] ike_cert_c1509 IkeIsCertChainAcceptable() - 29|2002:c178:9417::c178:9417|Doing BASE CAPI verification  
[2] 04B4.1500::09/21/2012-16:48:35.741 [user] wfp_error_c327 WfpReportSysErrorAsWinError() - |2002:c178:9417::c178:9417|CryptAcquireCertificatePrivateKey failed with Windows error -2146893807(NTE_NOT_FOUND)  
[2] 04B4.1500::09/21/2012-16:48:35.741 [user] wfp_error_c397 WfpReportError() - |2002:c178:9417::c178:9417|IkeGetSigKeyProv failed with HRESULT 0x800735fc(ERROR_IPSEC_IKE_NO_PRIVATE_KEY) -------> NO access to private key

Note This is a "FAST PUBLISH" article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use for other considerations.

Article ID: 2797301 - Last Review: 03/26/2013 18:16:00 - Revision: 4.0

Microsoft Forefront Unified Access Gateway 2010

  • KB2797301