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
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.
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 : http://technet.microsoft.com/en-us/library/jj134161.aspx. 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
Les derniers articles par Benoit (tout voir)
- Azure Automation en panne de certificats? - 28 février 2018
- Managed Service Identity pour machines virtuelles Windows - 13 février 2018
- Sécuriser son exposition RDP Internet Azure - 22 janvier 2018