TechOnTip Weblog

Run book for Technocrats

Archive for the ‘Direct Access’ Category

Microsoft Direct Access – Two NIC Architecture (Expanded)

Posted by Brajesh Panda on November 6, 2013

This is a two legged Direct Access implementation; where one NIC is in DMZ network & another one in LAN. Expanded version of 2nd option in this diagram http://wp.me/phPxo-nE. Click here to download below visio diagram.

Final Architecture Picture

Advertisements

Posted in Direct Access | 1 Comment »

Microsoft DirectAccess Group Policy WMI Filter Explained

Posted by Jason Heisley on June 18, 2013

Click here for other Direct Access related articles.

So when you setup DirectAccess by default it applies to only Laptops. In the documentation it states that this is done by a WMI filter but that’s it. So digging a bit deeper I found that it creates a WMI filter in Group Policy called “DirectAccess – Laptop only WMI filter” and adds the “DirectAccess Client Settings” GPO to that filter. Below I break down what the filter is and give some information on how you can create your own WMI filter for Group Policies.

This is the WMI Group policy created by DirectAcess:

The first Part selects only laptops.

Namespace: root\CIMV2

select * from Win32_ComputerSystem where PCSystemType = 2

The second part filters OS Types and Product SKUs.

Namespace: root\CIMV2

Select * from Win32_OperatingSystem WHERE (ProductType = 3) OR (Version LIKE ‘6.2%’ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 72 OR OperatingSystemSKU = 84)) OR (Version LIKE ‘6.1%’ AND (OperatingSystemSKU = 4 OR OperatingSystemSKU = 27 OR OperatingSystemSKU = 70 OR OperatingSystemSKU = 1 OR OperatingSystemSKU = 28 OR OperatingSystemSKU = 71))

So the filter evaluates to: laptops “PCSystemType = 2” and server “ProductType = 3″ or
Windows 2012, Windows 8 “Version LIKE ‘6.2%’” and Enterprise Edition “OperatingSystemSKU = 4″ or Enterprise N or Server Enterprise (evaluation installation) or Enterprise N (evaluation installation) or Windows 2008 R2, Windows 7 “Version LIKE ‘6.1%'” and Enterprise Edition or Enterprise N or Enterprise E or Ultimate or Ultimate N or Ultimate E.

So I am not sure why they are including server maybe just in case we have it installed on a laptop and want to use DirectAccess but never the less this is how it evaluates out.

How I got this information:

Below is where I found this info. I have put it here mainly for my own reference because I have not found another blog site where all this is all in the same place.

PCSystemType:

Source link

Windows Server 2003, Windows XP, Windows 2000, Windows NT 4.0, and Windows Me/98/95: This property is not available.

Value Meaning
0 (0x0) Unspecified
1 (0x1) Desktop
2 (0x2) Mobile
3 (0x3) Workstation
4 (0x4) Enterprise Server
5 (0x5) Small Office and Home Office (SOHO) Server
6 (0x6) Appliance PC
7 (0x7) Performance Server
8 (0x8) Maximum

ProductType:

Source post

Value Meaning
1 Work Station
2 Domain Controller
3 Server

Version:

This was pieced together from various sources on the internet.

Windows 10 Insider Preview  = 10.0%
Windows Server Technical Preview = 10.0%
Windows 8.1 = 6.3%
Windows Server 2012 R2 = 6.3%

Windows Server 2012 or Windows 8 = 6.2%

Windows Server 2008 R2 or Windows 7 = 6.1%

Windows Server 2008 or Windows Vista = 6.0%

Windows Server 2003 = 5.2%

Windows XP = 5.1%

Windows 2000 = 5.0%

OperatingSystemSKU:

So I pieced this together from this MSDN post and this incomplete post by converting the Hex numbers to decimal.

Stock Keeping Unit (SKU) number for the operating system.

Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0: This property is not available.

Version

OperatingSystemSKU

An unknown product

0

Ultimate

1

Home Basic

2

Home Premium

3

Enterprise

4

Home Basic N

5

Business

6

Server Standard

7

Server Datacenter (full installation)

8

Windows Small Business Server

9

Server Enterprise (full installation)

10

Starter

11

Server Datacenter (core installation)

12

Server Standard (core installation)

13

Server Enterprise (core installation)

14

Server Enterprise for Itanium-based Systems

15

Business N

16

Web Server (full installation)

17

HPC Edition

18

Windows Storage Server 2008 R2 Essentials

19

Storage Server Express

20

Storage Server Standard

21

Storage Server Workgroup

22

Storage Server Enterprise

23

Windows Server 2008 for Windows Essential Server Solutions

24

Small Business Server Premium

25

Home Premium N

26

Enterprise N

27

Ultimate N

28

Web Server (core installation)

29

Windows Essential Business Server Management Server

30

Windows Essential Business Server Security Server

31

Windows Essential Business Server Messaging Server

32

Server Foundation

33

Windows Home Server 2011

34

Windows Server 2008 without Hyper-V for Windows Essential Server Solutions

35

Server Standard without Hyper-V

36

Server Datacenter without Hyper-V (full installation)

37

Server Enterprise without Hyper-V (full installation)

38

Server Datacenter without Hyper-V (core installation)

39

Server Standard without Hyper-V (core installation)

40

Server Enterprise without Hyper-V (core installation)

41

Microsoft Hyper-V Server

42

Storage Server Express (core installation)

43

Storage Server Standard (core installation)

44

Storage Server Workgroup (core installation)

45

Storage Server Enterprise (core installation)

46

Starter N

