Skip to main content

1E 23.11 (SaaS)

Ensuring Nomad is secure

An overview of Nomad security methods, and how to customize default Nomad security settings.

Nomad is a peer-to-peer technology that works by using HTTP/HTTPS or the native Windows OS File and Print Sharing services to share content among computers.

In this section we explain details of Nomad file sharing mechanisms and offer configuration advice related to your desired level of security. Additionally, we describe settings that will affect the sharing of deployment content, as well as settings related to storing user migration data when using Peer Backup Assistant - PBA.

Configuration Manager content security

Nomad does not replace existing Configuration Manager (CM) security, so any content distributed by CM, whether it involves Nomad or not, undergoes a hash checking process before it is actioned by the CM client. CM provides a hash of content using the SHA-256 algorithm. CM content on a Distribution Point (DP) has a hash value provided to the CM client through its deployment policy.

When the CM client has received all of its requested content, a hash value of all the content received is generated at the client. This value is compared to the one provided in the policy from the DP source. If a single byte of the content has changed during the transfer between the DP and the client these values will not match, and that content will be deemed to fail the hash check, this ensures that any content that fails the hash check is not executed.

Nomad security methods

This table summarizes security methods for Nomad operations, including both content deployment and user data migration.



Election Process

  • AES 256 is used when you enableFIPS compliant communication encryption during the Nomad agent install

  • FIPS compliance is disabled by default

  • When FIPS compliance is disabled, RC2 block encryption is used.

Nomad Share and NTFS Permissions

  • SMSNomadP2P&-Local Account Nomad known pwd (SMB Share-Read)

  • Authenticated Users-Domain Authenticated Account (SMB Share-Read)

  • SYSTEM-NTFS Write-Option to limit to Machine Account (SMB Share – Read).

HTTPS Peer copy (Optional)

  • Encryption - Microsoft Cryptographic Provider – 256 Bit Symmetric Key Cipher Data Encryption – AES256 Algorithm with 256 key length

Nomad Hash Check Process

  • Content Hashing Algorithm – SHA 256

ConfigMgr Hash Check Process

  • Content Hashing Algorithm – SHA 256

Nomad Peer Backup Assistant - PBA Poll and ind

  • Microsoft Cryptographic Provider – 256 Bit Symmetric Key Cipher Data Encryption – AES256 Algorithm with 256 key length

HTTPS Nomad PBA user data copy to and from PBA host

  • Encryption - Microsoft Cryptographic Provider – 256 Bit Symmetric Key Cipher Data Encryption – AES256 Algorithm with 256 key length

Nomad PBA USMT user data encryption

  • In Replace scenarios where a native Configuration Manager (CM) Computer Association (CA) is used, user data is encrypted using AES 256 with the randomly generated key securely stored in the CM database. This occurs before the data gets copied to the target PBA Host

  • For Refresh or Replace scenarios not using the native CA, AES 256 is used to encrypt user data, with the key being generated by Nomad, the key gets generated when the task sequence runs and is never stored remotely.

How Nomad manages content and secures user data

In this section, we’ll separate out the way Nomad manages content and the methods behind securing user data when using Nomad Peer Backup Assistant - PBA. These two approaches to securing data are the same in principle, but contain essential differences, that we'll highlight in the following sections.

Securing captured user data

In this section, we’ll describe how Nomad incorporates encryption into the remote storage of captured user data. When using Nomad PBA, it can be important that captured user data is stored encrypted prior to it being restored on to a target device and deleted from the former storage hosts. The following sections explain how this is implemented.

Configuration Manager computer associations

Configuration Manager (CM) supports encryption of captured user data, with the encryption key stored in the CM database. The key is retrieved using the management point server during capture and restore operations within a task sequence. To acquire the key, the requesting host must be authenticated using the CM client certificate. Nomad PBA supports use of this key, and when the task sequence runs, the downloaded key is stored in the task sequence environment.

When running under a full OS, the task sequence environment is secured by applying the Windows file system, share and logon security typically applied using Group Policy. When running in WinPE, the security environment is different.

Task sequence environment and WinPE

During the WinPE phase of the running task sequence, the local host is not a member of the domain, and an interactive logon is not possible. The only way a user can interact with a host is through a Windows command shell. For this to be possible, command shell access must be explicitly enabled during boot image creation in the Configuration Manager console.

