UPDATE! Hereby a quick note that you no longer have to contact support, it’s available in the in the December Windows Update. Just install the latest Windows Update on your Windows Server 2012 R2 and you should be good to go. December 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 http://support.microsoft.com/kb/3013769
UPDATE! A private hofix (for now) is available that fixes URL length issues with Windows Application Proxy (applicable for NDES deployments) KB523052. This hotfix can be requested through a PSS case. For more details click here .
For those who are using Web Application Proxy (WAP) and intent or already have been published Network Device Enrolment Service (NDES) might noticed this isn’t working, even when pass-through preauthentication is configured. This post will go into details how NDES is working including a brief explanation of the issue.
The Network Device Enrollment Service (NDES) allows mobile devices running without domain credentials to obtain certificates based on the Simple Certificate Enrollment Protocol (SCEP). The user certificates can be used for managing company resource access (E-mail, WiFi- and VPN profiles) instead of using user name + password. This existing technique is recently emphatically re-evaluated by the use and application for mobile device management in relation to BYOD scenarios.
Before going in details to the problem, here is a short explanation of NDES is working in relation to Web Application Proxy (WAP), Configuration Manager and Microsoft Intune.
- Administrator configures policy in Configuration Manager 2012 R2.
- Policy is sent to Intune service where details about the cert policy are used to create the challenge for the device(s).
- Policy is pushed to mobile device by Intune service during the next check-in. This policy contains the URL of the NDES server as well as the challenge generated by Intune.
- Device contacts the NDES server using the URL from #3 and provides the challenge response. (This is why your NDES server needs to be available externally in some way)
- NDES Server (using our SCCM policy module) talks to the SCCM Certificate Registration Point (CRP) to validate challenge. You’ll need to make sure that 443 (SSL) is open between the NDES Server and the CRP for this validation to happen.
- CRP responds to NDES server with “true” or “false” to challenge verification. (Again, over 443 SSL.)
- If challenge is OK then the NDES server communicates with the CA to get a certificate for the device. You’ll need to make sure that the appropriate ports are open between NDES and CA for this to happen.
- NDES delivers certificate to mobile device.
(thanks Bob & Pieter for sharing!)
After extensive throubleshooting and research in close collaboration with Enterprise Mobility TSP- and Intune Incubation engineers, we could reproduce the issue and concluded the challenge response from mobile devices didn’t reach the NDES server. In other words, all challange requests are blocked by WAP.
For some reason the HTTP Protocol Stack driver (HTTP.SYS) is not able to handle and forward the PKI_Operation request and therefore the challenge response will fail.
As already mentioned by program manager Chris Green of the Windows Intune Team a hotfix will be available soon which solves this issue and allows you successfully publish Netwerk Device Enrollment Service through Web Application Proxy (WAP).
I’ll update this post and notify you when the new hotfix for Web Application Proxy (WAP) becomes savailable. Further big thanks to Pieter Wiglevens and Bob Roudebush for assisting to get this solved including the involved of the enginering team to produce a hotfix within a short time!