Implementing Microsoft DirectAccess Step by Step: Part 7
Before testing DirectAccess functionality, client needs to be added to the DirectAccessClients computer group. Use the following steps to complete this task:
1. On DC01, launch Server Manager.
2. Expand Roles\Active Directory Domain Services\Active Directory Users and Computers\example.local and select the OU that contains the DirectAccessClients group.
3. Right-click the group DA_Clients and select Properties.
4. Select the Members tab, and then click the Add button.
5. In the Select Users, Contacts, Computers, or Groups dialog box, click Object Types, check
Computers, and click OK.
6. Under Enter the Object Names to Select (Examples), type Client1, and click OK.
7. Click OK to save.
8. Restart the CLIENT1 computer to have the changes take effect.
By restarting CLIENT1 you are ensuring that the new DirectAccess group policies are applied. Additionally, you may need to also run gpupdate.exe on the DirectAccess server. Once you have ensured that the DirectAccess group policies have been on all DirectAccess servers and clients you will need to restart the IP Helper service on all internal servers (this includes DC, fileserver, Webserver, and DA). To complete this task use the following commands:
net stop iphlpsvc
net start iphlpsvc
By restarting the IP Helper service, the systems will be able resolve the isatap.example.local DNS entry created by the DirectAccess Setup Wizard and will enable their ISATAP interfaces. Once the service has been restarted the internal IPv6 network should be fully functional and all systems should be able to reach each other using the IPv6 addresses as well as the IPv4 addresses.
The ping.exe tool can be used to verify that IPv6 is working. The -6 option forces ping to use
IPv6. The -4 option forces ping to use IPv4. The command to ping a computer DC01 using IPv6 is ping DC01.example.local -6. The command to ping a computer DC01 using IPv4 is ping DC01.example.local -4. Each computer should be successfully pinged with both commands. This can be a very useful technique when troubleshooting DirectAccess and IPv6.
Testing DirectAccess
The last task in the DirectAccess configuration is to test the deployment and verify DirectAccess functionality. As mentioned previous the DirectAccess functionality will be verified by trying to access
Fileserver and Webserver using the internal network (Test A) and the public network (Test B).
Use the following steps to complete Test A:
1. While logged into CLIENT1 to the internal network.
2. Select Start, enter cmd, and press Enter.
3. At the command prompt, enter ipconfig and press Enter. Figure 13 shows that CLIENT1 has been assigned an IPv4 address (192.168.1.5) on the internal network and that an ISATAP address has been automatically generated in the ISATAP tunnel adapter.
4. Next, try to access a share on flsrv-iflex.example.local to demonstrate access.
5. Finally, open Internet Explorer and access http://nls.example.local to demonstrate access. By completing Test A you should be able to demonstrate that CLIENT1 is connected to the internal network and is able to access resources and that the IPv6 transitional technologies are working internally, specifically ISATAP.
For Test B, the connection to the public network, execute the following steps:
1. Connect the DirectAccess client CLIENT1 to the public network.
2. Select Start, enter cmd, and press Enter.
3. At the command prompt, enter ipconfig and press Enter. Figure 14 shows that CLIENT1 has been assigned an IPv4 address (14.194.56.174) on the public network and that a 6to4 address has been automatically generated with the 6to4 2001: prefix in the 6to4 tunnel adapter.
4. Next, try to access a share on flsrv.example.local to demonstrate access.
5. Finally, open Internet Explorer and access http://nls.example.local to demonstrate access.
By completing Test B you should be able to demonstrate that CLIENT01 is connected to the public network, able to access internal resources and that the IPv6 transitional technologies are working publicly, specifically 6to4.
6. To verify IP-HTTPS connectivity you will need to disable the Teredo interface by executing the following command:
netsh interface teredo set state disable
7. After disabling the Teredo interface execute the following command to verify the IP-HTTP connection
(the output should show an active status as shown in Figure 16):
netsh interface httpstunnel show interfaces
FIGURE 16 IP-HTTPS status.
8. Next, try to access a share on flsrv to demonstrate access.
9. Lastly, open Internet Explorer and access https://webmo.example.local to demonstrate access.
Leave your comments if you are having any issues, we will guide you.
No comments:
Post a Comment