DirectAccess with Windows Azure Multi-Factor Authentication Server RRS feed

  • Question

  • Hi,

    We're having some troubles implementing OTP-functionality for our DirectAccess-solution. We have DA-server with dual nics (one internal and one external) behind a firewall. We are successfully running it with Windows 7 computers using certificates issued by our own CA. Everything works fine (e.g. 6to4, Teredo and IP-HTTPS) and computers connect instantaneously.

    Then we decided to try to implement OTP-functionality using Azure MFA. We have downloaded the on-premises installation and configured a server with a couple of trial users synced from our Active Directory. It works flawlessly when using the portal and the built-in tests on the MFA. We receive the text messages promptly and are granted access.

    However when we tried to connect it to our DA-server things got weird.

    First of all our DA-server refuses to recognize our Issuing CA even though it is domain joined and published in our Active Directory. It worked the first time we went through the wizard, but even since it just keeps saying that "no CA servers can be detected". We ended up doing it the powershell way and the Operations status shows no error. When we added the Issuing CA and the Radius Server (our MFA-server) as Infrastructure Servers we got an error message saying that "One or more IP addresses of management server cannot be added because they are associated with the web probe URL" (which they don't).

    We went ahead and started testing the OTP-functionality - assuming this was some strange bug as well. Following the closest thing to a requirement specification we could find from MS regarding the certificates required. Both with a Windows 8.1 Ent-client and a couple of Windows 7 Ent-clients but neither are getting any password prompts. We can see with wireshark and in the logs that the DAProbeUser can communicate between the DA and the MFA. If we try to access the DaOTP-IIS-site we get a certificate error. The IIS-certificate is issued from the same trusted Root CA as the client certificate and all certificates are valid. The CRL:s are accessible both externally and internally.

    We are looking through the local computers OtpCredentialProvider logs but for the Windows 8.1-ones they are only saying Error 10001 (unable to send authentication information to error 12175). And for the Windows 7 clients we are getting Error 10003 (Either private key cannot be generated or user cannot access certificate template on the DC. Which we verified that we can using the infrastructure tunnel only). No other IPv4 traffic seems to be communicated between the two servers according to Wireshark.

    We have also tried using our SafeNet on-prem RADIUS-solution but no traffic seem to get sent to that server neither.

    So TL;DR:

    - Can anyone provide the precise certificate requirements for setting up DA OTP?

    - Are there any good tools for troubleshooting DA OTP-functionality? 

    • Edited by Rashi Vin Tuesday, September 9, 2014 4:07 PM
    Tuesday, September 9, 2014 3:42 PM

All replies

  • Hi,

    I was involved in some smartcard & OTP DirectAccess deployments. Yes it's hard. Certificate requirements are documented here : We had multiple discussion about using Microsoft MFA with DirectAccess and conclusion was it would not work. It may work for the first OTP authentication bu may not work for user OTP certificate renew. Have a look at this :

    if you experienced the powershell way to enable OTP, you might be using Windows Server 2012 R2. You already discover that DirectAccess clients will connect to a secure web site hosted on the DA Gateway. Behind, it's an ISAPI filter. I wrote a blog post about OTP authentication problems that might be usefull to you :

    According to error you get on client side, you have a problem with the certificates :

    -Does your DirectAccess Gateway have it's OTP signing certificate ?

    -Does your DirectAccess Gateway have it's OTP signing certificate before trying to authenticate with OTP? 

    -What kind of errors do you have on the ADCS side. (rejected requests, ...).

    IF OTP signing certificate is not present on client-side, OTP authentication cannot work.

    BenoitS - Simple by Design

    Monday, September 15, 2014 5:43 PM
  • At last some tips to troubleshoot OTP authentication :

    BenoitS - Simple by Design

    Monday, September 15, 2014 5:45 PM
  • Hello Benoit,

    Thank you for your reply. If we understood your blog post correctly then we are supposed to be able to access and not get a 403.7 error-page, even if the back-end Radius isn’t fully functional yet?

    The DA server has the OTP signing certificate (confirmed this on the issuing CA and the server’s computer certificate store), it renews this certificate once per day (as per the guide for the templates on:

    We’re not seeing any errors on the AD CS server, no requests, no rejections (for the client certificates), but this could be due to the settings followed for the client template on the TechNet guide (Do not store certificates and requests in the CA database)?

    What do you mean with "IF OTP signing certificate is not present on client-side, OTP authentication cannot work"? The signing certificate should be on the server side, or are we mistaken?

    Also, according to it is stated:

    “2.The administrator establishes one or more implementation-specific<1>CA servers”

    But other guides specifically mention that you can use your current CA environment and that you’re not required to install a dedicated CA for this particular task. 

    • Edited by Rashi Vin Tuesday, September 16, 2014 12:58 PM
    Tuesday, September 16, 2014 12:57 PM
  • Hi,

    if you have a look at the IIS console on your URA server, you will find a DAOtpSite with a DAOtpApp virtual directory. If you look at the ssl settings at this level, you will see that SSL is required but also client authentication. Required certificate is the signing certificate. 403.7 Means than authentication failed due to missing client certificate. Certificate is used to be sure that only a DirectAccess client configured with OTP can reach the DAOtpApp witch contains an ISAPI filter.

    So you need to OTP signing certificate on server side (for monitoring purpose) and on client-side to be able to submit your OTP request.

    if you need more information about OTP authentication process, have a look at this :

    At last, can can use your existing issuing CA to deliver these certificates but as DirectAccess & NAP use certificates as token (I recognize you as authenticated, as healthy), my recommandation is to have a sub-ca dedicated to these certificates. Consider that with OTP & NAP, it's not a standard certificate use case (identity). That's why we recommand to have a sub-CA dedicated to these use-cases.

    BenoitS - Simple by Design

    Wednesday, September 17, 2014 5:36 PM
  • Hello,

    Thank you for your advice! We can now see communication between the RADIUS server and the DA-server after creating a dedicated Subordinate CA. The RADIUS request returns the value successful according to wireshark and in the OTPCredentialProvider eventlog it is says that OTP completed successfully. Our clients also state in their application logs that "Certificate enrollment for DOMAIN\User is successfully authenticated by policy server {GUID}" "And Certificate enrollment for DOMAIN\User successfully load policy from policy server" from the Source "CertificateServicesClient-CertEnroll". Though we cannot see the OTP-certificate in the User certificates-snapin under the "Personal"-folder after OTP-authentication has been successful.

    Anyhow, after entering the OTP the client shows a prompt saying "Verifying your one-time password" and after that has completed it says "The smart-card certificate used for authentication was not trusted" . And that of course leads to the intranet-tunnel connection not being established. For testing purposes we tried changing the template for the OTP Logon so that it was allowed to be stored in our new OTP-Specific CA and that way we can confirm that the certificates get issued for our users when they authenticate with OTP. It seems somehow that the Direct Access server won't allow their connection even though they have a valid certificate.

    Thursday, September 18, 2014 5:14 PM
  • Hi,

    if that solve a part of your problems, it's a good point.

    Your right, there is no certificate in the user certificate store (it was back in UAG 2010 SP1 times). Now this certificate is stired somewwhere else.For your last problem, whar do you have in the OTP event log on client-side? Can your DirectAccess clients reach the CRL used by your ADCS role?

    BenoitS - Simple by Design

    Thursday, September 18, 2014 6:51 PM
  • The OTP Log on the client-side says "OTP authentication completed successfully. The OTP Certificate was issued by CA Server [dedicated OTP-CA]". We have verified that the CRL is reachable externally.
    Monday, September 22, 2014 8:34 AM
  • Hi,

    So DirectAccess OTP authentication process works. Now let's see why tunnel does not initialize.Are your sure that your AC chain is trusted (ROOT, Intermediate, Issuing CA) by your DirectAccess client? Do you see them in the result of a CERTUTIL.EXE on your DirectAccess client?

    BenoitS - Simple by Design

    Monday, September 22, 2014 8:43 AM
  • Hey,

    The CA chain is valid, from the OTP CA up to the root CA. We see them in the Certutil tool and in the certlm.msc console, the issuing CA and the OTP CA are trusted as intermediate CA's and the offline root CA is in the Trusted Root CA container. We verified this also by opening the OTP CA intermediate Cert on the client and it is identified as valid. And we can see the full chain on the Certification Path.

    Monday, September 22, 2014 10:53 AM
  • Hi

    Let's see what's Under the Hood with IPSEC. Just run this command on the DirectAccess client to enable extended logs auditpol.exe /set /SubCategory:"IPsec Main Mode","IPsec Extended Mode" /success:enable /failure:enable. We will be able to trace IPSEC tunnel negociation and find the reason why it does not establish correctly.

    BenoitS - Simple by Design

    Monday, September 22, 2014 12:07 PM
  • Hello Benoit,

    The only audit failures we get from IPsec are the following:

    An IPsec main mode negotiation failed.

    Local Endpoint:
    Local Principal Name:-
    Network Address: [ipv6-address of computer]
    Keying Module Port:500

    Remote Endpoint:
    Principal Name: -
    Network Address:[ipv6-address of DA-server]
    Keying Module Port:500

    Additional Information:
    Keying Module Name:IKEv1
    Authentication Method:Unknown authentication
    Impersonation State:Not enabled
    Main Mode Filter ID:0

    Failure Information:
    Failure Point:Local computer
    Failure Reason:No policy configured

    State:No state
    Initiator Cookie: 422b09b60877f0f7
    Responder Cookie: 0000000000000000

    An IPsec extended mode negotiation failed. The corresponding main mode security association has been deleted.

    Local Endpoint:
    Principal Name: [domain\user]
    Network Address:[ipv6-address of computer]
    Keying Module Port:500

    Remote Endpoint:
    Principal Name: host/[internal FQDN of DA-server]
    Network Address:[ipv6-address of DA-server]
    Keying Module Port:500

    Additional Information:
    Keying Module Name:AuthIP
    Authentication Method:Kerberos
    Impersonation State:Enabled
    Quick Mode Filter ID:464388

    Failure Information:
    Failure Point:Local computer
    Failure Reason: SA establishment is not authorized because of lack of a PKINIT-based credential of sufficient strength.
    State:Sent second (SSPI) payload

    Though we see the same errors for our test users with OTP-exemption and they can establish an IPsec-tunnel for intranet-traffic and have no issues with DA whatsoever.

    Are you supposed to be able to see the OTP-configuration reflected in the IPsec-rules? We can see on the Corp-tunnel rule that 1st auth is computer certificate (from our issuing CA) and second is Kerberos v5. Should you be able to see user certificate from our OTP CA in that config?

    Monday, September 22, 2014 3:42 PM
  • So OTP is not the problem. Is this the only error you see?

    BenoitS - Simple by Design

    Monday, September 22, 2014 6:55 PM
  • Yes, those are the only errors that we receive. Reading through the thread I see that I have accidentally provided you with the wrong error message when the OTP Verification is completed. It doesn't say "The smart-card certificate used for authentication was not trusted". It says "The request is not supported". Sorry about that.

    We also found a peculiar entry in the Local Machine Certificate Store on the DA-server. A folder named OTPTrustedIssuers. In the subfolder Certificates we could find our Issuing CA. We tried to manually import our OTP CA Certificate into that store, but it disappeared on reboot. We then tried using a certificate issued from the OTP CA for IPSec on the DA-server (Computer certificates  under Remote Access Server Setup -> Authentication) . After changing that setting and issuing such a certificate to the DA-server the OTP CA was the one in that certificate store. However we still got the exact same error.

    Tuesday, September 23, 2014 6:06 PM
  • Hi,

    We were seeing this message in the Windows 8 preview. The DAOTPTrustedIssuers only reference ADCS instances that will be deliver the certificates. Signing certificate must be present in the computer\personnal store (i made a mistake when i said it must be present on client-side too).

    If we check the client-side log with the "The request is not supported" event, we would have related events on the DirectAccess Gateway (if you also enable audit with auditpol.exe /set /SubCategory:"IPsec Main Mode","IPsec Extended Mode" /success:enable /failure:enable)

    Let's see what we can learn from the Gateway-side at the same time.

    BenoitS - Simple by Design

    Tuesday, September 23, 2014 7:47 PM