47

Professional

48

Professional N

49

Windows Small Business Server 2011 Essentials

50

Server For SB Solutions

51

Server Solutions Premium

52

Server Solutions Premium (core installation)

53

Server For SB Solutions EM

54

Server For SB Solutions EM

55

Windows MultiPoint Server

56

Windows Essential Server Solution Management

59

Windows Essential Server Solution Additional

60

Windows Essential Server Solution Management SVC

61

Windows Essential Server Solution Additional SVC

62

Small Business Server Premium (core installation)

63

Server Hyper Core V

64

Starter E

66

Home Basic E

67

Home Premium E

68

Professional E

69

Enterprise E

70

Ultimate E

71

Server Enterprise (evaluation installation)

72

Windows MultiPoint Server Standard (full installation)

76

Windows MultiPoint Server Premium (full installation)

77

Server Standard (evaluation installation)

79

Server Datacenter (evaluation installation)

80

Enterprise N (evaluation installation)

84

Storage Server Workgroup (evaluation installation)

95

Storage Server Standard (evaluation installation)

96

Windows 8 N

98

Windows 8 China

99

Windows 8 Single Language

100

Windows 8

101

Professional with Media Center

103

What the letters mean at the end of Windows products:

Source link

Windows 7 N:

Meant for European market, and includes the same functionality as Windows 7, except that it does not include Windows Media Player and related technologies such as Windows Movie Maker.

Windows 7 K:

Meant for Korean market, and includes the same functionality as ordinary Windows 7, except that it includes links to a Media Player Center Web site and a Messenger Center Web site.

Windows 7 KN:

Meant for Korean market, and includes the same functionality as Windows 7 K, except that it does not include Windows Media Player and related technologies such as Windows Movie Maker, links to download Windows Live Messenger, or links to a Media Player Center Web Site and a Messenger Center Web site.

Windows 7 E:

Meant for European Commission countries, including UK, and includes the same functionality as ordinary standard flavor of Windows 7, except that it does not include Internet Explorer 8 (IE8)

Posted in Direct Access, Windows 2012, WindowsServer | Tagged: , , | 6 Comments »

Windows 2012 Direct Access – ISATAP Router

Posted by Brajesh Panda on April 2, 2013

Click here for other Direct Access related articles.

Out of box Windows 2012 Direct Access configuration wizard enabled ISATAP Router in the Direct Access Server. This ISATAP router can distribute IPv6 IP Addresses & Routes to Windows ISATAP clients. Manage Out clients gets benefitted from this to make IPv6 enabled manage out connection. IIN this article I am not I am not covering how to configure ISATAP router in a standalone server; may be later in another article. For information about other IPv6 Transition technologies check out this article by me.

About ISATAP Interface

Current days all advance IPv6 enabled Operating systems mostly shipped with ISTAP IPv6 Transition technology. You may have observed ISATAP Network Interface while doing IPConfig. We expect One ISATAP Interface per Physical NIC. If you see more than that, try to uninstall them from device manager by doing show hidden devices.

By default these ISATAP interface names looks like isatap.{GUID} – like below picture. ISATAP Interfaces can be seen using IPConfig or NETSH command i.e. netsh interface ipv6 interface


These GUIDs represent the Physical Interface to which it is bonded to. GUID of physical adapter can be seen using “wmic nicconfig get description, SettingIfrom cmd prompt

From above two pictures we can compare and say ISATAP Interface 14 is mapped to Hyper-v Network Adapter #2 and ISATAP interface 27 is mapped to Hyper-v Network Adapter.

This is also another easy way to find out this; Just add a DNS Suffix in one Physical Interface. It will create another ISATAP interface with same DNS suffix. In below picture it created another ISATAP adapter for Corpnet. If you open device manager you will see a new ISATAP interface.

So better to uninstall all ISATAP adapters, add DNS suffix in the Physical Interface & reboot the server. It will create new ones & name them perfectly for identification.

ISATAP Router Discovery

To discover an ISATAP router these clients can query ISTAP.DomainName.Com. Where Domain name is the domain discovered by NIC. So this DNS A record should point to ISATAP Router’s IPv4 Address. This is hardcoded to operating system & part of IPv6 ISATAP transition technology.

If client is able to resolve ISATAP router’s DNS record, it will able to subscribe IPv6 Prefix & published routes. Without Proper deployment it may create routing issue etc., if deployed to all computers in the network. Because as soon as client configures itself using IPv6 address applications aware of IPv6 will start communicating over IPv6 to other ISATAP host or thru the ISATAP router to da different subnet. For better understanding grabbed below pic from https://espix.net/~wildcat/ipv6/i17_isatap_v1a.pdf

In this condition we may not like to create a Global DNS record as ISATAP. There is another option where we can use a custom DNS entry for this record & apply that GPO to specific clients where we want to enable ISATAP functionalities. There is a nice popular article by Jason Jones how to configure this.

  • Create a DNS A record as “DirectAccess-ISTAPRouter.Contoso.Local” & point it to Direct Access Servers Internal IP Address
  • Create an Empty GPO
  • In GPO open “Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies
  • Configure below parameters;
    • ISATAP Router Name: Enabled
    • Enter a Router or relay Name: “DirectAccess-ISTAPRouter.Contoso.Local”
  • Apply above GPO to respective clients. In direct access case Manage Out clients

You may need to reboot the client machine to get the ISATAP IPv6 addresses assigned. Else you may try “sc control iphlpsvc paramchangeto refresh the adapter

