What is Capture-NET?

Capture-NET is a computer audit tool capable of running on domain and peer-to-peer networks. It is part of the CaptureIT suite of tools from Isynch-D. Capture-NET supports heterogeneous networks of all Microsoft operating systems including Windows 95/98/ME/XP/Vista. Windows 7 testing is underway.

It is recommended to be run from a domain client of your network, although it will also run on the Primary Domain Controller (and from within a peer-to-peer network). The internal data capture engine is based on Windows Management Instrumentation (WMI), an industry initiative that establishes hardware and software management standards and provides a way to combine information from various hardware and software management systems. Capture-NET works by sending data requests to the WMI services running all Microsoft OS equipped client machines, via the DCOM protocol. Click here for more info on WMI.

What are the advantages of using Capture-NET?

There are a large number number of software products aimed at auditing networks of computers, so why write another one? Indeed, why should you switch from an older system you may be quite happy with, to using something new like Capture-NET? Its a good question, and if you are genuinely happy with your older product, then the answer is simple: Don't. But what if you you are not happy? Many older auditing systems have woefully inadequate security, some don't audit all the machines on a network reliably and still more do not generate enough data. The CaptureIT tools were originally developed to address a range of gripes we had with a number of commercially available auditing systems. These systems all seem to work in one of two ways:

• Via Log in scripts
  In which the data capture is done by running an executable at Log in time on each client machine. This has the following disadvantages:
• Users must be logged in to perform a capture, If the user is on vacation, or just decides to Log in locally (thus not running his Log in script) then an audit is not possible. The end result is partial audits and unhappy customers.
• With a log in-driven capture there is no possibility of producing a genuine snapshot of network status on a particular day. Thus if you wish to generate time-based reports you cannot easily do so unless you are willing to wait for a time when all machines are in use.
• There is no realtime GUI running to handle capture errors, so all error handling must be done entirely by log files. Errors may only show up when attempting to generate reports, by which time the opportunity to perform a full audit (see point above) may have been lost.
• The are often machines which are very rarely logged in on at all - such as Domain Controllers, various dedicated servers. These cannot be audited via Log in scripts.
• Security - it sounds a little strange, but if you are using one of these systems, you had better have a lot of trust in the company providing it. The reason is simple - an executable that is running from a Log in script will run with exactly the same access privileges and file permissions as the Log on id. Thus the executable (if maliciously programmed) could very easily steal every scrap of data on the machine. This is the major downside to the Log on script method
• By installing a client server module onto the clients
  The application runs on one machine and all the other machines to be audited must have a small software module installed on them (not to get too technical, but these are actually small COM server modules and the main application is then running as a kind of global client). This is a better solution regarding realtime generation of reports, and error logging, but it still has some serious problems
• Scalability. What happens if you install the client onto 1000 machines and then want to upgrade your OS on those machines? That is a lot of work in addition to the headaches you already have when doing a major upgrade.
• Security - as with the log on script approach, if you are using an installed server exe system, you had better have a lot of trust in the company providing it. The reason is simple - an executable that is running as an installed service will run with at most the same access privileges and file permissions as the id of the person installing it - and if the server exe is installed by an Administrator (as is often the case) then it will have complete and unrestricted access to the entire computer. Thus the server (if maliciously programmed) could very easily steal every scrap of data on the machine.

Capture-NET handles all the above problems by simply sidestepping them. By using the existing services already present on Microsoft operating systems post Win 2000 it doesn't need to run anything at all directly on the client (this is slightly different on WinME and Win98 machines see "Win9X Issues" below). As long as the WMI service is running on the client then we can do a capture. Disconnected clients can also be audited (albeit by use of the standalone CaptureLite product) and the saved .cap file can then be merged with the network .cap file. When the time comes around to do an update on either your client or server machines then this is also a breeze, as WBEM is a major industry initiative and will be fully supported for decades to come. All future planned Microsoft OS releases contain full (and indeed extended) support for WMI and there there will be no need to update or even reinstall capture at upgrade time, thus CaptureIT provides instant upgradability right out of the box. The final (and probably the most important) reason for switching over to using CaptureIT is the security issues of both the Log in and client exe approaches. With CaptureIT you do not have to trust Isynch-D Co., Ltd. - all trust issues are handled by DCOM security measures. All data passing from the client to the application is sent from the WMI service running on the client, and that service has no access rights to any user files - in short Capture-NET can get all the install data, hardware configurations etc. but it cannot read a single user file on the client computers. If your users have sensitive data then there are absolutely no security issues to worry about - unlike every other rival product (other than Microsoft's own very large, unwieldy and extremely expensive System Management Server) we have seen.

Are there any disadvantages of this approach?

Capture-NET is intended to be run on Microsoft-based networks, and as such it is completely dependent upon correct configuration of your network. The vast majority of connection problems can be directly traced to bad configuration of your IP addresses and DNS servers, while most others can be laid at the door of permissions problems. When a computer is joined to a Win2K/WinXP network, by default it automatically adds the Domain Users group from the server to the local Administrators group on the client. This is reasonable and ensures that authenticated, authorized admins can administer the clients. Interfering with this will cause Capture NET to be unable to audit the client machine. In addition, if the client is running a personal firewall the user must elect to allow thru traffic from the Winmgmt service. Auditing is necessarily a security sensitive operation, and as such there are very high-level security concerns when accessing such sensitive network data. This is why Capture NET must be run as a user who is a member of the Domain Admin. group. Even so there is still absolutely no way that Capture-NET can get access to any private data files on the client machines, these remain protected by the built-in security measures already in DCOM.

Win9X Issues

When connecting to a Windows 98 or Window ME machine there are some trust issues to be aware of. Firstly, these machines will need to run a small Log in script to configure them for future access. The Log in scripts will run a small setup routine once per client, and then the machine can be interrogated thru the network at any time, whether the user is logged on or not. The Log in script just runs a tiny 20K setup routine that will:

• · On Win9X: update the current version of the WMI service to WMI 1.5 using a Microsoft supplied patch.
• · On WinME: configure the WMI service for remote access.

WinXP Service Pack 2

Service Pack 2 has its firewall enabled by default and it must be disabled if you are running in a mixed environment. If you have a pure XP2 environment, you must allow the WMI subsystem to communicate thru the firewall (see the requirements page for how to do this).