This post was originally published on 8 June 2016.
Last time over we looked at two distinct technical ways of extracting software invetory from Windows machines. In this article, we are covering one specific type of application deployment that is easily missed by the traditional invetory run.
Applications installed in different user context i.e. user installed applications
As a technical design point, most every inventory and systems management solution is designed so that there exists some kind of client or agent that need to be installed on every PC. This client piece then talks to some backend system, typically running in your own datacenter but these days could be some cloud-based service as well, such as Microsoft’s InTune.
Another popular methodology for performing scans would be the agentless method of accessing all the PCs through the local network from the server-side, but there are obvious shortcomings for this model; of which the security implications and requirements for access through network are not the smallest ones.
Yet another model would be to run some install-less executable on the computer startup or user logon from the network share, but this kind of discovery is typical for solutions purely interested of having infrequent snapshot of software as there’s no telling when the computer might be booted next time or user logging on.
Typically, however, there exists client that runs on a machine, as it might be tasked to do many other things besides just getting the software inventory: installing software, configuring the machine et cetera. The way these clients are implemented is so that they need to be running in system context, for the obvious reason of needing more access rights to the local PC than what regular user account could achieve. Especially if things above and beyond of just reading the data from the local device is required as mentioned above.
But regardless of if that local piece of code is running under true system account context or using some specially defined service account, the fact is that it’s NOT running in any of the logged on users’ session context (unless again it’s run on user logon in the same session, but that’s usually too limited in access-wise as the program then must rely on what rights any random user might have or not have).
While running software inventory in the generic system context of course gives the information of all of the products that has been installed for the machine (the majority, sure), there’s a category of applications that it typically won’t be seeing due to this separation of user contexts: applications that user has managed to install all by themselves, even without administrative rights.
That’s right: you may think that even if we think that we can control our software environment by not giving local administrative rights to the regular users (and especially within IT functions in a typical organisation, there are usually exceptions – known or unknown – to this policy as well) it is very much possible for users to install certain applications per user –basis! In fact, even the Windows Installer technology supports installations done on user context rather for the all users on the same machine (e.g. machine –based installation). Other, custom, installers may enable this same thing.
Google Chrome, Skype and other “consumer focused” applications do have the capability of installing to the user’s own profile directories, into which regular user of course has – and needs to have – full rights to create any files they see fit. This means, from the system scanning perspective, those applications simply do not exist as they are not recorded to the “global” list of applications on a given Windows PC. But, if looking from the viewpoint of that user’s session, they actually do show up on a list of applications!
This poses a problem for getting an accurate inventory of what’s actually installed on the PCs: from the central software inventory/systems management perspective, you would only see those products that has been installed for all users on a machine but there’s actually those hidden per user applications lurking in different machines that are not shown to the inventory tool and thus missing from the reports. Furthermore, depending on the user profile setup that the organization is using, it could be that these applications roam between machines if using traditional roaming profiles and users are actually using multiple machines.
From licensing perspective, as an example, this could be a problem if the application is not actually free to use in a corporate setting even though it might be for private individuals. Typical model is to license per machine, so roaming applications would actually need to be counted for all PCs they happen to land on based on where the user’s profile roams to. World IS however moving slowly into per user licensed model more and more, big thanks to SaaS and Application Store delivered applications, but this is still nowhere universal with many traditional software packages.
Variation of this same problem is if there are some applications that are not even installed (so scanning installed programs list from even the user session’s perspective) but rather just placed somewhere in the user’s profile directory as standalone executables.
If the software inventory methodology is actually using the “brute force” approach of scanning all the .exe files as discussed in the beginning, these rogue applications would be detected but even then it’s kind of hit-and-miss as the user profiles may come and go. At one point of time the application can be on the disk and gone on the next as the user logs out, and Windows is configured to delete local copy of the profile.
These kind of applications are a typical shortcoming of many of the software inventory solutions, and understandably so as they are designed primarily from the perspective of making sense of the machines, not the users. But, as we have seen and will be seeing, the deployed software scene is rather complex equation when taking the view of the whole and thus it is not really adequate at this day and age to leave these usage scenarios out. Normal people accessing the resources sure won’t be thinking these matters when faced with possibility of being able to just installing something without having to bother IT department for permissions or help to do so.
In the next installment of the series, we discuss virtualized applications, which pose their own issues from inventory purposes.
