ads

Style6

Style3[OneLeft]

Style3[OneRight]

Style4

Style5[ImagesOnly]

Style2

Fix Win NAT-T for L2TP and IKEv2

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.

  1.   Edit Registry or create GPO:

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

  1.   Create new DWORD value:   AssumeUDPEncapsulationContextOnSendRule

  1.   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 Clients on Split-Tunnel VPNs.

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:
  1. Forward all domain name requests for Lync services to external DNS servers.
  2. 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:
  1. Create new GPO:  Computer Configuration → Policies → Windows Settings → Name Resolution Policy.

  2. Configure the Advanced Global Policy Settings: 

    Figure 4.  NTRP GPO to bypass split-tunneling.

  3. Change the Query Resolution settings.  Enable "Configure query resolution options".  Enable Resolve both IPv4 and IPv6 addresses for names.

  4. 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:
  1. Create new GPO:  Computer Configuration → Policies → Windows Settings → Security Settings → Windows Firewall with Advanced Security → Inbound Rules.
  2. 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.
  3. 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.

  4.  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!

Windows IKEv2 MTU


Problem:

How to set MTU on Windows Servers.  Windows Server 2012 VPN fragments packets after it applies encryption!  This issue causes latency and causes the VPN to disconnect clients -no good!

Background:

The default packet size is 1500.  Now consider how IPsec encryption adds a number of bytes to the original packet.  This process leads to post-fragmentation conditions.  In other words, packets are fragmented after encryption.  This condition degrades or disrupts VPN performance. 

Solution:

Adjust maximum segment size (MSS) on the outside interface so packet size is less that the default 1500 MTU.

Packet fragmenting occurs when a packet is larger than its default MTU.  TCP fragments the original data and sends it avoid encrypted packet.  According to Cisco, ESP overhead adds a maximum of 73 Bytes to each packet.  Therefore, we can adjust the MSS to a conservative 1400.

PowerShell:


Step 1:  Identify external interface.


PS C:\Users\administrator.SHORELAND_NT> netsh int ipv4 sh int

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 29          30     Default  connected     RAS (Dial In) Interface
 12           5        1500  connected     Inside
 14           5        1500  connected     Outside

Step 2.  Modify external interface MSS.

PS C:\Users\administrator.SHORELAND_NT> netsh int ipv4 set subint "Outside" mtu=1350 store=persistent


Step 3.  Confirm MSS:
PS C:\Users\administrator.SHORELAND_NT> netsh int ipv4 sh int

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 29          30     Default  connected     RAS (Dial In) Interface
 12           5        1500  connected     Inside


 14           5        1400  connected     Outside

That's It!

References:



Door Wide Open on Win IKEv2


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

Transfer SQL TempDB

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/

Harden RRAS IKEv2

How To:  

Harden Windows Server 2012R2 Routing and Remote Access (RRAS) VPN server.  Implement strong IKEv2 VPN cryptography:
• Diffe-Hellman Group (DH) 14 or DH Group 19
• Enable AES256 and SHA256 L2TP/IPsec and IKEv2 on Windows Server VPNs.

This simple method significantly improves security strength for Windows 2012 IPsec VPNs.

Problem:  

Windows RRAS server negotiates insecure IKEv2 and L2TP/IPsec cryptographic algorithms:

  • DH2-3DES-SHA1.   
Weak security strength risks data integrity and confidentiality.  IKE SA authenticates with RSA certificates.

This problem impacts all RRAS VPN clients:  Windows 10 phones, iPhones, Android, Cisco, Juniper and Sawn.  

Solution:  

Enable strong IPsec security algorithms in the Windows server registry:

  • IKEv2 DH14-AES256-SHA256

This (mostly) original approach is hands-down the easiest way to secure a Windows 2012 IKEv2 or L2TP/IPsec VPN.

Step 1:  Regedit:

HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\

Step 2:  Create new key:

\IKEv2CustomPolicy\

Step 3:  Create new DWORDs (Table 1):



Table 1
IKEv2CustomPolicy DWORD Attributes