Troubleshoot few things

  • How to verify if ISTAP is enabled?
    • Use NETSH Status command “netsh interface isatap show state
    • By default state is default
    • But if router is enabled state will be “enabled”
    • If it is enabled thru group policy like on clients it will show enabled (group policy)
  • How to disable ISATAP functionality from OS?
  • Which ISATAP router is used by client?
    • Use “netsh int isatap show router

  • Which routes are published thru router?
    • In Router use below NETSH command to test i.e. netsh int ipv6 show route. Make sure publish is set to yes. You can add extra routes for publish too.

  • How to verify if client is receiving IPv6 routes & default gateway is pointing to ISATAP route?
    • Use same netsh int ipv6 show route
      command and make sure client is receing routes and gateway is pointing to ISATAP address of router

Posted in Direct Access | Tagged: | 5 Comments »

Windows 7 Direct Access Client Troubleshooting Commands

Posted by Brajesh Panda on March 13, 2013

Click here for other Direct Access related articles.

Windows 7

  1. Check IPv6 enabled Interfaces

Netsh interface ipv6 show interface

  1. Determine if Direct Access client is inside or outside of network

Netsh dnsclient show state


  1. Verify Name Resolution Policy Table

Netsh namespace show policy
(same output while in Corporate or Outside Network)

Netsh namespace show effectivepolicy

  • Shows active policy while outside network & output is same as above command
  • While client is intranet it will give below message because no active policies are there

    DNS Effective Name Resolution Policy Table Settings

    Note: DirectAccess settings would be turned off when computer is inside corporate network

  1. Check current Windows Firewall Profile

Netsh advfirewall monitor show currentprofile

  1. Check Direct Access connection security rules thru Windows Firewall Advance Security Settings

Wf.msc

  1. Check current Windows Security Associations (while successfully connected to Direct Access).
    1. Windows Firewall Advance Security Main Mode or use use “netsh advfirewall monitor show mmsa

  1. Windows Firewall Advance Security Quick Mode or use use “netsh advfirewall monitor show qmsa”

  1. Generate Troubleshooting Logs if Direct Access is not connecting

Right Click Direct Access Connectivity Assistant & click Advance Diagnostics

8. Check NSLOOKUP for corporate network

nslookup -q=aaaa <fqdn intranet resource> <ipv6 DNS server>

Note: IPv6 DNS server is the IPv6 Address you got from “netsh namespace show effectivepolicy”

Posted in Direct Access, Windows 2012 | 3 Comments »

Windows 2012 Direct Access – Windows 7 Client Testing

Posted by Brajesh Panda on March 10, 2013

Click here for other Direct Access related articles.

In last article I have discussed how to test Windows 8 Direct Access Clients with and without computer certificate. In this article let’s test a Win 7 computer. To read other Windows 2012 Direct Access articles visit Direct Access tab on the home page of the blog.

  • Install Windows 7 Enterprise or Ultimate version of client Computer
  • Join it Contoso. Local Domain
  • Add the Computer Account to “Contoso\DirectAccessClients-Win7” security group
  • As Computer certificate is necessary for Windows 7 “Contoso\DirectAccessClients-Win7” group has been configured for auto enrollment of computer certificates
  • Make sure computer certificate is installed in Windows 7 Client Certificate store
  • Enable Windows 7 Access in Remote Access Server Management Console

  • Make sure GPO is applied to the computer. To validate run “Gpresult /r” and make sure direct access client policy is applied under computer configuration
  • Move the computer to public internet and disconnect from corporate network. Check IPConfig & make sure it got IP-HTTPS IP address
  • Try to ping tunnel end points & direct access server IPv6 Address
  • Try to ping Contoso. Local & other internal corporate servers
  • Try to access RDP & \\UNC path for internal resources
  • Check advance firewall console for created tunnels “wf.msc”
  • Check corporate DNS server for dynamic registration of IP-HTTPS interface IP address for Win 7 client.
  • However in Windows 7 there is NO inbuilt Network Connectivity Assistant
    to troubleshoot or disconnect or use local name resolution. So we have to install Direct Access Connectivity 2.0
    tool & configure related settings as per DCA 2.0 guide.
  • Download Direct Access Connectivity Assistant 2.0 Package to Windows 7 client & extract. Package contains below files

  • As per OS version (x64/x86) install respective MSI file. Installer will download Windows Update KB2666914
    from internet and install on the Windows 7 machine. Need internet connection.
  • After DCA 2.0 installation, Existing Network Connectivity Assistant GPO settings will not get applied to it & it will still give error saying Corporate Connectivity is not working. Even inside the corporate network it will throw the same error. If we generate diagnostic logs it will say it is not configured correctly.
  • So Copy GPO ADML & ADMX files as per below in the machine where you configure GPO – may be a domain controller or same DA Server.
    • Copy the DirectAccess_Connectivity_Assistant_2_0_ GP.admx file to the folder %systemroot%\PolicyDefinitions.
    • Copy the DirectAccess_Connectivity_Assistant_2_0_ GP.adml file to the folder %systemroot%\PolicyDefinitions\language. For example, for US English, copy the file to %systemroot%\PolicyDefinitions\en-us.
  • Open Group Policy Management Console & copy respective settings from DirectAccess Client Experience Settings
    to DirectAccess Connectivity Assistant. In below picture from Green to Red.

  • Connect the Win 7 client to corporate network & Gpupdate. After Gpupdate you should able to see DCA is working fine.

  • Reconnect the Win 7 client to Internet & make sure client is getting IPV6 address on IP-HTTPS interface & Direct Access connection is working fine.
  • As you updated the GPO, make sure you Gpupdate the Windows 8 clients too