Typically, command shell access is only enabled during task sequence development to facilitate troubleshooting. In a production environment, command shell access is usually turned off. Windows share access is not possible in WinPE.

When encryption is not required

In User State Migration Tool (USMT), encryption of captured user data must be enabled on the command line of the USMT scanstate.exe application. In some circumstances you may prefer not to encrypt captured data, and instead maximize ready access to the stored data when performing the restore. In this case the unencrypted data is secured only through the NTFS and share permissions implemented in Nomad PBA.

For some instances of OS deployment, securing captured user data is not even required. In an OS Refresh, USMT makes use of Windows file-system hard-links. In this scenario, user data is never stored off the local disk and Nomad PBA or an SMP is not required.

Transferring content and user data between peers

This section discusses how you can implement to help content and user data transfer between peers.

Nomad election and PBA traffic

Nomad election and PBA traffic is communicated over port 1779 by default (You can configure this if needed). It is also encrypted with the Microsoft Base Cryptographic Provider using the AES 256 encryption algorithm with a 256-bit key length.

Transferring content using SMSNomadP2P&

You can transfer content between peers using either the local computer account or the local account, SMSNomadP2P&. The Nomad agent is responsible for managing the password when using the SMSNomadP2P& local account, with the password synchronized between peers. To ensure a secure password, a new password gets regenerated on every Nomad agent service startup, when your computer reboots, Nomad resets the password.

The SMSNomadP2P& account password is complex and set to 14 characters long, and the account denied “Log on locally” security rights. This behavior cannot be changed as it's hard coded into the product. This feature is more secure than using Active Directory accounts because no one can know the password used, this password is different for each local SMSNomadP2P& account.

The 14 character password for SMSNomadP2P& is calculated based on a public hash shared by the master during election and a private (secret) hash. At start-up, Nomad generates a new private hash and password. The private hash gets communicated using encrypted communications during an election, and peers work out the password by applying the same algorithm. If that password gets altered, no other device could connect to the NomadSHR or Cache folder without a way of communicating that password out to every system that would need to use it.


Please refer to The Nomad share for more details about Nomad share security, for more details about:

  • Enhanced Nomad share security

  • Nomad Branch service and the Nomad share

  • Custom share permissions.

Transferring user data

For Nomad PBA, we have an additional, unique local account created by Nomad that's used to transfer user data between source and target devices; user data gets stored in the NMDS share on the participating Nomad PBA host. A unique account gets generated each time user data gets stored on a remote host and takes the format NMDSUser<number> for example, NMDSUser0001. The local computer account cannot be used when transferring user data.

The password for the local account gets synchronized in the same way as the SMSNomadP2P& account. The PBA local account gets assigned full permissions and rights to the NMDS share and NTFS folder on the PBA host. No other accounts get assigned permissions. Nomad also creates the NMDSUsers local group, to which it adds the NMDS account(s).

Active Directory considerations

Both HTTP/HTTPS and Windows File and Print sharing requires authentication to ensure secure access to cache content or user data that's shared or accessed. In an Active Directory Domain, Group Policy refers to this as network login rights. The Local Computer Security Policy must be modified, assigning the local account SMSNomadP2P& to the setting Computer Configuration→Policies→Windows Settings→Security Settings→Local Policies→User Rights Assignment→Access this computer from the network. For Nomad PBA, customers must assign the above rights to the NMDS_Users local group.

If Active Directory Group Policy enforcement is in place, ensure that the SMSNomadP2P& local computer account has access granted to the Access this computer from the network settings at the Active Directory Group Policy level.

The File and Print Server service is not available in WinPE and therefore the Nomad share will not exist. For this reason, the Nomad agent in WinPE will only be capable to copy content from a Nomad master running in the full OS and is not able to act as a master itself. The process of accessing and copying content from the remote cache is the same in WinPE as in the full OS and is done using a local SMSNomadP2P& account. Using the local computer account to connect to the remote share is not supported.


Nomad PBA does not support off-line (WinPE) user data capture and restore.

Changing the default behaviors of the Nomad security model

So far, we have described the default behavior of Nomad. Organizations that have more strict security policies may wish to adjust the default behavior of Nomad. These options can be configured in the Windows Registry.

You can find these values in the following registry location:

  • For 32-bit systems - HKLM\Software\1E\NomadBranch

  • For 64-bit systems - HKLM\Software\Wow6432Node\1E\NomadBranch.

