Skip to main content

1E 8.1 (on-premises)

The Nomad share

The Nomad cache is configured as a share that enables peer-to-peer distribution of downloaded content. Nomad provides control over the accounts that have access to the share and also provides an advanced Nomad FanOut mechanism that can overcome the connection limit to shares on workstations to ensure that content is distributed efficiently and securely.

Note

If Nomad is configured to use exclusively HTTP/HTTPS for peer copy, then the Nomad share is not created by the NomadBranch service.

For some example deployment scenarios and how you can monitor those deployments using the Nomad app refer to:

Enhanced Nomad share security

Nomad leverages native Windows security to define which accounts have access to the Nomad share. In Nomad’s default configuration, a Nomad share is created when the Nomad service is started and removed when it is stopped. The default Nomad settings also grants both Authenticated Users and the SMSNomadP2P& Nomad share account read-only access to the share.

In early versions of Nomad, further restricted access to the Nomad share could only be done using custom share permissions. The major disadvantage to this approach was that the Nomad service no longer managed the Nomad share, and it had to be created and managed through other methods. So, if you wanted to exclude Authenticated Users from the Nomad Share permissions, you must take over the management of the share.

In Nomad, a cache access security option has been implemented that is controlled using the AuthenticatedUsers registry value. This optionally restricts access to the Nomad share to just the SMSNomadP2P& Nomad share account, thereby excluding Authenticated Users from the Nomad share permissions but still leaves Nomad in control of the creation, management and removal of its share.

Nomad Branch service and the Nomad share

The Nomad share is created each time the Nomad Branch service starts and removed when it stops. When the Nomad Branch service starts:

  • A share called NomadSHR for the Nomad cache folder is created. The share is removed when the Nomad Branch service stops. If this share is created on a workstation, only 6 concurrent users can access it. If the share is created on a server, there is no limitation.

  • A local user account called SMSNomadP2P& is created with its password attribute set to Password Never Expires. This account is not removed when the Nomad Branch service stops. The password for this account is changed each time the Nomad service restarts and is made up of 14 characters using a combination of upper and lower case alpha-numeric characters. This account is not a domain user and does not have the logon locally privilege. Account details are requested by peer clients during the master election process.

  • If the AuthenticatedUsers registry value is configured to use the built-in security principal Authenticated Users, the NTFS permissions on the Nomad cache folder are updated so that Authenticated Users is granted Read and Execute, List folder contents and Read permissions for the folder, its subfolder and files. These NTFS permissions are not removed when the Nomad Branch service stops.

Share Permissions for NomadSHR is configured as Read-only for the local SMSNomadP2P& user account and optionally a built-in security principal as specified by the AuthenticatedUsers registry value. The default is:

  • local user account SMSNomadP2P&

  • built-in security principal Authenticated Users.

The default location for the Nomad cache is C:\ProgramData\1E\NomadBranch. The MODULE.NOMAD.CACHEPATH installer property is also used to configure the location of the Nomad Cache, which is stored in the registry value LocalCachePath.

You can use the MODULE.NOMAD.SPECIALNETSHARE installer property or update the SpecialNetShare registry value so that Nomad hides the Nomad share. If you do this, the share will be renamed NomadSHR$ and you will need to update all Nomad installations to use the hidden share.

Nomad can also be configured to use the machine account for peer connections instead of the local SMSNomadP2P& account by using the MODULE.NOMAD.SPECIALNETSHARE installer property or by updating the SpecialNetShare registry value. If the machine account is used, the local SMSNomadP2P& account is not created. Machine$ accounts in trusted domains are considered as Authenticated Users – the AuthenticatedUsers registry value must include Authenticated Users. Peer clients must be in trusted domains.

Use the MODULE.NOMAD.AUTHENTICATEDUSERS installer property or update the AuthenticatedUsers registry value to configure read-only access to the Nomad share for Authenticated Users (default), Everyone or neither in addition to the Nomad Share Account (SMSNomadP2P&). If Authenticated Users is selected, additional NTFS permissions are also configured for Authenticated Users on the Nomad cache folder.

The difference between Authenticated Users and Everyone depends on the OS version but in general Everyone includes Authenticated Users plus Guest.

Note

Domain controllers

When Nomad is installed on a domain controller (DC), it does not create the SMSNomadP2P& account and does not create the Nomad share. This is because it is not possible to create a local account on a DC. Nomad will not respond to elections and cannot be elected as a master.

  • If software is targeted at a DC, Nomad downloads the content from the distribution point (DP)

  • If the DC is also a DP, Nomad continues to process LsZ files and respond to Nomad clients as normal.

Custom share permissions

The SpecialNetShare registry values enables administrators to create their own share called NomadSHR, set the user limit and permissions. The Nomad cache is shared as NomadSHR, giving read access to the local Nomad share account and authenticated users. This enables new peer connections to be established and also allows access to the cache for computers with existing connections.

Share permissions can be configured on the share and requires the minimum read-only permission for

  • the local user account SMSNomadP2P& if not using the machine account

  • Built-in security principal Authenticated Users if using the machine account

NTFS security can also be set on the Nomad cache folder and requires these minimum permissions:

  • Built-in security principal SYSTEM requires Full control permission (because the Nomad Branch service uses the local system account)

  • Local group Users requires Read & execute, List folder contents and Read permissions

  • Local group Administrators requires Full control permission.

In addition, if using the built-in security principal Authenticated Users, as required when using the machine account, it requires NTFS security permissions Read & execute, List folder contents and Read.

In this section: