Steven M. Jordan

Showing posts with label Windows Server. Show all posts

How to Assign Active Network Location with PowerShell.

Step 1: Identify networks and associated NICs.

Get-NetConnectionProfile

Name             : domain.com

InterfaceAlias   : Ethernet (Domain)

InterfaceIndex   : 1

NetworkCategory  : DomainAuthenticated

IPv4Connectivity : Internet

IPv6Connectivity : NoTraffic



Name             : Unidentified network

InterfaceAlias   : RDMA

InterfaceIndex   : 2

NetworkCategory  : Public

IPv4Connectivity : NoTraffic

IPv6Connectivity : NoTraffic

The above examples shows two NICs that belong to two different networks.

Step 2. Change the NetworkCategory:

Set-NetConnectionProfile -InterfaceIndex 13 -NetworkCategory Private

This example changes the active network for the NIC named RDMA. The network location changed from Public to Private. Confirm with Get-NetConnectionProfile.

That't It!

References:

https://docs.microsoft.com/en-us/powershell/module/netconnection/get-netconnectionprofile?view=win10-ps

Problem:

How to use PowerShell commands to transfer FISMO roles?

Solution:

Active Directory PowerShell module.

Assumptions:

FISMO PowerShell management requires Active Directory PowerShell module.

Import-Module ActiveDirectory

Example 1. Show forest FSMO roles (forest):

PS> Get-ADForest contoso.com| ft DomainNamingMaster, SchemaMaster

Example 2. Show domain FSMO roles (domain):

PS> Get-ADDomain contoso.com | ft InfrastructureMaster, PDCEmulator, RIDMaster

Example 3. Transfer single role to a domain controller.

PS>; Move-ADDirectoryServerOperationMasterRole -Identity "DCX" PDCEmulator

#N.B., PowerShell FISMO role names:

0= PDCEmulator
1= RIDMaster
2= InfrastructureMaster
3= SchemaMaster
4= DomainNamingMaster

Example 4. Transfer multiple roles.

Move-ADDirectoryServerOperationMasterRole -Identity “DCX” –OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster

Example 5: Transfer all roles with numbers:

Move-ADDirectoryServerOperationMasterRole “DCX” –OperationMasterRole 0,1,2,3,4

Example 6. Transfer FSMO roles between domain controllers:

Move-ADDirectoryServerOperationMasterRole

That's It!

References:

https://docs.microsoft.com/en-us/powershell/module/addsadministration/move-addirectoryserveroperationmasterrole?view=win10-ps
https://blogs.technet.microsoft.com/canitpro/2017/05/24/step-by-step-migrating-active-directory-fsmo-roles-from-windows-server-2012-r2-to-2016/

Problem:

Windows 2012 RRAS IPsec VPN does not support NAT-T out-of-the-box. By default, RRAS only works with public IP addresses -no NAT. Windows 10 clients cannot connect with L2TP from outside the office. Windows 2016 does not support L2TP for any client from behind routers running NAT.

Solution:

Enable NAT-T on both Windows servers and the clients. NAT-T allows the VPN server to serve clients (e.g., Windows 10, Android, Apple iOS) from behind the NAT device. Modify MTU.

Background:

Why NAT-T?

IPsec uses Encapsulating Security Payload (ESP) to encrypt packet headers and payloads. By default, ESP is not compatible with Port Address Translation (PAT). This is because TCP uses ports and ESP does not.

TCP and ESP are different Internet protocols. TCP uses protocol number 6. N.B., TCP protocol number 6 is not the same thing as TCP port 6. TCP ports are communication endpoints. For example, TCP uses port 80 for web traffic.

ESP uses protocol (i.e., not port) number 50. ESP is a protocol without ports. Network Address Translation (NAT) uses port translation PAT to bind traffic flows with internal hosts. Therefore, ESP does not work with NAT.

NAT-T allows ESP to work from behind NAT. It encapsulates ESP protocol 50 inside User Datagram Protocol (UDP) 4500. N.B, NAT-T is not the same as IPsec over UDP.

