Service Account
When JobServer.NET is installed, it defaults to creating the service to run under the machine’s LocalSystem account. For machines that are installed as standalone servers, then this means that the JobServer will only be able to access any of the direct resources located on that machine such as locally attached disks and filesystems. The exceptions would be when using any modules where the module must be given credentials to access a remote resource, such as an FTP server for any of the FTP based modules.
For machines that are members of an Active Directory network, the default installation of the service running under the machine’s LocalSystem account means that the JobServer is restricted to direct access to resource on the installed machine only. To allow any of the modules in the job steps to access network resources, you would need to change the account that JobServer uses to allow and control access to the network resources. When reviewing access to domain network resources, we are specifically referring to endpoints such as UNC paths to a share and folder on a specific network machine, or to a DFS namespace roots and folders on the network.
The easiest method to opening up network resources to JobServer.NET and any of the configured job definitions is by changing the account that the JobServer.NET service uses to an account on the domain with administrator rights. This gives the service the most access to published network resources in a default installation. This may be fine for small installations and where the server(s) the JobServer.NET service is running on a secure machine. When we refer to a secure machine in this sense, it means a machine that has both good strong user credentials for your administrative (and all) accounts and logins. And in addition, also has good strong physical security in that nobody has any casual access to the machine.
((TODO: add screenshot showing the LogOn tab for the service properties for a JobServer installation))
Whenever possible, it is best to use a more fine-grained approach to securing critical machines on your network and when used with JobServer.NET. It is certainly more work to setup and configure but grants you the ability to precisely control the access that any of the installed modules on a JobServer installation has access to across your network. The following steps outline how to setup a single installation of JobServer.NET on one server in your Active Directory domain, but this can be scaled out to multiple servers as needed.
We will use the fictional name "MyDomain" as the name of your Active Directory domain in this example. Certainly, you want to substitute your own domain for this in the examples. We mention this since we will also use a few other example names that are used to illustrate the relationship between the various items, and you are certainly able to name them as you see fit for your network or naming conventions. The specific items this applies to is an account to create in the domain named JobServerService and a local group you create on each machine where JobServer is installed called JobServerServiceGroup. Now let us look at how we would configure this for a more constrained approach.
First you create the user account you want the JobServer.NET service to run under in your domain. Under your Active Directory Users add the new account we will creatively call JobServerService under your domain "MyDomain". At this point, if you already know what shares or other UNC paths you need to grant access permissions for the account, go ahead and add those to the account now. Thus, if you have a folder on your network where you will have modules sending and receiving files from an external FTP endpoint, you might have some sub-folders you use for various parts of the process, but the top-level folder containing them such as \\MyServer\Vendors\AcmeCo you would add Full Access permissions to account MyDomain\JobServerService to it for all the sub-folders to be accessible to the JobServer instance. Then you would repeat this for any other specific locations on your network where the JobServer will need to have file system access.
Now onto the steps to configuring the service to run under the domain account for your member server. The first part is to open Computer Management on the JobServer machine and under Local Users and Groups, you want to add a new group call JobServerServiceGroup. Once that is created, you can now add the network user MyDomain\JobServerService to this new group. After this is complete, you want to open the Local Security Policy app on the JobServer machine and under Local Policies, find and select the User Rights Assignment folder. When you have done this, you should now be able to locate and open the setting for Log on as a service. There will be entries here already, and we are not going to touch these. We just want to use the Add User or Group button to allow us to add the local group you created named JobServerServiceGroup here. These steps so far are just getting the account able to be used for running the service, now with that completed, we can move onto the next part.
The final part of configuring the machine to run JobServer.NET under the Active Directory domain account is to give it the necessary local permissions on the machine. There are two parts to this, the file system level permissions, and the network access permissions. First, you should already have JobServer installed on this machine. If you used the default options, it should use the following local paths on your boot volume. If you customized your installation, you would need to identify your customized paths to each of these. Locate the path for application data, which defaults to C:\ProgramData\XCENT and grant Full Permissions for this folder to the local JobServerServiceGroup. Next will be the path that the application is installed in, which defaults to C:\Program Files\XCENT and grant Full Permissions for this folder to the local JobServerServiceGroup.
With the local file system level permissions completed, now we just have to setup the network access permissions for the service. To do this, you will need to use the net shell (netsh.exe) command in an elevated command prompt. Of course, this is done by right clicking on the cmd.exe command line icon and selecting the Run As Administrator option from the pop-up menu. When the elevated command prompt opens, you will just need to enter the following command.
netsh http add urlacl url=https://*:7901/ user=JobServerServiceGroup
When you have completed these steps, you are now able to change the LogOn credentials for the service to the domain account and will be able to restart the JobServer.NET service under the new login with the more restrictive control. When you have successfully completed that, you will just need to remember in the future that as you add or change any job definitions, that if it involves changing or adding any references to Active Directory resources, you will just need to include adding or changing the permissions for the domain account also.
For additional details on configuration of Active Directory network accounts with JobServer, see the following article.