Posted in Direct Access, Windows 2012 | 9 Comments »

Windows 2012 Direct Access – Windows 8 Client Testing

Posted by Brajesh Panda on March 10, 2013

Click here for other Direct Access related articles.

In last two articles I have demonstrated how to Install, Configure & Verify Direct Access installation. In this article we will test & verify using a Windows 8 Client. For Windows 7 clients check out my next article. Visit Direct Access
tab on the home page for other Windows 2012 Direct Access articles.

  • Install Windows 8 Enterprise Client Computer
  • Join it Contoso. Local Domain
  • Check certificate store to ensure no computer certificate is installed in this machine
    • Note: Remember certificate is not mandatory and we have not selected to use computer certificate in configuration section. We will test with certificate later in this article
  • Add the Computer Account to “Contoso\DirectAccessClients-Win8” security group
  • Make sure GPO is applied to the computer. To validate run “Gpresult /r” and make sure direct access client policy is applied under computer configuration
  • You will able to see Direct Access Connection in the Network List
    • On Windows Start bar click on the network Icon
    • You should able to see “Contoso DA Connection
  • Make sure Windows Firewall is NOT stopped
  • Check windows firewall advance setting rules – “wf.msc

  • Open properties of “DirectAccessPolicy-ClientToCorpSimplified” policy & from Authentication tab check authentication method.

  • Let’s disconnect the computer from Contoso.Local LAN network & start the external wireless connection and observe what is happening
  • Observe network connection list; you will Contoso DA Connection is connected

  • In Advance Windows firewall console and check out Main Mode Security Associations or tunnels. You can observe 1st Computer Account is used & User Account for authentication.

  • Check out IPConfig details in Windows 8 computer. You will find both IP-HTTPS and Teredo interfaces has been assigned IPv6 addresses.
  • Just note if IP-HTTPS interface has an IP address, it means system is using IP-HTTPS technology. DA Client by default tries Teredo connection 1st with its auto address & if connection is not successful it tries IP-HTTPS. So in below picture we see an IP address for Teredo interface. However as IP_HTTPS interface has IP address we can assume it is using IP-HTTPS. Technically permanently we can disable the Teredo Interface to avoid confusion.

  • Try to Ping Corporate servers.

  • Try to access corporate resources like RDP & \\UNC path for fileshare
  • In domain controller check DNS for dynamic host entries for this client. There are two entries one for IP-HTTPS and other for Teredo interface. Teredo interface can be disabled in client to stop registering in DNS unnecessarily – “netsh interface Teredo set state disabled

  • In Direct Access Server management console check Remote Client Status for details. You will find connection information.

  • Till now we have NOT used Computer Certificate. But if we have Win 7 clients & if we need few other advance functionalities we need to have computer certificate based authentication.
  • To use computer certificate
    • We have to issue computer certificate to the windows 8 machine
    • And we have to enable the same from Remote Access Management console
  • After PKI infrastructure get configured certificates can be installed manually or using auto enroll option. I have already configured PKI infra and auto enroll, you may like to check out here to know how.
  • After certificate get installed on the client make sure you verify the same to ensure all is okay.
  • On Server Side; Make sure your Enterprise or Standalone Root CA cert is installed.
  • Open Remote Access Management Console on Step 2 “remote access server” configuration click on configure; On 3rd Authentication window select use computer certificates & click on browse and select root CA certificate


  • Go back to the connected Windows 8 client and do “gpupdate /force” to apply the policy
  • And to check new firewall policies open advance windows firewall console using “wf.msc”.

  • Double click and open properties of “DirectAccessPolicy-ClientToCorp”, click Authentication Tab & under method click customize. You can see 1st Authentication method has been changed to “Computer Certificate”

  • Now disconnect the client from corporate network and hook it up to internet. You can observe Two Tunnels are created for the connection using computer certificate.


  • You can conduct same set of corporate access testing as we did in 1st section of this article without certificate

Check out next article for Windows 7 client testing.

Posted in Direct Access, Windows 2012 | 1 Comment »

Windows 2012 Direct Access – Verify Installation

Posted by Brajesh Panda on February 13, 2013

Click here for other Direct Access related articles.

In last post I have shown you how to install and configure a dual homed direct access server behind the edge. If you have not read that, read it here. Before we move forward in our exercise let’s check out what configurations has been changed in our server. This will help during troubleshooting.

  • IPConfig in DA Server; Few things has been changed
    • In Automatically Private IPv6 Address has been provisioned
    • ISATAP Address has been configured
    • IP-HTTPS Interface and Tunnel End Points has been configured

.

  • Local IPv6 route table & persistent routes for IPv6 prefix has been updated

  • In IIS IP-HTTPS SSL is not configured in binding section of default website with 443.
  • To check SSL certificate binding lets run “netsh http show sslcert”.

  • In Remote Access management console Operation Status Page check everything is working fine

  • In Direct Access server open “Windows Firewall with Advanced Security” Console. You can use “wf.msc to open the same. Make sure “DirectAccess Policy-DaServerToCorpSimplified” Connection Security Rules is created.

  • Make sure DirectAccess Policy-DaServerToCorpSimplified rule is set for both inbound and outbound connection & Authentication is set to Custom.
  • To check Authencation, Open properties for the rule – click authentication tab – click customize
  • First Authentication Method is selected for Computer & 2nd Authentication is selected for User.

  • Active Directory DNS has been updated with few Host Records

  • Open Group Policy Management console and verify two newly created GPOs and to whom they are applied to