IntegrityMethod1Integrity check algorithm to be negotiated during MM SA negotiation [RFC4306].
INTEGRITY_SHA1 (0x1)
INTEGRITY_SHA_256 (0x2)
EncryptionMethod4Encryption algorithm to be negotiated during MM SA negotiation [RFC4306].
CIPHER_AES_128 (0x2)
CIPHER_AES_256 (0x4)
CipherTransformConstant5Encryption algorithm to be negotiated during QM SA negotiation [RFC4306].
(0x3) CIPHER_CONFIG_CBC_AES_128
(0x5) CIPHER_CONFIG_CBC_AES_256
AuthTransformConstant1Specifies the hash algorithm to be negotiated during QM SA negotiation [RFC4306].
AUTH_CONFIG_HMAC_SHA_1_96 (0x1)
HMAC secret key authentication algorithm. SHA-1 (Secure Hash Algorithm) data integrity and data origin authentication algorithm. [RFC2404].
AUTH_CONFIG_HMAC_SHA_256_128 (0x2).
HMAC secret key authentication algorithm. SHA-256 data integrity and data origin authentication algorithm.
DHGroup3Type of Diffie-Hellman group used for Internet Key Exchange (IKE) key generation during MM SA negotiation [RFC4306].
DH_GROUP_2 (0x2)
DH_GROUP_14 (0x3)
DH_GROUP_2048 (0x3) - IKE for DH-14. Name change to match standard terminology
PfsGroup0Diffie-Hellman algorithm to be used for Quick Mode Perfect Forward Secrecy (PFS) [RFC4306].
PFS_NONE (0x0)
PFS_2 (0x2)
PFS_2048 (i.e., DH-14) (0x3)
PFS_MM (0x6) - Uses same DH as MM that contains this QM.
Note: DWORD values for IKEv2 Custom Policy Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IKEV2\IKEv2CustomPolicy\
This method also supports stronger security (e.g., DH-EC and GCM).  See MSDN MS-RRASM for additional options.

Additional Thoughts:

Client Requirements:

VPN clients must support the same cryptography in order to connect.  Consider how Windows clients use DH2-3DES-SHA1 by default (yikes).  I'll provide instructions on how to update Windows 10, iPhones, and Android IPsec clients in an upcoming article.

PowerShell:

PowerShell can implement stronger IKEv2 secuirty targets for both Windows 8.1 and 2012R2:

New-NetIPsecMainModeCryptoProposal -Encryption AES256127 -Hash SHA256 -KeyExchange DH19
Be warned, the process is challenging.  If you go this route don't test it out on production servers.  Also, the TechNet examples create new GPO policy specific to IKEv2.  It does not account for all the other firewall rules.  In other words, it creates a new firewall policy that only permits IKEv2 traffic -it's easy to get locked out without console access.  

The trick is to copy ALL firewalls rules and IPsec rules, crypto-sets, and IPsec rules (and anything else I haven't thought of) to the new GPO -all through PowerShell.  Alternately, use the GUI to copy the existing firewall settings to a separate firewall policy (i.e., separate from the PowerShell IKEv2 GPO).  Do not use the GPO GUI to edit the IKEv2 (i.e., PowerShell) firewall or you risk corrupting it.   You can then apply both GPOs to the VPN server.     

Also, we may be able to accomplish the same thing by saving the object to the local policy store.  Don't take my word on this because I haven't tried it yet.  So yeah, this is a bit more work but the benefits should provide solid security and greater interoperability.   

If anyone completes this script before I get around to it please forward me your work!  Either way, I'm sure it will be good material for another blog article.

That's it!  

References:

https://msdn.microsoft.com/en-us/library/hh536658.aspx
https://technet.microsoft.com/en-us/library/jj573824(v=wps.630).aspx
https://technet.microsoft.com/en-us/library/jj554897(v=wps.630).aspx


Change Office Default Save Location

Problem:

Office sets OneDrive as the default location during its installation.  This default location causes trouble for users who prefer to save to their local or network directories.  Word or Excel may prompt users for multiple authentication requests before they can save locally.

Solution:

Change the default save location.
  1. Open any Microsoft Office 2016 program.
  2. Click on the File menu item.
  3. Click on Options.
  4.  Click on the Save tab located on the left menu.
  5. Toggle the check box field that reads “Save to computer by default”.  Click OK.


That's it!



Windows Cannot find the Microsoft Software License Terms

Repair Windows installation licensing errors.

Problem:

   Windows 2012R2 license error reads, "Windows cannot find the Microsoft Software License Terms. Make sure the installation sources are valid and restart the installation".

Background:

  This error occurs after selecting the "operating system you want to install" in the Windows Setup wizard. This error occurs on VMWare, VirtualBox, or Hyper-V virtual machines (VMs). 

Solution:

   This licencing terms error occurs if there is not enough memory allocated to the virtual machine. Increase the VM's start-up memory in the VM settings to resolve.


NLA Default Location

How to set the default location for NLA.

Problem: 

 Users do not have Internet access after connecting to wireless networks. Network Location Awareness (NLA) appears to hang on identifying network.

Additionally, defining the default location is important because it directly impacts firewall rules. It’s not prudent policy to open client ports on an untrusted hotspot.

 Solution: 

 Use Group Policy to pre-define the default network location for unidentified AND identifying networks.
GPO: Computer Configuration → Policies →Windows Settings → Security Settings →Network List Manager Policies → (a) Unidentified Networks and (b) Identifying Networks.


Network Name:  

Choose either the Private or Public network: 



  • Outbound:  Most outbound traffic permitted.
  • Inbound:  Unsolicited SMB (e.g., file and print sharing). 



  • Outbound:  Most outbound traffic permitted.  No SMB traffic permitted.
  • Inbound:  No unsolicited traffic permitted.
N.B., Err on the side of caution.  Consider, do we really want unidentified networks to permit unsolicited traffic?  The Private network location invites common SMB replay attacks that steal credentials.  Further adjust client firewall rules to align with your organization’s security policies.

That’s It!

How to Disable RTF in Office

Problem:

Microsoft Office is vulnerable to memory corruption vulnerabilities.  Malicious emails, sent in rich text format (RTF), can provide attackers remote code execution (RCE).  In other words, RTF emails are not safe!

Versions:  

Common vulnerability and exposure (CVE) CVE-2016-0127 impacts Office 2007, Office 2010, and Office 2013.

Solution:  

  1. Run Windows Updates on a regular basis.    
  2. Enable Microsoft Office File Block Policy to block RTF documents.

Disable RTF in Office 2007:  

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Word\Security\FileOpenBlock] 

  • RtfFiles DWORDvalue: 1

