locked
Server 2012 DirectAccess - Third-Party Computer Cert for Windows 7 Clients RRS feed

 , 
 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi All

    The documentation clearly state PKI is now "optional" even for Windows 7.

    http://technet.microsoft.com/en-us/library/hh831416.aspx

    Windows Server 2012 includes features to facilitate deployment, particularly for small and medium size organizations. These new features include a simplified prerequisite list, removal of the need for a full PKI deployment, integrated certificate provisioning, and removal of the requirement for two consecutive public IPv4 addresses

    ...

    The DirectAccess server should have a server authentication certificate for TLS issued by a Certification Authority (CA) that is trusted by the DirectAccess clients. This can be a public CA and does not require an internal PKI deployment.

    ...

    I'm keen to find out, has anyone used a Third Party Certificate as yet? If so, who did you use, what Certificate did you need to buy and what process did you use to generate and isntall the certs?

    Sunday, October 21, 2012 8:19 AM

Answers

  • Question
    Sign in to vote
    1
    Sign in to vote

    I absolutely recommend using an SSL certificate from a public CA for the IP-HTTPS listener, exactly as you said. That way you don't have to worry about publishing your own CRL at all, you let them do it for you. If the certificate is in place before you run through the DirectAccess wizard, it will find and use it automatically, otherwise if you add the cert later (just like you would any SSL cert to IIS) - then you can go back into the Remote Access configuration and specify which cert to use.

    Yes, in small companies it is common to see the CA role on a (or the) DC. Of course "best practices" for CA servers in general include dedicated servers, and more than one for redundancy, but that is just not always a reality :) I am not aware of any conflicts of the CA role and other roles, except I wouldn't put the CA role on the DirectAccess server itself.

    Tuesday, October 23, 2012 6:41 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
    #crickets...
    Monday, October 22, 2012 10:06 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    First I've seen that quote.  We've been testing with an internal PKI, and if we can do it with a third-party cert, we absolutely will.  I pushed Microsoft on this a few weeks ago through the partner newsgroups, but they couldn't give a response.  I need to open a support case with them (Not sure how else to get anyone to respond.)  Would love to hear someone chime in on this.
    Tuesday, October 23, 2012 1:26 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hey guys, sorry this is probably being overlooked because it's not posted in the DirectAccess forums (it's a little confusing because it's DirectAccess, UAG and TMG but is still the core area for DA questions of any kind)

    Anyway, having an internal PKI is still absolutely required to make Windows 7 clients connect over DirectAccess, even when running the DA Gateway on Server 2012. Windows 8 clients can get away without it because they have this new feature called Kerberos Proxy, which brings the DA environment down to one IPsec tunnel instead of two, and with this the Win8 client computers don't need a machine certificate issued to them from an internal CA server. Win7 clients do not know anything about Kerberos Proxy, and still require a machine cert issued to them by an internal CA.

    I have done lots and lots of DA implementations and even with Server 2012 I still plan to recommend the full PKI solution to all of my future customers, it's simply more secure. And it's not that complicated to implement! Here is a post that outlines the certificate requirements to make a successful DirectAccess environment. This is specifically written for UAG DirectAccess, but it applies 100% to Server 2012 DA: http://www.ivonetworks.com/news/2012/05/directaccess-help-im-drowning-in-certificates/

    Tuesday, October 23, 2012 6:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Confusing (re: forums) indeed!  I assumed that forum was only if you were using DA under UAG, which we're not.

    Anyway, your post is helpful.  The biggest issue we have is publishing the CRL.  We don't have any sites that we host internally, so, we'd have to stand-up another IIS instance and publish it.  Not the end of the world, but seems like another security hole and waste of resources.  If we can put a third-party SSL on the IP-HTTPS listener, then that certainly helps!

    Finally, it sounds like no matter what, we need to have internal PKI for the machine certs - no way around this in terms of using a third-party.  

    You are correct, for the most part - standing up a PKI (As we did in testing) was easy enough, and if it's just for the machine certs, no biggie.  The question is - where do we put the PKI role?  We've been advised putting it on a DC.  Are there any other roles that are not recommended for being with a CA?  We'd prefer not to stand-up another server just for PKI - our clients are small and typically under 100 seats, so many might just have two or three servers (DC, Exchange, File/Print services, maybe an app and/or Terminal Server box.)

    Tuesday, October 23, 2012 6:30 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I absolutely recommend using an SSL certificate from a public CA for the IP-HTTPS listener, exactly as you said. That way you don't have to worry about publishing your own CRL at all, you let them do it for you. If the certificate is in place before you run through the DirectAccess wizard, it will find and use it automatically, otherwise if you add the cert later (just like you would any SSL cert to IIS) - then you can go back into the Remote Access configuration and specify which cert to use.

    Yes, in small companies it is common to see the CA role on a (or the) DC. Of course "best practices" for CA servers in general include dedicated servers, and more than one for redundancy, but that is just not always a reality :) I am not aware of any conflicts of the CA role and other roles, except I wouldn't put the CA role on the DirectAccess server itself.

    Tuesday, October 23, 2012 6:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    How do I go about preparing a CA request for DirectAccess with a public CA?
    Tuesday, November 13, 2012 5:24 PM
  • Question
    Sign in to vote
    1
    Sign in to vote
    Open IIS and generate  a CSR (Certificate Signing Request), the information inside the CSR is what the public CA will need to be able to issue you a certificate. In IIS7, you click on the servername on the left, then click on the "Server Certificates" applet in the middle, then click on the Action over in the right to generate a csr.
    Tuesday, November 13, 2012 5:32 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thank you! I just purchased a new cert to hopefully solve my issues with DirectAccess. I will try this now!

    http://social.technet.microsoft.com/Forums/en-US/winserver8gen/thread/3ab274e1-afee-4a24-a0bf-a001a3f22177

    Tuesday, November 13, 2012 5:33 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    I use an external hostname with the same name as my internal domain. When I setup the new cert with DA I got this error:

    Warning: The NRPT entry for the DNS suffix .<DOMAIN>.net contains the public name used by client computers to connect to the Remote Access server. Add the name da.<DOMAIN>.net as an exemption in the NRPT.

    How do I fix that?

    Tuesday, November 13, 2012 6:03 PM
  • Question
    Sign in to vote
    2
    Sign in to vote
    In the "DNS Suffixes" screen of Step 3 in the DirectAccess wizards, you need to set this external name as an Exclusion from that DNS Suffix "naming table" (the NRPT). The NRPT is essentially a glorified HOSTS file that tells the DA clients what names to push through the DirectAccess tunnels, and what names not to. Your external name for DirectAccess must not be included in the NRPT or you will enter a catch-22 situation :)
    • Proposed as answer by Pyr3x Tuesday, November 13, 2012 6:36 PM
    Tuesday, November 13, 2012 6:25 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    MAN I COULD KISS YOU RIGHT NOW!

    THANK YOU!

    Not only did you solve my problem with requesting a certificate but it also fixed the BIG issue I have been having with DA since I implemented my UTM50 Firewall! 

    My clients are connecting now! And not only do they connect they are working 100% of the time! THANK YOU!!!!!!!!!!!!!!

    Tuesday, November 13, 2012 6:38 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    I'm glad I could help, but I'm going to have to respectfully decline that offer! LOL
    Tuesday, November 13, 2012 7:03 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    OK - I have to re-open this thread (And hope for an answer. . .)

    How many certificates are we talking about here with DA?  We have the IP-HTTPS listener cert, the machine cert (Must be PKI), and then the NLS cert, right?

    I hear people talking about using a third-party cert for IP-HTTPS, which makes sense so you don't have to deal with CRL.  But what about the NLS cert?  If you use it from PKI, then you're back to the CRL issue again, no?  Or do you also do a third-party cert for NLS?  Still need to wrap my head around why NLS even needs a cert. . .

    Friday, December 14, 2012 11:12 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The NLS website must be HTTPS, that is a requirement from Microsoft and that is why it requires a cert. The NLS cert is generally issued from the internal CA server so there is no cost. Being part of the same domain as the CA server, your client computers will automatically trust the issuing CA and they will only be contacting the NLS website (and therefore the CRL) when inside the network, so you don't have to do any of the work of configuring your CRL to be externally accessible like you would with the IP-HTTPS if you tried doing it with your own cert. I wrote up an article a while ago on the 3 different places certs are used in DA, hopefully this clears it up :)

    http://www.ivonetworks.com/news/2012/05/directaccess-help-im-drowning-in-certificates/

    Saturday, December 15, 2012 3:38 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Hi. For the machine clients or client certificates, can I use the same cert used on IP-HTTPS - da.mydomain.com? How do I assign it to clients using our Internal CA? Thank you.
    Thursday, April 18, 2013 1:41 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The machine certificates are not the same as the SSL certificate that you use for IP-HTTPS.

    The IP-HTTPS certificate is an SSL cert that is typically issued from a public CA, like GoDaddy.

    The machine certificates are issued from your own internal Enterprise CA (certification authority) server. If you don't have one, you'll have to add the role to a Windows Server and create one. Then you can issue those certificate to the laptops by opening MMC on the laptops, snap-in the Certificates (choosing "Computer") and request a new certificate. You can use the built-in "Computer" template from your CA server to issue the certs to each laptop. You will need one of these machine certificates issued in the same way to your DirectAccess server or servers as well.

    Friday, April 19, 2013 3:45 PM