Enable NAT-T

NAT-T is enabled on most operating systems (e.g., Android) -Windows is the exception. Fortunately, we can enable NAT-T on Windows 10 and Windows 2012 with a few simple changes.

~~Windows IPsec clients are supposed to work from any location. Therefore, only enable NAT-T on the 2012 RRAS server.~~

Create a new registry key to enable NAT-T.

Edit Registry or create GPO:

HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Parameters\

Create new DWORD value: AssumeUDPEncapsulationContextOnSendRule

Modify DWORD value: 2

These changes will fix those pesky L2TP-NAT problem.

Troubleshooting Issues

Make sure clients use the latest edition of Windows 10. Early versions had quirks where clients simply would not connect via NAT-T.

NAT-T does not work with the following editions:

version 10240
version 1511 (i.e. November Update)

Unconfirmed (may or may not work):

version 1607 (i.e., Anniversary Update)

Confirmed:

version 1703 (i.e., Creators Update)

NAT-T works great with the registry fix and Creators Update.

Workarounds:

Some folks had to toggle the NAT-T registry value in order to connect (http://bit.ly/2r2CKnF). I assume this fix was for the November or Anniversary Update.

MTU

Don't forget to adjust the Max Segment Size (MSS):
http://www.stevenjordan.net/2016/11/windows-ikev2-mtu.html.

That's It!

S4B: Bypass Split-Tunnel VPNs.

Take Away:

Skype for Business (S4B) and Lync clients may experience problems when traversing a split-tunnel VPN. Use Name Resolution Policy Table (NRPT) and Windows firewall group policies (GPOs) to bypass split-tunnel VPNs. This solution is easy to administer and provides remote offices the best multimedia experience.

Problem:

The DCA office experiences weird S4B/ Lync issues:

Local S4B/ Lync clients cannot host conference calls for external clients.
All clients (external and DCA) can connect to conference calls hosted at at the company headquarters (JFK).
Local S4B/ Lync clients cannot share multimedia content (e.g., screen-sharing, video, etc.) between external clients.
All clients can share multimedia content when connected to conference calls hosted at JFK HQ.
Audio and video quality is poor (e.g., choppy or static) between DCA and JFK locations.

Topology:

This business consists of two locations: JFK is the primary HQ office. DCA is the branch office.

A site-to-site IPsec VPN tunnel connects the DCA and JFK offices.
DCA uses split-tunneling to forward all corporate data.
DCA uses its default gateway to forward all other traffic to the Internet.
JKF hosts all Lync servers: Front End, Access Edge, and Reverse Proxy servers.
Both DCA and JFK use Active Directory (AD) integrated DNS servers.
External clients allow staff to work from home.

Figure 1. Example of Lync and organization topology.

ICE Framework:

S4B-Lync uses network topology to select the best connection path. It uses a peer-to-peer connection framework called Interactive Connectivity Establishment (ICE).   This framework includes Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) protocols.

STUN identifies client Network Address Translation (NAT) (i.e., private IPs). This process also identifies the default gateway (i.e., public IP).  Multimedia travels directly between end-points when STUN is used. S4B/ Lync clients prefer to communicate directly (i.e., peer-to-peer) between clients which reside on the same LAN. N.B., LAN is not a reference for broadcast domains. LAN, in this situation, includes all internal networks (i.e., subnets) with routes to the Front-End subnet. Internal clients never use the Access Edge server for internal communication.

Similarly, external clients prefer STUN for communicating multimedia content to other external peers.  The Access Edge server will only bridge external-to-external clients (i.e., TURN) if peer-to-peer communication is not possible.

Lync clients use TURN framework when end-points do not share a common LAN. The TURN process creates dynamic ports on the Access Edge server; and in turn (pun), proxies external multimedia.  TURN is similar to Port Address Translation (PAT), just as the Access Edge server is similar to an Internet gateway.

