One of our customers suddenly had the following error pop up today on their Direct Access server and clients: “A client certificate was not provided”.
After a bit of troubleshooting we checked the Direct Access wizard we checked the DCs that were configured and noted that some where emboldened. Emboldened DCs in the list show new DCs added and these were configured to be used – interesting! Additionally we came across this post: http://blogs.technet.com/b/sooraj-sec/archive/2012/08/11/uag-da-clients-do-not-connect-to-the-internal-network-and-on-uag-server-we-get-a-getting-quot-a-client-certificate-was-not-provided-quot-warning.aspx.
This prompted us to double check we had communication to the DCs – all pinging fine. After a bit more investigation we found that whilst we could ping the local DC we couldn’t actually connect to it. After rebooting via the console DA sprang to life! But why just on that DC – what about fail over and redundancy? After reading through the article it became apparent that the other DCs clearly couldn’t route back to the UAG servers but only one could (the one that hung). Whilst adding a persistent route does work it really shouldn’t be necessary in a fully Active Directory integrated environment. After a bit more checked we realised that the subnet the UAG servers were on was not declared in Sites and Services! No wonder the DCs couldn’t route to it – they had no idea where that subnet fits in to the environment. Our customer is looking to fix this and do some testing!
Experts in transformation
