1E 8.1 (on-premises)

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.

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.

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.

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.

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.

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).

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.