Choosing the best agent type
In most production environments and organizations in the past decade, there were numerous Microsoft Windows-based operating systems. In order to satisfy the multitude of requirements, there are two possible agent types when it comes to Windows agents. The most recommended agent is the service type. This stands for installing the agent as a standard Windows service. As such, it is executed on each startup like the other services.
Another possibility is opting for the standalone agent type. This solution is best fit for those scenarios where the client machine is not networked, and it is not supposed to contact and provide the central management server with the gathered inventory. It may rarely happen that due to some side company regulations, we are not allowed to install more services. The same situation applies to laptops that are in the field the majority of the time. In these cases, opting for this kind of agent is our only solution.
The standalone agent gathers and saves the inventory locally. The exported results can then be imported. Should we require an update to the database, we need to execute again the standalone agent on the said computer so that it refreshes the inventory, and then we'll head over to import again. This can also be scheduled and automated. We're going to discuss this in detail in a later chapter when we get into inventorying client hosts that are not networked.
In short, unless the host is not able to network or strict company policies are restricting the installation of new Windows service, we should always choose the first route.
Setting up the agent as a service has many benefits:
- Hosts are inventoried even when users are not logged in. Should the employee be on vacation, the machine is still inventoried on a predefined basis.
- Package deployment functionality is possible. It happens in the background, and it will not require user interaction. The employee can work seamlessly.
By default, the service is installed to be launched under the LocalSystem account.
Demystifying the LocalSystem account of Windows OS
Years ago, most system level services were run under the LocalSystem account. It was the only account that provided such privileges. It was the most powerful as well. Later on, Microsoft implemented two derivates of the almighty System account: LocalService and NetworkService. Depending on their needs, services are now run under either of these. The OCS-NG client agent has remained under the almighty LocalSystem account.
These accounts are all predefined local accounts. LocalSystem is the only account that can access the security database located at HKLM\Security inside the Windows registry. Other than these, it has unrestricted access to local resources. It has enough privileges to bring down a system to its knees (or worse), if the server is a harmful one.
LocalService and NetworkService are limited privileges accounts. The latter provides more security by protecting local resources, but it won't protect remote ones. Services logged in under the NetworkService account are authenticated using the computer's account within the domain. In this way, if they try to access remote shares, the policy that determines this eligibility is determined on the system that initiates the connection.
In case of LocalService accounts, the services are authenticated as no one—technically, it is a kind of anonymous connection. Should the same service running under LocalService want to access remote shares, the requests are only allowed if the shares are available to everyone. As you can see, the LocalService makes it tougher to take over remote clients.
Note
For more information regarding how to tighten down these security permissions, please refer to the following Microsoft documentation. It is a comprehensive guide on how services are working, how to strip their privileges from the token, and so on. Refer to the document titled Services and Service Accounts Security Planning Guide at:
As mentioned earlier, the OCS-NG agent is set under the powerful SYSTEM account. One side of the coin is that it won't struggle to gather the necessary inventory data and it gets its job done. However, if we are security conscious and we want to tighten down these permissions, we need to follow the previously mentioned Microsoft's planning guide.
In a robust environment, which is otherwise firewalled, protected, and monitored against miscellaneous behavior, the chances are really slim (close to none) that the OCS-NG agent will be exploited in order to access some unrestricted network resource. Thus, we do not consider this as a priority at all. It is just food for thought. It does not mean that leaving the service under that account will open a dangerous security hole.
The real deal is to know how to deal with SYSTEM accounts, like in the case of unknown services, things can get messy fast. That was the reason why we demystified them. In our case now, the OCS-NG agent is popular, and under no means has malicious attempts.
Another option is to create a special log on account for service, if used within a domain environment. Neither of these is the best option that universally applies to every kind of situation. Ultimately, it depends on the environment, and these are all options. We need to make the best use of each of these options, read that Microsoft guide on security planning regarding services and design the best approach. In the end, it's always up to us to tighten our security.