Nomad has historically taken advantage of technologies that are already built into the underlying Windows operating system, such as the Microsoft Cryptographic Service Providers for encryption, and the Microsoft SMB Protocol for peer-to-peer sharing of content between local computers.This has allowed 1E to build upon tried and tested technologies, rather than duplicate these capabilities into proprietary code which would be subject to additional security penetration testing and be worrisome for some customers.
But some technologies age over time and are replaced with newer technologies. Such is the Microsoft SMBv1 Protocol, which Microsoft publicly deprecated back in 2014 due to its limited security strength. Even though Nomad has never utilized the SMBv1 protocol, 1E grabbed the opportunity with both hands and added support for other protocols, such as HTTP and HTTPS for peer-to-peer sharing. Again, 1E took advantage of the Microsoft WinInet library rather than introduce 3rd-party proprietary code that could expose customers’ environments to unknown vulnerabilities. This all ties in very well with our message of staying current (#StayCurrent) because customers usually find it easier to patch the operating system itself than 3rd-party applications. Indeed, as a key part of 1E’s Windows Servicing Suite, Nomad is already used by hundreds of customers to #StayCurrent – whether they’re in the midst of a migration or keeping up with the demanding Windows 10 servicing model
With Nomad’s support for peer-to-peer sharing over HTTP/HTTPS and also downloading content from the centralized Distribution Point(s) using HTTP/HTTPS, Nomad is not reliant on the Microsoft SMB Protocol at all, which was a subject of interest during the recent ransomware attacks (WannaCry and Petya) earlier this year.
Furthermore, when developing the Nomad integration with HTTPS, we took the opportunity to utilize your existing PKI certificate infrastructure (if available) – further enhancing the security of all Nomad communications.
How to configure Nomad Peer Copy over HTTP/HTTPS
Always review the latest information available at the online documentation here (may require registration)
For new installations of Nomad, you will need to configure the following Nomad settings:
- P2PENABLED – default value is 9, and this will require reconfiguration to support HTTP and/or HTTPS
- P2PHTTPPORT – default port is 5080
- P2PHTTPSPORT – default port is 5443
- P2PSSLSETTINGS – default value is 0 (use self-signed certificate)
If you want to enable Nomad Peer Copy over HTTP and/or HTTPS, then you’ll need to add Bit 5 (0x0020 hex / 32 decimal) to enable HTTP and/or Bit 6 (0x0040 hex / 64 decimal) to enable HTTPS. You can enable both settings so that Nomad will try HTTPS first and then fall back to HTTP.
So if you’re existing P2PENABLED value is 9 (decimal) and you want to disable SMB and enable both HTTP and HTTPS, then remove Bit 1 (0x0001 hex / 1 decimal) and add 32 (Bit 5) and 64 (Bit 6) to the existing value (9), which equates to 104 (decimal).
When you install the Nomad Agent, you will want to set P2PENABLED to 104. You can do this in a MST Transform (best-practise) or on the command-line (as shown below). Furthermore, take advantage of the 1E Endpoint Agent Installer Solution Accelerator which provides a wizard interface to setup & configure all 1E agents for new installations. You can download this tool from the 1E Support Portal.
Eg: msiexec.exe /i NomadBranch-x64.msi P2PENABLED=104 /qb!-
For existing implementations of Nomad, all you’ll need to do is make the same changes to P2PENABLED but make that change in the Windows registry of each client. There are many possible methods to do this, such as Group Policy Administrative Templates, or my preference Compliance Baseline Settings in ConfigMgr. 1E has introduced a new Settings Wizard which enables you to centrally control all Nomad client settings from the Compliance Baseline Settings in the ConfigMgr Console.