Disable RTF in Office 2010:  

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Word\Security\FileBlock]
  • RtfFiles DWORD: 2
  • OpenInProtectedView DWORD:  0

Disable RTF in Office 2013: 

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Word\Security\FileBlock]
  • RtfFiles DWORD: 2
  • OpenInProtectedView DWORD:  0
That's It!

References:




RemoteApp Configuration for Thin PC


Problem:  How to auto-config RemoteApp webfeed on Thin PC.

Solution:  Push the RemoteApp webfeed URL via GPO registry
  1. Launch Registry Editor with regedit.
  2. Locate the following hive:  HKEY_LOCAL_MACHINE -> SOFTWARE -> Microsoft
  3. Create a new key in the above hive:  Name the key:  Workspaces.
  4. Create a new key in the newly created Workspaces hive.  Name the key:  ResourceType.
  5. Restart.
That's It!


Convert VMDK to VHD




Problem:  

Import VMWare virtual machine (VM) into Hyper-V hypervisor.  Convert VMDK virtual disk into VHDX disk.

Solution:  

Use Microsoft Virtual Machine Converter (MVMC) 3.1 to import and convert the VMWare ESXi VM into Hyper-V.

Background:   

The MVMC GUI provides a simple import wizard.  Please note, the GUI only imports VMWare hypervisors (including ESXi) connected to VMSphere.  MVMC PowerShell commands can convert stand-alone ESX and ESXi VMs.

Convert:

  1. Download MVMC.  The Microsoft download sites lists MVMC as 3.0.  N.B., the file installs version 3.1.
  2. Install MVMC on Hyper-V host.
  3. Uninstall VMTools from VMDK VM.
  4. Copy VMDK to Hyper-V host.
  5. Open PowerShell.  Import MVMC PowerShell library.

    Import-Module "C:\Program Files\Microsoft Virtual Machine Converter\MvmcCmdlet.psd1"
  6. Use PowerShell to convert VMDK to VHD.  N.B., Do not use VMDK_Flat file!

    PS D:\TMP> ConvertTo-MvmcVirtualHardDisk -SourceLiteralPath "D:\VMS\DEV.vmdk" -DestinationLiteralPath "S:\VMS" -VhdType DynamicHardDisk
  7. Create new VM in Hyper-V.  Add newly created (i.e., system) disk to IDE adapter.  Additional disks can use the SCSI adapter.  This is the time to configure dynamic memory or add additional CPUs.
    N.B., Do not resize the disk until after the VM starts at least once in Hyper-V!
  8. Start-up VM.  Install Hyper-V tools.  Restart.
  9. Optional:  New NIC "hardware" causes problems with retaining preexisting static IPs.  Resolve problem by deleting the network adapter and restating.  Windows creates a new network adapter upon start-up.  Manually add IP addresses into new adapter.
That's It!

Manage Local Computer Administrators with GPO restricted groups

Summary:  

Create separate user account or security group to manage domain computers.  This account cannot have domain admin privileges.


Problem:  

System Administrators log onto workstations and general purpose servers with their domain admin account.  Casual use of domain administrator accounts put the entire organization at risk of compromise from malware, keyloggers, and hash attacks.

Goal:  

Primary goal prevents network administrators from using domain admin accounts for purposes other than Active Directory tasks.  Secondary goal provides a general purpose administrative access for support staff and management.   

Solution:  

Implement GPO restricted groups provide administrator (i.e., non-domain admin) to manage computers. Steps:

  1. Create new security group in AD.  This group will be used to manage computers.  Add domain users to this group as needed.
     
  2. Create Restricted Group GPO.

    Computer Configuration\Policies \Windows Settings\Security Settings\Restricted Groups\

  3. Right click on Restricted Groups.  Left click on Add Group. 
  • Members of this group (i.e., domain group):  New AD security group created in Step 1.
  •  The Group is a member of (i.e., local group):  This is the local security group for each workstation (e.g., Administrators).
      4.  Assign new GPO to AD OU.  Wait for change to propagate.
  No more unnecessary use of domain admin accounts.  That's It!