To recap, S4B/ Lync clients prefer direct peer-to-peer multimedia communication.  Internal clients will never use the Access Edge server for internal multimedia communication. External clients use the Access Edge server to bridge communication whenever peer-to-peer communication is unavailable; including external-to-external, and external-to-internal.

Split-Tunnel Problems:

ICE framework (generally) provides the best multimedia experience. However, it does not work well over split-tunnel VPNs. Split-tunnel VPNs create STUN and TURN mismatches. For example, the DCA branch office firewall forwards all domain traffic to the JFK primary office; all other traffic forwards out the local gateway (i.e., Internet). DCA and external Lync clients interpret this topology differently (Table 1).

Table 1. Default Multimedia Network Traffic Between Lync Clients
Source	Destination
	JFK	DCA	External Client
JFK	STUN	STUN	TURN
DCA	STUN	STUN	TURN
External Client	TURN	STUN	STUN
Notes: DCA uses split-tunnel VPN to connect to JKF. Stun represents Lync client-to-client. TURN represents multimedia proxy (i.e., Lync Access-Edge) requirement. Blue represents split-tunnel topology. Red represents client topology mismatch.

The primary problem with split-tunnel VPNs is with how the S4B/ Lync client interprets the topology. Recall, internal clients always use the Access Edge server for external communication. Likewise, internal clients never use the Access Edge for internal conversations. The VPN firewall forwards all domain traffic to the JKF network. Therefore, DCA clients consider themselves as internal; and external clients as external. DCA clients will only use the Access Edge server when communicating with external clients.

External clients have an entirely different interpretation of the topology. External clients are aware of the DCA Internet gateway, but they remain unaware of its split-tunneling. External clients will therefore interpret DCA clients as external peers; multimedia traffic is sent directly to the DCA clients (i.e., STUN).

To recap, external clients are unaware of the DCA split-tunnel. These external clients attempt to send audio and video (AV), and expect to receive AV, directly from the DCA clients. Whereas DCA clients send AV, and expect to receive AV, proxied from the Access Edge server.

Figure 2. Lync directional mismatch.

The split-tunnel VPN causes a secondary problem between JFK and DCA. These clients use STUN to establish peer-to-peer connections across the VPN. Users complain about overall client AV quality between these locations.

Multiple layers of encryption decreases overall AV quality. Lync encrypts multimedia packets with TLS and SRTP protocols. The VPN adds additional packet overhead as it encrypts and encapsulates each packet. Staff at both locations can expect better AV if DCA S4B-Lync clients bypass split-tunneling (i.e., TURN).

Figure 3. Bypass the split-tunnel VPN.

Resolution:

S4B-Lync clients can bypass split-tunneling entirely: (a) changes to DNS topology; and (b) changes to client firewalls. Recall, both offices belong to a single AD domain, and each office uses recursive AD integrated DNS servers. AD replication ensures internal name resolution is the same at each location. Lync clients use DNS to locate S4B-Lync servers via S4B-Lync Discovery (Table 2).

Table 2. S4B-Lync Client Discovery Preference Order
DNS Prefix	lyncdiscoverinternal	lyncdiscover
Discovery Order	1st preference	2nd preference
Client	Internal clients	External clients
Server	Front-End	Access-Edge
Notes: Discovery preference assumes organization uses a split-brain DNS topology. Topology consists of independent internal and external DNS servers.

All internal clients, including those on the VPN, use internal DNS for Lync Discovery resolution. External clients use external DNS for their Lync Discovery process. Therefore, VPN clients can bypass split-tunneling using a process that distinguishes Lync traffic, and resolves it using external name records. N.B., Internal DNS continues to resolve all other (i.e., non-Lync) requests. Otherwise, what's the point of having a VPN?

Name Resolution Policy Table:

Split-brain DNS requires a confusing array of zone records. Most Internet documentation suggests pin-point DNS zones to influence Lync traffic. Instead, consider using NRPT, which simplifies the entire domain resolution process.

