DNS zone types

Zones store DNS resource record information. The DNS Server role in Windows Server supports several zone types, each of which is appropriate for a different set of circumstances. These zone types include primary, secondary, stub, and GlobalNames zones. You can integrate zones into Active Directory, or you can use the traditional primary or secondary architecture.

Add-DNSServerDirectoryPartition -Name Tasmania

Add-DnsServerPrimaryZone -Name tailwindtraders.com -ReplicationScope Forest

Secondary zones

A secondary zone is a read-only copy of a primary zone. Secondary zones cannot process updates and retrieve updates from a primary zone. Also, secondary zones cannot be Active Directory–integrated zones, but you can configure a secondary zone for an Active Directory–integrated primary zone. Before configuring a secondary zone, you need to configure the primary zone that you want it to replicate from to enable transfers to that zone. You can do this on the Zone Transfers tab of the Zone Properties dialog box. Secondary zones work best when the primary zone that they replicate from does not update frequently. If the primary zone does update frequently, it is possible that the secondary zone might have out-of-date records.

Use the Add-DNSServerSecondaryZone cmdlet to create a secondary zone. For example, to create a secondary zone for the australia.contoso.com zone, where a DNS server hosting the primary zone is located at 192.168.15.100, issue the following command:

Click here to view code image

Add-DnsServerSecondaryZone -Name "australia.contoso.com" -ZoneFile "australia.contoso
.com.dns" -MasterServers 192.168.15.100

Reverse lookup zones

Reverse lookup zones translate IP addresses into FQDNs. You can create IPv4 or IPv6 reverse lookup zones, and you can also configure reverse lookup zones as Active Directory–integrated zones, standard primary zones, secondary zones, or stub zones. The domain controller promotion process automatically creates a reverse lookup zone based on the IP address of the first domain controller promoted in the organization.

Reverse lookup zones are dependent on the network ID of the IP address range that they represent. IPv4 reverse lookup zones can only represent /8, /16, or /24 networks, which are the old Class A, Class B, and Class C networks. You can’t create a single reverse lookup zone for IP subnets that doesn’t fit into one of these categories, and the smallest reverse lookup zone you can create is for subnet mask /24, or 255.255.255.0.

Use the Add-DNSPrimaryZone cmdlet and the NetworkID parameter to create a reverse lookup zone. For example, to create an Active Directory–integrated reverse lookup zone for the 192.168.15.0/24 subnet, issue the following command:

Click here to view code image

Add-DnsServerPrimaryZone -NetworkID "192.168.15.0/24" -ReplicationScope "Forest"

Few applications actually require that you configure reverse lookup zones. In most organizations, the only reverse lookup zone is the one that is automatically created when Active Directory is installed. One of the few times where reverse lookup zones seem necessary is when you configure Simple Mail Transfer Protocol (SMTP) gateways. This is because some anti-SPAM checks perform a reverse IP address lookup to verify the identity of the SMTP gateway. Often, the SMTP gateway’s IP address, being a public address, belongs to the ISP, which means creating the reverse lookup zone entry is beyond your direct control as a systems administrator.

GlobalNames zones

GlobalNames zones are a single-label, name-resolution replacement for WINS (Windows Internet Naming System) that can utilize existing DNS infrastructure. Deploying GlobalNames zones enables organizations to retire their existing WINS servers. If your organization still needs WINS (and apparently some do), you can still deploy the service on computers running Windows Server 2022.

Your organization should consider deploying GlobalNames zones instead of WINS in the following situations:

• Your organization is transitioning to IPv6. WINS does not support IPv6, and you need to support single-label name resolution.

• Single-label name resolution is limited to a small number of hosts that rarely change. GlobalNames zones must be updated manually.

• You have a large number of suffix search lists because of a complex naming strategy or disjoined namespace.

Entries in the GlobalNames zones must be populated manually. GlobalNames zone entries are alias (CNAME) records to existing DNS A or AAAA records. The existing DNS A and AAAA records can be dynamically updated, with these updates flowing on to records in the GlobalNames zone.

To deploy a GlobalNames zone in a forest, perform the following steps:

1. On a domain controller that is configured as a DNS server, create a new Active Directory–integrated forward lookup zone and configure it to replicate to every domain controller in the forest using the New Zone Wizard

2. On the Zone Name page, enter GlobalNames as the zone name. You can also accomplish the same task by running the following PowerShell command:

   Click here to view code image

   Add-DnsServerPrimaryZone -Name GlobalNames -ReplicationScope Forest

3. Next, activate the GlobalNames zone on each authoritative DNS server hosted on a domain controller in the forest. To do this, execute the following PowerShell command (where DNSServerName is the name of the domain controller hosting DNS):

   Click here to view code image

   Set-DnsServerGlobalNameZone -ComputerName DNSServerName -Enable $True

4. To populate the GlobalNames zone, create alias (CNAME) records in the GlobalNames zone that point to A or AAAA records in existing zones.

Zone delegation

Zone delegations function as pointers to the next subordinate DNS layer in the DNS hierarchy. For example, if your organization uses the contoso.com DNS zone and you want to create a separate australia.contoso.com DNS zone, you can perform a zone delegation so that the DNS servers for the contoso.com DNS zone point to the DNS servers for the australia.contoso.com DNS zone. When you create a new child domain in an Active Directory forest, zone delegation occurs automatically. When you’re performing a manual delegation, create the delegated zone on the target DNS server before performing the delegation from the parent zone.

