Archives de catégorie : OTP

MS-OTPCE – One-Time Password Certificate Enrollment Protocol

I had many questions these days about DirectAccess OTP authentication mechanism. I already published multiple blog posts on the subject:

All these blog post are useful to understand and troubleshoot DirectAccess OTP scenario but on resource was missing : the Windows protocol definition for [MS-OTPCE]. Now you have all information to clearly understand the authentication process.


BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

Some new DirectAccess unsupported scenarios

I was involved in some DirectAccess pre-sale & projects with One-Time Password feature. For a while we have a dedicated Technet web page for special cases / requests or scenarios DirectAccess Unsupported Configurations. I used to have a look at it some time to time to check if I missed something. Today, I was surprised to  discover new section related to OTP scenarios :


I understand for the second one. We must establish a SSL session excluded from the IPSEC tunnel, that is not possible with force tunneling. IMO, force tunneling feature need to be reviewed (a wish for Windows V.Next). From a technical point of view we can replace it with the Web Filtering for DirectAccess users approach.

For the first one, it’s a surprise. I was about to consider the SSL Offload for IP-HTTPS DirectAccess Traffic from Windows 7 Clients using F5 BIG-IP proposed by Richard Hicks for a project of mine including OTP. I will have to forget SSL Offload. In some way it’s logic, we cannot have different way to manage SSL authentication for the same endpoint (ISAPI filter used by OTP and IPHTTPS endpoint).


BenoîtS – Simple and Secure by Design but Business compliant.

Tips for your DirectAccess OTP deployment

While troubleshooting a lab for a customer of mine, I discovered that troubleshooting OTP problems can be painful, especially if you do not know some Jedi Minds tricks. So use the force (and your Brain).


OTP Status on Remote Access Management Console

According to the Remote Access Console, My DirectAccess infrastructure have a problem with OTP feature. But I can notice currently connected DirectAccess Clients. And OTP authentication process was successful for them. So What does the console test?


Technically, the Remote Access Management Console test network connectivity with Network Policy Server that will manage authentication requests to OTP infrastructure. This test include :

  • NPS network connectivity
  • User authentication


But witch user are we talking of? After some research and network traces, it’s the DAProbeUSer account that is used by the Remote Access Management Console to test authentication process every five minutes.



My recommendation is to use these registry key to configure an alternate password for this account (even if it does not exists in Active Directory) and allow user authentication for this user into your OTP infrastructure. 


From my point of view, this test prove nothing as this account does not exists in Active Directory and is not recognized by your OTP infrastructure.


It only prove that your OTP infrastructure is able to deny authentication requests.


Alternate test

I have a better tests, just test the OTP process responsible for authentication. In UAG 2010, it was a dedicated portal trunk. In Windows Server 2012, it’s much more simple :



Yes, in Windows Server 2012, OTP authentication process rely on a old school ISAPI extension running inside IIS. Take a look at the Internet Information Services console on your DirectAccess gateway.



You will find a dedicated web site running with it’s own application pool. Calling the DAAUTHOTP.DLL allow to test this ISAPI extension and provide an essential information : Time. Time synchronization is critical to OTP authentication.


On DirectAccess client-side

On client side, you can also call the DirectAccess OTP ISATAP extension. It’s reachable even outside IPSEC tunnels.



That’s a good thing to monitor using System Center Operation manager 2012/2012R2. Web Application Availability Monitoring is a useful feature for that.

And the OTPCredentialProvider event log located on your DirectAccess clients (if you installed the DirectAccess Connectivity Assistant on Windows 7), give enough details to troubleshoot OTP authentication problems.


Don’t forget to enable this event log if your want to read something.


Stay tuned for other DirectAccess OTP deployment tips.


BenoîtS – Simple and Secure by Design but business compliant

The 0x80040008 DirectAccess + OTP case

I was recently involved in a DirectAccess + OTP deployment. The DirectAccess setup began like a charm (Powershell based) but strange things began to happened when I added OTP authentication feature for Windows 7 DirectAccess clients. From an end-user point of view, here is the problem :



My first reaction was to Google Bing the does not help a lot. Let’s trace this problem into all layers of the DirectAccess  OTP authentication process.


Trace from the URA console

That was the begin of this long journey. According to the Dashboard view of the Remote Access Management Console everything is healthy.



So problem, may not be located on the URA server. If you know how OTP work with DirectAccess, you should know that the URA server is configured as a RADIUS client that send authentication requests to a RADIUS server. In my case, this RADIUS server is a dedicated Network Policy Server that include the GEMALTO NPS extension for GEMALTO Server SA. Illustration bellow is one of the message I found in the application event log of my NPS server.



According to this event, GEMALTO NPS extension successfully authenticated my user. This second event prove that this authentication was performed with Username and OTPPassword and not user password.



This point is very important because the Network Policy role included with Windows Server 2012 does not support the Challenge/response exchange Radius messages. This information if critical when you setup your GEMALTO NPS Extension.



With this second message, I’m sure that the NPS agent returned a positive result for my authentication request.4


At last, this ultimate NPS message prove that the Network Policy Server granted user access. So there is no problem with Network Connections or Network policies. Definitively, my problem is not an OTP problem.



Back to the client-side

If problem is not located on server side, let’s come back to client side. By default, the OtpCredentialProvider/Operational log is not enabled and is only available is you install the DirectAccess Connectivity Assistant on your Windows 7 computer. This is a PKI problem.



DirectAccess OTP authentication process is described on TechNet at this location : The DirectAccess computer will use a specially designed certificate to sign a certificate request generated to prove OTP user authentication. In my case, the signing certificate is present in my DirectAccess.


Move to the ADCS-side

If we have a certificate request problem, we should have a certificate request denied in the ADVS console. Now we know it’s a ADCS related problem, not a DirectAccess or OTP.



Let’s have a look at the URAOTPLogin certificate template.



First thing I noticed about this certificate template is the key length. I was aware that minimum key length requested by Microsoft operating system is now 1024 bits (unless you did not installed associated KB).



I tried with a 1024 minimum key size, but it did not solved the problem. If key length is not the problem, let see on the signature side.



After some tests, I enforced cryptographic provider to “Microsoft RSA SChannel Cryptographic Provider” and found it was the root cause of the problem.



Enabling OTP DirectAccess capability is a simple checkbox in the Remote Access Management Console but rely on precise certificate templates prerequisites and specific OTP configuration.


BenoîtS – Simple and Secure by Design but Business compliant