Lync clients can bypass the VPN with NRPT group policy. NRPT is configured with two simple rules:

Forward all domain name requests for Lync services to external DNS servers.
Use client DNS settings (i.e. internal) for all other DNS resolution.

Create the NRPT Group Policy to allow S4B-Lync clients to bypass the VPN:

Create new GPO: Computer Configuration → Policies → Windows Settings → Name Resolution Policy.
Configure the Advanced Global Policy Settings:

Figure 4. NTRP GPO to bypass split-tunneling.
Change the Query Resolution settings. Enable "Configure query resolution options". Enable Resolve both IPv4 and IPv6 addresses for names.
Create rules that forward Lync FQDNs to external DNS servers.

a. To which part of the namespace does this rule apply? Choose FQDN.
b. Click on the Generic DNS Server tab.
c. Toggle the Enable DNS settings check box
d. Click the Add button
e. DNS server: Enter an external recursive DNS server; or the authoritative public (i.e., Internet facing) DNS server for your organization's sip-domain.
f. Click Apply.

GPOs are applied to AD domains, sites, or Organizational Units (OUs). In most situations, it makes sense to apply the NRPT GPO to the AD site that correlates with the branch office.

From Group Policy Management: Right click on Sites → Left click on Show Sites → Right click on the branch office site → Link an Existing GPO.

Alternately, create separate computer OUs per location. Link the NRPT GPO OU that nests all branch office computers.

Windows Firewall:

NRPT influences clients to logically bypass the VPN. However, there may be circumstances when Lync clients discover alternate (i.e., split-tunnel) paths to internal resources. Lync clients, therefore, require both logical and physical divisions. Windows Firewall compliments the NRPT GPO with two simple rules:

Restrict traffic based on application (i.e., S4B).
Restrict traffic based on source (i.e., DCA) and destination (i.e., JFK).

Create the Windows Firewall GPO:

Create new GPO: Computer Configuration → Policies → Windows Settings → Security Settings → Windows Firewall with Advanced Security → Inbound Rules.
Right click on Inbound Rules → New Inbound Rule → Program → Path: %ProgramFiles%\Microsoft Office\Office15\lync.exe → Block the Connection → Apply rule to Domain. N.B, Use applicable application paths. For example, Lync Basic and Lync Professional may use different paths.
Edit the new Inbound Rule: Right click on the new rule → Click on the Scope tab → Add all internal IP subnets (i.e., primary office) to the Remote IP address field → Click Add → Click OK.

Figure 5. Windows Firewall GPO to bypass VPN.
Apply the newly created Firewall GPO to apply the AD site that correlates with the branch office. Alternately, apply this GPO to OU that nests branch office computers.

Conclusion:

NRTP and firewall GPOs force S4B-Lync clients to bypass split-tunnel VPNs. These combined GPOs have two primary effects: (a) DCA-to-external clients prefer STUN (i.e., client-to-client); and (b) DCA-to-JFK clients use TURN (i.e., client-to-Access Edge) for external AV communication (Table 3).

Table 3. Effects of Split-Tunnel GPOs on Multimedia Traffic
Source	Destination
	JFK	DCA	External Client
JFK	STUN	TURN	TURN
DCA	TURN	STUN	STUN
External Client	TURN	STUN	STUN
Notes: DCA uses split-tunnel VPN to connect to JKF. Stun represents Lync client-to-client. TURN represents multimedia proxy (i.e., Lync Access-Edge) requirement. Blue emphasizes branch office traffic. That's It!

Fix for Windows VPN Certificate Authentication Vulnerability

Problem:

Windows Server 2016 VPN server has left the front door wide open for attackers –by default! It authenticates ANY client certificate issued by ANY public CA. This problem occurs when the client certificate trust chain matches a certificate in the server’s trusted root store. For example, an attacker can authenticate with any DigiCert certificate (Figure 1).

How vulnerable are these servers? I'm willing to wager that my twelve-year old son can hack it in under five minutes. This is a pants-on-fire security hole that needs to be fixed before the server hits production.

Figure 1. Win IKEv2 authenticates with ALL root CAs. Yikes!

N.B., Take additional precautions to secure your VPN: http://www.stevenjordan.net/2016/09/harden-rras-ikev2.html.

Solution:

There are two ways to fix this serious IKEv2 flaw:

Remove public CAs from the Trusted Root certificate store.
Use PowerShell so RRAS only authenticates certificates issued from our private CA.

Certificate Store Solution:

Use Windows CA or OpenSSL CA servers, etc. DO NOT use a public CA. Remove ALL public CAs from the server’s trusted root store. Turn off automatic certificate updates. Implement additional authentication safeguards.

Step 1: Only use private certificates (e.g., Windows CA) –do not use public CAs.

We won’t cover the entirety of installing a CA in this article. However, it’s important to understand that the private CA root certificate resides in the Trusted Root certificate store –on both servers and clients.

Step 2: Edit Trusted Root Store:

Start → Type MMC → File → Add → Certificates → Local Computer → OK.

Backup your system.
• Exporting root certificates before you delete them –just to be safe.
• Take a system checkpoint if applicable.
Certificates to keep:

• Microsoft Root Authority 12/31/2020 -required

• Thawte Timestamping CA 12/31/2020 -required

• Microsoft Root Certificate Authority 5/9/2021 -required

• Private Root CA

Delete all other certificates in the Trusted Root Store.

Step 3: Create new GPO that prevents certificate updates.

Edit GPO:

→ Computer Configuration

→ Policies

→ Administrative Templates

→ System

→ Internet Communication Management

→Internet Communication Settings

→ Turn Off Automatic Root Certificate Updates: Enabled.

PS Solution:

Is there a better method? Until recently, there was no way to assign specific trust chains for IKEv2 client authentication. The system was simply all or nothing.

Thankfully, Microsoft now provides a solution that fixes this authentication vulnerability. We can finally configure specific root certificates for authentication purposes. N.B., This solutions assumes we’re using a private CA for authentication. Also not, that Microsoft documentation states that this method is only for site-to-site (S2S) VPNs –not true!

Step 1: Confirm existing VPN authentication settings: Get-VPNAuthProtocol (Figure 2):

Figure 2. Confirm IKEv2 authentication with Get-VPNAuthProtocl.

The RootCertificateNameToAccept field should not be empty. If so, your sever trusts ANY client from ALL Public CAs in the Trusted Root store. Let’s fix this!

Step 2: Configure the VPN server so it only authenticates certificates issued from our private CA:

PS C:\Windows\system32> $cert1 = ( Get-ChildItem -Path cert:LocalMachine\root | Where-Object -FilterScript { $_.Subject-Like "*THWATE*" } )

PS C:\Windows\system32> Set-VpnAuthProtocol -RootCertificateNameToAccept $cert1 -PassThru

WARNING: Configuration parameters will be modified after the Remote Access service is restarted.

The above example uses a variable that assigns a root certificate (i.e., issuer) from our Trusted Root store. It requests a certificate that has “THWATE” in its subject. This is for demonstration purposes only. Do not use THWATE in your configuration.

Successful execution always provides output that specifies the associated root certificate (Figure 3):

Figure 3. Set-VPNAuthProtocol secures our VPN.

Please note, this script does not provide errors if the variable doesn't match a subject a certificate in the Trusted Root store. The Root Certificate field simply remains empty (e.g., Figure 2).

Step 3: Restart the RRAS service.

Additional Thoughts:

Consider additional PowerShell safeguards for certificate authentication:

Define the server certificate sent to clients:
Set-VpnAuthProtocol –CertificateAdvertised
Only accept certificates issued for client authentication:
Set-VpnAuthProtocol –CertificateEKUsToAccept 1.3.6.1.5.5.7.3.2

Consider implementing both certificate and EAP authentication. This may not be a good fit for all devices because of different types of clients. However, if every client is Windows 10 we may be better off with SSTP.