Using HTTP and HTTPS

Nomad 6.2 introduced Peer copy over HTTP or HTTPS. Configuring Nomad to use HTTP/HTTPS means that Nomad Peer BackUp Assistant (PBA) uses the transport to transfer USMT capture data between the capture/restore and PBA hosts.

By default, Nomad uses the SMB transport. Implementing HTTP/HTTPS requires additional Windows Installer properties need to be specified when installing or upgrading the NomadBranch agent. For existing installations of the agent, the registry will need to be updated, in order for Nomad to use HTTP or HTTPS.

The principal registry setting used to configure Nomad is P2PEnabled. By configuring this setting, the agent can be configured to use either SMB, HTTP or HTTPS and, if required, fall back to using a different transport. The values for selecting the transports are:

Registry setting


P2PEnabled = 0x0001

P2P enabled. This option is set by default and enables Nomad P2P using SMB. When set, the Nomad agent will create the NomadSHR file share started, unless the CustomShare option has been enabled in SpecialNetShare. When P2PEnabled is set in addition to Bit 5 (use HTTP) or Bit 6 (use HTTPS), Nomad will attempt to use HTTPS/HTTP and will fall back to SMB if HTTPS/HTTP is unavailable on other peers. To disable SMB P2P, set this bit to 0.

P2PEnabled = 0x0020

Use the HTTP protocol to share its own cache and access other caches.

P2PEnabled = 0x0040

Use the HTTPS protocol to share its own cache and access other caches.

Other registry values are used to set the HTTP/HTTPS ports and configure the use of HTTPS and PKI, for example:


P2PSSLSettings indicates that Nomad should use a PKI or self-signed certificate. If using a PKI certificate, then you must specify Certissuer and CertSubject.

Using file and print sharing

You can use the SpecialNetShare registry value to configure security options. SpecialNetShare can be a combination of multiple options by combining the bit values. You can find a complete list of options for this registry key in SpecialNetShare. If you change the default settings, ensure you apply the same setting consistently on all Nomad Clients.

What if Windows file and print sharing and HTTP/HTTPS are disabled?

If the File and Print sharing is unavailable, we recommended you configure Nomad to use HTTP or HTTPS, which are also supported when you use Nomad in WinPE.

If Windows File and Print Sharing and HTTP/HTTPS is not allowed on the local host due to security restrictions, then the Nomad is still able to copy content using the SMB protocol from a peer who happens to have Windows File and Print Sharing enabled. However, the local host will not be able to act as a master and serve content to other peers. This is the case in WinPE, where Windows File and Print Sharing is unavailable. Nomad clients running in WinPE are still able to access remote peer cached running under the full OS using SMB.

In any set ConfigMgr task sequence, to use Nomad in Windows PE, in theInstall Nomad task sequence step configure P2PEnabled=0x0007. This is the combined value of having P2P enabled and allowing the device to act as a P2P server and client if you wish the WinPE Nomad agent to act as a master.


Normally, you would not want a WinPE Nomad client to act as a master as this state tends to be transitory with several reboots occurring.

Configuration table

The following table summarizes the configurations discussed on this page.

Device state

Default Configuration


Device account Security

(Not applicable to Nomad PBA)

Connection-less (UDP)

(Not applicable to Nomad PBA)









Unknown; auto-generated by Nomad during service restart. For PBA automatically generated during PBA.

Nomad Share permissions:

Uses defaults, for example Authenticated Users, SMSNomadP2P&

NMDS share and folder permissions

NMDS_User<nnnn> Full access

Client (Peer) Authentication:








Unknown; auto-generated by Nomad during service restart. For PBA automatically generated during PBA.

Server (Master) Authentication:

Certification based authentication, either PKI or Nomad Self-signed certificate used.




Unknown; auto-generated; managed by AD

Nomad Share permissions:

Uses defaults, for example Authenticated Users

Group Policy:

Add Domain Computers

P2PEnabled = 0x0007

0x0001 (P2P enabled)

0x0002 (P2P server)

0x0004 (P2P client)

Windows PE

(Not applicable to Nomad PBA)




Manually created and managed by ConfigMgr admins




Manually created and managed by ConfigMgr admins

P2PEnabled = 0x0005

0x0001 (P2P enabled)

0x0004 (P2P client)