We will now proceed with the remaining steps of our DirectAccess deployment. In the following phase of our configuration we\u2019ll need to setup the Remote Access Server<\/i>. Once you click on the Edit<\/i> button from Step 2 of the DirectAccess map, you will be presented to the following wizard:<\/span><\/p>\n Add the public DNS name or the IP address of your Remote Access Server. Note that my DirectAccess server is located behind an edge device (my router who\u2019s performing NAT) and it\u2019s deployed with a single network adapter so I\u2019ll chose the appropriate option.<\/span><\/p>\n In the following window we\u2019ll have to set the network interface that is exposed to our private network. Note that DirectAccess uses computer certificates to authenticate IP-HTTPS<\/i> connections, you can either use a self-signed certificate<\/a> or deploy one from your local CA (Certification Authority).<\/i><\/span><\/p>\n The last page of the Remote Access Server configuration wizard, deals with how DirectAccess clients authenticate with the server:<\/span><\/p>\n Once the Remote Access Server has been configured, it\u2019s time to proceed further with step 3 that deals with Infrastructure server<\/i> setup:<\/span><\/p>\n On the first page of the wizard you will have to specify the network location server. You can opt for a remote web server<\/i> or use the Remote Access server<\/i> (with a self-signed certificate for authentication). As we\u2019ve mentioned in a previous article, the network location server is used by DirectAccess clients to determine if they are located within the enterprise network or connected directly to the public Internet:<\/span><\/p>\n You can add the name suffixes and the associated DNS servers<\/a> that are authoritative for a particular domain in the DNS page of the wizard. This basically builds a table that informs DirectAccess servers what DNS server should be queried for a particular domain name. This table is also known as NRPT (Name Resolution Policy Table)<\/i> which is written into the GPOs and applied to the DirectAcess clients. In this section you will also have to configure the local name resolution behavior that will be used by clients. It\u2019s recommended that you use local name resolution if the name does not exist in DNS or the DNS servers are unreachable when the client computer is on a private network<\/i>. By selecting this option, you ensure that if DNS servers are not responsive for whatever reason, their names and IPs are not leaked through local name resolution:<\/span><\/p>\n In the following section is where the ordered search suffix list can be created. This option allows clients to query for single-label DNS names. The host will then append each suffix (in the order they were added here) to search for a particular DNS name:<\/span><\/p>\n In last page of the wizard we specify the management servers that cannot be detected by DirectAcess clients. I\u2019m saying only \u201cservers that cannot be detected\u201d because DNS can be used for example, to detect Domain Controllers or SCCM servers. Servers that can be added here may include third party update software or antivirus. You can add the FQDN, IPv4 or IPv6 address of these machines:<\/span><\/p>\n We\u2019ll finish our DirectAcess configuration with Step 4 in which we can optionally specify application servers if end-to-end authentication and encryption is needed. By default, DirectAcess provides these two security mechanisms between the client and the server. If you want to extend authentication and encryption further, you can specify them within this section. Optionally, you can restrict access only to the servers specified here or use only authentication without encryption. Note that if you choose to extend authentication to other application servers, IPv6 addressing is required:<\/span><\/p>\n Now that the final step has been completed, we can view the configuration summar<\/i>y by accessing the right section of the DirectAcess console. All these settings will be applied to the clients once you click the apply<\/i> button:<\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-1.png\")
<\/a><\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-2.png\")
<\/span><\/p>\n\n
![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-3.png\")
<\/a><\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-4.png\")
<\/a><\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-5.png\")
<\/a><\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-6.png\")
<\/a><\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-7.png\")
<\/a><\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-8.png\")
<\/a><\/span><\/p>\n
![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-9.png\")
<\/a><\/span><\/p>\n![\"Installing](\"https:\/\/www.poweradmin.com\/blog\/wp-content\/uploads\/2015\/07\/installing-and-configuring-directaccess-in-windows-server-2012-part-2-10.png\")
<\/a><\/span><\/p>\n