Alternately, S2S VPNs can serve as a work-around for this public CA free-for-all. We can assign specific client authentication certificates to individual S2S interfaces. The system works but it creates administrative overhead. I’ll write more about this in a future article.

Finally, it’s OK to implement both solutions: Remove all public CAs from the Trusted Root Store; and only authenticate clients from our private CA (i.e., PowerShell).

That’s It!

References:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/52bd49e9-8842-42e2-916a-cbb07eddae33/ikev2-machine-certificate-authentication?forum=winserverNIS

https://support.microsoft.com/en-us/kb/293781

https://social.technet.microsoft.com/Forums/windows/en-US/9c90c7bb-af4a-4668-8ce4-852ce734ae8e/turn-off-automatic-root-certificates-update?forum=winserverDS

Task:

How to transfer the TempDB.

Problem:

MS SQL ran slow on 6Gb/s SAS hard drive (HHD). Moved the user database (DB) to PCIe x4 (i.e., 31.52 Gb/s), MLC solid-state (SSD) storage -and it still runs slow!

Solution:

Does the TempDB run on the old HHD drive or the new MLC SSD? Consider how the TempDB can generate serious disk I/O. Transfer the TempDB to the high-speed SSD as well. N.B., this entire process gave new life to my old DPM2010 server.

Step 1: TSQL script to identify TempDB location:

Use master
GO

SELECT 
name AS [LogicalName]
,physical_name AS [Location]
,state_desc AS [Status]
FROM sys.master_files
WHERE database_id = DB_ID(N'tempdb');
GO

TSQL output:


tempdev C:\Program Files\Microsoft DPM\SQL\MSSQL10.MSDPM2010\MSSQL\DATA\tempdb.mdf
templog C:\Program Files\Microsoft DPM\SQL\MSSQL10.MSDPM2010\MSSQL\DATA\templog.ldf

Step 2: TSQL script to move TempDB to new location.


USE master;
GO

ALTER DATABASE tempdb 
MODIFY FILE (NAME = tempdev, FILENAME = 'X:\SQL\Data\tempdb.mdf');
GO

ALTER DATABASE tempdb 
MODIFY FILE (NAME = templog, FILENAME = 'X:\SQL\Data\templog.ldf');
GO

TSQL output:


The file "tempdev" has been modified in the system catalog. The new path will be used the next time the database is started.
The file "templog" has been modified in the system catalog. The new path will be used the next time the database is started.

Step 3: Restart SQL services

Step 4: Verify Change - See Step 1.

Conclusion:

SQL server runs quick with new storage. Disk queue lengths, for all disks, are a thing of the past. Individual results may vary based on load (duh).

That's It!

References:

http://dbadiaries.com/tempdb-best-practices
http://dbadiaries.com/sql-server-tempdb-whats-it-for
http://www.mytechmantra.com/LearnSQLServer/How-to-Move-TempDB-to-New-Drive-in-SQL-Server/

Problem:

Definition: Group Policy Slow Link Detection

Background:

Group Policy Slow Link Detection:

Solution:

References:

How to Assign Active Network Location with PowerShell.

Step 1: Identify networks and associated NICs.

Step 2. Change the NetworkCategory:

References:

Problem:

Solution:

Assumptions:

Example 1. Show forest FSMO roles (forest):

Example 2. Show domain FSMO roles (domain):

Example 3. Transfer single role to a domain controller.

Example 4. Transfer multiple roles.

Example 5: Transfer all roles with numbers:

References:

Problem:

Solution:

Background:

Enable NAT-T

Troubleshooting Issues

MTU

Take Away:

Problem:

Topology:

ICE Framework:

Split-Tunnel Problems:

Resolution:

Windows Firewall:

Conclusion:

Problem:

Background:

Solution:

PowerShell:

References:

Problem:

Certificate Store Solution:

PS Solution:

Additional Thoughts:

References:

Task:

Problem:

Solution:

Conclusion:

References:

My Instagram