Although you can delegate several levels, remember that the maximum length of an FQDN is 255 bytes and the maximum length of an FQDN for an Active Directory Domain Services domain controller is 155 bytes.

Use the Add-DnsServerZoneDelegation cmdlet to add a delegation. For example, to add a delegation for the australia.contoso.com zone to the contoso.com zone pointing at the name server ausdns.australia.contoso.com, which has the IP address 192.168.15.100, use the following command:

Click here to view code image

Add-DnsServerZoneDelegation -Name "contoso.com" -ChildZoneName "australia" -NameServer
"ausdns.australia.contoso.com" -IPAddress 192.168.15.100 -PassThru

Zone aging and scavenging

Aging and scavenging provide a technique to reduce the incidence of stale resource records in a primary DNS zone. Stale records are records that are out of date or no longer relevant. If your organization has zones that relate to users with portable computers, such as laptops and tablets, those zones might end up accumulating stale resource records. This can lead to the following problems:

• DNS queries return stale rather than relevant results.

• Large zones can cause DNS server performance problems.

• Stale records might prevent DNS names being reassigned to different devices.

To resolve these problems, you can configure the DNS server service to do the following:

• Time stamp resource records that are dynamically added to primary zones. This occurs when you enable aging and scavenging.

• Age resource records based on a refresh time period.

• Scavenge resource records that are still present beyond the refresh period.

After you configure the DNS server service, aging and scavenging occur automatically. It is also possible to trigger scavenging by right-clicking the DNS server in DNS Manager and then selecting Scavenge Stale Resource Records. You can also configure aging and scavenging using the Set-DnsServerScavenging cmdlet. For example, to enable stale resource record scavenging on all zones of a DNS server and to set the Scavenging and Refresh Intervals to 10 days, issue this command:

Click here to view code image

Set-DnsServerScavenging -ApplyOnAllZones -RefreshInterval 10.0:0:0 -ScavengingInterval
10.0:0:0 -ScavengingState $True

Forwarders

When you want to have a specific DNS server on the internet handle your organization’s DNS resolution traffic, you are likely to use a DNS forwarder, rather than have your DNS server just use the root servers. Most organizations configure their ISP’s DNS server as a forwarder. When you do this, the ISP’s DNS server performs all the query work, returning the result to your organization’s DNS server. Your organization’s DNS server then returns the result of the query back to the original requesting client.

You configure forwarders on a per-DNS server level. You can configure a forwarder using the DNS Manager. You can do this by editing the properties of the DNS server and then configuring the list of forwarders on the Forwarders tab.

You can create a DNS forwarder by using the Add-DnsServerForwarder cmdlet. For example, to create a DNS forwarder for a DNS server with 10.10.10.111 as the IP address, issue this command:

Click here to view code image

Add-DnsServerForwarder 10.10.10.111

You can’t create a forwarder on one DNS server and then have it replicate to all other DNS servers in the forest or the domain; however, this is possible with conditional forwarders and stub zones.

Conditional forwarders

Conditional forwarders only forward address requests from specific domains rather than forwarding all requests that can’t be resolved by the DNS server. When configured, a conditional forwarder takes precedence over a forwarder. Conditional forwarders are useful when your organization has a trust relationship or partnership with another organization or you need to have resolution occur in an Azure DNS private zone that can be connected to through site-to-site VPN or ExpressRoute. You can configure a conditional forwarder that directs all traffic to host names within that organization instead of having to resolve those host names through the standard DNS-resolution process.

You can create conditional forwarders using the Add-DnsServerConditionalForwarder Zone PowerShell cmdlet. For example, to create a conditional forwarder for the DNS domain tailspintoys.com that forwards DNS queries to the server at IP address 10.10.10.102 and also replicates that conditional forwarder to all DNS servers within the Active Directory forest, issue this command:

Click here to view code image

Add-DnsServerConditionalForwarderZone -MasterServers 10.10.10.102 -Name tailspintoys.com
-ReplicationScope Forest

Stub zones

A stub zone is a special zone that stores authoritative name server records for a target zone. Stub zones have an advantage over forwarders when the address of a target zone’s authoritative DNS server changes on a regular basis. Stub zones are often used to host the records for authoritative DNS servers in delegated zones. Using stub zones in this way ensures that delegated zone information is up to date. If you create the stub zone on a writable domain controller, it can be stored with Active Directory and replicated to other domain controllers in the domain or forest.

You can add a stub zone using the Add-DnsServerStubZone cmdlet. For example, to add a DNS stub zone for the fabrikam.com zone using the DNS server at 10.10.10.222 and to also replicate that stub zone to all DNS servers in the forest, execute this command:

Click here to view code image

Add-DnsServerStubZone -MasterServers 10.10.10.222 -Name fabrikam.com -ReplicationScope
Forest -LoadExisting

DNS event logs

The DNS server log is located in the Applications And Services Logs folder in Event Viewer. Depending on how you configure event logging on the Event Logging tab of the DNS server’s properties, this event log can record information, including the following:

• Changes to the DNS service, such as when the DNS server service is stopped or started

• Zone loading and signing events

• Modifications to the DNS server configuration

• DNS warning and error events

By default, the DNS server records all these events. It’s also possible to configure the DNS server to only log errors, or you can have it log errors and warning events. The key with any type of logging is that you should only enable logging for information that you might need to review at some point in time. Many administrators log everything “just in case,” even though they’re only ever interested in a specific type of event.

In the event that you need to debug how a DNS server performs, you can enable Debug Logging on the Debug Logging tab of the DNS server’s Properties dialog box. Debug logging is resource intensive, and you should only use it when you have a specific problem related to the functionality of the DNS server. You can configure debug logging to use a filter so that only traffic from specific hosts is recorded, instead of recording traffic from all hosts that interact with the DNS server.

DNS options

In high-security environments, you can take a number of steps to make a DNS server more secure from attackers who attempt to spoof it. Spoofing can cause the server to provide records that redirect clients to malicious sites. While DNSSEC provides security for zones hosted on the server, most DNS server traffic involves retrieving information from remote DNS servers and passing that information on to clients. In this section, you learn about settings that you can configure to ensure that the information relayed to clients retains its integrity in the event that a nefarious third party attempts to spoof your organization’s DNS servers.

Dnscmd /config /socketpoolsize 4000

Set-DNSServerCache -LockingPercent 80

Set-DNSServerRecursion -RetryInterval 3 -PassThru

Deploy IPAM

You can install the IPAM feature only on a computer that is a member of an AD DS domain. You can have multiple IPAM servers within a single AD DS forest. You are likely to do this if your organization is geographically dispersed and you have separate support teams in the different geographic locations.

It’s important to note that IPAM cannot manage a DHCP or DNS server if the role is installed on the same computer that hosts IPAM. For this reason, you should install the IPAM server feature on a server that doesn’t host the DNS or DHCP roles. IPAM is also not supported on computers that host the AD DS domain controller server role. Additionally, if you want to use the IPAM server to manage IPv6 address ranges, you need to ensure that IPv6 is enabled on the computer hosting the IPAM server. IPAM can use the Windows Internal Database or a dedicated SQL server instance to host data.

Configure server discovery

Server discovery is the process where the IPAM server checks with Active Directory to locate domain controllers, DNS servers, and DHCP servers. You select which domains to discover in the Configure Server Discovery dialog box. After you’ve completed server discovery, you need to run a PowerShell cmdlet that creates and provisions Group Policy objects (GPOs) that allow these servers to be managed by the IPAM server. When you set up the IPAM server, you choose a GPO name prefix. Use this prefix when executing the Invoke-IpamGpoProvisioning PowerShell cmdlet that creates the appropriate GPOs.

If you use the GPO prefix IPAM, the three GPOS are named:

• IPAM_DC_NPS

• IPAM_DHCP

• IPAM_DNS

Until these GPOs apply to the discovered servers, these servers are listed as having an IPAM Access status of Blocked. After the GPOs are applied to the discovered servers, the IPAM Access status is set to Unblocked. After the discovered service has an IPAM Access status set to Unblocked, you can edit the properties of the server and set it to Managed. After you do this, you are able to use IPAM to manage the selected services on the server.

IPAM supports managing DNS and DHCP servers in forests where a two-way trust relationship has been configured. You perform DHCP and DNS server discovery in a trusted forest on a per-domain basis.

IPAM administration

You can delegate administrative permissions by adding user accounts to one of five local security groups on the IPAM server. By default, members of the Domain Admins and Enterprise Admins groups are able to perform all tasks on the IPAM server. The five following local security groups are present on the IPAM server after you deploy the role, and they allow you to delegate the following permissions:

• DNS Record Administrator Members of this role can manage DNS resource records.

• IP Address Record Administrator Members of this role can manage IP addresses, but not address spaces, ranges, subnets, or blocks.

• IPAM Administrators Members of this role can perform all tasks on the IPAM server, including viewing IP address tracking information.

• IPAM ASM Administrators ASM stands for Address Space Administrator. Users added to this group can perform all tasks that can be performed by members of the IPAM Users group, but they are also able to manage the IP address space. They cannot perform monitoring tasks and are unable to perform IP address tracking tasks.

• IPAM DHCP Administrator Members of this role can manage DHCP servers using IPAM.

• IPAM DHCP Reservations Administrator Members of this role can manage DHCP reservations using IPAM.

• IPAM DHCP Scope Administrator Members of this role can manage DHCP scopes.

• IPAM MSM Administrators MSM stands for Multi-Server-Management. Members of this role can manage all DNS and DHCP servers managed by IPAM.

• IPAM DNS Administrator Members of this role can manage DHCP servers using IPAM.

Managing the IP address space

The benefit of IPAM is that it allows you to manage all the IP addresses in your organization. IPAM supports the management of IPv4 public and private addresses, whether they are statically or dynamically assigned. IPAM allows you to detect whether there are overlapping IP address ranges defined in DHCP scopes on different servers; determine IP address utilization and whether there are free IP addresses in a specific range; create DHCP reservations centrally without having to configure them on individual DHCP servers; and create DNS records based on IP address lease information.

IPAM separates the IP address space into blocks, ranges, and individual addresses. An IP address block is a large collection of IP addresses that you use to classify the address space that your organization uses at the highest level. An organization might only have one or two address blocks: one for its entire internal network and another smaller block that represents the public IP address space used by the organization. An IP address range is part of an IP address block. An IP address range cannot map to multiple IP address blocks. Generally, an IP address range corresponds to a DHCP scope. An individual IP address maps to a single IP address range. IPAM stores the following information with an IP address:

• Any associated MAC (Media Access Control) addresses

• How the address is assigned (static/DHCP)

• Assignment date

• Assignment expiration

• Which service manages the IP address

• DNS records associated with the IP address

IP address tracking

One of the most important features of IPAM is its ability to track IP addresses by correlating DHCP leases with user and computer authentication events on managed domain controllers and Network Policy Servers (NPSs). IP address tracking allows you to figure out which user was associated with a specific IP address at a particular point in time, which can be important when trying to determine the cause of unauthorized activity on the organizational network.

You can search for IP address records using one of the following four parameters:

• Track by IP address You can track by IPv4 address, but IPAM does not support tracking by IPv6 address.

• Track by client ID You can track by client ID in IPAM, which allows you to track IP address activity by MAC address.

• Track by host name You can track by the computer’s name as registered in DNS.

• Track by username You can track a username, but to do this, you must also provide a host name.

Naturally, you can only track data that has been recorded since IPAM has been deployed. So, while it is possible to store several years of data in the Windows Internal Database that IPAM uses, you are limited to only being able to retrieve events recorded after IPAM was configured.

Microsoft estimates that the Windows Internal Database IPAM uses is able to store three years of IP address utilization data for an organization that has 100,000 users before data must be purged.

You can use IPAM to locate free subnets and free IP address ranges in your existing IP address scheme. For example, if you need 50 consecutive free IP addresses for a project, you can use the Find-IpamFreeRange PowerShell cmdlet to determine whether such a range is present in your current environment.

Server and scope options

DHCP options include additional configuration settings, such as the address of a network’s default gateway or the addresses of DNS servers. You can configure DHCP options at two levels: the scope level and the server level. Options configured at the scope level override options configured at the server level.

Common scope options include:

• 003 Router The address of the default gateway for the subnet.

• 006 DNS Servers The address of DNS servers that the client should use for name resolution.

• 015 DNS Domain Name This is the DNS suffix assigned to the client.

• 058 Renewal time This determines how long after the lease is initially acquired that the client waits before it attempts to renew the lease.

You can configure IPv4 scope options using the Set-DHCPServer4OptionValue cmdlet. For example, to configure the scope with ID 192.168.10.0 on DHCP server dhcp.contoso.com with the value for the DNS server set to 192.168.0.100, issue the following command:

Click here to view code image

Set-DHcpServerv4OptionValue -Computername dhcp.contoso.com -ScopeID 192.168.10.0
-DNSServer 192.168.0.100

Superscopes

A superscope is a collection of individual DHCP scopes. You might create a superscope when you want to bind existing scopes for administrative reasons. For example, imagine that you have a subnet in a building that is close to fully allocated. You can add a second subnet to the building and then bind them into a superscope. The process of binding several separate logical subnets on the same physical network is known as multinetting.

At least one existing scope must be present on the DHCP server before you can create a superscope. After you have created a superscope, you can add new subnets or remove subnets from that scope. It’s also possible to deactivate some subnets within a scope while keeping others active. You might use this technique when migrating clients from one IP address range to another. For example, you could have both the source and destination scopes as part of the same superscope and activate the new scope and deactivate the original scope as necessary when performing the migration. You can create superscopes using the Add-DHCPServerv4 Superscope cmdlet. For example, to add the scopes with ID 192.168.10.0 and 192.168.11.0 to a superscope named MelbourneCBD, run the following command:

Click here to view code image

Add-DhcpServerv4Superscope -SuperscopeName "MelbourneCBD" -ScopeId 192.168.10.0,
192.168.11.0

Multicast scopes

A multicast address is an address that allows one-to-many communications on a network. When you use multicast, multiple hosts on a network listen for traffic on a single multicast IP address. Multicast addresses are in the IPv4 range of 224.0.0.0 to 239.255.255.255. Multicast scopes are collections of multicast addresses. You can configure a Windows Server 2016 DHCP server to host multicast scopes. Multicast scopes are also known as Multicast Address Dynamic Client Allocation Protocol (MADCAP) scopes because applications that require access to multicast addresses support the MADCAP API.

The most common use for multicast addresses using the default Windows Server 2016 roles is for Windows Deployment Services (WDS). You can, however, configure the WDS server with its own set of multicast addresses, and you don’t need to configure a special multicast scope in DHCP to support this role.

Split scopes

A split scope is one method of providing fault tolerance for a DHCP scope. The idea behind a split scope is that you host one part of the scope on one DHCP server and a second, smaller part of the scope on a second DHCP server. Usually, this split has 80 percent of the addresses on the first DHCP server and 20 percent of the addresses on the second server. In this scenario, the DHCP server that hosts the 20 percent portion of the address space is usually located on a remote subnet. In the split-scope scenario, you also use a DHCP relay agent configured with a delay so that most addresses are leased from the DHCP server that hosts 80 percent of the address space. Split scopes are most likely to be used in scenarios where your DHCP servers aren’t running on Windows Server 2012 or later operating systems. If you want to provide fault tolerance for scopes hosted on servers running Windows Server 2012 or later, you should instead implement DHCP failover.

Name protection

DHCP name protection is a feature that allows you to ensure that the host names a DHCP server registers with a DNS server are not overwritten in the event that a non-Windows operating system has the same name. DHCP name protection also protects names from being overwritten by hosts that use static addresses that conflict with DHCP-assigned addresses.

For example, imagine that in the tailwindtraders.com domain there is a computer running the Windows 11 operating system that has the name Auckland and receives its IP address information from a Windows Server DHCP server. The DHCP server registers this name in DNS and creates a record in the contoso.com DNS zone that associates the name Auckland.tailwindtraders.com with the IP address assigned to the computer running Windows 11. A newly installed computer running a custom distribution of Linux is also assigned the name Auckland. Because name protection has been enabled, this new computer is unable to overwrite the existing record with a new record that associates the name Auckland.tailwindtraders.com with the Linux computer’s IP address. If name protection had not been enabled, it is possible that the record would have been overwritten.

You can enable name protection on a scope by selecting Configure on the DNS tab of the IPv4 or IPv6 Properties dialog box. You can also do this by using the Set-DhcpServerv4 DnsSetting or the Set-DhcpServerv6DnsSetting cmdlet. For example, to configure the DHCP server on computer MEL-DC so that name protection is enabled on all IPv4 scopes, issue the following command:

Click here to view code image

Set-DhcpServerv4DnsSetting -Computer MEL-DC -NameProtection $true

DHCP relay

The DHCP relay agent allows you to relay DHCP requests from a logical network or VLAN that does not have a DHCP server to a subnet that does. Windows Server supports the deployment of a DHCP relay agent as part of the Routing and Remote Access role. When configuring the DHCP relay agent component of Routing and Remote Access, you specify the IP address of the DHCP server that is used to provision IP addresses. Because configuring Routing and Remote Access to support a DHCP relay agent is more complicated than deploying a new DHCP server, some organizations simply opt to deploy a new DHCP server and manage the relevant scopes through IPAM. Alternatively, most organizations configure routers to forward DHCP requests, and in those environments, it is not necessary to configure a DHCP relay agent. Other aspects of the Routing and Remote Access role are covered later in this chapter.

DHCP policies

DHCP policies allow you to group DHCP clients based on information contained with that client’s DHCP request packet. For example, if you had a collection of Microsoft Teams phones that had a specific range of MAC addresses connected to a subnet serviced by a specific DHCP scope, you could configure a DHCP policy to assign separate scope options to those clients that differed from those assigned normally.

Configuring reservations

There are two ways to configure a DHCP reservation. The simplest way is to locate an existing IP address lease in the DHCP console, right-click it, and then select Add To Reservation. This then ties that specific network adapter address to that IP address. The only drawback of this method is that the reservation is for the assigned IP address, and you cannot customize it.

If you know the network adapter address, also known as a MAC address, of the computer for which you want to configure a reservation, you can right-click the Reservations node under the scope that you want to configure the reservation under, and then select New Reservation. In the New Reservation dialog box fill out the Reservation Name, IP Address, and Network Adapter Address fields, and then select Add to create the reservation. You can also configure a reservation using the Add-DhcpServerv4Reservation cmdlet. For example, to configure a reservation, issue the following command:

Click here to view code image

Add-DhcpServerv4Reservation -ScopeId 192.168.10.0 -IPAddress 192.168.10.8 -ClientId
A0-FE-C1-7A-00-E5 -Description "A4 Printer"

DHCP filtering

You can configure DHCP filtering on the Filters tab of the IPv4 Properties dialog box in the DHCP console. DHCP filtering is used in high-security environments to restrict the network adapter addresses that can utilize DHCP. For example, you can have a list of all network adapter addresses in your organization and use the Enable Allow List option to lease only IP addresses to this list of authorized adapters. This method of security is not entirely effective because it is possible for unauthorized people to fake an authorized adapter address as a way of gaining network access. You can add a specific network adapter to the allowed list of MAC addresses using the Add-DHCPServerv4Filter cmdlet. For example, to allow a laptop with the MAC address D1-F2-7C-00-5E-F0 to the authorized list of adapters, issue this command:

Click here to view code image

Add-DhcpServerv4Filter -List Allow -MacAddress D1-F2-7C-00-5E-F0 Description "Rooslan's
Laptop"

RADIUS servers

The Network Policy Server (NPS) role is Microsoft’s implementation of a RADIUS server. A RADIUS server performs authentication, authorization, and accounting for VPN, 802.1x wireless access point and authenticating switches, and dial-up connections.

Given that NPS is an implementation of the RADIUS protocol, you can use NPS with other third-party products that support the RADIUS protocol, as well as other versions of Microsoft products that support RADIUS. The NPS role’s support for the RADIUS protocol means that you can integrate it with most third-party remote and network access products. Active Directory functions as the user account database when a server with the NPS role installed is a member of an Active Directory Domain Services (AD DS) domain. You configure whether the local server performs RADIUS authentication when creating a connection request policy, or by editing the properties of a connection request policy.

VPN server

After you install the Remote Access role on a computer running Windows Server, you can configure the server as a VPN server. Before you deploy Windows Server as a VPN server, ensure that you have met the following requirements:

• The computer that functions as the VPN server must have two network adapters. Prior to configuring the VPN server, you must determine which interface accepts incoming traffic from untrusted networks. You specify this network interface during VPN setup.

• Determine how clients from untrusted networks receive IP addresses on the trusted network. You can configure the VPN server to interact with an existing DHCP server on the trusted network. When you do this, the VPN server leases blocks of 10 IP addresses and assigns them to remote clients. You also have the option of manually configuring an address pool from which the VPN server can lease IP addresses. When you do this, you must ensure that the manually selected IP addresses are not already in use and are not used in the future by clients other than those that connect using the VPN server.

• Decide whether you want the VPN server to authenticate connections or pass authentication requests on to a server with the NPS role installed. You might choose to configure the VPN server to pass authentication requests on to a server with the NPS role installed if you have multiple servers or if you have configured a stand-alone server as a VPN server as a way of enhancing security.

LAN routing

You can configure Windows Server to function as a network router in the same way that you configure traditional hardware devices to perform this role. LAN routing is often used with virtual machines to connect private or internal virtual machine networks with an external network. To perform the LAN routing function, Windows Server must have two or more network adapters. Windows Server supports using Routing Information Protocol (RIP) v2 for route discovery. You can also use the Routing and Remote Access console to configure static routes.

Network address translation

Network address translation (NAT) enables you to share an internet connection with computers on an internal network. In a typical NAT configuration, the NAT server has two network interfaces, where one network interface is connected to the internet and the second network interface connects to a network with a private IP address range. Computers on the private IP address range can then establish communication with computers on the internet. It is also possible to configure port forwarding so all traffic that is sent to a particular port on the NAT server’s public interface is directed to a specific IP address/port combination on a host on the private IP address range.

DirectAccess

DirectAccess is an always-on remote access solution, which means that if a client computer is configured with DirectAccess and connects to the internet, a persistent connection is established between that computer and the organization’s internal network. One big advantage of DirectAccess is that it does not require users to directly authenticate. The client computer determines that it is connected to the internet by attempting to connect to a website that is only accessible from the internal network. If the client determines that it is on a network other than the internal network, it automatically initiates a connection to the internal network.

When determining its network connection status, the client first attempts to determine whether it is connected to a native IPv6 network. If the client has been assigned a public IPv6 address, it can make a direct connection to the organization’s internal DirectAccess servers. If the client determines that it is not connected to a native IPv6 network, it attempts to create an IPv6 over IPv4 tunnel using the 6to4 and then Teredo technologies. If connections cannot be established using these technologies, it attempts to use IP-HTTPS, which is similar to the SSTP protocol discussed earlier, except that it encapsulates IPv6 traffic within the HTTPS protocol.

When a connection is established, authentication occurs using computer certificates. These computer certificates must be preinstalled on the client, but the benefit of this requirement is that user intervention is not required. Authentication occurs automatically and the connection occurs seamlessly.

DirectAccess supports remote client management through a feature named Manage Out. Manage Out enables remote management functionality for DirectAccess clients, allowing administrative tasks, including tasks that in the past could only be performed on computers on a local area network, to be performed on clients without requiring a connection to cloud-hosted solutions such as Intune.

The primary drawback of DirectAccess is that it requires a domain-joined computer. DirectAccess clients are configured through GPOs. The configuration GPO is automatically created through the DirectAccess setup process. This GPO is filtered so that it only applies to the security group you’ve designated to host the DirectAccess clients.

Dnscmd /config /globalqueryblocklist wpad

Connection request policies

A connection request policy is a set of conditions that enable you to specify which RADIUS server performs the authorization and authentication process for specific RADIUS clients. You can configure multiple connection request policies on a server with the NPS role installed. When multiple policies are present, policies are processed according to the policy processing order. The first policy where conditions are met is used.

Network access server type

One of the first steps you take when creating a connection request policy is to specify the type of network access server that will be sending traffic to the NPS server. When configuring the policy, you can choose from the following connection types:

• Remote Desktop Gateway Use this option when you are configuring the NPS server to perform authentication for an RD Gateway server.

• Remote Access Server (VPN-Dial Up) Use this option when you are configuring the NPS server to perform authentication for remote access. You can use this method with both VPN and dial-up servers.

• Unspecified Use this type if you are configuring NPS to perform authentication for an 802.1x authenticating switch or wireless access point.

You can also configure a vendor-specific network access server and use the vendor-specific ID if you are configuring NPS to perform authentication from a third-party access server.

Request policy conditions

When you configure multiple policies, the policies are evaluated in numerical order, with the first policy that matches the specified conditions being used. You add conditions on the Specify Conditions page of the New Connection Request Policy wizard. Although at least one condition must exist, you can also use multiple conditions when you create a connection request policy. You can select from the following conditions:

• Username The username as specified in the RADIUS message. This name includes both the user account name and the RADIUS realm name. You can use wildcards when configuring this condition.

• Access Client IPv4 Address The IPv4 address of the client requesting access.

• Access Client IPv6 Address The IPv6 address of the client requesting access.

• Framed Protocol Use this condition when you want to apply the policy to clients using a specific framing protocol such as PPP.

• Service Type Enables you to create a condition that depends on the type of service.

• Tunnel Type Use this condition to create a policy that applies only to a specific type of tunnel, such as an LT2P/IPsec tunnel.

• Day and Time Restrictions Enables you to create a condition determining when connection attempts will be accepted or denied. Day and time restrictions are based on the time zone set on the NPS server.

• Calling Station ID This RADIUS client property enables the policy to match the telephone number of the network access server to which the client connected. For example, if the dial-up server had the phone number 555-5555, it could be used as the calling station ID.

• Client Friendly Name This RADIUS client property enables the policy to match the identity of the RADIUS client that forwarded the connection request to the NPS server. For example, if the VPN server were named VPN-ALPHA, it could be used as the client friendly name.

• Client IPv4 Address This RADIUS client property enables the policy to match the IPv4 address of the RADIUS client that forwarded the connection request to the NPS server. For example, you could use the IPv4 address of a VPN server as the client IPv4 address.

• Client IPv6 Address This RADIUS client property enables the policy to match the IPv6 address of the RADIUS client that forwarded the connection request to the NPS server. For example, you could use the IPv6 address of a VPN server as the client IPv6 address.

• Client Vendor Enables you to use the name of the RADIUS client vendor that is forwarding connection requests to the NPS server.

• Called Station ID Similar to the RADIUS client property, this property enables you to specify the telephone number of the network access server. In this and the following property items, the network access server is not using RADIUS but is forwarding authentication traffic to the server with the NPS role installed.

• NAS Identifier In this scenario, NAS is the acronym of Network Access Server rather than Network Attached Storage. This property enables you to specify a character string representing the name of the network access server.

• NAS IPv4 Address This property enables you to specify the IPv4 address of the network access server.

• NAS IPv6 Address Use this property to specify the IPv6 address of the network access server.

• NAS Port Type Use this property to specify the types of access media, including ISDN, VPN, Ethernet, or Cable.

RADIUS terminology can be confusing. It is important to remember that RADIUS clients are not the same as remote access clients. For example, a VPN or dial-up server that forwards authentication requests to an NPS server is a RADIUS client. The remote computer making the connection to the VPN or dial-up server is not a RADIUS client.

Connection request forwarding

By configuring a connection request forwarding setting, you can specify whether the local server performs authentication or forwards authentication traffic to a remote RADIUS server group. You can also configure connection request forwarding so that users are automatically accepted without any credential validation. You can also configure accounting on the Specify Connection Request Forwarding page. Accounting enables you to record RADIUS traffic.

Authentication methods

The Specify Authentication Methods page enables you to configure which authentication method or methods clients can use. These settings override any authentication methods specified in the network policy. When you specify multiple methods, the NPS server attempts the most secure method, and then the next most secure method, until it reaches the least secure specified method. The most secure authentication types are the Extensible Authentication Protocols (EAPs), which include the following:

• Microsoft: Smart Card or Other Certificate

• Microsoft: Protected EAP (PEAP)

• Microsoft: Secured Password (EAP-MSCHAP v2)

You can also configure NPS to support less secure authentication protocols. The less secure authentication protocols, from most secure to least secure, are the following:

• Microsoft Encrypted Authentication Version 2 (MS-CHAP-v2) When enabling this authentication method, you can also allow users to change passwords after that password has expired. MS-CHAP-v2 was first introduced with Windows NT 4.0 Service Pack 4.

• Microsoft Encrypted Authentication (MS-CHAP) A less secure version of MS-CHAP-v2. You can also allow users to change passwords after the password expiration date.

• Encrypted Authentication (CHAP) Unless there is an excellent reason otherwise, don’t use this authentication protocol. You should use this protocol only if you need to support old clients that don’t support more secure authentication protocols.

• Unencrypted Authentication (PAP, SPAP) You use these protocols only if you need to support old clients that don’t support more secure authentication protocols. Use these protocols with care because they pass credentials in cleartext format.

• Allow Clients To Connect Without Negotiating An Authentication Method This option enables clients to connect without requiring a specific authentication method.

Realm and RADIUS attributes

You can apply a realm name as well as RADIUS attributes to a connection request policy. This is often done when the computer with the NPS server role installed is functioning as a RADIUS proxy. When functioning as a proxy, the server with the NPS role installed can alter attributes that were passed to it by a RADIUS client. This process enables the RADIUS server providing authentication to use the altered attributes instead of the ones sent by the client. When functioning as a RADIUS proxy, the server with the NPS role installed can also add additional attributes to the traffic forwarded to the RADIUS server that provides authentication services.

Default connection request policy

Windows Server creates a default connection request policy when you deploy the NPS role. The name of this policy is Use Windows Authentication For All Users, and it is assigned the processing order of 999999. The NPS server uses this policy as a last resort. The policy has the following properties, with all other properties not configured:

• Authentication Methods: Unspecified

• Authentication: Authenticate Requests On This Server

• Conditions: Sunday To Saturday, 00:00 To 24:00

Creating a connection request policy

You can create a connection request policy from the NPS console. To create a connection request policy, perform the following steps:

1. Open the NPS console from the Tools menu in Server Manager, expand the Policies node, and select Connection Request Policies. In the Action menu, select New.

2. On the Specify Connection Request Policy Name And Connection Type page, provide a policy name and specify the type of network access server to which the policy applies.

3. On the Specify Conditions page, add at least one condition that differentiates the policy from any other policies on the server with the NPS role installed.

4. On the Specify Connection Request Forwarding page, specify whether the local server will perform authentication, or whether the server with the NPS role installed will function as a RADIUS proxy and forward requests to a remote server. You can also configure accounting on this page.

5. On the Specify Authentication Methods page, choose whether to override network policy authentication settings. If you do, you must specify which authentication methods you will use in place of the ones specified in the network policy.

6. If the server with the NPS role installed is functioning as a RADIUS proxy, you can configure additional attributes as well as replace existing attributes forwarded by a RADIUS client on the Configure Settings page.

7. You then complete the New Connection Request Policy Wizard. The policy will be assigned the next available processing order number. You can right-click the policy and select Move Up or Move Down to change the policy processing order.

IP filters

IP filters enable you to control incoming and outgoing traffic based on source and destination IP address, as well as port and protocol. You use IP address filters to limit communication between clients and specific hosts and services on the network. You can configure IP filters on the Settings page of the Network Policy properties or when creating a network policy.

Encryption

When configuring network policies, you can select which types of encryption the connection can use on the Configure Settings page of the New Network Policy Wizard or by editing the properties of an existing network policy. If you want to force network connections to use strong encryption, ensure that the No Encryption and Basic Encryption settings are not selected in the network policy. The key length determines the strength of the encryption. Although increased key length does improve security, it also comes at the cost of increased processor overhead.

IP settings

IP settings, which you can configure when creating a network policy or by editing the properties of a policy, enable you to configure how a client receives an IP address. You can configure the following settings:

• Server Must Supply An IP Address

• Client May Request An IP Address

• Server Settings Determine IP Address Assignment

• Assign A Static IPv4 Address

You can configure an IPv6 address on the Standard page of the RADIUS attributes section.

Creating network policies

Network policies determine which users and computers are authorized to connect to the network. The process of creating network policies is similar to creating connection request policies. Both sets of policies share many of the same elements. To create a network policy, perform the following steps:

1. In the NPS console, select Network Policies under the Policies node and on the Action menu, select New.

2. On the Specify Network Policy Name And Connection Type page, enter a policy name and specify the type of network access server. The options are the following:

   • Remote Desktop Gateway

   • Remote Access Server (VPN-Dial Up)

3. On the Specify Conditions page, select one or more conditions that determine whether the policy applies.

   • Windows Groups The user or computer must belong to a Windows security group.

   • Machine Groups The computer must belong to a Windows security group.

   • User Groups The user must belong to a Windows security group.

   • Day And Time Restrictions Policy applies only at specific dates and times.

   • Access Client IPv4 Address The client’s IPv4 address, not the RADIUS client’s IP address.

   • Access Client IPv6 Address The client’s IPv6 address.

   • Authentication Type Authentication method used, which includes CHAP, EAP, MS-CHAP v1, MS-CHAP v2, PAP, PEAP, and Unauthenticated.

   • Allowed EAP Types Allowed EAP types, which includes Microsoft: Smart Card or other certificate, Microsoft PEAP, and Microsoft: EAP-MSCHAP v2.

   • Framed Protocol Policy applies only to clients using the specified framed protocol, such as PPP or SLIP.

   • Service Type Applies when the client uses a particular service type.

   • Tunnel Type Applies when the client uses a particular tunnel type.

   • Calling Station ID RADIUS calling station ID.

   • Client Friendly Name RADIUS client name.

   • Client IPv4 Address RADIUS IPv4 address.

   • Client IPv6 Address RADIUS IPv6 address.

   • Client Vendor RADIUS client vendor.

   • MS-RAS Vendor RADIUS vendor ID.

   • Called Station ID Number of the network access server.

   • NAS Identifier Network access server name.

   • NAS IPv4 Address Network access server IPv4 address.

   • NAS IPv6 Address Network access server IPv6 address.

   • NAS Port Type Network access server media type, including ISDN, wireless, VPN, or tunnel.

4. On the Specify Access Permission page, choose whether access is granted or denied to computers or users that meet the specified conditions.

5. On the Configure Authentication Methods page, specify which authentication methods the client can use to authenticate.

6. On the Configure Constraints page, you can configure the following properties:

   • Idle Timeout

   • Session Timeout

   • Called Station ID

   • Day and Time Restrictions

   • NAS Port Type

7. On the Configure Settings page of the New Network Policy Wizard, you can configure the following:

   • RADIUS Attributes

   • Multilink and Bandwidth Allocation Protocol

   • IP Filters

   • Encryption

   • IP Settings

8. Clicking Next enables you to complete the wizard. You can then alter the position of the policy by moving it up and down. Clients use the first policy for which they meet the conditions.

NPS templates

NPS templates enable you to save a specific NPS component configuration so that it can be reused or exported to another server with the NPS role installed. You can apply the template to multiple policies to ensure uniform configuration. You can configure the following templates:

• Shared Secrets

• RADIUS Clients

• Remote RADIUS Servers

• IP Filters

To configure a template, select the type of template that you want to configure in the NPS console. Then, from the Action menu, select New. Configure the template in the same way that you would configure the associated properties in a policy.