Managing networking in Windows 8.1 and Windows Server 2012 R2
Managing networking in Windows 8.1 and Windows Server 2012 R2
In Group Policy, you’ll find network management policies for both wired networks (IEEE 802.3) and wireless networks (IEEE 802.11) are located in the Administrative Templates for Computer Configuration under Windows SettingsSecurity Settings. Only one wired policy and one wireless policy can be created and applied at a time. This means you can establish both a wired policy and a wireless policy for computers running Windows Vista and later releases of Windows. You also can create a wireless policy for computers running Windows XP.
If you press and hold or right-click the Wired Network (IEEE 802.3) node, you can create a policy for Windows Vista and later releases that specifies whether the Wire AutoConfig service is used to configure and connect these clients to 802.3 wired Ethernet networks. For Windows 7 and later releases of Windows, you have options for preventing the sharing of user credentials and for specifying whether to prohibit computers from making autoconnection attempts to the network for a specified amount of time.
If you press and hold or right-click the Wireless Network (IEEE 802.11) node, you can create separate policies for Windows XP computers and computers running later releases that enable WLAN autoconfiguration, define the specific networks that can be used, and set network permissions. For Windows 7 and later releases of Windows, you have options for preventing the sharing of user credentials, for specifying whether to prohibit computers from making autoconnection attempts to the network for a specified amount of time, and for preventing the use of hosted networks.
Windows Vista SP1 or later and later releases of Windows support several wired and wireless enhancements. These enhancements enable users to change their password when connecting to a wired or wireless network (as opposed to using the Winlogon change password feature), to correct a wrong password entered during sign on, and to reset an expired password-all as part of the network logon process.
Network security enhancements include the following:
? Secure Socket Tunneling Protocol (SSTP)
? Secure Remote Access (SRA)
? CryptoAPI Version 2 (CAPI2)
? Online Certificate Status Protocol (OCSP) extensions
? Port preservation for Teredo
? Remote Desktop Protocol (RDP) file signing
Secure Socket Tunneling Protocol allows data transmission at the data link layer over an HTTPS connection. Secure Remote Access enables secure access to remote networks over HTTPS. Together these technologies enable users to securely access a private network by using an Internet connection. Secure Socket Tunneling Protocol and Secure Remote Access represent improvements over the Point-to-Point Tunneling Protocol (PPTP) and Layer Two Tunneling Protocol/Internet Protocol Security (L2TP/ IPsec) protocols because they use the standard TCP/IP ports for secure web traffic, and this allows them to traverse most firewalls in addition to Network Address Translation (NAT) and web proxies.
Secure Socket Tunneling Protocol uses HTTP over Secure Sockets Layer (SSL), which is also known as Transport Layer Security (TLS). HTTP over SSL (which uses TCP port 443) is commonly used for protected communications with websites. Whenever users connect to a web address that begins with https://, they are using HTTP over SSL. Using HTTP over SSL solves many of the virtual private network (VPN) protocol connectivity problems. Because SSTP supports both IPv4 and IPv6, users can establish secure tunnels using either IP technology. Essentially, you get VPN technology that works everywhere, which should mean that you receive far fewer support calls.
CAPI2 extends support for public key infrastructure (PKI) and X.509 certificates and implements additional functionality for certificate path validation, certificate stores, and signature verification. One of the steps during certificate path validation is revocation checking, which involves verifying the certificate status to ensure that it has not been revoked by its issuer; this is where Online Certificate Status Protocol comes into the picture.
OCSP is used to check the revocation status of certificates. CAPI2 also supports independent OCSP signer chains and specifying additional OCSP download locations on a per-issuer basis. Independent OCSP signer chains modify the original OCSP implementation so that it can work with OCSP responses that are signed by trusted OCSP signers that are separate from the issuer of the certificate being validated. Additional OCSP download locations make it possible to specify OCSP download locations for issuing CA certificates as URLs that are added as a property to the CA certificate.
To ensure IPv4/IPv6 coexistence, Windows enables applications to use IPv6 on an IPv4 network, and it also supports related technologies such as port preservation for Teredo, which is a User Datagram Protocol (UDP)-based tunneling technology that can traverse NATs. This feature enables Teredo communications between “port preserving” symmetric NATs and other types of NATs. A NAT is port preserving if it chooses to use the same external port number as the internal port number.
Current releases of Windows Server support TCP Chimney offloading. This feature enables the networking subsystem to offload the processing of a TCP/IP connection from a server’s processors to its network adapters, as long as the network adapters support TCP/IP offload processing. Both TCP/IPv4 connections and TCP/ IPv6 connections can be offloaded. By default, TCP connections are offloaded on 10-gigabits per second (Gbps) network adapters but are not offloaded on 1-Gbps network adapters. To modify the related settings, you can use Netsh.
Network Diagnostic Framework (NDF) simplifies network troubleshooting by automating many common troubleshooting steps and solutions. When you run Windows Network Diagnostics, each diagnostic session generates a report with diagnostics results, and you can view this information in Action Center by tapping or clicking the Troubleshooting link, and then tapping or clicking View History. On the Troubleshooting History page, each diagnostic session is listed by type and date run. To get detailed information, select the session you want to review, and then tap or click View Details.
The diagnostic information shown in Action Center comes from an Event Trace Log (ETL) file created as part of diagnostics. If you press and hold or right-click a diagnostic session and then select Open File Location, you can view the files generated as part of diagnostics for the selected diagnostic session.
You can use the Netsh Trace context to perform comprehensive tracing in addition to network packet capturing and filtering. You perform traces by using predefined or custom scenarios and providers. Tracing scenarios are collections of providers. Providers are the actual components in the network protocol stack that you want to work with, such as TCP/IP, Windows Filtering Platform and Firewall, Wireless LAN Services, Winsock, or NDIS. Typically, you use Network Monitor (Netmon) to analyze trace data. If you collect trace data on a computer where Netmon isn’t installed, you can just copy the trace file to a computer where Netmon is installed so that you can analyze the data.
Windows Vista with SP1 or later and later releases of Windows use an RDP 6.1 or later compatible client. Here, RDP files can be digitally signed to prevent users from opening or running potentially dangerous RDP files from unknown sources. Administrators can sign RDP files by using a signing tool provided by Microsoft. Three related settings can be configured through Group Policy or through the registry. These settings include a comma-separated list of certificate hashes that are trusted by the administrator (known as the trusted publishers list), an option to enable users to decide to accept untrusted publishers (enabled by default), and an option to enable users to accept unsigned files (enabled by default).
Windows 8.1 and Windows Server 2012 R2 have a number of enhancements in their built-in DNS clients that improve name resolution on IPv4 and IPv6 networks. With adaptive query timeout, the DNS client adapts the timeout interval based on the time required for previous queries. Thus, instead of waiting 1000 milliseconds (ms) before timing out a query, the timeout is adjusted based on past performance for the network, resulting in timeouts between 25 ms and 1000 ms.
The DNS client for Windows 8.1 and Windows Server 2012 R2 also supports query coalescing, parallel queries, and persistent caching. With query coalescing, the DNS client combines multiple DNS queries for the same name. This results in only one query and optimizes performance. With parallel queries, the DNS client issues IPv4 and IPv6 queries for A and AAAA records in parallel when both IP interfaces are enabled, which streamlines the query process and improves performance. Link-local multicast name resolution (LLMNR) and NETBIOS queries are also issued in parallel for IPv4 and IPv6. With a persistent cache, the DNS client maintains the DNS cache across changes that occur on the same network. For example, the DNS client now persists the cache after address change notifications and when the computer is resuming from the sleep or standby state.