In next post we will test Direct Access Infrastructure with Windows 8 clients.

Posted in Direct Access | Tagged: , | Leave a Comment »

Windows 2012 Direct Access – Installation & Configuration

Posted by Brajesh Panda on February 13, 2013

Click here for other Direct Access related articles.

In this posting I am going to demonstrate how to install & configure a Dual Homed Direct Access server. You can find the topology diagram here. I am going to try middle scenario i.e. Behind an Edge device (with two network adapters.

This will be a few part series, keep following the connected URLs at the end of the posting. Here we will be using Windows 2012 Server’s Remote Access Role & Direct Access feature.

Requirement

  • Create Two security groups in Active Directory
    • DirectAccessClients-Win8 and add Windows 8 Computer Accounts
    • DirectAccessClients-Win7 and add only Windows 7 Computer Accounts
  • Decide on below URLs & create necessary certificates
    • IP-HTTPS (remoteconnect.contoso.local)
    • Network Location Server (DirectAccess-NLS.contoso.local
  • Install IP-HTTPS certificates on Direct Access Server along with private key
  • Install IIS & NLS certificate on the Network Location Server & create necessary internal DNS record to resolve the NLS URL.
  • In this build I have provisioned Two Network cards for the Direct Access server
    • One in DMZ & and Another one in Corporate Network
    • DA server can only discover internal Active Directory domain thru Corporate Network NIC

  • Make sure IPv6 components are not disabled in this computer. IPConfig should show all IPv6 Transition tunnel adapters with media disconnected as state.

Installation & Configuration

  • Install Remote Access and requisite components from Server Manager. Just default installation
  • Open Remote Access Management Console
  • From Setup page click on “Run the Remote Access Setup Wizard” Option

  • Click on Deploy Direct Access Only

  • It will check pre-requisites & Open Setup page. Where you will find Active & Grayed out tiles & they will get activated as soon as you configure the previous section

  • To configure Step 1 click on Configure option
  • On Deployment Scenario page Select “Deploy Full direct Access for client access and remote management” & click Next

  • In Select Groups page perform below steps and click next
    • remove “Domain\Domain computers” and add your Direct Access Clients Groups
    • Unselect “Enable DirectAccess for Mobile Computers only“. If you select this option, with WMI it will detect which computer is laptop and only apply the policies to those computers. So if you are testing with a VM or Desktop computer, GPO will not get applied.
    • Make sure “Use Fore tunneling” is not selected. Selecting this will route all internet traffic thru direct access server.

  • In “Network Connectivity Assistant” page Double click empty Resource space to add new internal resources, which will be used by NCA or Win 7 DCA (Direct Access Connectivity Assistant) to check Direct Access connection is okay

  • After you add resources for NCA, add Help Desk Email Address and a descriptive name for the connection. So incase user face any DA connection issue & user clicks to generate Diagnostic Logs it will show the email address to which mail can be send and a Descriptive name will help the user to differentiate the connection from other VPN connections.
  • Also select “Allow Direct Access Clients to use local name resolution” option. It helps users to use their own name resolution while Network Location server is not available and user is inside the corporate network & also to disconnect DA Connection temporarily .
  • And click Finish

  • Now in Remote Access management console you will find Step-2 is activated for configuration.
  • On Step 2 Click Configure; In “Network Topology” window select the “Behind an Edge device (with two network adapters)” topology window type the IP-HTTPS URL you are going to use & click next

  • As IP-HTTPS certificate is already installed, it will auto detect the certificate in “Network Adapters” window. If you don’t have IP-HTTPS certificate, use a self-signed certificate option will be highlighted. Make sure correct Adapters are mapped to correct network & click Next

  • In Authentication window select “Active Directory credentials” option and click Finish. If you have “Windows 8″ only clients “Use of Computer Certificate” is optional, if you need few advance functionalities in Windows 8, you need computer certificate else it is not required. However if you have Windows 7 Clients we need computer certificates and related PKI infra.
  • For now let’s NOT select Computer certificates and Windows 7 client computers. We will enable this during client testing phase in our exercise.

  • Now in Remote Access management console you will find Step-2 is activated for configuration.
  • On Step 3 Click Configure
  • In “Network Location Server” window type the network location server’s HTTPS URL and click validate & after successful validation click next.

  • In “DNS” window to add local corporate domains double click the resource field and type the domain suffix and click detect to resolve the name. This Table is called as Name Resolution Policy Table (NRPT).
  • This table helps the client to determine which domains/namespace are located inside corporate network. So name resolution for them and traffic related to them pass thru direct access connection. Other domains which are not part of this list are resolved thru clients own external DNS configuration and traffic follows accordingly direct to internet – split traffic.
  • Also make sure in DNS window 2nd Option is selected under local name resolution option. It helps the clients to use corporate DNS server or own name resolution while NLS/DNS is not reachable in the corporate network.

  • In “DNS Suffix Search List” add internal DNS suffixes for cross domain or forest resolution & click next
  • In Management window add server names from where management connections will be started thru management tunnel. SCCM & Domain Controllers are automatically discovered later after completion of the Wizard.
  • And Click Finish to complete Step 3 Configuration

  • Step 4 is optional and required to be configured if end to end IPSec Authentication is required from DA Client to Application Server.

  • In the Remote Access Management Console click Finish to commit all configurations. It will present a report to review before commit.
  • Review the same, change necessary information like GPO name if required and click Apply

  • Verify the result page for any error and click Close to finish

In next posting I will show you to verify new/changed configurations on Direct Access Server.

Posted in Direct Access | Tagged: , , | 6 Comments »

Direct Access in Windows 2012

Posted by Brajesh Panda on February 4, 2013

Click here for other Direct Access related articles.

DirectAccess allows domain users to securely access corporate network thru their domain joined remote computer without dialing a traditional VPN dialer or accessing SSL web site for SSL-VPN.

Every time a DirectAccess-enabled computer connects to the Internet it establishes bidirectional connectivity automatically with corporate network.

And by default it uses split technology so only corporate traffics traverse thru the Direct Access Connection. This behavior can be changed to force public internet traffic thru corporate network.

Direct Access technology is based on IPv6. So Direct Access Server & Clients communicate using IPv6 and this is done thru IPv6 transition technologies. Same way Direct Access Client talks to internal IPv4 infrastructure thru Direct Access Server using IPv6 Transition Technologies.

Direct Access was introduced with Windows 2008 R2. But in new version some good enhancement has been done;

  • Windows 2008 R2 need Forefront to use few (NAT64, DNS64) IPv6 transition technologies. However these are right built into this Windows 2012; removing dependency on forefront.
  • IP-HTTPS technology has been improved in Windows 2012 which can come over Teredo limitations.
  • In a simpler deployment IP-HTTPS connection can use a self-signed certificate.
  • In a truly Windows 8 client environment, it don’t need a computer certificate removing PKI requirement. However if you have Windows 7 and want to support it, you need Computer Certificate resulting PKI environment for client version.
  • Both traditional Windows VPN (RRAS) and Direct Access can co-exist on the same server.
  • Supports Load Balancing between multiple servers
  • Support multiple entry points for Site disaster recovery & helps to connect to near access point in the world
  • Supports multiple network architecture like; (check out the diagram)
    • With One NIC inside corporate network,
    • With two NIC; -one nic in DMZ and other one in corporate,
    • Two NIC – one in Public Internet (for Teredo) and one in corporate network

Few things need to be considered for production deployment where both Win 7 & 8 clients are coexisting;

  • PKI infrastructure
  • Public certificate for IP-HTTPS deployment. If you are using internal CA certificate, make sure your CA’s CRL (certification revocation list) URL is available over internet for clients to verify
  • You have to still deploy Direct Access Connectivity 2.0 tool to Windows 7 clients. And have to configure DCA settings manually. Easy way of doing is enable Multisite connectivity in Remote Access configuration where you can define a separate GPO for Windows 7 computers
  • Best practice is to use two different security groups for Windows 7 & 8 clients.
  • Configure internal CA templates to issue computer certificates to clients as per their membership
  • Make sure Network Location Server (NLS) is highly available & its URL is not published to internet. NLS helps clients to determine if they are inside or outside of corporate network. If outside clients start direct access connection. So if clients are inside corporate network and NLS is not accessible that time, they will start Direct Access connection and being inside corporate network they may not able to connect to Direct Access server’s public interface and clients will not able to access network resources.

Will keep updating this article with my findings! Watch out for upcoming articles how to configure Direct Access Infrastructure.

Posted in Direct Access | Tagged: | 2 Comments »

IPv6 Transition – DS-Lite

Posted by Brajesh Panda on January 3, 2013

Click here for other Direct Access related articles.

As promised in my last NAT/64/DNS64 article, in this article we will be discussing a technology called DS-Lite used for IPv6 Transition. This technology is used for IPv4 Communication over IPv6 network.

I found this nice article by Kapil Digani from Citrix Blog. I am going just re-blog the same original piece. He also wrote few other good articles. You may like to refer to the original
site.
All Credit goes to him.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In IPv6 blog series we have covered transition technologies NAT64 – that allows IPv6 hosts to communicate with resources on IPv4 network and 6rd – that allows IPv6 traffic to be tunneled over IPv4 network. When service providers want to migrate their core network to IPv6, they need to ensure that existing IPv4 users continue to get access to IPv4 internet as before. This is where DS-Lite comes in – it is a tunneling technology that encapsulates IPv4 packets in IPv6 transport to be delivered to final IPv4 destination. DS Lite combines IPv4-in-IPv6 tunneling with NAT – NAT does the IPv4-IPv4 translation before sending packets to public IPv4 network.

DS-Lite enables service providers to natively allocate IPv6 addresses to new customers while continuing to support IPv4 customers. Main functional components involved in DS-Lite are B4 (Basic Bridging BroadBand) and AFTR (Address Family Translation Router) as shown in figure below:


In a DS Lite enabled network, customer premise device provides B4 functionality. Customer device allocates private IPv4 addresses to hosts in the home / customer networks. B4 connects with service provider access network using the IPv6 address allocated by service provider and uses this IPv6 address to establish tunnel with the AFTR device.

AFTR is usually deployed at the edge of service provider IPv6 network and terminates the tunnel created with customer B4 element. AFTR also provides IPv4-IPv4 NAT to translate customer private IPv4 address to public IPv4 address before sending packets out to the public network.

Following sequence describes the connection establishment process using DS Lite:

  1. Host with private IPv4 address initiates a connection to a resource on the public internet
  2. Traffic is sent to B4, which is the default gateway
  3. B4, using its service provider network facing IPv6 addresses establishes the tunnel with AFTR. Address of the AFTR can be pre-configured or can be discovered using DHCPv6
  4. B4 encapsulates the IPv4 packets in IPv6 transport and sends across to AFTR
  5. AFTR terminates the tunnel and de-capsulate the IPv4 packet
  6. AFTR device performs IPv4-IPv4 NAT before sending traffic to the destination IPv4 network

There are many benefits that DS Lite provides:

  1. A lightweight solution to allow IPv4 connectivity over IPv6 network
  2. Avoids the need of multiple levels of NAT as in case of LSN
  3. Allows service providers to move their core and access networks to IPv6 thus enabling them to benefit from IPv6 advantages
  4. Allows coexistence of IPv4 and IPv6
  5. Helps resolve IPv4 address scarcity issue
  6. Allows incremental migration to native IPv6 environment

But as always is the case, benefits don’t come without its own set of challenges:

  1. DS Lite does not provide IPv6 and IPv4 hosts to talk to each other
  2. Increases the size of traffic due to tunnel headers – requires MTU management to avoid fragmentation
  3. Need to manage and maintain bindings between customer addresses and public addresses used for translation in the AFTR device
  4. Brings in additional challenges for DPI in service provider network

Posted in Direct Access, IPv6 | Tagged: , , , | Leave a Comment »

Microsoft Direct Access – Basic Architecture Options

Posted by Brajesh Panda on December 29, 2012

Click here for other Direct Access related articles.

Microsoft  Direct Access 2012’s basic architecture options. Will add load balancer in next version. Let me know if I got something wrong or any other good suggestions.

Posted in Direct Access, IPv6 | Tagged: , , , , | 4 Comments »

Microsoft Direct Access – When what type of IPv6 Transition Technology used by Direct Access Client?

Posted by Brajesh Panda on December 23, 2012

Click here for other Direct Access related articles.

Direct Access server can be configured for all three internet IPv6 Transition Technologies i.e. Teredo, 6to4 & IP-HTTPS. As per server config group policy get applied on clients. So if server is configured for all 3 transition technologies & GPO is applied accordingly, when what type of IPv6 transition technologies is used by direct access clients???

This post describes the same. These are my screenshot notes from TechNet Article.



Posted in Direct Access | Tagged: , , | 6 Comments »

Microsoft Direct Access – How DNS64 & NAT64 works?

Posted by Brajesh Panda on December 23, 2012

Click here for other Direct Access related articles.

As I said in my previous article Direct Access is an IPv6 only technology; Direct Access clients talk to Direct Access Server using IPv6 technologies. (Don’t forget this communication happens using IPv6 transition technologies i.e. IPV6 encapsulation in IPv4 packets.). As client to server communication happens using IPv6, Name lookup also happens using IPv6 & AAAA query. So if a internal server has IPv6 address it is easy for the client to start communication. But if internal server is only IPv4 configured, how it will communicate. This is where DNS64 and NAT64 come into the picture.  So NAT64/DNS64 are needed when you want to have IPv6 communication over IPv4 network. For other way round look forward to next article.

  • So IPv6 enabled DA Clients send an IPv6 host resolution query (AAAA Query- Quad A query) to Direct Access Server.
  • In Direct Access Server DNS64 (DNS 6 to 4 Proxy) accepts this query & contact internal corporate DNS server as per Direct Access Servers own internal DNS IP Address config.
  • Internal corporate DNS server hands over either IPv6 or IPv4 or both addresses for the internal destination application server to DNS64. This depends on what kind of address internal app server is registered with internal dns server.
  • If DNS64 receives both IPv6 & IPv4 address it hands over the IPv6 address to DA Client. DA Client starts communication to that IPv6 address of destine application server.
  • If DNS64 receives only IPv6 address from the internal Corporate Server, it hands over that IPv6 IP to the Direct Access Client. DA Client starts communication to that IPv6 address of destine application server.
  • If DNS64 receives only IPv4 address from the internal corporate server, it cannot hand over that to Direct Access client; because DA client is not aware of IPv4 address. So it handover that address to NAT64 service in the same server.
  • NAT64 service converts that IPv4 address to IPv6 by using it’s configured IPv6 Prefix
  • Then DNS64 hand over the translated IPv6 address to the DA Client
  • Then DA Client sends it’s communication to above IPv6 address thru Direct Access Server
  • In Direct Address server NAT64 captures the IPv6 communication packets as it is carrying it’s NAT64 prefix.
  • Then NAT64 removes its proxy and creates an IPv4 payload of same data and forwards to the destination application server.
  • When NAT64 receive a reply for that packet, again it creates IPv6 address using prefix & forward to Direct Access client & continues.
  • Just to remember; When Direct Access Server is load balanced, these translation packets carry same nodes address so reply come to the same node, which did the translation.
  • Here is a nice article about this functionality with some good picture; http://blogs.technet.com/b/edgeaccessblog/archive/2009/09/08/deep-dive-into-directaccess-nat64-and-dns64-in-action.aspx
  • In Windows 2008 R2 version Direct Access, DNS64 & NAT64 were not inbuilt so had to use UAG or any other 3rd party product and in UAG we have to configure NAT64 prefix.
  • But in Windows 2012 NAT64 &DNS64 are integrated, so we don’t need UAG, Also we don’t need to configure any separate prefix per say.

Other Direct Access Articles

Microsoft Direct Access & IPv6 Transition Technologies

Posted in Direct Access, IPv6 | Tagged: , , | 13 Comments »

Microsoft Direct Access & IPv6 Transition Technologies

Posted by Brajesh Panda on December 23, 2012

Click here for other Direct Access related articles.

  • Direct Access is a completely IPv6 Technology
  • DirectAccess uses IPv6 with IPsec to create a secure connection between DirectAccess client computers and the internal corporate network.
  • However, DirectAccess does not necessarily require connectivity to the IPv6 Internet or native IPv6 support on internal networks.
  • Instead, it automatically configures and uses IPv6 transition technologies to tunnel IPv6 traffic across the IPv4 Network
    • Over IPv4 INTERNET (Extranet) it can use 6to4, Teredo and IP-HTTPS
    • Over IPv4 INTRANET it use any one between ISATAP, NAT64 and DNS64
  • These IPv6 transitioning technologies provide automatic tunneling between two Dual-Stack devices; here tunnel doesn’t mean a typical vpn like tunnel. Tunnel refers to encapsulation and they also auto assign IPv6 address to the participating hosts.
    • So IPv6 transitioning technologies encapsulate IPv6 packet with an IPv4 Packet Header

    • As per Dual Stack is concern, it refers to how IPv6 Stack is implemented in that device
      • Dual IP Layer – Common Transport Stack

      • Dual Stack Layer – Different Transport Stack

  • Extranet (Internet) IPv6 Transitioning Technologies
    • 6To4
      • It is an address assignment and dual stack IPv6 tunneling technology
      • Used to provide Unicast IPv6 connectivity between IPv6 sites & hosts across IPv4 Internet
    • Teredo
      • It provides address assignment and automatic tunneling for unicast IPv6 connectivity across the IPv4 Internet, even when IPv6/IPv4 hosts are located behind one or multiple IPv4 NATs.
      • Known as IPv4 NAT Traversal (NAT-T) for IPv6. To traverse IPv4 NATs, IPv6 packets are sent as IPv4 UDP messages.
      • Due to nature of UDP Teredo provides more performance than other transition technologies.
      • It is designed as last resort transition technology for IPV6. It only used where native IPv6, ISATAP or 6To4 connectivity is not possible.
    • IP-HTTPS
      • Like other extranet IPv6 transition technologies, IP-HTTPS auto assigns globally routable IPv6 address to IPv4 enabled hosts.
      • IP-HTTPS establish connectivity by tunneling IPv6 packets inside an IPv4-based HTTPS session.
      • IP-HTTPS is used instead of HTTP so that Web proxy servers will not attempt to examine the data stream and terminate the connection.
      • On certain networks, Internet firewall settings may prevent successful client connections using the 6to4 or Teredo IPv6 transition technologies; but IP-HTTPS bring more flexibility due to HTTPS
      • IP-HTTPS implementation in Windows 2012 Direct Access is different from Windows 2008 R2 Implementation.
      • In Windows 2008 R2 Direct Access with Windows 7 clients also use IPSec encryption for data transfer. Resulting IPSec Encryption inside SSL Encryption tunnel. This brought more overhead & performance issues.
      • Windows 2012 implementation brings more enhancement & performance to the protocol by implementing SSL with NULL encryption. Null encryption allows for authentication to take place during the SSL handshake. Once the SSL handshake has completed all messages flow without being encrypted over that socket.
      • Windows 7 Direct Access deployment needs Computer Certificate for each IP-HTTPS client. But Windows 8 Direct Access deployment don’t need a Computer Certificate for IP-HTTPS client
      • In Windows Server 2012, a new feature solves issues while Direct Access client is behind a proxy server. Specifically, the user can configure IP-HTTPS to work when behind a proxy that is not configured using WPAD (Proxy Discovery) and IP-HTTPS will request and provide the proxy credentials needed to IP-HTTPS request authenticated, and relay it to the DirectAccess server.
      • IP-HTTPS can use a valid Public/Private SSL cert generated from CA or Self Signed Certificate.
  • Intranet IPv6 Transitioning Technologies
    • ISATAP
      • Stands for Intra-site Automatic tunnel Addressing Protocol
      • It is an address assignment and dual stack IPv6 transitioning/tunneling/encapsulating technology
      • It doesn’t need any manual configuration. It can automatically assign IPv6 address using auto configuration mechanism & tunneling
      • Used to provide Unicast IPv6 Connectivity between IPv6/IPv4 hosts across an IPv4 intranet
      • ISATAP mostly used to provide auto IPv6 Address to intranet servers
      • If we are using ISATAP and want to establish connectivity to another IPv6 subnet we need ISATAP Router
    • NAT64 & DNS64
      • Unlike other intranet & extranet IPv6 transition technologies; NAT64 & DNS64 don’t provide encapsulation or tunneling of IPv6 packets over IPv4 packets
      • Windows 2008 R2 Direct Access deployment doesn’t provide these two options out of box. And Direct Access needs these two features to work. Microsoft UAG (Unified Access Gateway) provides these two options & you have to configure little bit. If you don’t have UAG; you need a 3rd party component to deploy them.
      • Windows 2012 Direct Access provides these two features out of box & you don’t need to configure anything.
      • NAT64 & DNS64 work hand in hand
      • NAT64 is a network translation service, which provides IPv6 to IPv4 Address Translation i.e. it translate Direct Access Clients IPv6 traffic to IPv4 to reach internal servers; not other way round i.e. it is Unidirectional. So any intranet server needing access to Direct Access Clients needs to have their own IPv6 Address using static assignment or ISATAP technology.
      • DNS64 is a DNS Proxy service provides DNS service for Direct Access Clients.
      • DNS64 takes DNS resolution request from IPv6 client and query to corporate dns server & return the address. In case query resulted a IPv4 address, it take help from NAT64 to generate a corresponding IPV6 address and handover to direct access client. See other article to understand how NAT64 & DNS64work hand in hand.

Posted in Direct Access | Tagged: , | 4 Comments »

 
%d bloggers like this: