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


Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.