References: 

https://support.microsoft.com/en-us/kb/279301
http://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx


Hide Windows Update Warnings on RDP /RDS Server

Problem: 

   Staff receive Windows Update message when logging onto the RDP server.  This problem confuses end users and causes unnecessary calls to help desk. 

Background: 

   Remote desktop servers receive regular updates on Patch Tuesday. However, this problem was accentuated after Microsoft changed their patching policy to expedite out-of-band patches. 

Solution: 

Create new GPO policy to hide Windows Update messages on the RDP server.
    GPO Setting Path:  
      User Configuration\Policies\Administrative Templates\Windows Components\Windows Update
    GPO Policy:   
      Remove access to use all Windows Update features 
    GPO Attribute:  
     Enabled: 0. Do not show notifications. 

Note:  

   This is a User Configuration setting -not a Computer Configuration.  Enable Loopback processing to ensure changes apply to all users that logon.  
    GPO Loopback Path:
      Computer Configuration\Policies\Administrative Templates\System/Group Policy\
    GPO Loopback Policy: 
     Configure user Group Policy loopback processing mode
    GPOLoopback Attribute:
     Enabled

   

Renewing Certificate on BranchCache Error

Problem:  Hosted Cache server's SSL certificate expired.  New certificate has a different thumbprint.  Error when linking the new certificate thumbprint to BranchCache server.

Error:  SSL Certificate add failed, Error: 183.  Cannot create a file when that file already exists.

Solution:  You cannot associate a new certificate to the BranchCache server until the old certificate information is deleted from HTTP.sys.  Use the following commands to correct the problem:

C:\Users\Administrator> netsh http delete sslcert ipport=0.0.0.0:443
SSL Certificate successfully deleted 


Link the new certificate after the old certificate is deleted from HTTP.sys:

netsh http add sslcert ipport=0.0.0.0:443 certhash=xxxxxxxxxxxxxxxx appid={d673f5ee-a714-454d-8de2-492e4c1bd8f8}

Fix: "The trust relationship between this workstation and the primary domain failed"

Error:  "The trust relationship between this workstation and the primary domain failed".  

Background:  Domain logon fails because the computer password is outdated.  The machine password updates every 30 days.  This problem occurs when adding a computer to the domain with the same name, or restoring a computer from backup (e.g., VM snapshot).

Solution:    First and foremost, ensure computers have a local Administrator account and password before this problem occurs!

  • Create a unique (i.e., new) administrator account and password for each computer.  
  • Document the information.
  • Disable the default local "administrator" account. 

Use the local administrator account to log onto the computer after the domain authentication fails.  One of the following steps will fix this issue:

Netdom:
netdom.exe resetpwd /s: /ud: /pd:*
= a domain controller in the joined domain
= DOMAIN\User format with rights to change the computer password

 Netdom is not available with every version of Windows.
  • Standard with Windows 2008 R2.
  • Standard with Vista.
  • Install Netdom on Windows 7 with the Remote Server Administration Tools (RSTAT).
  • Powershell replaces netdom,exe in Windows 2012 and Windows 8
PowerShell:
Reset-ComputerMachinePassword [-Credential ] [-Server ]

Note:  "-Server" represents the local domain controller.

GUI:

Alternately, Microsoft recommends removing the computer from the domain:

Control Panel > System > Computer Name > Change settings > Add computer to a workgroup > Restart > Repeat process and add computer to the domain.




References:

https://support.microsoft.com/en-us/kb/2771040
https://support.microsoft.com/en-us/kb/325850
https://technet.microsoft.com/en-us/library/hh849751.aspx


How to Fix Primary Domain Trust Failures

Error:  

The trust relationship between this workstation and the primary domain failed.

Problem:  

Domain computers use internal passwords to authenticate with Active Directory (AD).  Servers and workstations automatically reset their passwords every 30 days.  Suspended virtual machines or server backups may not logon domain users if the computer has a new password in AD.

Solution:   

Fix domain trust issues: (1) in AD, and (2) on the computer.

  1.    Reset the computer account in Active Directory Users and Computers (ADUC). 

    Open ADUC → Computers OU → Right-Click on the computer → Reset Accout

  2.  Reset the computer with PowerShell.  N.B., This step requires local Administrative rights.  We can't reset the computer, or even re-join the domain, with out the ability to log on locally.

    From PowerShell:  Reset-ComputerMachinePassword 
That's It!

References:  http://technet.microsoft.com/en-us/library/hh849751.aspx