DirectAccess in Windows 7. Part 3
In the previous part about DirectAccess, I looked at transit technologies that provide IPv6 interoperability in an IPv4 environment, IPsec over IPv6, and DA clients' access models to corporate resources and focused on the NRPT name resolution table. I recall that NRPT is used only when the DA client is on the Internet, or, in other words, outside the corporate network. Accordingly, there is an algorithm that allows a DA client to determine its location relative to the corporate network. Let's look at this algorithm.
Positioning
The point is pretty simple. When you configure DirectAccess in the DirectAccess Setup Wizard, the administrator sets a certain URL (network location URL) (see Figure 1).
')
This URL is transmitted to all DA clients through group policies and is stored in the registry key:
HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ NetworkConnectivityStatusIndicator \ CorporateConnectivity \ DomainLocationDeterminationUrl
Each time a DA client network status changes (the computer restarts, a cable is inserted into the network card, the WiFi adapter is connected to the network, etc.), the client tries to connect to a resource called Network Location Server (NLS) at the specified URL. If this succeeds, the DA client believes that he is on the corporate network, if not - on the Internet. By default, a DA client always believes that it is outside the corporate network.
In more detail the procedure is as follows:
1. The Fully Qualified Domain Name (FQDN) specified in the network location URL is allowed.
2. An HTTPS connection is established on the 443 TCP port.
3. The SSL certificate of the NLS server is verified.
4. The certificate is checked against the list of revoked CRL certificates, the location of which is specified in the DA client settings.
After successfully connecting to the NLS server, the DA client tries to discover the domain controller and perform authentication. If the authentication is successful, the client grid switches to the domain profile. And since all DirectAccess settings, including IPsec settings, apply only to the Public and Private network profiles, these settings are deactivated, the NRPT is deactivated, and the DA client works like any other ordinary domain computers.
Several important conclusions can be drawn from this algorithm.
1. Network location URLs should be resolved only by internal DNS servers and should not be resolved by any external DNS servers.
2. Since communication with the NLS server is critical for determining the location of the DA client, it is necessary to ensure an adequate level of availability and resiliency of this resource.
3. It is also necessary to attend to the level of availability of the CLR.
What happens if being in a domain network DA-client can not reach the NLS? Obviously, the DA client will consider that it is on the Internet and will try to establish a tunnel to the external interface of the DA server. And if he succeeds, he will work with internal resources as if he were located outside the corporate network, that is, through a DA server. Naturally, firstly, it generates unnecessary traffic and reduces the speed of network interaction, and secondly, the client will get access only to those internal resources that are allowed by DirectAccess policy. If, however, the external interface of the DA server could not be reached, then the short names still have a chance to be resolved using other mechanisms besides DNS, for example, Link-Local Multicast Name Resolution or NetBIOS.
Infrastructure Requirements for DirectAccess Deployment
Now that the basic DirectAccess mechanisms have been considered, we can discuss the infrastructure requirements for technology deployment.
DA client:
1. Windows 7 Ultimate or Enterprise or Windows Server 2008 R2
2. Member of Active Directory Domain
DA server:
1. Windows Server 2008 R2
2. Member of Active Directory Domain
3. At least two network adapters connected one to the Internet, one to the intranet
4. Two consecutive public IPv4 addresses for the correct operation of transit technologies. Specifically, Teredo technology requires two IPs. Under the RFC, they should not be consistent, but in the current implementation of DirectAccess, the requirement is exactly that.
Network:
1. Active Directory. At least one domain controller under Windows Server 2008 (not necessarily R2)
2. Expanded public key infrastructure (Public Key Infrastructure, PKI) for issuing computer certificates. The latter are required for authentication when installing the tunnel
3. Support for IPv6 and transit technologies on devices to which DA clients will be granted access. Let me remind you that in Microsoft OS such support appeared, starting with Windows XP
Deploy DirectAccess
I recorded a short video where I showed the main steps for configuring DirectAccess and at the same time once again explained some technological highlights. In this case, I left behind the scenes everything that is not directly related to DirectAccess, for example, the deployment of PKI.
For more information, which is now enough, you can refer to the appropriate section of the TechNet portal .
Conclusion
In conclusion, I would like to once again outline the main features of DirectAccess. You can probably argue about the terminology for a long time: whether DirectAccess is a kind of VPN extension option or not. I came across different points of view on this question. For example, DirectAccess - VPN on steroids. Or, VPN is a temporary user access to the corporate network from the outside, and DirectAccess is the constant provision of internal resources to remote users. But, it seems to me, ultimately, it is not so important. It is important when organizing remote user access to internal resources to remember about DirectAccess the following:
1. DA provides a transparent connection of remote users to the corporate network. In addition, nothing is required from the user himself.
2. A DA connection is established and restored automatically as soon as a connection to the Internet (with a DA server) appears.
3. When a DA connection is established, both the computer and the user are authenticated. Connection via DA is possible only from certain machines specified by the administrator.
4. By default, DA implements traffic separation: traffic to local resources goes through the tunnel through the DA server to the corporate network, traffic to external resources goes through the current ISP provider to the Internet.
5. Since when using DA clients are always connected to the corporate network (as long as there is a connection), DA clients are always under the control of IT services.
6. This is not "next crutches Microsoft to VPN" :). DA is based on IPv6, which is deprived of many of the problems and limitations of traditional IPv4 VPNs.
Perhaps, for now.
Positioning
The point is pretty simple. When you configure DirectAccess in the DirectAccess Setup Wizard, the administrator sets a certain URL (network location URL) (see Figure 1).
')
This URL is transmitted to all DA clients through group policies and is stored in the registry key:
HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ NetworkConnectivityStatusIndicator \ CorporateConnectivity \ DomainLocationDeterminationUrl
Each time a DA client network status changes (the computer restarts, a cable is inserted into the network card, the WiFi adapter is connected to the network, etc.), the client tries to connect to a resource called Network Location Server (NLS) at the specified URL. If this succeeds, the DA client believes that he is on the corporate network, if not - on the Internet. By default, a DA client always believes that it is outside the corporate network.
In more detail the procedure is as follows:
1. The Fully Qualified Domain Name (FQDN) specified in the network location URL is allowed.
2. An HTTPS connection is established on the 443 TCP port.
3. The SSL certificate of the NLS server is verified.
4. The certificate is checked against the list of revoked CRL certificates, the location of which is specified in the DA client settings.
After successfully connecting to the NLS server, the DA client tries to discover the domain controller and perform authentication. If the authentication is successful, the client grid switches to the domain profile. And since all DirectAccess settings, including IPsec settings, apply only to the Public and Private network profiles, these settings are deactivated, the NRPT is deactivated, and the DA client works like any other ordinary domain computers.
Several important conclusions can be drawn from this algorithm.
1. Network location URLs should be resolved only by internal DNS servers and should not be resolved by any external DNS servers.
2. Since communication with the NLS server is critical for determining the location of the DA client, it is necessary to ensure an adequate level of availability and resiliency of this resource.
3. It is also necessary to attend to the level of availability of the CLR.
What happens if being in a domain network DA-client can not reach the NLS? Obviously, the DA client will consider that it is on the Internet and will try to establish a tunnel to the external interface of the DA server. And if he succeeds, he will work with internal resources as if he were located outside the corporate network, that is, through a DA server. Naturally, firstly, it generates unnecessary traffic and reduces the speed of network interaction, and secondly, the client will get access only to those internal resources that are allowed by DirectAccess policy. If, however, the external interface of the DA server could not be reached, then the short names still have a chance to be resolved using other mechanisms besides DNS, for example, Link-Local Multicast Name Resolution or NetBIOS.
Infrastructure Requirements for DirectAccess Deployment
Now that the basic DirectAccess mechanisms have been considered, we can discuss the infrastructure requirements for technology deployment.
DA client:
1. Windows 7 Ultimate or Enterprise or Windows Server 2008 R2
2. Member of Active Directory Domain
DA server:
1. Windows Server 2008 R2
2. Member of Active Directory Domain
3. At least two network adapters connected one to the Internet, one to the intranet
4. Two consecutive public IPv4 addresses for the correct operation of transit technologies. Specifically, Teredo technology requires two IPs. Under the RFC, they should not be consistent, but in the current implementation of DirectAccess, the requirement is exactly that.
Network:
1. Active Directory. At least one domain controller under Windows Server 2008 (not necessarily R2)
2. Expanded public key infrastructure (Public Key Infrastructure, PKI) for issuing computer certificates. The latter are required for authentication when installing the tunnel
3. Support for IPv6 and transit technologies on devices to which DA clients will be granted access. Let me remind you that in Microsoft OS such support appeared, starting with Windows XP
Deploy DirectAccess
I recorded a short video where I showed the main steps for configuring DirectAccess and at the same time once again explained some technological highlights. In this case, I left behind the scenes everything that is not directly related to DirectAccess, for example, the deployment of PKI.
For more information, which is now enough, you can refer to the appropriate section of the TechNet portal .
Conclusion
In conclusion, I would like to once again outline the main features of DirectAccess. You can probably argue about the terminology for a long time: whether DirectAccess is a kind of VPN extension option or not. I came across different points of view on this question. For example, DirectAccess - VPN on steroids. Or, VPN is a temporary user access to the corporate network from the outside, and DirectAccess is the constant provision of internal resources to remote users. But, it seems to me, ultimately, it is not so important. It is important when organizing remote user access to internal resources to remember about DirectAccess the following:
1. DA provides a transparent connection of remote users to the corporate network. In addition, nothing is required from the user himself.
2. A DA connection is established and restored automatically as soon as a connection to the Internet (with a DA server) appears.
3. When a DA connection is established, both the computer and the user are authenticated. Connection via DA is possible only from certain machines specified by the administrator.
4. By default, DA implements traffic separation: traffic to local resources goes through the tunnel through the DA server to the corporate network, traffic to external resources goes through the current ISP provider to the Internet.
5. Since when using DA clients are always connected to the corporate network (as long as there is a connection), DA clients are always under the control of IT services.
6. This is not "next crutches Microsoft to VPN" :). DA is based on IPv6, which is deprived of many of the problems and limitations of traditional IPv4 VPNs.
Perhaps, for now.
Source: https://habr.com/ru/post/112192/
All Articles